5 general modding questions on 5 different topics

[Guest headscratcher]

Hi,

I have a few questions, maybe somebody would be willing to shed a light on those things for me.

1) Is more than 24 ability points to distribute on HLAs level-up screen between abilities possible?

I've tried to edit .2DA files to see if I can get more than 24 ability points to distribute among abilities on HLAs level-up screen (there is no highly intellectual reason for it other than that I just want to and want to know that [if] I can do it). No matter what I tried (editing luxx0 & lunumab both together and separately in every possible combination I could think of), nothing worked, and so I wanted to check in if it is at all possible and I just didn't do it right or if I'm banging my head against the wall for no reason. If it has been accomplished by someone / in some mod, could you please point me that way?

2) In .D/.DLG files, "DO" is a transition and from my many attempts I deduced that it is not possible without the first, main, block, as in, "SAY". I'd like for somebody to either confirm or correct this. I'm asking this in the context of wanting the file to begin with "DO" first, then the first "SAY".

3) What is the difference in practice between Wait() and SmallWait() in .BAF/.BCS files? I don't mean in the amount of actual seconds, more in the difference of their processing? Is SmallWait(15) and Wait(1) like, effectively the same thing? Links / practical examples or direction where to find them appreciated.

4) When updating the mod to EE / EET, is "EVALUATE_BUFFER" necessary? And if yes, then why.

5) When "fl#reload" (below) was an active piece of code, strings from 2 files got mixed in-game, "ccc" was a setup file and had more strings, "aaa" was a short dialogue and had less strings. For whatever reason, it ended up that overlapping string numbers were taken from dialogue file when they should be taken from setup file. Any idea why that would be?

I will also add that the order "dialogue otherfile setup" within array seemed to work better than "setup otherfile dialogue", but still not perfect

 

AUTO_TRA ~xxx/lang/%s~

ALWAYS	

			
    DEFINE_ACTION_FUNCTION autotra_workaround BEGIN
      COPY ~xxx/lang/English~  ~xxx/lang/autotra/%LANGUAGE%~
      COPY ~xxx/lang/%LANGUAGE%~  ~xxx/lang/autotra/%LANGUAGE%~
    END

    LAF autotra_workaround END


	ACTION_DEFINE_ARRAY fl#noconvert BEGIN END

// ACTION_DEFINE_ARRAY fl#reload BEGIN aaa bbb ccc END

    LAF HANDLE_CHARSETS
      INT_VAR
        infer_charsets = 1
      STR_VAR
        tra_path = EVAL ~xxx/lang/autotra~
        noconvert_array = fl#noconvert
//        reload_array = fl#reload
	END


	ACTION_IF (GAME_IS ~eet~) BEGIN
		OUTER_SET bg2_chapter = 12
	END ELSE BEGIN
		OUTER_SET bg2_chapter = 0
	END
	OUTER_FOR (i=1; i<=10; i=i+1) BEGIN
		OUTER_SET bg2_chapter = bg2_chapter + 1
		OUTER_SPRINT name_source ~bg2_chapter_%i%~
		OUTER_SET EVAL ~%name_source%~ = bg2_chapter
	END

	INCLUDE ~xxx/lib/gw_functions.tpa~

END

Sorry if it's all obvious, not obvious to me though. : P

[Jarno Mikkola]

1) Did you try installing EEex ? Or rather... https://github.com/mrfearless/EEexLoader/releases

4) The EVAL is the same command line than EVALUATE_BUFFER is... at least it was like that years ago...

[subtledoctor]

For #1 I’m pretty sure you need to edit the UI, not 2da tables, to go above 24. EEex may or may not also be needed. 

My recollection is that the UI only allows 24 HLAs to be in a table, period. So even if you have 24 or more points to spend at one level-up, you would not be able to select any more/different ones at future level-ups. (Unless they were repeatable HLAs, I guess.)

[Bubb]

The engine hardcodes the "24" limit as the size of an array that holds the available HLAs, and as the maximum number of points allowed at level up. Edit: The ability list is capped at 256 useful entries, it's the maximum number of selected abilities that is capped to 24 by a hardcoded array length.

You can't bypass it without engine hacks, and EEex doesn't help in this instance. (Getting around array-based limits is difficult, as you can't simply expand the array without encroaching on surrounding fields).

On 5/30/2023 at 12:46 PM, Jarno Mikkola said:

1) Did you try installing EEex ? Or rather... https://github.com/mrfearless/EEexLoader/releases

The correct repo is: https://github.com/Bubb13/EEex

Edited May 31, 2023 by Bubb
Correct mistake as noted by kjeron

[kjeron]

1 hour ago, Bubb said:

The engine hardcodes the "24" limit as the size of an array that holds the available HLAs, and as the maximum number of points allowed at level up.

Unless it changed from v2.3, the engine will still display up to 256 HLAs, you just cannot take more than 24 per level-up (and taking any more than once counts for each time).

[Bubb]

1 hour ago, kjeron said:

Unless it changed from v2.3, the engine will still display up to 256 HLAs, you just cannot take more than 24 per level-up (and taking any more than once counts for each time).

You're right. The actual ability list is unbounded, but the engine keeps track of which abilities have been chosen with an array of 24 bytes that index into the ability list. So you can only distribute up to 24 points per level up, and the useful size of the list is capped at 256 since indices greater than that wrap around.

[Guest headscratcher]

 Thanks for the replies and suggestions.

 

On 5/30/2023 at 9:46 PM, Jarno Mikkola said:

1) Did you try installing EEex ? Or rather... https://github.com/mrfearless/EEexLoader/releases

4) The EVAL is the same command line than EVALUATE_BUFFER is... at least it was like that years ago...

4) Is there somewhere where I can find an explanation of what exactly it does?

 

On 5/31/2023 at 8:09 PM, Bubb said:

You can't bypass it without engine hacks [...]

Truthfully, I'm not very coding savvy (yet), so I don't think I'm going to engine hack anything anytime soon. : P

 

If anyone is willing to look at the remaining 3 points I would appreciate it too.

[jastey]

On 5/29/2023 at 10:42 PM, Guest headscratcher said:

4) When updating the mod to EE / EET, is "EVALUATE_BUFFER" necessary? And if yes, then why.

The EVALUATE_BUFFER or EVAL for short is needed if you have variables inside the files that need evaluating. Variables in this case means definitions to cover diffrent filenames for different games. For example, in BG:EE the area of Coast Way is "AR2800". But in EET, it's "BG2800". That is why mods that cover BG1 part of several games (BG:EE/EET(BGT etc.) use the cpmvars.tpa definitions for these resources, and compile the mod files using EVALUATE_BUFFER. Using these, the area code would be called by "%CoastWay%" and the installer puts in the right definition. EDIT: This way, you can cover all BG1 games with one set of files, which is advantages for maintenance.

[jastey]

On 5/29/2023 at 10:42 PM, Guest headscratcher said:

2) In .D/.DLG files, "DO" is a transition and from my many attempts I deduced that it is not possible without the first, main, block, as in, "SAY". I'd like for somebody to either confirm or correct this. I'm asking this in the context of wanting the file to begin with "DO" first, then the first "SAY".

DO is part of the transaction. I don't see a way to start a dialogue state with a transaction - the state has to start first, which is done by the SAY containing the NPC line.

To be honest I don't get what you mean with starting with DO. If you want an action performed without the NPC saying something first, you need to do it via script.

[jastey]

On 5/29/2023 at 10:42 PM, Guest headscratcher said:

5) When "fl#reload" (below) was an active piece of code, strings from 2 files got mixed in-game, "ccc" was a setup file and had more strings, "aaa" was a short dialogue and had less strings. For whatever reason, it ended up that overlapping string numbers were taken from dialogue file when they should be taken from setup file. Any idea why that would be?

If you load several tra files at once, they can't use the same line numbers. Did "ccc" and "aaa" have lines with the same line numbers (@0, @1, etc)? Then the second tra you load will overwrite the first ones.

This is a concept that the mods make use of, actually. For example, it enables to load EE-specific item descriptions only for EE games simply by putting them into a game_ee.tra which gets loaded for EE games, overwriting the lines with item descriptions that are inside the (formerly loaded, for classic engine) game.tra, for example.

This is also the explanation of "tp2-lines get used in mod dialogues" bugs: if the aaa.tra / ccc.tra loaded at the beginning of the installation match the dialogue lines of a d-file where there is no matching tra-file, the installer will just take whatever matching @ number reference it already has, and use it without an error message.

[jastey]

On 5/29/2023 at 10:42 PM, Guest headscratcher said:

DEFINE_ACTION_FUNCTION autotra_workaround BEGIN
      COPY ~xxx/lang/English~  ~xxx/lang/autotra/%LANGUAGE%~
      COPY ~xxx/lang/%LANGUAGE%~  ~xxx/lang/autotra/%LANGUAGE%~
    END

    LAF autotra_workaround END

Just for info: I use this "autotra" workaround for my mods because if a mod is installed on EE, you can't edit the tra files, or, to be precise, you could edit them but any edits will be reverted after deinstallation of the mod. So I added the autotra folder where the converted tra files get copied in, while the /%LANGUAGE% folder remains untouched, so I can edit the texts although the mod is installed. It's not disadvantageous to have this structure, but for a mod that is done (or for players in general) it doesn't have much use.