jmerry

Regarding the kobolds, it's not the difficulty but the thematics. Kobolds don't do tanky. If those 25-HP creatures were some sort of beast instead (kobolds can have pets, right?) then they'd be fine. (Also, 3 XP for a 4-HD creature is ridiculously low. Those stats are almost a match for a worg - level 3, 26 HP, AC 6, 1 APR, base THAC0 17 and damage 1d8 with +1 to hit and +3 damage from 18/40 strength. And a worg is 120 XP.) They're not supposed to go hostile until you talk to them. But they are supposed to initiate conversation on their own, as soon as they see you. SCS might trade a "walk up to melee range and talk" script for "start talking at range", but it doesn't mess with override scripts like that otherwise. If they didn't talk on their own, maybe something else broke their scripts?

This one's a complicated mix of stuff, including obscure game mechanics. First, Sanik's CRE file has him at 1/1 HP. But he has a bunch of levels (16), and the game engine doesn't allow maximum HP to be below a creature's level. So as soon as he spawns in, that becomes 1/16 HP. A similar effect can be seen when a player is transformed by a Polymorph Other effect; they end up at 5/N HP, where N is their level, because the effect tries to set their maximum HP to 5. Second, Sanik's levels are in a normal character class - mage. And he has a generic mage combat script. Which means all the normal SCS routines kick in; he gets an updated combat script, he gets potions, and so on. That will usually include healing potions, and obviously you drink one of those when you're at 1 HP and there's nothing else pressing like combat. Finally, when the assassin shows up, it's a cutscene. Which means that combat script doesn't have a chance to interfere; he just shoots with his +1 bow and +1 arrows until Sanik dies. Since nobody was hostile before the cutscene, Sanik's prebuffs don't activate either. He just stands there and takes it. Even with Sanik's -100% missile vulnerability, if he drank a greater healing potion to reach full HP, that'll take several arrows to kill him. Awkward. (The vanilla version of the assassin is a thief with bow specialization. Not sure if SCS wipes that specialization out and reduces his damage, but it might.) A fix for this ... you'd have to either lower Sanik's level (there's no narrative reason for him to be high-level) or explicitly exclude him from the potion component. .............. On the general tone of "all these miscellaneous things should be tougher" ... why? It's OK for there to be easy stuff out there. And sometimes it makes narrative sense. For example, you mentioned Saerk's guards. When Anomen goes off to attack on his own, he just tears straight through them and you meet him already confronting Saerk himself. The guards are just a speed bump. And they should be; they're just hirelings of some rich merchant. Their job is to defend against ordinary criminals, not well-equipped adventurers with a bunch of levels. Very much out of scope. That's a druid-on-druid duel, and druids should be able to handle fighting without gear due to their spells and shapeshifting. If it's anything else, it's because you applied some other mod to change things.

Android is another Unix-based system (modified Linux, more specifically). So, the hypothesis is plausible - one or more Windows-style backslashed path references in there, breaking on other operating systems. Hmm. Just searching the code files for backslashes does seem to work pretty well - there aren't that many of them in normal code. Here's one example of a Windows-style path I found: (Line 1 of eyesek01.ssl in the Abazigal's lair component) Except ... that isn't a v35 change. And I don't remember any errors when I installed this (on Mac) back then. Maybe the paths do get converted both directions, and this is something a bit more complicated?

Yeah, that needs to be translated. From context, it looks like game text that will be inserted via the L_(language) lua files rather than the tlk.

WeiDU handles it automatically in one direction; forward slashes are the expected standard and work regardless of platform. But I'm not sure about the other direction. If it is that problem, some backslashed paths slipping in with the big update and working on Windows systems, I'm not sure how to search for it properly.

Some things to note, editing things like this: - The thief skill numbers in the CRE file (part of the save) are the base values of what you invested. The final numbers include race and dex modifiers, which are dynamically applied in gameplay. Also buffs and item effects. So, don't be surprised when the numbers you see on the character screen are higher than the numbers you see when editing the save. (Want 100 FT on BG2 Imoen? +1 DEX will do that. Want 100 FT on Nalia? There's a ring for that in the Planar Sphere.) - Proficiencies get complicated when a character dual-classes. Best to leave them alone until the dual is complete and you get the original class's skills back.

Not necessarily. After all, DLCMerger creates a copy for its backups. That's probably where the seventeenth instance is. No, the issue is what's in those files. It kind of looks like what you have there is basically the unmodded game's text ... applied to a game with mods that expect a bunch more text.

The way those probability fields work: roll 0-99 randomly to get a result X. If Probability 2 ≤ X ≤ Probability 1, the effect happens. Otherwise, it doesn't. So if you want an effect that happens 75% of the time, you could have P1 = 74 and P2 = 0, or P1 = 84 and P2 = 10, or P1 = 100 and P2 = 25, etc. Setting P1 = 7 and P2 = 5 would result in an effect that happened 3% of the time. Note also that the same roll is used for all effects that happen at the exact same time as part of a spell or ability; that lets "one of these things at random" effects like the Sphere of Chaos spell work. Most effects in the games don't have any randomness to them, and use values of 0 and 100 for the two probability fields. And then, for quite a few of the effects that do have randomness, the designers apparently thought it was rolling 1-100 and got things off by one. Oops. The BG1 (EE) breakable weapons system, in more detail: - Each breakable weapon has an associated spell. That spell removes the weapon and creates the "broken weapon" item. - Each breakable weapon has, as part of its attack ability, an effect that casts that spell. Probability 1 = 1, Probability 2 = 0: a 2% chance. This is absolutely something that could be made to work in any game. That note about the BG1 engine ... original BG1 did things differently, ignoring the "Probability 2" field and treating it as always being zero. You're not playing that game or using that engine, so you can ignore that note and just look at the standard version of how the probabilities work.

The game has sixteen languages. Each of those should have an instance of dialog.tlk in the lang/[language] folder; the English version is in lang/en_US, for example. Those are what the game uses. And then you have one more somewhere.

All of the game text is stored in a file (dialog.tlk) that's basically just a master list of strings. Each string has a number, and game resources use those numbers to reference that file. The "Invalid: XXXX" message is specifically what you see if a resource uses a number that doesn't match a string. Checking ... the strings in unmodified BGEE with SoD (version 2.6) go up to 71403. Anything beyond that is a mod-added string. (25000 of them? That's a lot of mod stuff.) And based on this, I don't think it's the unmerged DLC issue; that would have defined strings starting at about 35K where non-SoD BGEE ends. You'd be seeing bits of SoD text out of context instead of the "Invalid: XXXX" error messages. Another possibility here ... which files did you copy, exactly? Because dialog.tlk doesn't live in the override, and you could easily have missed it...

I'm pretty sure what's going on is that Item Revisions (and Spell Revisions) are based on pre-EE material - and they copy their resources in, overriding the base game versions rather than modifying them. The EE has a flag for weapons (actually, the "melee attack" and "ranged attack" abilities) to grant the strength bonus to damage without also granting the strength bonus to hit. This is used for throwing weapons and slings. Non-EE games don't have that flag as an option. So those pre-EE throwing weapons get copied in, and they don't get bonus damage from strength on their ranged attacks.

Not just PST; item charges are visible to the player somewhere in the interface in all IE games. If you want unpredictability, you need a different system - most likely, one with true randomness such as the BG1 "iron crisis" system. At least in BGEE, the way that one works is that the weapon has an on-hit effect; 1% of the time (actually, 2% due to an off-by-one bug) the weapon breaks, and the rest of the time nothing happens.

The charge number in the item file isn't the only number that matters. When an item is placed in the world - in a container, in a store, on a creature created by script action - that comes with a charge number too. The number in the item file is the maximum (relevant for recharge purposes), while the number in that specific instance is what it has when you find it. You need to check that too.

Well, the mh prefix tells you where to start. Made in Heaven is a surprisingly ambitious collection, and seems to be very good at breaking things. Black puddings don't exist in the base game; they're added by MiH. Specifically, the component in "Encounters and Quests" for the Undercity. The creature itself doesn't appear malformed ... might be one of the associated resources that's breaking things - the weapon mh#blkpd.itm or the conditional spell when hit mh#blkpd.spl.

The catch on editing item descriptions is that the field in the item file is just a number - a reference to the master list of strings, over in "dialog.tlk". Unless you edit that file (to add your new string in, or change the text of an existing string), all you can do is choose from the strings that are already there. Which probably doesn't include what you want the item description to be. And dialog.tlk is one thing that I refuse to touch with Near Infinity. A bad edit on that file can scramble all the text in the game. Best to only interact with it through specific functions that edit it in predictable ways - which, for me, means WeiDU commands like SAY.

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.