jmerry

Easily; you use different targets for the various effects. Your spell has a projectile, the area effects use "Preset Target", and the caster effects use "Caster". Look at Emotion: Hopelessness to see how it's done.

Or to convince the system to not do any conversion on the file that's already in UTF-8? Conceptually, that shouldn't be hard ... But then, I mod for EE only. All I have to do for my own stuff is ensure that it's all in UTF-8.

Okay. Now the parse error is something different. Because you used ~ to delimit the beginning of the action block, the system expects ~ to delimit the end of the block. And it finds that tilde, immediately after the left parenthesis. Which makes that an incomplete action that doesn't make sense. That's why both ~ and " are accepted as string delimiters. Use one on the outside, use the other on the inside. If you're using ~ to delimit the action block, you need to use " to delimit the strings inside it. Such as "rqcontractKamraarn", or "GLOBAL", or that whole long journal string.

The parse error is because you have that EraseJournalEntry floating in the wrong place, rather than in the action block (DO ~~). That's where script actions go. When the system tries to parse this response, it sees an empty condition trigger, an action block, a SOLVED_JOURNAL entry, and then something which isn't a transition flag or a valid end to the response. Parse failed. In other words, to fix it, put the EraseJournalEntry into the action block where it belongs.

So that encoding error – it's clearly meant to be the long dash character. Which is hard to visually distinguish from the short dash character - but the latter is in the ASCII set that's the same in UTF-8 and the pre-EE encoding, and the former isn't so it can get scrambled.

RESOLVE_STR_REF is a WeiDU command that goes in the tp2 file; look it up in the WeiDU documentation for the syntax. Your sample there absolutely won't work, because EraseJournalEntry is a script action that goes in a completely different place. So, here's a sample that does work: In the .tp2 file: SET journal1 = RESOLVE_STR_REF(@12345) // Assume @12345 is the desired journal entry. // More stuff. Probably unrelated. COMPILE EVALUATE_BUFFER ~mymod/quest.d~ // Compile the dialogue, evaluating variables. In the .D file: /* Stuff, including a response for this action to attach to */ DO AddJournalEntry(%journal1%) /* More stuff */ DO EraseJournalEntry(%journal1%) Or you can just use that same @12345 reference directly in both places instead of the variable; the system is smart enough to handle that properly. That's what the file I looked at did, anyway.

Yeah, it's hard to work with no feedback at all. I have seen that "nothing happens" result myself with a different program - it was an attempt to run a 32-bit app. (Incidentally, I deleted EEKeeper from my current system because it was a 32-bit app. The previous system was running an older version of the OS that still allowed 32-bit apps, but no chance now.) That shouldn't be the issue with NI, but who knows...

So you get it. RESOLVE_STR_REF is a useful command for this; it puts your string in the TLK and returns the number for you to use.

I don't see anything obviously wrong. It's possible this was a glitch and it would work just fine if you replayed it; that's happened quite a few times to me in various spots. Of course, this is a post-battle cutscene, which means you need to replay the battle too...

Why would a dialogue not be viewable in tree mode? Probably because it lacks "starting" states; you get to the relevant parts by talking to someone else and having that NPC cut in, so you'd need that other dialogue tree to see it.

PHB: "Player's Handbook". One of the basic rulebooks that any group should have, and the one with all the rules for how to create and play characters. Mechanically in the IE games, there's a flag to apply both the attack and damage bonuses for high strength. Melee weapons use this. Ranged weapons get a bonus to attack for high dexterity; no flag is needed here. Then the EE also has a flag which applies only the damage bonus; this is used for slings and thrown axes/daggers/hammers, but not other ranged weapons (in the BG series, anyway). I don't think there's a clean way to get the damage bonus for strength in a pre-EE game without also getting the attack bonus.

Aec'Letec and the Demon Knight are demons, not mages. They don't have spells like Stoneskin or PFMW. At all. They have specific spell-like abilities they use, which are often clones of mage spells, and that's it. Now, with true mages like Tracea Carol (the one in the cult basement), you should be seeing Stoneskin if they have enough levels. And ... checks ... level 10 before any mods. Yeah, she should have Stoneskin with SCS. Unless you blast her before her prebuffs can trigger, which is certainly possible especially if you lay some traps before the cult moves in.

Whether a kit is allowed to dual class is very simple; it's governed by the table dualclas.2da. If you inspect that file (with Near Infinity or a similar tool, or you can just open it up in a text editor if it's in your override folder), what does the STALKER row say? The three ranger kits should be together; FERALAN (Archer), then STALKER, then BEASTMASTER. Then the five remaining entries in that row are what they can dual-class to. Obviously not fighter, mage, thief, druid, or ranger so those entries will be zero, but the CLERIC column might have 1s in it instead. The original ToB version of that table has zeros for FERALAN and STALKER, but a 1 for BEASTMASTER; beastmasters are allowed to dual-class to cleric, while the other two kits aren't. Basically, you can look it up yourself. And change it if you want to.

So that says that there was a reference to string number 12389, but no actual string at that number so it couldn't resolve. And checking (English) setup.tra, yup. No @12389. The reference to @12389 is in the combat skills component, at line 4132: COPY ~d5/d5cs110.d~ ~weidu_external/%MOD_FOLDER%/compile/d5cs110.d~ PATCH_IF (FILE_EXISTS_IN_GAME ~d5ctp00.spl~) BEGIN REPLACE_TEXTUALLY ~~~~~GOTO d5cs110_9.+$~~~~~ ~~~~~GOTO d5cs110_10 // Shadowstep IF ~GlobalGT("D5CS110J","GLOBAL",0) OR(2) Global("D5CSI0","LOCALS",0) Global("D5CSI0","LOCALS",2)~ THEN REPLY @12389 GOTO d5cs110_10 // Cantrips %WNL%~~~~~ END The .D file is defined inline; this bit extends it with an extra bit, if a certain marker file is detected. That extra bit is for cantrips, and its text is not defined. Oops. So until this oversight is corrected, this combat skills component is incompatible with the component in one of @subtledoctor's other mods that adds cantrips.

A thought ... dialogue actions often aren't executed instantly. So it says "give away the potion, get the ring", dumps you back to the menu, but the action hasn't actually happened yet so you still have that item, and the trade is still valid. Select it again, get another instance of "give away the potion, get the ring". First instance resolves, you have the ring. Second instance resolves, there's no potion to give away anymore but you still get a second instance of the ring. To avoid this, there's a flag you can set (bit 9) on the response with the action attached to force it to execute immediately. But ... that flag is EE-only, so non-EE IWD doesn't get that neat solution.

It should be editable in NI ... but maps go into the .SAV, so you need to edit the save to actually impact an ongoing game. Editing maps also gets pretty clunky, as you have to go through several layers of substructure before you reach the links.

Not a Spell Revisions change. Against creatures of level 5-6, vanilla Cloudkill is exactly the same. Level 1-4 creatures get that instant death with no save at all. If you want to get out of instant death range, you need either poison immunity or level 7+. Brutal, brutal spell. Those revealed areas don't become reachable until you try a map exit that has a transition leading there. Which is sometimes dependent on which side of the map you try. You need to go north from the Coast way crossing to reach the Friendly Arm; south, west, or east from that map won't allow that travel. And it seems that Dorn's Deep is the same way. The transition leading there is on the east side of the map, not the west. Once you've opened up a path there, it doesn't matter which way you choose. All future map transitions, unless you're completely cut off in a different travel zone, will allow you to go there. Some games try to avoid this system by duplicating the transitions for every direction. BG2 mostly doesn't care which way you leave the map. But even there ... if you leave the slums on the east side (by the Jansen home) the first time, you can go anywhere in Athkatla except the bridge district. The bridge itself is "unreachable" from that side.

The minimal amount of coding? COPY the spell, use an action such as ForceSpellRES to reference the spell by its resource name. Or you could actually assign the spell to the NPC, and have a somewhat wider range of actions you could use because of that memorization. I have no idea what you mean by "the projectile method".

That warning is because rqrev is not a valid object identifier. If you want to use a creature's script name to identify an object in a trigger or action, you need to enclose it in quotes: "rqrev" instead.

The .D file is not the fundamental unit here. It can unpack to a .DLG file, multiple .DLG files, part of one .DLG file ... basically, what you just said is irrelevant. What matters is that, at the time the .D file is compiling and you reach the CHAIN command, the files being chained to exist. If you're spreading the creation commands among different files and compiling them as a batch, you have no way to know whether a .DLG created in one .D exists when you need to reference it in another. In order to ensure that CHAIN and the like work, you need to either (a) put the creation command BEGIN %filename% earlier in the same file as the commands that reference that .DLG, or (b) create the file before you even get to that batch. Fundamentally, for what you're trying to do, I see no reason not to just put everything into one .D file. It works better that way. You have control over the order that things happen in, so you can ensure that dialogues exist when you need to reference. And of course, your symbolic labels will still be remembered when you use them.

A DLG needs to exist before you can CHAIN to it. How do you ensure this? Well, it's perfectly valid to do a BEGIN %name% command in your .D to create a DLG file, and then simply move on to something else without putting anything in that DLG file just yet. One mod I checked for reference (an NPC mod, and the dialogue for extra characters involved in the quest) did this for several characters at the beginning of the file.

It would technically work either way, as %WNL% (Windows) is %MNL% (old Mac OS) concatenated with %LNL% (Unix-based systems, including Linux and modern Mac OS)

Yes. Some random treasures break and get turned into NULL items (harmless; even if you pick them up, they transform into nothing). Others are converted into the new random scroll tokens properly but break at game run time, failing to resolve into a real item (don't pick up these or you'll lose an inventory slot to undroppable garbage, but leaving the area and returning rerolls the item).

The file to edit is the one in your override folder - the one the game will actually use. The backup file is only there for reference. So, assuming you have NI set up the normal way, you'll look at the main list of files in the sidebar. Depending on the options you have selected, the files you're looking for will either be under "Override" or "ARE". Pick an area you're interested in changing. Go to that file. That's what you're looking to change. Then, use the "Open File" menu option, navigate to the backups, and find the file for the same area in that particular backup. Open it up in a new window. Now you have both versions open; you can compare them and edit the one to match the other. "A list of ToB locations" ... that sounds like something completely different, probably in a lua file somewhere (the in-game list of areas for debug mode needs to be defined, after all). It doesn't sound like the big list of game resources at all. There are about a thousand AREs in baseline EET, plus whatever mods add; if you aren't seeing at least hundreds of areas, you're not looking at the right thing. Oh, and a small fraction of areas won't be changed by this component at all. No rule against randomizing to what's already there, so it's basically certain to happen over enough trials. In that case, the area won't show up in the backups and there won't be any need to change.

No offense taken. Most of my tweaks are born of the tinkering I've done on for own play, and other people will want different things out of their experience. I'm just happy when I see people using my stuff. Then there are some tweaks I've put together that I'd never use myself - like one time someone wanted all the battle music gone. (My solution to that one: reuse the same code for setting battle music in all areas, but set it to "none" so that the area music just keeps playing)