Jump to content

Discussion on 'Converting existing mods to the EE engine'


jastey

Recommended Posts

Most of BG2 NPC mods also work with songlist.2da(because blank.mus is botched in non-bg2ee games). But leaving this code in the mod should be safe... right? Or not?

 

COPY_EXISTING ~songlist.2da~ ~override~

SET_2DA_ENTRY 2 1 2 ~Blank~

SET_2DA_ENTRY 2 2 2 ~Blank.mus~

Link to comment

Very helpful, thank you for the tutorial. However, I think it's incomplete, as a few other things need to be taken into account for EE transition.

 

- Area MOS images in BG1EE and BG2EE are larger since EEs have larger minimaps to accomodate higher resolution support.

Old MOS files in EE seem glitchy - at the very least character position markers are shown in incorrect places (only tested this on full-size areas, smaller areas might be ok).

Solution: Recreate each area's minimap MOS file in DLTCEP (make sure it's loaded with EE setup). So any mods which include new areas and want to be distributed as one package for BG[2] and BG[2]EE will need to include 2 versions of each MOS, and only copy one of them depending on detected platform.

 

- EE games expect item description images to be BMP files with alpha transparency channel, old BAMs are not displayed.

Solution: convert existing description BAMs to new BMP format (this thread describes how to save as bmp with alpha in Photoshop). Include 2 versions (bam and bmp) for each item, copy one of them depending on detected platform.

 

- EEs use UTF8 encoding for characters in strings, which allows using some previously unsupported language-specific characters ingame.

However, this means that for EE any used TRA files (or perhaps only those with special characters? not sure) need to be UTF8-encoded. For reference see this post from the BG1NPC thread on the EE forums:

Either you set up your editor (for instance notepad++) to use a specific encoding or you use a converter tool to change encoding from the original encoding required for older games. The second solution is currently used in the BG1 NPC github version, provided the tp2 is up to date (it is now). Some other mods include two sets of files to handle the different encodings depending on the game.
.

 

The solution used by BG1NPC is (if EE platform detected) to call a BAT file from TP2 which uses an external program to create UTF8-converted versions of each TRA file in the language folder. These new TRAs are then re-loaded to override the default ones.

 

ATweaks mod, as another example, pre-includes two versions of each TRA file (instead of converting on-the-fly), and loads the UTF8-version if EE was detected:

//Load UTF8-encoded tra files if the game is BGEE
DEFINE_ACTION_MACRO bgee_language BEGIN
 ACTION_IF GAME_IS ~bgee bg2ee~ BEGIN
LOAD_TRA ~atweaks/tra/bgee/english/game.tra~
LOAD_TRA ~atweaks/tra/bgee/%LANGUAGE%/game.tra~
 END
END

Link to comment

Thank you, pro5! One of these points I learned painfully. The tutorial is great nevertheless, though, of course.

 

For the text encoding, see also here concerning the problem of providing two sets of encoded tra files. Short version: Copying them into the AUTO_TRA folder upon install is the only way to be able to use AUTO_TRA. Heads up: The copying will be done for every separate mod component, so in this case adding a check file to the override is recommended to minimize needed backup space (example here).

Alternatively, you can code your mod so you have only one (huge) tra file (or split in several, but still) and define a variable %tra_path% that gets applied for LOAD_TRA and/or USING (without AUTO_TRA, as this overwrites the USING path) see here for cmorgans summary.

Link to comment
Heads up: The copying will be done for every separate mod component, so in this case adding a check file to the override is recommended to minimize needed backup space (example here).

 

You can use ACTION_IF NOT VARIABLE_IS_SET to make sure ALWAYS block only executes once:

// Actions executed for every component
ALWAYS

 // only do this once per Weidu session
 ACTION_IF NOT VARIABLE_IS_SET ~GameTypeDetected~ BEGIN  

ACTION_IF GAME_IS ~BGEE~ BEGIN	  
	// Enhanced Edition:
	PRINT @0
	INCLUDE ~modfolder\lib\g3_bgee_cpmvars.tpa~
END
ELSE  
ACTION_IF GAME_IS ~Tutu_TotSC~ BEGIN	  
	// Tutu:
	PRINT @1
	INCLUDE ~modfolder\lib\g3_tutu_cpmvars.tpa~		
END			
ELSE
ACTION_IF GAME_IS ~BGT~ BEGIN	
	  // BGT:		
	PRINT @2
	INCLUDE ~modfolder\lib\g3_bgt_cpmvars.tpa~		
END

// do other stuff

OUTER_SET GameTypeDetected = 1

 END  // IF NOT VARIABLE_IS_SET ~GameTypeDetected~

END  // ALWAYS

Link to comment
What happens in this case if the mod setup is run a second time for e.g. installing / destalling one mod component? I'd assume the variable is only set for the same install session.

Thanks for the suggestion, nevertheless.

Well in that case the variable stays the same it was before the uninstall (or actually during the uninstall as for that you actually need to run the function that sets the variable, as it's before it).

But be assured, it won't rise as an issue as you can't have all the BGT, BG1 and BGTutu & BGEE in the same game. Whiich is why you can't need multiple variables, but always the same exact one.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...