Jump to content

Changing existing NPC starting location


Domi

Recommended Posts

Oookay. WHat I was trying to do using scripts written by Dorotea originally was to

-spawn a joinable NPC in a different location

-if that NPC was talked to prior to chapter 5, his/her clone was to be destoyed in the original location

-if s/he was not talked to, he/she should have self-destructed him/herself once chapter 5 started.

 

The original hypothesis was that clones of the same CRE have different count of NumTimesTalkedTo()

 

so the proposed algorythm was:

 

-assign new override script to CRE.

-spawn CRE in the new location. The game spawns the clone CRE in the old location independently.

-this new override script reads:

 

IF
!NumTimesTalkedTo(0)
GlobalLT("X#AloraMoved","GLOBAL",2)
THEN
RESPONSE #100
SetGlobal("X#AloraMoved","GLOBAL",2)
ChangeAIScript("_ALORA",OVERRIDE)
END

IF
NumTimesTalkedTo(0)
GlobalGT("Chapter","GLOBAL",4)
Global("X#AloraMoved","GLOBAL",2)
AreaCheck("AR4000")
THEN
RESPONSE #100
SetGlobal("X#AloraMoved","GLOBAL",3)
DestroySelf()
SetGlobal("SPRITE_IS_DEADALORA","GLOBAL",0)
END

IF
NumTimesTalkedTo(0)
GlobalGT("Chapter","GLOBAL",4)
Global("X#AloraMoved","GLOBAL",2)
AreaCheck("FW0130")
THEN
RESPONSE #100
SetGlobal("X#AloraMoved","GLOBAL",4)
DestroySelf()
SetGlobal("SPRITE_IS_DEADALORA","GLOBAL",0)
END

 

The idea being that upon being talked to, the CRE takes on the old override script and continues to function with it. The CRE which was not talked to, self destructs once Chapter 5 begins. However, once I assigned the scripts, the talking to one of the Aloras changed the script to _ALORA on both Aloras. In other words the clones do not count the NumOfTimesTalkedTo separately.

 

So, any advice on how to spawn and destroy the clones? Or does anyone knows how to suppress the original NPC spawn altogether?

Link to comment

Yes, they are. So what I am trying to script is destoying one of the clones, if the other one was talked to. I will try a simple hack now that checks for not in party(myself) and then destroyself(), but I am afraid that it will destory both aloras, or it will be insensitive to the InParty() check if one of them is in party...

Link to comment

Shouldn't it be possible to avoid the use of NumTimesTalkedTo by creating a new global?

 

So as soon as the first Alora is talked to, in her dialogue file ==> SetGlobal("AloraHasBeenTalkedTo","GLOBAL",1)

 

And then add a simple check to the area scripts:

 

AR4000.BCS

 

IF

Global("AloraHasBeenTalkedTo","GLOBAL",0)

GlobalGT("Chapter","GLOBAL",4)

THEN

RESPONSE #100

ActionOverride("Alora",DestroySelf())

END

 

FW0130

 

IF

Global("AloraHasBeenTalkedTo","GLOBAL",1)

GlobalGT("Chapter","GLOBAL",4)

THEN

RESPONSE #100

ActionOverride("Alora",DestroySelf())

END

 

Or am I not understanding something correctly?

 

Problems arise when you can make Alora join the party in AR4000 which causes two Alora's in FW0130 - which makes the code above seriously problematic.

 

Also - it is not possible to suppress Alora being spawned in FW0130 since she is not spawned but is only activated/deactivated (at least it works that way in BG1 - so I guess also in TUTU (In BGT she is spawned though)). - maybe you can do that by fiddling with Baldur.gam, as Icelus suggested, but I don't know how to do that.

 

EDIT: death variables edited, incorrectly thought TUTU changed them too

Link to comment

Alora's activation/deactivation is traditionally bugged in TUTU due to her faulty override script, but that's not the point.

 

The problem is that both Aloras will have the same death variable, "alora".

 

This:

 

IF
NumTimesTalkedToGT(0)
!InParty(Myself)
GlobalGT("Chapter","GLOBAL",4)
Global("X#AloraMoved","GLOBAL",2)
AreaCheck("FW0130")
THEN
RESPONSE #100
SetGlobal("X#AloraMoved","GLOBAL",4)
DestroySelf()
SetGlobal("SPRITE_IS_DEADALORA","GLOBAL",0)
END

 

in alora's override script does nothing if one of the Aloras in the party, and crashes the game once she is kicked out. I have an inkling that moving it to areal script will do the same, or destroy both Aloras.

Link to comment
The problem is that both Aloras will have the same death variable, "alora".

 

So Alora is supposed to join the party in the first dialogue? Sorry, missed that in your first post - complicates things a lot.

 

in alora's override script does nothing if one of the Aloras in the party, and crashes the game once she is kicked out. I have an inkling that moving it to areal script will do the same, or destroy both Aloras.

 

Yes, it probably will.

 

The only solution I see is changing things so that Alora is indeed spawned in FW0130 and is not always already there - if so, you would be able to simply add a block at the start of FW0130.BCS saying

 

IF

OnCreation()

InParty("Alora")

THEN

REPSPONSE #100

SetGlobal("AloraSpawned","FW0130",1)

END

 

where "AloraSpawned" is the global used to trigger and detect Alora being spawned. - But than you should delete the reference to Alora in Baldur.gam, which I don't know how to do safely with weidu. - but I am sure one of the experts around should know that. By using the DELETE_BYTES command, combined with several checks? - I think it will be rather complex though.

 

P.S. It might probably be a good idea to make all BG1 NPCs spawn in the next version of TUTU if there are issues because of it. BGT does that and it works just fine.

Link to comment

No, issues with Alora is not in the way that she is spawned. It is because her override has contradictoty block that tells her both activate and disactivte herself in the DAY time. It's easily fixable. Anyway, I need to know how to edit GAM. It does not seem to be anything straightforward, because it looks like each NPC has its own subfile.

Link to comment

The saved game style .gam contains ALL npcs (including those you never met before).

It contains their location, numtimestalkedto too.

 

Since you don't have to insert bytes, this could be easily done with weidu, you just have to find the offsets.

I don't know how much weidu supports embedded structures (like .cre embedded in .gam). etc.

It would probably be trivial to tell weidu that starting from offset xyz there is a .cre structure. (ask the Bigg).

Link to comment

To keep it all together, from Bigg's reply:

 

I don't think there is any specific difficulty in editing cre files in the .gam file. Supposing you want to edit Alora in Tutu when she has not joined, you need to read the GAM file and start reading consecutive offsets.

 

COPY_EXISTING ~default.gam~ ~override~

  READ_LONG 0x30 non_joined_npcs_off

  READ_LONG 0x34 non_joined_npcs_count

  FOR (i = 0; i < non_joined_npcs_count; i+=1) BEGIN

    READ_LONG non_joined_npcs_off + i * 0x160 + 4 cre_offset

    READ_ASCII 0x280 + cre_offset deathvariable

    PATCH_IF !(~%deathvariable%~ STRING_COMPARE_CASE ~_ALORA~) BEGIN // if we're patching _Alora

      DO_OUR_USUAL_STUFF_AS_IF_IT_WERE_A_CRE_FILE

      BUT_REMEMBER_TO_REPLACE_EACH_OFFSET_WITH (cre_offset + OLD_OFFSET)

    END

  END

BUT_ONLY_IF_IT_CHANGES

 

PRINT ~Remember to start a new game!!!!~

Link to comment

Archived

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

×
×
  • Create New...