Help - Search - Members - Calendar
Full Version: I_C_T versus I_C_T2
The Black Wyrm's Lair - Forums > Mod development resources & discussion > Modder's Workshop
Moongaze
I'm going to try interjection coding sooner or later, and I have a question regarding that.
When I first tried to in my Wikaede mod, I found that simply interjecting using INTERJECT_COPY_TRANS works fine in some cases, but in other cases (such as Lieutenant Aegisfield upon first meeting) it messes up the dialogue and the actions that follow, (in this case, it prevented the Tanner Murder quest from starting). In some cases I found a workaround, by adding an extra line where the NPC in question says something back, and then it sometimes works. This, however, doesn't always work, and is an annoying way of getting by.

I've seen multiple NPC mods use INTERJECT_COPY_TRANS2 (or was it INTERJECT_COPY_TRANS_2 ?) ... what is the difference between the two, and would it be best to use the "2" version in a problem mentioned above? If not, what is recommended to ensure that the dialogues work, save not placing any interjections there at all?
Sir_Carnifex
I had that problem at first, too. Halbo was accidentally turned into an abominable creature that was hostile when I used the wrong interject.

Suppose the original character is supposed to DO ~EscapeArea() after saying something and you interject into that section, your NPC will end up taking over that action. However, if you use Interject_Copy_Trans2 you can prevent that from happening.

In general, when a DO action that directly affects a character comes immediately after the dialogue string, you should use ICT2.

Check the WeiDU readme sections on the two for a much more clear explanation.
Moongaze
Thanks. I had a hunch it did the trick, but I wasn't sure...
jastey
With I_C_T2, you have to be careful if there are multiple actions, meaning different actions for different reply options / conditions, though. In this case, I_C_T2 cannot be used, but I_C_T with a give back line from the original speaker xhould be used.

Example:

In the following, I_C_T2 would be perfect, since every reply option has the same action:

IF ~~ THEN xx
SAY ~I agree.~
++ ~Fine.~ DO ~EscapeArea()~ EXIT
++ ~But I don't.~ DO ~EscapeArea()~ EXIT
END

In the following, I_C_T2 would not work, but screw up the actions of the reply options (it tends to take one of them and put it after all reply options):

IF ~~ THEN xx
SAY ~I agree.~
++ ~Fine.~ DO ~EscapeArea()~ EXIT
++ ~But I don't.~ DO ~Enemy()~ EXIT
END

After a first enthousiasm, I nowadays don't use I_C_T2 at all anymore. The reason is, that, even if the original dialogue state doesn't contain multiple actions, I can never be sure that another mod hasn't added a reply option that contains one. If another mod that was installed before mine added one, my mod would give a warning upon install and screw things up. I am only using I_C_T with a giveback line.

Btw: With I_C_T3, you can add multiple interjections to the same state that have different triggers, which is not possible for I_C_T.
If you want your mod NPC give different comments depending on his state of romance, for example, I_C_T3 is the one to use. The following coded using I_C_T would lead to only the first line being shown, when the conditions are met, the following would never show.

I_C_T3 gamechar X XXvariablename
== ~moddlg~ IF ~(Romanceactive = 0)~ THEN ~text1~
== ~moddlg~ IF ~(Romanceactive = 1)~ THEN ~text2~
== ~moddlg~ IF ~(Romanceactive = 3)~ THEN ~text3~
END
Moongaze
There's a version 3 as well? Great.
Thanks.. I hope I'll be able to get it to work. closedeyes.gif
jastey
There is also an I_C_T4, which would be the multiple trigger variation of I_C_T2. I only learned it by reading about it myself:
Re: I_C_T vs I_C_T2 revisited.
.
Moongaze
Hmm, and another...
This is going to be a pain to code correctly...
Sir_Carnifex
Four ICTs??!! blink.gif I think the WeiDU readme needs some updating then.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2024 Invision Power Services, Inc.