Ardanis

Those vars look like arguments for party AI scripts, to turn off item usage by clones. They don't affect actual item flags.

It certainly works.

Rain probability set to 100? I vaguely remembering having similar problem in SoD with BG city districts, but I don't remember the details, except it was something close to Australian shaman dance indeed... Some possibilities - try adding your area to mastarea.2da, or to the worldmap. Could have been some other file than these, but my memory stops there. Otherwise something to do with WED... I think.

ADD_ITEM_HEADER https://github.com/Gibberlings3/ItemRevisions/blob/master/item_rev/lib/macros.tpa Maybe check WeiDu readme/history, I won't be surprised if it's been included, or there's a similar function.

You can read info points for >0 strref and empty script field. If the former is true, create a prefix%strref% script with DisplayString() if it doesn't exist yet, and assign to the script field.

Info points can function without a script, as long as they have a valid strref specified. For your purpose you'd have change strref to -1 and attach a script that would DisplayString() it instead.

Unless StoreZoomlevel() & RestoreZoomLevel() work in cutscene mode (which they very well might not), I suspect that no. PSTEE is a separate branch, which is probably why it behaves differently from BG/BG2/IWD EEs.

Luck parameter gone wild, by the look of it.

TriggerOverride() doesn't work on objects not present in the active area. Worse, it doesn't return false either in such cases. And *worse yet*, it will even break OR() trigger if you put it in there as workaround, unless it goes the last in the entire condition section. From SoD's BDJAHEIR.D, this is how I managed to check that Jaheira is not inside of any Flaming Fist camps, without having to put dummy ff_camp region into each and every area: IF ~IsValidForPartyDialog("khalid") OR(2) !Range("ff_camp",999) !TriggerOverride("ff_camp",IsOverMe("jaheira"))~ Changing the order of triggers would break it. Better play it safe and just add SetGlobal() to the dialog. Or, as Jastey says, patch the script to set the var.

DECOMPILE_AND_PATCH BEGIN REPLACE_TEXTUALLY ~IF AttackedBy([GOODCUTOFF],DEFAULT) Allegiance(Myself,NEUTRAL)~ You need to \ the square brackets, to make WeiDU recognize them as literal characters rather than expression: DECOMPILE_AND_PATCH BEGIN REPLACE_TEXTUALLY ~IF AttackedBy(\[GOODCUTOFF\],DEFAULT) Allegiance(Myself,NEUTRAL)~

Slightly more complex than adding single category - it adds them in batches, - but this func should give you some idea where your code fails (I spent too much time away from IE to figure it off the top of my head): https://github.com/Gibberlings3/ItemRevisions/blob/master/item_rev/lib/store_rev_macros.tpa#L155 And some context for it: https://github.com/Gibberlings3/ItemRevisions/blob/master/item_rev/lib/store_rev_macros.tpa#L17 https://github.com/Gibberlings3/ItemRevisions/blob/master/item_rev/components/store_revisions.tpa#L106

If you teamed up with someone to work on a project and want to host on your site along with other works of yours, then yes, you describe the details of collaboration on mod's page and in its readme, but you put it under My Mods. If you're going to pick on such excuse for a blame with such prejudice, then like I said, it is nothing short of medieval witch hunt. Well, worse, actually.

I think it's IE-specific. Other games I tinkered with were far more internally organized and structured.

I'm just slightly concerned that we don't have a repeat of the witch hunt from couple years ago, when some people have been ranting about what a Satan incarnate Roxanne was, when in the links they provided as "proof" she's only been responding to players who asked for help. So I hope you'll forgive me for inquiring whether the Seatower case is a fact or just speculation that Amnesia told her where did he get the files.

Is Roxanne even aware of the original project, to begin with? Or has she been informed of its existence, in case there were doubts? The only reason I even know about it, is because I remember a decade old thread on SHS, so if you weren't around there back then and don't check on every recently active thread now, you'd be forgiven for being ignorant.

No idea, it's been a while ago, and I don't use any myself. But iirc something on the older side. Any trigger that calls Nearest()/Farthest() object. Obviously, it only has a possibility to become an issue if you routinely run hundreds of checks, simultaneously for many actors. In practice, I never had any slowdown on PC, so the precautions taken with SoD were mainly to minimize the CPU load during siege events, in case for some devices it would in fact become too intense.

Probably NearestXXX(). There aren't any real limits - SCS scripts are extremely heavyweight, but the game still runs fine (I think). The only slowdown issue I'm aware of are SoD mass battles on mobile platform, and I don't remember if giving them individual scripts instead of sharing one universal actually improved the performance. If you want to recreate SoD's scale, then consider keeping AI minimalistic, otherwise you might not need to care.

One player in SoD changed their PC's gender to neither and got locked in a cutscene mode (waking up in Ducal Palace after dealing with Korlash) because the script only had triggers for MALE and FEMALE. Can't remember if it got fixed. I made a point to script everything in binary manner (i.e. !FEMALE and FEMALE) to avoid unforeseen holes like that, but it's possible other scripters/modders have been less cautious - as the game lock with edited gender made evident - and you could theoretically run into similar issue. Chances for it to happen to a joinable are fairly slim though, I think.

Adding a few script blocks won't ruin or slow down anything. It's adding a few hundred blocks when you should stop and ask yourself if you're doing it right. Furthermore, if the script in question is your mod's and not e.g. baldur.bcs, then there's not much reason to back down even from a few hundreds. Apart from that, there are random execution delays up to a couple seconds (but rarely above half a second) when scripts run, so it's a poor choice when you need very precise timing and have no control over game's state (aka not in cutscene mode). If you absolutely insist on optimizing it to perfection, then you can order trigger lines from top to bottom to be increasingly less critical and more CPU heavy - i.e. instead of checking for ten nearest enemies in range, then for having the appropriate spell, and then for spell cooldown and/or for being in combat, you can do it in reverse order and avoid running more CPU-expensive range checks when you don't need them anyway. Likewise, you can do some high level general stuff at the top of combat script and then cut off the rest of it with e.g. ~IF /* not in combat */ THEN RESPONSE NoAction() END~ and save yourself putting hundreds of individual in-combat checks in every block. But you may shoot yourself in the foot with this unless you really know what you're doing and keep the structure firmly in mind.

I used distance check of 999 to determine if PCs were anywhere on the same map as the object (FF camp in SoD). Not sure if it was overkill or not, though, never bothered to test.

Not the actual script, obviously, but you should get the idea. Don't remember what the stat's actual name is, make sure to check stats.ids IF Global("level",0) Level(1) RESPONSE #100 SetGlobal("level",1) END IF Global("level",0) Level(2) RESPONSE #100 SetGlobal("level",2) END ETC IF Switch("level") RESPONSE #1 ChangeStat(Level2,1) DestroySelf() RESPONSE #2 ChangeStat(Level2,2) DestroySelf() ETC END

https://weidu.org/~thebigg/README-WeiDU.html#hevea_default461 (OH FUCK WYSIWYG SHITWARE)

Smarter AI doesn't always equal AI that is more entertaining to play against. This is one such case.

It's a valid tactic, not an exploit. The last thing I would want to see is enemies ignoring the tank sent in for distraction and pelting my mage with arrows instead. That's wrong on so many levels I'm not sure where to begin.

Also even if your melee weapon is useless against nearest target, it's still reasonable to switch to it to deny the enemy the melee bonus (+4 thaco/damage) he would otherwise receive against non-melee target.