Question to EET_NPC_TRANSITION

[jastey]

I think there is an inconsistency in what EET_NPC_TRANSITION does for mod NPCs.

If a mod adds a mod NPC with this code (Skie Cost of one Soul in this case):

 INCLUDE ~EET/other/EET_functions.tph~
  LAF ~EET_NPC_TRANSITION~
    INT_VAR
      type = 2
    STR_VAR
      dv = "l#2sdskie"
      override_SoA = "L#2SDSKI"
      override_ToB = "L#2SD25"
      dialog_ToB = "L#2SD25"
      traFile = EVAL "SkieCost/translations/%LANGUAGE%/Skie.TRA"
      string = "@49" 
      stringPosDV = "Sharteel"
  END

the following things are performed as far as i can see:

 

1. In FATESP.dlg, the three entries regarding the mod NPC are added - but not directly before Shar-Teel, but in between Shar'Teel [1]:

IF ~ Global("SharTeelSummoned","GLOBAL",0)
Dead("SharTeel")
~ THEN REPLY #287617 /* ~Bring me Shar-Teel, the fighter.~ */ DO ~SetGlobal("SharTeelSummoned","GLOBAL",2)
~ GOTO 10
IF ~ Global("l#2sdskieSummoned","GLOBAL",0)
Dead("l#2sdskie")
~ THEN REPLY #387406 /* ~Bring me Skie, the human thief.~ */ DO ~SetGlobal("l#2sdskieSummoned","GLOBAL",2)
~ GOTO 10
IF ~ Global("l#2sdskieSummoned","GLOBAL",0)
Global("l#2sdskiePartyBG2","GLOBAL",0)
!Dead("l#2sdskie")
~ THEN REPLY #387406 /* ~Bring me Skie, the human thief.~ */ DO ~SetGlobal("l#2sdskieSummoned","GLOBAL",2)
~ GOTO 7
IF ~ Global("l#2sdskieSummoned","GLOBAL",0)
Global("l#2sdskiePartyBG2","GLOBAL",1)
!Dead("l#2sdskie")
~ THEN REPLY #387406 /* ~Bring me Skie, the human thief.~ */ DO ~SetGlobal("l#2sdskieSummoned","GLOBAL",1)
~ GOTO 9
IF ~ Global("SharTeelSummoned","GLOBAL",0)
Global("SharTeelPartyBG2","GLOBAL",0)
!Dead("SharTeel")
~ THEN REPLY #287617 /* ~Bring me Shar-Teel, the fighter.~ */ DO ~SetGlobal("SharTeelSummoned","GLOBAL",2)
~ GOTO 7
IF ~ Global("SharTeelSummoned","GLOBAL",0)
Global("SharTeelPartyBG2","GLOBAL",1)
!Dead("SharTeel")
~ THEN REPLY #287617 /* ~Bring me Shar-Teel, the fighter.~ */ DO ~SetGlobal("SharTeelSummoned","GLOBAL",1)
~ GOTO 9

 

 

2. In AR4000.bcs, the switch to the mod NPC's ToB script but also the fate spirit deactivation in case she was never in party for a continuous game [2]:

IF
	Global("NEWGAME_TOB","GLOBAL",0)
	Global("l#2sdskieSummoned","GLOBAL",0)
	!BeenInParty("l#2sdskie")  // Skie
THEN
	RESPONSE #100
		SetGlobal("l#2sdskieSummoned","GLOBAL",2)
		Continue()
END

3. In AR4500.bcs the MoveGlobal of the mod NPC for a continuous game. What I do not see is the script block for a new ToB game (CreateCreature)? [3]

 

4. What it does not is adding the SetGlobal("l#2sdskiePartyBG2","GLOBAL",1) to the NPC's SoA script neither to Ar4000.bcs for a new ToB game -> leading to an unsummonable mod NPC in case of a new game? I tested only for a new ToB game and the Mod NPC was indeed not summonable because fates were no longer connected. [4]

 

I see the following problems:

[1] placement of the additional reply options in between the one that should be before. I have no idea how the function determins where it should add the new reply options but this needs to be adjusted, obviously.

[2] Why is the summoning reply option deactivated if a SoA NPC wasn't in the party? The Fate spirit dialogue would already cover this, leading to a reply that the fate spirit can't call this NPC because she is no longer connected to the PC's fate. This reply option will never be active for a continuous game, but I think it should. My suggestion: Remove the script block that sets the summoned variable for a continuous game to "2" in AR4000.bcs.

[3] I reinstalled the mod plus EET-end.exe two times and both times the script block for a new ToB game was missing like the one for Yoshimo:

IF
Global("NEWGAME_TOB","GLOBAL",1)
Global("YoshimoSummoned","GLOBAL",1)
Global("YoshimoSpawnPlane","GLOBAL",0)
THEN
RESPONSE #100
CreateVisualEffect("SPPORTAL",[1999.1218])
Wait(2)
CreateCreature("YOSHI12",[1999.1218],S) // Yoshimo
SetGlobal("YoshimoSpawnPlane","GLOBAL",1)
END

. This needs to be added, obviously.

[4] Setting the "NPCPartyBG2" variable needs to be added to the mod NPC's SoA script as well as [EDIT: to the NPC's script seems to be the case for RC11] to AR4000.bcs or AR4500.bcs for a new ToB game, or a mod NPC can't be called via the fate spirit.

Edited August 25, 2018 by jastey

[jastey]

[4] Setting the "NPCPartyBG2" variable needs to be added to the mod NPC's SoA script as well as to AR4000.bcs or AR4500.bcs for a new ToB game, or a mod NPC can't be called via the fate spirit.

Alternatively, for a pure SoA+ToB mod NPC (type "2") using the BeenInParty() variable would suffice here.

[jastey]

I just realized I might be working with an older version of the function. Were there any changes to the EET_NPC_TRANSITION with the last update(s)?

 

EDIT: I redid the installation with an updated EET_functions.tph. The only thing that changed is the position of the reply options in fatesp.dlg (in between the NPC it should proceed). First post is edited accordingly.

Edited February 12, 2018 by jastey

[Roxanne]

ThisModder's Notes.html is the one contained in latest EET.

Honestly speaking, I never used it for any of the NPCs I did in EET just for the reason you state.

There is no sense in summoning a continuous NPC for a ToB only game. The result is a crappy stooge you just carry around to hold a sword for you or serve as a meat shield.

It was k4thos decision to support a ToB only game with EET. For me this makes no sense at all, I simply ignore this.

Edited February 12, 2018 by Roxanne

[jastey]

The link you provided gives me the modder notes, I don't see a changelog? I am downloading the newest EEt release currently.

 

The summoning for a new ToB game makes only sense if there is a "ToB cre" file provided (or the NPC gains enough experience when joining). It does make sense for the canon NPC as well as older mod NPCs who would always join with their ToB cre if spawned. But for a continuous NPC it's extra work for I don't know how many players. I am a perfectionist if it comes to player choices so I always try to provide the option, but for an NPC with three different fate spirit options (romance, no romance, no spawn for evil PC) and the differenciation between a new ToB game and a continuous game (plus BGT/BGII...) this can easily become a pain in the somewhere.

 

Still, I think it's a valid option and would vote for the function supporting the feature.

[jastey]

I redid the installation with an updated EET_functions.tph. The only thing that changed is the position of the reply options in fatesp.dlg (in between the NPC it should proceed). First post is edited accordingly.

[Roxanne]

I redid the installation with an updated EET_functions.tph. The only thing that changed is the position of the reply options in fatesp.dlg (in between the NPC it should proceed). First post is edited accordingly.

There is one thing easily forgotten. The EET world all hangs together. The Fate Spirit option is from a time/game where you were limited to the ToB map after transition. EET is far more realistic as it allows you to go to the whole worldmap you know. If you want to pick up an old companion from Copper Coronet, just take a trip...

 

I have extended some older mods like Chloe with new ToB contents and the ways to have her in ToB is by either having her in party at SoA end or to go back to where you left her.

Preservation is about the only argument for Fate Spirit in EET. It is an oddity,and slightly immersion breaking but maybe this is something you can only experience if you play EET yourself. I have played EET a couple of times now, and I simply ignore the Fate Spirit completely.

Edited February 12, 2018 by Roxanne

[jastey]

Interesting point. Indeed I never thought about it but (also indeed) I never really played EET.

 

Still, the features offered by the function should work correctly, of course.

[jastey]

Hi k4thos, the points addressed in the first post are still there for RC11. (Not to write "*bump*")

[K4thos]

(Not to write "*bump*")

 

thanks for bumping, I've missed this topic

 

It's been a while since I've messed with this code, but will check your test case and report back to you. Even if there is some problem here no mod that uses this function will need to be updated thanks to the fact that the function is loaded from EET directory rather than mod directory.

Edited August 26, 2018 by K4thos

[jastey]

Even if there is some problem here no mod that uses this function will need to be updated thanks to the fact that the function is loaded from EET directory rather than mod directory.

That's another of the genius things about EET design!

 

I tested it for another local NPC mod yesterday, if you want any testcase let me know.

[jastey]

Hi there @K4thos

did you have a chance to look at the raised topics?

[Jarno Mikkola]

8 hours ago, jastey said:

Hi there @K4thos

did you have a chance to look at the raised topics?

 

If there is multiple, and I were you, I for one would link to the ones that you have ran into. So links ?

[jastey]

In the first post oft this thread.

[K4thos]

Sorry for the late reply, completely forgot about this. Yes, I've looked into it.

Quote

1. In FATESP.dlg, the three entries regarding the mod NPC are added - but not directly before Shar-Teel, but in between Shar'Teel [1]:

Fixed, thanks. As you can see in the commit the code expected that there is one more exit response right at the beginning (that's why all responses were moved by 1). This has been changed in some version (exit response is now the last one) but I forgot to update the function.

As for the other stuff all seems to be working as expected.



Quote

[2] Why is the summoning reply option deactivated if a SoA NPC wasn't in the party? The Fate spirit dialogue would already cover this, leading to a reply that the fate spirit can't call this NPC because she is no longer connected to the PC's fate. This reply option will never be active for a continuous game, but I think it should. My suggestion: Remove the script block that sets the summoned variable for a continuous game to "2" in AR4000.bcs.

There are variables that already handle this. Quoting the documentation:

INT_VAR:

    default_ToB = 0 //controls if NPC should be spawnable in ToB when the game has been started in ToB (no by default - 0)
    clean_ToB = 0 //cleans out existing EET code in FATESP.DLG, AR4000.BCS, AR4500.BCS for DV specified in clean_ToB_DV
STR_VAR:

    cre_ToB = "IMOEN15" //if type = 4 and/or default_ToB = 1 name of the ToB CRE file is needed (used to create new CRE rather than migrating existing one from SoA)
    clean_ToB_DV = "" //if clean_ToB = 1 existing code for this DV will be removed from FATESP.DLG, AR4000.BCS, AR4500.BCS

none of these are set for Skie for some reason. At least clean_ToB and clean_ToB_DV are needed to get rid of vanilla Skie references (Lava's mod doesn't use the same DV as vanilla Skie). default_ToB and cre_ToB shold be added if he wants to make Skie default NPC for ToB (which makes sense considering how important she is to the SoD plot).

edit:

the correct code that Lava should use for this NPC is:

  INCLUDE ~EET/other/EET_functions.tph~
  LAF ~EET_NPC_TRANSITION~
    INT_VAR
      type = 2
      default_ToB = 1
      clean_ToB = 1
    STR_VAR
      dv = "l#2sdskie"
      override_SoA = "L#2SDSKI"
      override_ToB = "L#2SD25"
      dialog_ToB = "L#2SD25"
      cre_ToB = "L#2SD25"
      traFile = EVAL "SkieCost/translations/%LANGUAGE%/Skie.TRA"
      string = "@49" 
      stringPosDV = "Sharteel"
      clean_ToB_DV = "Skie"
  END

 

Edited January 25, 2019 by K4thos