[Info Request] [expert] [weidu] Mod Transfer of NPC BG:EE > SoDR > BG2:EE, .cre and variables set

cmorgan

OK, checking in here because I think this is where the folks currently expanding the game behind-the-scenes may be found more easily

I am looking for information on the simplest way (from an end-user standpoint) of working with a "continuous" NPC moving from BG:EE > Dragonspear > BG2:EE

Assumptions:
* BG:EE/BG2:EE game only. No backwards compatibility necessary. Clean slate on improved engine.
* WeiDU distribution.
* Not dependent on EET or an expanded EET that might include Dragonspear
* Trying to avoid lots of user manipulation

What needs to be transferred:
* .cre information (as developed by player) from the end of BG:EE content into BG:EE SoDr and/or BG2:EE, and BG:EE SoDr into BG2:EE
* assorted variables set in the game with the same treatment.

Things done in current mods:
* custom item on BG content added to BG2 at installation that prompts the NPC to discuss the prior relationship and set vars; .cre is non-continuous (Kivan, Gavin, et. al)
* BGT (and I assume EET) transfer of .cre to an area, then placing them in the next game (assumes both games are installed using an outside mod to link content)

Current ideas (but still can't get around the transfer of the .cre intact with different mod loadouts)
* run a weidu-based "information capture" tool that works on a savegame, extracting specific variables and the existing .cre, and then having the user manually drop the resulting information into the distribution folder of the next game - if no such file exists, assume a clean slate and install from regular files. PROBLEM: requires some advanced knowledge on the user's part
* Determine a way to run an outside tool from *within* the .cre_assigned.bcs or area.bcs that would quietly do the equivalent of APPEND ~myoutsidefile~ ~OUTER SET mymovedvariable = value~ - then ignore .cre continuity and distribule a L1 NPC with experience so that the player can rebuild.


Current pie-in-the-sky idea is to have a single NPC mod that can be installed on BG:EE with or without Neera/Rasaad/Dorn/Hexxat, same package on BG:EE SoDr, same package on BG2:EE. User would be able to easily take the same party with this mod-added NPC continuously from game to game without a ton of work (basically, no more work than they would have to do to have thier PC get passed between games.

(Final question - sorry - what is BG:EE/BG2:EE using to define the equivalent of !Global("endofbg1","GLOBAL",2) and stopping content designed for BG:EE from playing on BG2:EE ?)

Dee

@Avenger_teambg can probably be of better help, but VARIMPRT.2da allows you to grab specific global variables on import.

Avenger_teambg

Well, the final question has no meaning in the EE context, since they are separate games (yet). Any content in BG2EE is BG2EE related, there is no BGEE related stuff, thus nothing to be stopped.

As far as i know, BGEE ends the same way as vanilla BG1, i don't know if we ever removed a variable named "endofbg1".

If you ask about variable transfer between games, then what Dee said. Variables listed in varimport.2da will be transferred between the games, thus romances or other states (death vars) could be preserved.
You wouldn't need this neat NPC trick in EE

cmorgan

OK, very good - another reason (besides MakeGlobal() and the huge number of fixes already present) to build completely on the new platform. So the trick for globals is to install the mod (where I would manipulate varimport.2da to look for and import the minimum specific vars I would need) on the new game, then have a player import the save.

I think end_of_bg1 was added by BGT to deal with stacking BGII content on top of BG content, but I will research this again.

EDIT: OK, with a quick hacky weidu "spell", I can toss the global names to import and number them appropriately even if someone else does this (row count starts at 0 and 1st entry is at value 1 so use row count as the first added row number and we are good to go)

COPY_EXISTING ~varimprt.2da~ ~override~
 COUNT_2DA_ROWS 2 ~rows~ 
   SET value1 = (%rows%)
   SET value2 = (%rows% + 1)
   SET value3 = (%rows% + 2) 
   SET value4 = (%rows% + 3)
   SET value5 = (%rows% + 4)
   APPEND ~varimprt.2da~ ~%value1% c-desireinterest~ UNLESS ~c-desireinterest~
   APPEND ~varimprt.2da~ ~%value2% c-desirerom~ UNLESS ~c-desirerom~
   APPEND ~varimprt.2da~ ~%value3% c-desirerombg~ UNLESS ~c-desirerombg~
   APPEND ~varimprt.2da~ ~%value4% c-desirefriendbg~ UNLESS ~c-desirefriendbg~
   APPEND ~varimprt.2da~ ~%value5% c-desirealignment~ UNLESS ~c-desirealignment~

I have not tried doing a BG:EE to BG2:EE save import - does that procedure bring InParty NPCs along as well, or will I still need to dodge around transferring the .cre?

cmorgan

And as a followup - this import transfer treatment is going to be needed for the new expansion, right?

Ardanis

As long as you NPC is global, i.e. stored in the GAM file, it should be accessible after import via MoveGlobal().

cmorgan

@Ardanis, thank you -

So it sounds like for modders wanting to let a player take their NPC along for the full ridealong,

BG:EE > SoDR, moving from game to game is as easy as MoveGlobal(S:Area*,O:Object*,P:Point*)
and then the player can re-recruit. Variables that you want to keep "continuous" can be accessed via patching varimprt.2da (side research - can't remember if LOCALS are still stored on the .cre in IE+ ; if they are, then those values will still be available in SoDR as well).

BG:EE > BG2:EE or BG:SoDR > BG2:EE is still "mod in a new .cre, script, extend pdialog.2da to 25x, and probably let the player rebuild the choices from L1 to generally match what was there before"
AND if you take advantage of varimprt.2da, you can keep GLOBAL settings between games.

for initial dialogues, stuff like

IF ~GlobalGT("c-desirefriendbg","GLOBAL",2)~ THEN EXTERN C-DESIRE c-desire_was_in_bg

IF ~GlobalGT("c-desirefrienddr","GLOBAL",2)~ THEN EXTERN C-DESIRE c-desire_was_in_dr

IF ~GlobalGT("c-desirefriendbg","GLOBAL",2) GlobalLT("c-desirefrienddr","GLOBAL",1)~ THEN EXTERN C-DESIRE c-desire_was_in_bg_only

IF ~GlobalLT("c-desirefriendbg","GLOBAL",2) GlobalGT("c-desirefrienddr","GLOBAL",2)~ THEN EXTERN C-DERIRE c-desire_was_in_dr_only

IF ~GlobalGT("c-desirefriendbg","GLOBAL",2) GlobalGT("c-desirefrienddr","GLOBAL",2)~ THEN EXTERN C-DERIRE c-desire_was_in_bg_and_dr

This could be lots of fun.