Jump to content

Comments/Discussion on Upgradeable Items Tutorial


Recommended Posts

Just a quick question: is this WW-Item Upgrade safe? IU adds his own transitions via REPLACE and restructuring the dialogue, so I thought it best to ask ;)

 

(and no, I'll be a lazy bastard and ask rather than just check it myself)

Link to comment
Just a quick question: is this WW-Item Upgrade safe? IU adds his own transitions via REPLACE and restructuring the dialogue, so I thought it best to ask  ;)

 

(and no, I'll be a lazy bastard and ask rather than just check it myself)

Kinda. Item Upgrade nukes wsmith01 state 13, meaning your mod has to be installed after it, and pushes the old state 13 out to 107. So you need to modify the EXTEND_BOTTOM and COPY_TRANS to target state 107 instead. I worked around this with Delainy by detecting IU and compiling different .d files, one with the 13 reference and the other to 107. Ideally, we'd get Item Upgrade to use this technique as well, but... ;)

Link to comment

Rather than double .d files (= teh evil), you can use a bit of trickery with inlined files:

 

// in mydfile.d, replace EXTEND_BOTTOM wsmith 13 with EXTEND_BOTTOM wsmith I_Hate_IU_But_This_Was_State_13. Remember that REPLACE_TEXTUALLY is case-sensitive unless you stick a CASE_INSENSITIVE in there.

 

ACTION_IF has_iu THEN BEGIN

COPY - mydfile.d mydfile.d // the minus is not important but it reduces the backup clutter, and be sure to 'overwrite' the old file

REPLACE_TEXTUALLY ~I_Hate_IU_But_This_Was_State_13~ ~107~

END ELSE BEGIN

COPY - mydfile.d mydfile.d

REPLACE_TEXTUALLY ~I_Hate_IU_But_This_Was_State_13~ ~13~

END

 

COMPILE mydfile.d // or mydirectory if you have overwritten the old file

Link to comment
Rather than double .d files (= teh evil), you can use a bit of trickery with inlined files:

 

// in mydfile.d, replace EXTEND_BOTTOM wsmith 13 with EXTEND_BOTTOM wsmith I_Hate_IU_But_This_Was_State_13. Remember that REPLACE_TEXTUALLY is case-sensitive unless you stick a CASE_INSENSITIVE in there.

 

ACTION_IF has_iu THEN BEGIN

  COPY - mydfile.d mydfile.d // the minus is not important but it reduces the backup clutter, and be sure to 'overwrite' the old file

    REPLACE_TEXTUALLY ~I_Hate_IU_But_This_Was_State_13~ ~107~

END ELSE BEGIN

  COPY - mydfile.d mydfile.d

    REPLACE_TEXTUALLY ~I_Hate_IU_But_This_Was_State_13~ ~13~

END

 

COMPILE mydfile.d // or mydirectory if you have overwritten the old file

 

Could we forgo the separate COMPILE by using COMPILE_D_TO_DLG in a patch action on the COPY?

Link to comment

No, sorry. Tp2 patches are meant to change a file in-place, not to alter other files while being unchanged (and that includes altering other dlg files).

 

I could do this (maybe), but that's a can of worms I don't feel like opening.

Link to comment
IF ~PartyGoldGT(7499)~ THEN DO ~SetGlobal("CDItems","GLOBAL",1)

                                SetGlobal("ForgeStuff","GLOBAL",1)

                                TakePartyGold(7500)

                                DestroyGold(7500)~ REPLY ~Yes, let's do it.~ GOTO 56

That totally passed me by. Can the DO and the REPLY order be changed in this way nowadays?

 

That's a very helpful tutorial and .tp2 patching code, btw. ;)

Link to comment
IF ~PartyGoldGT(7499)~ THEN DO ~SetGlobal("CDItems","GLOBAL",1)

                                SetGlobal("ForgeStuff","GLOBAL",1)

                                TakePartyGold(7500)

                                DestroyGold(7500)~ REPLY ~Yes, let's do it.~ GOTO 56

That totally passed me by. Can the DO and the REPLY order be changed in this way nowadays?

 

That's a very helpful tutorial and .tp2 patching code, btw. ;)

 

According to the WeiDU readme, yes. It's just a list of transFeatures. transFeatures can be DOs, JOURNALs, REPLYs and many other things. So yes, the order can be changed, but we just tend to do it one way.

Link to comment
Rather than double .d files (= teh evil), you can use a bit of trickery with inlined files:

 

// in mydfile.d, replace EXTEND_BOTTOM wsmith 13 with EXTEND_BOTTOM wsmith I_Hate_IU_But_This_Was_State_13. Remember that REPLACE_TEXTUALLY is case-sensitive unless you stick a CASE_INSENSITIVE in there.

 

ACTION_IF has_iu THEN BEGIN

  COPY - mydfile.d mydfile.d // the minus is not important but it reduces the backup clutter, and be sure to 'overwrite' the old file

    REPLACE_TEXTUALLY ~I_Hate_IU_But_This_Was_State_13~ ~107~

END ELSE BEGIN

  COPY - mydfile.d mydfile.d

    REPLACE_TEXTUALLY ~I_Hate_IU_But_This_Was_State_13~ ~13~

END

 

COMPILE mydfile.d // or mydirectory if you have overwritten the old file

 

All right, seems like I didn't manage to use this code right. :)

 

So basically I'd need a bit more spesific instructions, please. :D

 

My tp2 looks currewntly like this:

ACTION_IF MOD_IS_INSTALLED ~Setup-ItemUpgrade.tp2~ ~0~ THEN BEGIN
 COPY - ~amber/dialogs/m#npcapp.d~ ~amber/dialogs/m#npcapp.d~ // the minus is not important but it reduces the backup clutter, and be sure to 'overwrite' the old file
 REPLACE_TEXTUALLY ~I_Hate_IU_But_This_Was_State_13~ ~107~
END ELSE BEGIN
 COPY - ~amber/dialogs/m#npcapp.d~ ~amber/dialogs/m#npcapp.d~
 REPLACE_TEXTUALLY ~I_Hate_IU_But_This_Was_State_13~ ~13~
END

 

Which gives you this error if you have Item Upgrade installed:

 

WARNING: internal label [107] not found in processed DLG [WSMITH01]

ERROR: COPY_TRANS WSMITH01 state #107 out of range 0-102, SKIPPED

ERROR: Cannot process COPY_TRANS

ERROR: processing COPY_TRANS [amber/dialogs/m#npcapp.d]: Failure("COPY_TRANS out of range")

Stopping installation because of error.

[amber/backup/0/UNSETSTR.0] SET_STRING uninstall info not found

 

For me it looks like the isn't as many states as 107 in Cromwell's dialogue, even after IU? Darios tried to look for the old state 13 in Infinity Explorer, but could not find it. :D I'm really clueless here now. :(

 

Without IU everything seems to be fine.

 

EDIT: Should I stick everything I add for Cromwell in my .d file here?

Link to comment

Thinking about this, I just started to wonder whether the state IU pushes the old state 13 to depends on what other mods one has installed (i.e. if it pushes it to be the last state of the dialog file), in which case we're basically screwed. Since at least in our installation, which has only IU installed, Cromwell's dialog file has 102 states (0-101), of which 101 is the old state 13. So I'm basically hoping that Cam & bigg just made a typo in writing 107.

 

And yes, after checking out IU's handling of Cromwell's dialogue, it seems that it appends the old state 13 to be the last state of the current file. So IU really needs to be installed after any mods that alter Cromwell's dialogue (or before any of them), not only ones that alter state 13.

 

[EDIT: Added "(or before any of them)".]

Link to comment
Thinking about this, I just started to wonder whether the state IU pushes the old state 13 to depends on what other mods one has installed (i.e. if it pushes it to be the last state of the dialog file), in which case we're basically screwed. Since at least in our installation, which has only IU installed, Cromwell's dialog file has 102 states (0-101), of which 101 is the old state 13. So I'm basically hoping that Cam & bigg just made a typo in writing 107.

 

And yes, after checking out IU's handling of Cromwell's dialogue, it seems that it appends the old state 13 to be the last state of the current file. So IU really needs to be installed after any mods that alter Cromwell's dialogue, not only ones that alter state 13.

Yes, this is a good point and one I hadn't considered. IU, as its last modification to Cromwell's dialogue file, appends a new state that essentially uses a COPY_TRANS from state 13. Darios is correct here--state 13 gets moved to the last state. On the upside, I got permission from Wes some time ago to update IU; just haven't gotten around to it with Tweaks and Fixpack and all. Removing the state 13 pokery-jiggery is at the top of my list.

Link to comment

Archived

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

×
×
  • Create New...