Taylan

Gentle bump on this thread, since BG3 is about to be launched. We've made really great progress with the wiki, both in terms of the server's ability to handle load, and the wiki's design and content. I think we're ready for the potential onslaught of new visitors and anonymous editors at launch, LOL. Google unfortunately still hates us for inexplicable reasons (even SEO professionals are baffled) so I thought I'd make sure to mention it here again for those who care about BG3.

Hahaha to each their own my friend! But I think your criticism is partly... misplaced? The barrelmancy is just a meme, there aren't really that many places where you can use it. And it's not like there weren't silly ways to cheese fights in the older games. I think they intentionally overdid the environmental damage stuff in the earliest parts of early access (the prologue, and then the first group fight you're likely to encounter in chapter one) because they wanted to show it off. The max level is probably gonna be like 12, which makes sense for a "fresh start." Think BG1. Maybe you should give it a go once it's released.

Hey all, I don't know how many people here are interested in BG3 but I've been having lots of fun with it and a while ago decided to set up a wiki for it: https://bg3.wiki/ It's a completely non-profit project, unlike the Fextralife one that's filled with ads, auto-playing videos, and claims exclusive copyright ownership over anything you contribute. We already have some amazing contributors who wrote a number of pages that are a lot more comprehensive, detailed, and well-written than anything you'll find on the other wiki, so I have high hopes about this becoming the go-to resource for fans. So yeah, just a heads up that this exists.

I'm trying to debug the issue I've described in the following post: Since I'm still very unfamiliar with BCS files, it's difficult to figure out which of the dozens (hundreds?) of possible IF blocks might be erroneously triggering (or not triggering) to cause the observed behavior. Well, even if I was familiar with all the actions and triggers, I think it would be difficult to find out where I have to look without having some preexisting knowledge about where the actual combat logic is likely to reside. Hence the question: is there a way in the Infinity Engine to enable some sort of debugging mode where it traces ALL script execution and writes a massive log of every single decision it takes? Of course, this would generate heaps of data, but I figure it shouldn't be too hard to search such a log for certain actions (like the Beholder's piercing melee attack maybe) to quickly find the whereabouts of the problematic decisions taken by the script. For those familiar with Unix/Linux kind of programming, I'm talking about a trace log of the sort you would get from debugging tools like strace/ltrace/truss. Alternatively, let me explain what I'm looking for with an example. Consider the following script snippet written in BAF: IF Allegiance(Myself,NEUTRAL) OR(7) AttackedBy([GOODCUTOFF.0.0.0.0.SUMMONED],DEFAULT) AttackedBy([PC],DEFAULT) AttackedBy([FAMILIAR],DEFAULT) AttackedBy([ALLY],DEFAULT) AttackedBy([CONTROLLED],DEFAULT) AttackedBy([CHARMED],DEFAULT) SpellCastOnMe([GOODCUTOFF.0.0.0.0.SUMMONED],0) THEN RESPONSE #100 Enemy() Shout(89) Continue() END Now let's say that "Allegiance(Myself,NEUTRAL)" evaluates to false, therefore it skips this whole block. The trace log would then contain a snippet which somehow encodes the steps that were taken during execution. For example, using an imaginary BAF-like syntax: BEGIN CONDITIONS Allegiance(Myself,NEUTRAL): FALSE END Or for a more complicated example, let's say that "Allegiance(Myself,NEUTRAL)" matches, and from the OR(7) the third one i.e. "AttackedBy([FAMILIAR],DEFAULT)" matches, and therefore the actions are executed. The trace log would then contain something encoding the following execution, again using our imaginary BAF-like syntax: BEGIN CONDITIONS Allegiance(Myself,NEUTRAL): TRUE OR(7) AttackedBy([GOODCUTOFF.0.0.0.0.SUMMONED],DEFAULT): FALSE AttackedBy([PC],DEFAULT): FALSE AttackedBy([FAMILIAR],DEFAULT): TRUE BEGIN RESPONSES HIT RESPONSE #100 Enemy() Shout(89) Continue() END I know that BAF scripts are not executed directly but rather compiled to BCS, and that probably means that unless our tracing mechanism is highly sophisticated, it will NOT contain such nice snippets in a BAF-like format but rather something ugly that contains the kind of codes and references you see in raw BCS. Still, it would be an immense debugging help, and one can imagine writing a tool that parses it to turn it into a BAF-like syntax just like we can decompile BCS into BAF. So yeah, is something like this possible? Some native debug functionality of the engine? Some DLL hack? The next step would be to develop a whole modding IDE where you can set breakpoints in your scripts and trace the execution live while the game is running. xD

I had completely missed this thread until now. Just want to say: neat! When I wrote that WeiDU is "probably" Turing-complete I was still very very unfamiliar with it. I'm still not particularly familiar with it, but I've since realized that it does offer all the basics (and then some) for general-purpose programming. Perhaps my main issue is the rather unique syntax and naming of builtin operations.

I'm in the Beholder Cave in the Underdark right now and noticed a strange behavior from the Beholders in there. I reinstalled the game clean then installed the mods/components indicated by the WeiDU.log below, to make sure it wasn't due to my outdated SCS installation. Basically, if I charge into a big group of Beholders with Valygar, then as expected, they vaporize him pretty quickly. Death Ray, Disintegrate, Cause Serious Wounds, the whole shebang. But if I charge in with any of my other characters, they barely do anything. For some of them, literally all they do is try to bite them (melee piercing damage), with some others they cast only a few spells like Anti-Magic Ray but not much more. Perhaps they're trying to be smart by saving up their abilities for party members who are particularly vulnerable, though I can't figure out a sensible pattern. (It doesn't seem to be saving throws or magic resistance, for example.) They were acting more normal (i.e. properly aggressive against all my characters) after I had done the clean install of the game / before reinstalling SCS, so it must be an issue with SCS. WeiDU.log:

@subtledoctor Thanks for the tips! I have SCS installed of course, hence posting this thread in the SCS section of the forum. Next time I encounter an enemy like Deirex I'll make sure to note whether repeated Pierce Shield / Pierce Magic / RRoR really do what they're supposed to. Your mod sounds very interesting. Currently I have all the SCS enemy/tactics improvements for mages and priests installed so I guess it would be incompatible, but I'll check it out in the future.

Unfortunately I've already beat him by cheesing now. (Well, if you consider Protection from Undead to be cheesing.) But it's surely not going to be the last SCS enemy who poses this issue. I think the main issue tends to be that spells to eliminate protection from magical attacks like the ones I listed above don't work on them, probably due to innate immunity to spells up to a certain level, and that in turn means you can't Breach them so they're also immune to physical attacks (innate immunity to non-magical weapons + Protection from Magical Weapons or Mantle).

Maybe I'm stupid but this seems kind of broken... All of the following spell protection removals result in a "Spell Ineffective" on Deirex: Pierce Shield Pierce Magic Secret Word This means I also can't cast Breach on him, so he's effectively completely immune to my attacks for enough time to cast a Comet and Dragon's Breath, obliterating my weaker characters. Is there a way to properly fight against him? Currently I'm thinking of cheesing the fight like I had to do with some other ridiculously powerful spell-casters, especially Liches who seem to love staying in one place and never chasing you. Just move in and out of their sight to bait out the protection spells and wait for them to wear away... Makes it easy but feels really wrong.

Sorry for triple-posting / bumping, but I feel like I should provide an update since it's the end of August now: I had to take care of my grandmother for a big chunk of my vacation, since she has dementia and can barely move. From 3-4 different projects I had lined up for my vacation and was enthusiastic about, I was able to complete just one. T_T Please don't expect any quick progress, though I really don't want to let this project idea die. I'll probably work on it on and off as time goes.

In case anyone's wondering what happened to this, I've just had all my energy taken by work and personal things in the last couple weeks. Will continue working on it soon, at least when I'm in vacation in August.

@kjeron If that really is the case, that's a problem indeed. Quoting my previous post: A third option might be to expect the sound set mod to contain one SoundID->WAV mapping table per supported game. So the contents of the definitions file could look like: [sounds/bgee] battle_cry1 = bc1.wav battle_cry2 = bc2.wav ... select_action4 = select4.wav select_action5 = select5.wav ... [sounds/bg2ee] battle_cry1 = bc1.wav battle_cry2 = bc2.wav ... select_action4 = action4.wav select_action5 = action5.wav ... (I'm using the names from SNDSLOT.IDS, just lowercase.) There would be lots of duplication because those sections will be 90% the same, but at least there's no chance of confusion. Although I think I like solution nr. 1 in my quoted post better. There would be a small number of "special" names which the sound set installer automatically translates to a different name, based on the game. Consider: [sounds] battle_cry1 = bc1.wav battle_cry2 = bc2.wav ... select4 = select4.wav # Translated to select_action4 for BGEE, select_common4 for BG2EE select5 = select5.wav # Likewise ... action4 = action4.wav # Translated to (???) for BGEE, (???) for BG2EE action5 = action5.wav # Likewise ... (I'm not sure what the "(???)" should be in the last example. Is this what those game-prefixed IDs are for? E.g. within BGEE, there are IDs like BG2EE_SELECT_RARE1.) So this half-half solution might be best. It allows using mostly the IDs defined in SNDSLOT, and only requires the sound set installer to assume special knowledge over a small number of incompatibilities between the games. Doesn't require defining a whole table of our own IDs per game.

I still don't see why it would be an issue to use the names from SNDSLOT.IDS. That the game engine doesn't actually read that file isn't important, so long as the mapping in it is accurate. I'm not proposing to write to the file, only to use it as a reference. And if for instance IWDEE uses BATTLECRY1 but BG2EE uses BATTLE_CRY_1 then all your sound set mod has to do to support both games is to list both of those entries (pointing to the same WAV file), like: BATTLECRY1 = my_fancy_battle_cry.wav BATTLE_CRY_1 = my_fancy_battle_cry.wav. Tell me if I'm still missing something. Neat! I still think a language like Python would be beneficial in the long term, but to each their own. We'll have to see if my project goes anywhere; it depends mostly on whether I actually find enough time and energy to put into it.

@kjeron Why not use SNDSLOT.IDS when it tells me which symbolic name corresponds to which integer index? No need to create one's own mappings. A sound set can define a WAV file for BATTLE_CRY1, SELECT_COMMON1, etc., and it will be automatically translated to the correct integer index based on the SNDSLOT.IDS of the game for which you're installing the sound set.

A sound not existing in all games or having a different numeric ID is no problem. 1. If a sound set provides a sound, but it doesn't exist in all games, it will simply not be installed for that game. 2. The numeric ID will always be looked up from the current game's SNDSLOT.IDS, the mod utility never assuming any knowledge of numeric IDs. What would pose a very minor problem: - Games use different symbolic names for what's obviously the same sound. E.g. if one game calls it BATTLE_CRY_1 and another calls it BATTLECRY1. Easy solution: sound set definition must define both, pointing to the same WAV. What would pose a significant annoyance: - The same symbolic name is used for completely different purposes in two games. E.g. if the name "DAMAGE" is used by one game for the generic sound whenever a character is hit, but another game uses it for the "critical damage reached" sound where the character asks for help. (This particular example is surely not the case, it's just an example of what could be.) Solutions might be: 1. use a symbolic name that exists in none of the games, the installer translates it to the correct real name; 2. sound set definition must specify which game is meant with the symbolic name, by specifying it as e.g. "DAMAGE/BG2EE" and "DAMAGE/IWDEE" and the installer interprets it the right way. That last issue *might* be the case for some symbolic names that are used for NPCs only, but I think it never applies to a regular character sound, so I think we're safe. This means the installer doesn't have to include tables mapping symbolic names to integers; it can use the mapping from SNDSLOT.IDS and expect the sound set definition to use names from there. The only "special knowledge" a sound set installer needs is a mapping from sound to WAV filename suffix, for pre-2.6 compatibility, because that mapping isn't defined in any game file, correct me if I'm wrong?