To @Ardanis : I'll try that. Usually I just compile the entire mod's folder, as you've taught me a long time ago, but that keeps turning my BAFs used to extend scripts into stand-alone BCS files just cluttering Override. So now I write things out line by line...
Mods usually have separate folders for dialog, scripts and script extensions. Easier to keep things organized that way.
Quotes/tildas are not mandatory in most cases. They're normally needed when dealing with special characters, white spaces, variables etc. The rule of thumb is - when in doubt, use them.
I'm pretty sure this will work fine, because COMPILE accepts lists:
EVAL should also work on folders... Or at least I'd expect it to.
Another thing: do you know how to put new states on top of a dialogue? APPEND puts them on the bottom.
I don't think such option exists. You *really* shouldn't shuffle the existing state order, because any other mod that tries to modify the same dialog file will have its state coordinates wrong and can turn the file into a mangled mess. This is similar to the general "patch instead of overwriting" concept of BG modding, but is doubly relevant for dialog files because unlike other game data they form higher-level structures aka dialog flow than just individual units (states).
Also, it didn't quite register in my mind when I was reading the previous question, but if you're decompiling vanilla files, editing them, then compiling the edited version back, then that effectively overwrites any previous changes to the file. So it's not a nice thing to do either.
I recommend to only ship the new states and patch vanilla gotos/scripting to link to it, then you should be able to shuffle things to your heart's content without worry.
I dont see how that can work very well for kit abilities. My example: On level 1 an ability is gained that applies a reapting EFF file permanantly. On level 5 that same ability is meant to upgrade in the frequency of EFF file repeating. Say from once every 10 rounds to once every 9 rounds. I just can't see a way so far to get rid of the first instance of the ability. I can add both but then I have the EFF file repeated twice within 10 rounds which is far too powerful.
The solution you suggest only works for abilities that are not permanant but are time limited, which defies my goal of having a passive class ability that is there all the time and which improves as you level up.
You can use opcode 321 to remove passive effects you no longer want.
Also, it didn't quite register in my mind when I was reading the previous question, but if you're decompiling vanilla files, editing them, then compiling the edited version back, then that effectively overwrites any previous changes to the file. So it's not a nice thing to do either.
I recommend to only ship the new states and patch vanilla gotos/scripting to link to it, then you should be able to shuffle things to your heart's content without worry.
I try to avoid overwriting "vanilla" files this way, although in some cases it's unavoidable - if I actually want different responses from Liia and Belt, as in this case. Mostly I make my own dialogues for my own characters. And interjections are fine anywhere, prefaced with False(). But sometimes it's neither a rewrite nor my own file nor an interjection but an addition, and then I need new conditions and states on top of previous things.
For this mod I'm going to write different reactions for bartenders and innkeepers when they see Charname after his face has appeared all over the Sword Coast on posters following the Candlekeep business and escape. The same mod will keep his Reputation at 1 until he clears his name. But bartenders and innkeepers already have states triggered by low Reputation. These states necessarily have to be on top of regular states but under Charmed states, if any, and that's where they are in "vanilla" files. To leave Charm out of it, for simplicity, my states have to land higher in the tree than the usual low-Rep states, otherwise no one will see them. That's why I'm asking for some kind of APPEND_EARLY, or I'll have no choice but to rewrite the dialogues and recompile them.
Vis-a-vis other mods that might add different responses to regular states, it makes sense for those options to be submerged until the characters in question can see Charname for something other than a wanted murderer and Amnian spy. Not everyone is going to believe that or care, of course, but then, neither will I change all dialogues. And the new states will go away after redemption, but this is all just theory if there is no way to stick my states on top of a dialogue.
WEIGHT should be your thing, then. What determines the dialog priority is the state trigger order aka weight, rather than state order (though they often overlap... but not always, even in vanilla files).
APPEND dialog
IF WEIGHT #1 ~True()~ THEN BEGIN new_state_which_will_be_third_in_priority
SAY ~Something.~
IF ~~ THEN EXIT
END
END
Weight counter starts with 0, and WEIGHT #xxx inserts the trigger after xxxth (which doesn't need to exist - the values are relative and only specify for WeiDU the insertion point in state trigger list). If you want the state to trigger first, then you'll need a negative, e.g. WEIGHT #-1.
Whatever you do, never change the existing state order, though. Even if you recompiled dialogs, there may be other vanilla files that link to them, and those links will end up broken - much the same way as you saw with Liia/Belt.
Roxanne at Spellhold was a little quicker in giving this same advice. Yes, I did it with weights, though I'm going to need something deep in the negative - deeper than what other modders may stick there. Incidentally I discovered a difference from the Weidu documentation description of this function. The tutorial there claims states without weights are always "lighter" than states with weights, so any weight should put my stuff on top. Not so. #1 and #2 still put them on the bottom, so I had to do negatives.
The #xxx values are WeiDU arguments for insertion points, relative to existing entries and/or newly added, they aren't saved after .d file is compiled. The state trigger table in .dlg format is a normal file structure, starting with 0, so any negative will always put the trigger to the top. Multiple negatives are only needed when you want several triggers added to the top.
Not sure if you can insert this way several triggers between existing ones in one session, though. If not, there is SET_WEIGHT patch, which presumably works in concert with weighting states in APPEND.
The tutorial there claims states without weights are always "lighter" than states with weights, so any weight should put my stuff on top.
Yeah, I'm quite certain it used to be the case, but no longer.
Well, I put two negative weights on top: -2000 for Global + Charmed and -1999 for just the Global. And I think you're mistaken about weights not being saved. If they didn't stay in the DLG form, invisibly somehow, then they wouldn't show when the file has been decompiled in D, and the structure would collapse. There's be no going back to DLG with that file. They do show, though. The first time I saw weights was in Belt and Liia's "vanilla" dialogues that I extracted in D.
Okay, at least I got that to work, thanks to people's explanations. Who can tell me how to go about patching a CRE for a different script name? I want a creature to have another script, my own script, FFSLEE_#, for Override. Near Infinity says it's an 8-bit long field, the code is 584. I'm trying to use this and I getting an error:
COPY_EXISTING ~FFSLEEP.cre~ ~override~ PATCH_IF (SOURCE_SIZE > 0x2d0) THEN BEGIN WRITE_ASCII 0x584 ~FFSLEE_#~ END BUT_ONLY
The error is that it's an "illegal 8-byte write offset 1412 of 1156-byte file FFSLEEP.CRE."
Another thing. Can someone please give me an example of using EXTEND_TOP with a dialogue file, to attach my own transitions to a state? There is no tutorial for this, and
EXTEND_TOP filename stateLabel list [ #positionNumber ] transition list END
And I think you're mistaken about weights not being saved.
Only the state trigger list gets saved, its entries' indexes serving as weights for respective states. If you decompile you dialog now, your charmed state will be at 0 and global one at 1, and the rest offset by 2 compared to vanilla. In any case, all I was trying to say was using high negatives is no different from using low, they're just a way to tell WeiDU to append to the top of list. Any a mod using negative will put its condition above any other that already exists, be it vanilla or another mod.
Near Infinity says it's an 8-bit long field, the code is 584. I'm trying to use this and I getting an error:
0x584 (that you try to write at) is hexadecimal, while 584 (0x248 in hex) is decimal. Tbh I'm puzzled how you can even get NI to display offsets *not* in hex format. Unless I missed a few recent version updates.
EXTEND_TOP filename stateLabel list [ #positionNumber ] transition list END
EXTEND_TOP dialog 0 1 #0 // add this to dialog.dlg's states 0 and 1
IF ~~ THEN REPLY ~True.~ GOTO 3
IF ~False()~ THEN REPLY ~False.~ GOTO 4
END
Okay. That's a clear example. Yes, you're right about the weights here... These things are explaining themselves by the by, it's more difficult to tackle a new function. And the decimal/hexadecimal thing - Near Infinity shows both, and the length of the field too.
How does one retain comments in custom ai scripts in near-infinity? Every time I compile and save, then re-view the script, my comments have disappeared.
How does one retain comments in custom ai scripts in near-infinity? Every time I compile and save, then re-view the script, my comments have disappeared.
Comments cannot be stored in compiled scripts. NI auto-generates comments every time you view a script for easy reference of spells, items, and strings.
You can write your scripts in .baf format (renamed .txt) and use WeiDU to compile them. Effectively, making it a minimod for personal use. If you're writing directly in NI/DLTCEP then no way.
Another question is about tavern drinks. Who can tell me how to assign a name to one with Weidu? I really don't see a way. It's not even a stand-alone file.
It tells WeiDU to fill to 8 characters with blanks, if necessary. For example, if your new dialog was mydlg.dlg but the original was somedude.dlg, just doing a WRITE_ASCII of ~mydlg~ would change the DIALOG entry in the CRE file to "mydlgude" (i.e., not overwriting the last three characters). WRITE_ASCII ~mydlg~ #8 makes sure it is overwritten as "mydlg ".
Slow down here. What is ~findme~? How about a more complete example? Assume the name of the tavern is TAVERN.STO, what would you write in the tp2? I can create drinks, set their prices and likelihood of rumors inside NI, it's only the names that give me trouble. So does your code rename those drinks? Or do you know how to create drinks in Weidu directly, name, price and everything? As written, I don't understand your answer.
@AstroBryGuy I'm trying this code, and it's not assigning the dialogue file.
COPY_EXISTING_REGEXP GLOB ~.*\.CRE~ ~override~ PATCH_IF (SOURCE_SIZE > 0x2d0) THEN BEGIN READ_BYTE 0x08 name PATCH_IF (name = 8755) THEN BEGIN WRITE_ASCII DIALOG ~XVART_#~ #8 END END BUT_ONLY
This is a dlg for all creatures with "Xvart" as name. There are two entries in the tlk for this, just as there are for other creatures - one for "Name" and a neighbouring string for "Tooltip." But I've tried this code with both, the dialogue is compiled before this but not assigned...
Is it possible to create a spell or script that will change the amount of XP a single creature gives when it is killed? There is no opcode I know of that can change it, but can a script modify the amount?
One of my mods allows me to bring hostile critters into the party, and I'd like to prevent it from opening up an infinite XP trick (you could make a spider join the party and then repeatedly kill it to farm XP).
Another, bigger problem: when I bring critters into the party, the game crashes when I try to level them up.
I can use opcode 72 to change their class to fighter, but it doesn't seem to help. My carrion crawler shows up as a fighter on the Record screen, but in EEKeeper, its class is coded as "carrion crawler," same as before. Same problem if I try to change its race and its class.
If it's not possible to force a class change via spell, can it be done using a script? Because I already use a script to add the creature into the party.
Otherwise, the only way to avoid the leveling problem is to prevent them from gaining XP, but it would be much better if I could have the monsters gain levels normally, as they wouldn't feel like XP drains that way.
It might be possible to work around the level up issue by applying opcode 104 (XP bonus) with param2 = 1 (Set) or 2 (Set % of), and param1 = 0 to keep the creature's XP value at 0. Apply it when it joins the party and remove the effect again when it leaves (e.g. via opcode 321 or 337).
I can use opcode 72 to change their class to fighter, but it doesn't seem to help. My carrion crawler shows up as a fighter on the Record screen, but in EEKeeper, its class is coded as "carrion crawler," same as before. Same problem if I try to change its race and its class. If it's not possible to force a class change via spell, can it be done using a script?
Set the timing mode of the opcode 72 effect to 1.
You will also need to remove all usability flags from undroppable items, as you cannot level up if you cannot drop items inappropriate to your class.
Comments
I'm pretty sure this will work fine, because COMPILE accepts lists:
COMPILE ~Wanted Charname/BELT.d~ ~Wanted Charname/LIIA.d~ EVAL
EVAL should also work on folders... Or at least I'd expect it to. I don't think such option exists. You *really* shouldn't shuffle the existing state order, because any other mod that tries to modify the same dialog file will have its state coordinates wrong and can turn the file into a mangled mess. This is similar to the general "patch instead of overwriting" concept of BG modding, but is doubly relevant for dialog files because unlike other game data they form higher-level structures aka dialog flow than just individual units (states).
Also, it didn't quite register in my mind when I was reading the previous question, but if you're decompiling vanilla files, editing them, then compiling the edited version back, then that effectively overwrites any previous changes to the file. So it's not a nice thing to do either.
I recommend to only ship the new states and patch vanilla gotos/scripting to link to it, then you should be able to shuffle things to your heart's content without worry.
For this mod I'm going to write different reactions for bartenders and innkeepers when they see Charname after his face has appeared all over the Sword Coast on posters following the Candlekeep business and escape. The same mod will keep his Reputation at 1 until he clears his name. But bartenders and innkeepers already have states triggered by low Reputation. These states necessarily have to be on top of regular states but under Charmed states, if any, and that's where they are in "vanilla" files. To leave Charm out of it, for simplicity, my states have to land higher in the tree than the usual low-Rep states, otherwise no one will see them. That's why I'm asking for some kind of APPEND_EARLY, or I'll have no choice but to rewrite the dialogues and recompile them.
Vis-a-vis other mods that might add different responses to regular states, it makes sense for those options to be submerged until the characters in question can see Charname for something other than a wanted murderer and Amnian spy. Not everyone is going to believe that or care, of course, but then, neither will I change all dialogues. And the new states will go away after redemption, but this is all just theory if there is no way to stick my states on top of a dialogue.
Weight counter starts with 0, and WEIGHT #xxx inserts the trigger after xxxth (which doesn't need to exist - the values are relative and only specify for WeiDU the insertion point in state trigger list). If you want the state to trigger first, then you'll need a negative, e.g. WEIGHT #-1.
Whatever you do, never change the existing state order, though. Even if you recompiled dialogs, there may be other vanilla files that link to them, and those links will end up broken - much the same way as you saw with Liia/Belt.
Not sure if you can insert this way several triggers between existing ones in one session, though. If not, there is SET_WEIGHT patch, which presumably works in concert with weighting states in APPEND.
The tutorial there claims states without weights are always "lighter" than states with weights, so any weight should put my stuff on top.
Okay, at least I got that to work, thanks to people's explanations. Who can tell me how to go about patching a CRE for a different script name? I want a creature to have another script, my own script, FFSLEE_#, for Override. Near Infinity says it's an 8-bit long field, the code is 584. I'm trying to use this and I getting an error:
COPY_EXISTING ~FFSLEEP.cre~ ~override~
PATCH_IF (SOURCE_SIZE > 0x2d0) THEN BEGIN
WRITE_ASCII 0x584 ~FFSLEE_#~
END
BUT_ONLY
The error is that it's an "illegal 8-byte write offset 1412 of 1156-byte file FFSLEEP.CRE."
EXTEND_TOP filename stateLabel list [ #positionNumber ] transition list END
is not exactly intuitive.
Only the state trigger list gets saved, its entries' indexes serving as weights for respective states. If you decompile you dialog now, your charmed state will be at 0 and global one at 1, and the rest offset by 2 compared to vanilla.
In any case, all I was trying to say was using high negatives is no different from using low, they're just a way to tell WeiDU to append to the top of list. Any a mod using negative will put its condition above any other that already exists, be it vanilla or another mod.
Near Infinity says it's an 8-bit long field, the code is 584. I'm trying to use this and I getting an error:
0x584 (that you try to write at) is hexadecimal, while 584 (0x248 in hex) is decimal.
Tbh I'm puzzled how you can even get NI to display offsets *not* in hex format. Unless I missed a few recent version updates.
NI auto-generates comments every time you view a script for easy reference of spells, items, and strings.
If you're writing directly in NI/DLTCEP then no way.
Another question is about tavern drinks. Who can tell me how to assign a name to one with Weidu? I really don't see a way. It's not even a stand-alone file.
@AstroBryGuy Thanks, that's very helpful.
COPY_EXISTING_REGEXP GLOB ~.*\.CRE~ ~override~
PATCH_IF (SOURCE_SIZE > 0x2d0) THEN BEGIN
READ_BYTE 0x08 name
PATCH_IF (name = 8755) THEN BEGIN
WRITE_ASCII DIALOG ~XVART_#~ #8
END
END
BUT_ONLY
This is a dlg for all creatures with "Xvart" as name. There are two entries in the tlk for this, just as there are for other creatures - one for "Name" and a neighbouring string for "Tooltip." But I've tried this code with both, the dialogue is compiled before this but not assigned...
https://gibberlings3.github.io/iesdp/file_formats/ie_formats/cre_v1.htm
CRE V1.0 Header Offset Size (datatype) Description 0x00000 4 (char array) Signature ('CRE ') 0x0004 4 (char array) Version ('V1.0') 0x0008 4 (strref) Long name 0x000c 4 (strref) Short name (tooltip)You need to use READ_LONG.
One of my mods allows me to bring hostile critters into the party, and I'd like to prevent it from opening up an infinite XP trick (you could make a spider join the party and then repeatedly kill it to farm XP).
Although, I personally wouldn't bother if it were just to eliminate an exploit... Whoever wants to, will find their way regardless.
I can use opcode 72 to change their class to fighter, but it doesn't seem to help. My carrion crawler shows up as a fighter on the Record screen, but in EEKeeper, its class is coded as "carrion crawler," same as before. Same problem if I try to change its race and its class.
If it's not possible to force a class change via spell, can it be done using a script? Because I already use a script to add the creature into the party.
Otherwise, the only way to avoid the leveling problem is to prevent them from gaining XP, but it would be much better if I could have the monsters gain levels normally, as they wouldn't feel like XP drains that way.
You will also need to remove all usability flags from undroppable items, as you cannot level up if you cannot drop items inappropriate to your class.