Avenger

script_area is a script slot, like script_race, script_override, etc. The area script level should be different than the race script level. See scrlev.ids This slot is not present in the .cre structure, it is only stored in the area's creature entries (this is why it is called 'area' script level).

OOps, i was wrong. "there is no way the opcode will ever touch player A." is not true Actually, it uses the source of opcode 146 (player A) for a lot of things. It would use player B as source only if it is coming from a save or something like that. Now i can only hope it is still the same as in the original, because i have my name all over this part of the code

Haha, so you wanted Minsc only and got Dyna only?

i don't know of any way

Well, tl;dr. But i looked at the first line where you used Effect: Opcode 146, target = (1 or 9), parameter2 = (0 or 1), resource = SpellB. By using target type 1, you effectively disabled targeting B. I wrote "The 'target' of 146/148 is your thief or whoever wants to cast a mage spell. " You made 'A' as the target of the effects. B is irrelevant for target type 1. Even with target type 9, where the projectile is targeted at B, opcode 146/148 will still get their target as A (original caster). Obviously, you don't do that if you want 'B' as target. I also wrote: It is always the affected creature who casts the spell in #146/#148 If you use target type 1, obviously the affected creature is A. Admittedly, i didn't chew myself through your whole chart. Maybe you want to show me this: SpellA: Ability Target: Living Actor -Effect: Opcode 146, target = 2(Preset), parameter2 = (0 or 1), resource = SpellB SpellB: -Effect: Opcode 12, target = 1(Self) = affects Player A I'm pretty sure this part is in error. If SpellA really affected player B, there is no way the opcode will ever touch player A. Maybe you could also add a displaystring (139) with the same targeting as opcode 146, to see if your 146 indeed targeted the intended creature.

I've always gotten different results from that: Opcode 146: The source always does the casting. If p2=2 and target=(1 or 9), Source casts spell at "Preset Target" and this effect bypasses targets deflection/reflection effects (though its subspell's effects are still subject). Otherwise, Source casts spell at any/all specified target(s). Opcode 148: The source always does the casting when p2=0, and the spell is cast once for each effect target. The target(s) always does the casting when p2=1. With either p2 value, the spell is always cast at the ability target(point). To compare: Opcode 258 (activate sequencer) The target is always the caster, and is who must have the spells sequenced. Opcode 260 (activate sequencer at point) The target is always the caster, and is who must have the spells sequenced. Opcode 326 (apply effects list) The source always does the casting. Unless target = 2, this effect bypasses targets deflection/reflection effects (though its subspell's effects are still subject). When target=(1 or 9), Source casts spell at "Preset Target". Otherwise, Source casts spell at any/all specified target(s). Delaying the effects can further complicates the identify of "Source" and "target", as they revert to defaults if you save&reload before the delay expires. Using them further in Subspells also complicates the identity of "Source" and "target". The target of those effects is supposed to be the 'would be' caster of the spell stored in their resource field. You can test this by targeting them at someone other than self, but with a spell that targets self. You must see the spells affect the second guy, not the first.

I guess you need (stat & 15) == 2 or (stat & 15) == 3 or (stat & 15) == 4 ? Otherwise you wouldn't have to use bit operators

The formula for 11 is this: if (stat&value) != value then effects are resisted If you need something else, write it here

The 'target' of 146/148 is your thief or whoever wants to cast a mage spell. Their level might be used or ignored depending on the parameters for 146/148. The normal casting option, for example, just queues up a ForceSpell or ForceSpellPoint action.

You can make it always the same model by changing the paperdoll id of the item. (FS for the flaming longsword) The problem here is more like that the Moonblade in IWD is a spell, so the created item has no long description Porting the spell and the item shouldn't be too hard, though. If you go only for the item, you should also make it movable in inventory, the original created item is made as a magical weapon so it isn't movable.

To me vanilla means the last patch of any of the originals, completely unmodded. If EE is added to the mix, then probably the first EE version released.

Sure, the fog data is in a file the vanilla doesn't use. So no problem there. The fog field was assigned to fog by vanilla, but unused. Also no problem.

I don't understand this one. Yeah, fog won't work in vanilla games, but why would you need to provide two sets of maps because of fog? The fog feature, while it won't work in vanilla as it is an EE feature, doesn't break any vanilla area.

Sadly bhaalspawn are not dreaming of rainbow ponies.

GemRB is pretty flexible to reassign the opcode numbers, though. So, if it implements an opcode (it does implement weather), you can make it mimic both TobEx or EE.

Are you using some of the 'Spell*' actions or ApplySpell? Using blocking actions can indeed cause stutter, but instant actions are fine.

Well, maybe i was in haste, not sure if this would work, but if you are not EE only, this is moot anyway.

Here is a weird idea: if you are programming only for the EE, you can detect the fatigue opcode with param2 = 0 by seven eyes (335/336). In the triggered spell, you can target familiars globally by anything (using 177 or 318 or 324). You can add the seven eyes opcode by the familiar on creation. This way, you can refresh your familiar the moment its owner has rested. Note: i didn't test this, but feels like doable.

Save it as uncompressed bmp for sure, best is 24 bits per pixel.

I... think there is a bug with the area type check

Is it? A lot of effects are immediate only. Ah, you talk about the 8 letter bug. You shouldn't copy bugs

Try moving SetGlobal("TSFired","LOCALS",1) after the smallwait.

Cold iron and silver are flags to support damaging certain creatures with damage resistance. Adamantine has no specific support in the engine, except the scripting action DestroyAllFragileEquipment(I:Type*ITEMFLAG) can destroy all items flagged by it. (This is to support the drow items in bg2ee). Modders can use the remaining unused flags for their own.

You had any doubts? Lol

Yeah, iwd2 is different. I'm pretty sure (99.9%) it works in iwd2 So, if everything will go as I expect, sometimes in the future EE will store the last (but also dead) AttackOneRound target there. This is eerily resembling the 'experimental discovery' of the above mentioned topic, but as of now, not released. So that's why i'm spooked. (Mostly because i don't want to break something that's actually working).