Ardanis

Kill the mobile cancer.

I didn't notice at first, but is this an area script - KKNar1700.baf? If it is, using LOCALS to trigger dialog will fail, because they're only used by actors. IF CombatCounter(0) NumDead("KKBarbs",5) // this should be whatever you set in their WRITE_ASCII 0x280, can be ~NumDead("KKBarbs",4) Dead("KKAmana")~ too, if you want them to have different DVs Global("KKMissingWarriors","GLOBAL",7) Global("KKDeadWarriors","AR1700",0)THEN RESPONSE #100 SetGlobal("KKMissingWarriors","GLOBAL",8) // all enemies are dead SetGlobal("KKDeadWarriors","AR1700",1) // proceed to initiating dialogEND IF Global("KKMissingWarriors","GLOBAL",8) Global("KKDeadWarriors","AR1700",1)THEN RESPONSE #100 ActionOverride("KKNavar",StartDialogueNoSet(Player1)) // make sure dialog has state trigger ~Global("KKMissingWarriors","GLOBAL",8)~, and that it's updated to 9 or whatever immediately in the first set of transitionsEND

Contrary to what Jarno implies, StartDialog() is what should be avoided like plague unless you know exactly what you're doing and why. In fact, it's the worst dialog action out of all to use, because it overwrites the dlg file of the actor. Either use Dialog() if you want the subject to walk up to the target, or StartDialogOverride() which starts specified dlg without permanently setting it, or StartDialogNoSet() which is the standard practice. As for why it doesn't work, make sure you dialog's triggers are matching the script's values. Also if you set KKMissingWarriors/KKDeadWarriors variable in the same block as the dialog action, you'll only get a single attempt at initiating it, which might fail due to various circumstances. Consider updating those vars in dialog itself, rather than in initiating script block.

In that case, the next best bet is to try including separator string into expression outside of the match variable: SPRINT quote ~\("[^"]+"\)~ // anything encased within ""s that isn't a " itselfSPRINT tilda "\(~[^~]+~\)" // anything encased within ~~s that isn't a ~ itself SPRINT separator ~ , off , , hgj. ~ // without initial comma ~[%separator%]?[ ]*\(\(%quote%\|%tilda%\|[^,]\)+\)~

My bad... In that case, this will probably return MATCH1 without initial spaces: ~[ ]*\(\(%quote%\|%tilda%\|[^,]\)+\)~ Same thing in slightly more human-readable form: SPRINT quote ~\("[^"]+"\)~ // anything encased within ""s that isn't a " itselfSPRINT tilda "\(~[^~]+~\)" // anything encased within ~~s that isn't a ~ itself SPRINT nonseparator ~[^,]~ And this for matching expression: ~[ ]*\([%quote%%tilda%%nonseparator%]+\)~ // MATCH1 is set to what's inside \(\), so the first space(s) will be omitted *Scratches head* Not sure if I understand correctly... Is it found somewhere between quote/tilda characters, i.e. after you've already run the initial match you now need to further process its results? Or is it what you actually use instead of comma separator in the above example? If the former, you can nest multiple REPLACE_EVALUATE and use outer's %MATCH1% as input string for the inner. If the latter... I believe WeiDU doesn't actually support negating a specific sequence of symbols You might try this SPRINT separator ~, , off , , hgj. ~ SPRINT nonseparator ~[^%separator%]~ But I'm not certain it's going to fool WeiDU. If it doesn't, then can you simply reduce it to a single comma and then proceed as before? REPLACE_TEXTUALLY ~, , off , , hgj. ~ ~,~

SPRINT quote ~\("[^"]+"\)~ // anything encased within ""s that isn't a " itself SPRINT tilda "\(~[^~]+~\)" // anything encased within ~~s that isn't a ~ itself It's been years since I touched WeiDU, but theoretically this should match anything that is either quoted, tilda'ed or anything non-comma: \(%quote%\|%tilda%\|[^,]\)+

You can TriggerOverride(Player2,Global("local_var","locals",1)) to check personal values from external point of view.

Probably second... but unless you're going to have literally hundreds of thousands of those, I really wouldn't care about infinitesimal 0,0001% or something performance increase.

Or just add SetPrivateProfileString('Script','QAMODE','1') line to baldur.lua, then select Player1, press B key and jump chapters as you wish You can also toggle the debug menu on by setting global via console, but I forgot its name.

There is also something funky with trying to use read value when some keys were missing, as WeiDU would return arrayname_key0_key1_key3_etc gibberish instead. Or something like that I ended up just ignoring values altogether and instead putting all data into keys for SoD AI, like a table that it actually was in my case. CLEAR_ARRAY ability_list DEFINE_ASSOCIATIVE_ARRAY ability_list BEGIN // ability , type , local_trigger , probability_weight_to_skip , condition , local_action , ability_timer => 0 ~WIZARD_HORROR~ , spell , ~~ , 25 , arcane , ~~ , ~~ => 0 // use Horror spell with probability = 100 / (100 + 25) ~wand02~ , item , ~~ , 50 , arcane , ~~ , ~~ => 0 // use Wand of Fear item with probability = 100 / (100 + 50) ~WIZARD_HOLD_PERSON~ , spell , ~General(%target%,HUMANOID)~ , 75 , arcane , ~~ , ~~ => 0 // extra check for humanoids, but only when actually casting it END

Not sure if I'll need it, but looks interesting. Wishlisted. The only really time consuming part is walling a lot of tiny objects - fences, leaves, etc. Then adding door graphics tiles. The rest is more doable.

The action is probably not in INSTANT.IDS, hence why it gets queued until after dialog mode ends. BTW it might be possible to just use SoD's QA dialog menu (bddebug.dlg?) to change the stats... It's only triggered from PC's script, but you could have the summon AO() anyone else to start it for themselves.

You can use ChangeStat() instead, btw. If it's technical feature, rather than a proper mod, then just run a cutscene script to read all the values and set tokens, yes.

I very vaguely recall that you need RANDOM_SEED (?) put in somewhere to get RANDOM to be actually random.

Bg2Fixpack has/had a lot of dialog fixes somewhat like that for vanilla BG2, but I don't quite remember the exact syntax.

Walking has nothing to do with vision, it only cares about searchmap colors and doors' blocking regions. The problem with walls is that they attempt to emulate 3D environment, even though the game engine is one hundred percent 2D. I had a fair share of grievance with walls overlapping on otherwise passable terrain, so the only thing I can say for certain is that it's a cancer. Not impossible to work with, but something that must not be a thing.

Before EE it would fail if the talker couldn't see the object. It would even fail if the talker was the object itself. Since EE it returns true if the object is in party and not dead, even if it is across the whole map and likely if stunned/silenced/etc.

Not sure about InMyArea(), but it certainly doesn't care for range/see anymore.

Haven't got a clue... but NoInterrupt usually stands for ignoring being talked to or AO'ed. Whereas NoLeaveArea switches off looking for exit.

There used to be a lot of cases when actors were told to RunAwayFrom() and they'd pick an exit and disappear for good, instead of just milling around in the area.

Btw "modding" in that picture can be safely replaced with "making"

Actually, I'm quite sure a proper database could very well attract a critical mass of users to maintain it. But to that end it'd have to be something more than just a google spreadsheet with categories and links - I'm talking about tags, ratings, reviews, comments section etc. It worked well with imdb, anidb, vndb etc. However, going through the effort of building such infrastructure for a 20 years old game with ever dwindling user base doesn't exactly sound like the best time investment to me

By all means, keep wondering. For I too must admire your unshakable faith that community with 20 years long history is suddenly going to abandon its past ways and follow the teachings of enlightened random nobody out of the blue

If it were an absolute necessity, it would've been already done at some point in the 20-years long span of IE modding history.

It updates the structure as soon as it's done changing it. Which sounds to me like expected behavior from a function I.e. I'm quite sure you can also achieve the same result with: LPF fj_are_structure INT_VAR fj_delete_mode = 0 STR_VAR fj_structure_type = ~actor~ END LPF fj_are_structure INT_VAR fj_delete_mode = 0 STR_VAR fj_structure_type = ~actor~ END It does kinda complicates things when you want to delete multiple objects, though, that is true.