critto

Hi. No, not really, thanks for pointing out. I do now. This only shows that the problem (if it could be called that) has been there for some time now. Unfortunately, there are no clues what causes this behaviour.

Thanks for your reply. Unfortunately, it only covers the things I already know and doesn't really explain the rest

> Varscona is chosen if you don't have any of the weapons in the list on your imported save/char
Why this item exactly? Is it hard-coded?

> My guess is that you got three copies because you imported three characters.
Yes, that is pretty logical to assume. Still doesn't explain why the three copies when we call TakeItemListPartyNum only once and pass it 1 as the argument for the amount of items to be selected.

Hello. I'm struggling to understand how it works. So there's this snippet everyone probably knows by heart:

IF
	Global("TakeImportItems","AR0602",0)  // Irenicus's Dungeon 1st Floor
THEN
	RESPONSE #100
...
		ActionOverride("Table3",TakeItemListPartyNum("IMPORT02",1))
		ActionOverride("DuegarClanChief",TakeItemListPartyNum("IMPORT01",1))
		ActionOverride("Shelf1",TakeItemListPartyNum("IMPORT03",1))
...
END

Shortened for brevity. I create a new game, use "create party" option to import a few chars from character files (Lessa, Abdel, i.e. the ones shipped with BG2, not the actual chars from the first game) and hit play. I find three identical Varscona swords (SW1H06) on the table in the golem room. Did all of them have these swords in the inventory, including the protagonist whom I've created manually from scratch? If so, why are there three copies of it? I thought TakeItemListPartyNum was supposed to take only one item per list?

Thanks.

What Jacek wants is to lower saving throws against a specific spell school when spells of that school are cast by a specific character/kit (e.g., conjuration spells when cast by a conjurer). Solution proposed by subtledoctor is definitely easier and more straightforward, but the penalty to saving throws would apply no matter which character casts a spell from the relevant spell school.

If I understood correctly, Temnix proposes how to actually restrict this to a particular character/sub-set of characters via spell states. I haven't exactly figured out yet which opcodes are suggested to use. Is it #232, cast spell on condition?

Yes, the removal is permanent, which is good; but the SPPR spells get added every level so a 172 effect would have to be applied at every level-up.  A 1-second delay works fine.  Note one issue here: spells with timing mode 4 do NOT get applied when you "pre-generate" a character and then import it into a game.  So if someone pre-generated a character with this mod, they would have the spells you want to remove, until their first level-up.

Interesting. I haven't thought about this scenario at all. So many gotchas.

Ah.  Doing this with the base Shaman is not great, since that is a class and AFAIK it uses the trueclass exclusion flag, and there is  no way to give it a different one.  Shamans are hard-coded to get the same spells as druids and rangers: every SPPR spell that does not have the druid exclusion flag set in byte 0x21 (i.e. the 4th byte of the field at 0x1e, as you said).  Differentiating between druids and shamans probably requires using 172.

Yes. I did some searching on the forum for the exclusion flag and figured that might be an issue. It's a shame, this is a much cleaner solution, overall.

(In Near Infinity, change one of the spells from divine to arcane in the field at 0x1c, and then the bard kits will be visible in the field at 0x1e. You can check the Jester flag, and then change the spell back to divine.)

Yeah, I finally found those earlier when I was checking out different spells in NI. These aren't listed in IEDSP, so I was clueless at first. Just to be clear, there's no correlation between the exclusion flags and the type of spell? I.e. if the type is set to divine and the exclusion flag is checked for the Jester kit, this would still work? The game does not make any extra checks to make sure that the jester kit should be taken into account only if the type of spell is set to wizard?

Now those spells will not be added automatically at level-up (no need for 172), and they will not be shown during character generation.  This would be perfect for you... but again, I don't think it can be done with a class - only with kits.

I guess I'll have to resort to the first solution. The delayed application works well enough, but there are still some funny things. For example, when there's no delay on the application of 172, you can see the effect immediately during character creation. Once you're done with the "skills" section, there's an information screen, and the spells being removed aren't present on it. But if you use timing mode 4, spells would still be listed. The 172 code gets applied only after you actually start the game. Which kind of makes sense, I guess, because the game is probably "on pause" during character creation.

Quote

I assume you’re talking about divine spells? All spells with the filename “SPPR[1-7][01-49]” are automatically added to the spellbook upon every level-up, as long as they are not precluded by an exclusion flag.

Yes, about divine spells, exactly. Yes, I figured that they are added upon every level-up.

Quote

This happens a split second after CLAB effects are processed. I don’t think that means “something is wrong” with the order of events... that’s just the way the engine works. Scripted triggers probably happen later because they require the game clock to be running for a second or so before they are recognized and acted upon. (Try your XP script trigger and level up with the game paused.)

This is sort of makes sense. I used the DPLAYER3 script trigger and activated it on demand by turning the party AI on and off, so there's obviously more lag between the events.

Quote

1) Use timing mode 4 with a duration (delay) of 1 second on your 172 effects, and apply it every level... I do this sometimes, like to make multiclass druids as multiclass cleric kits. It works tolerably well, the only hitch is that it requires the game clock to run, so if someone levels up and looks at their spellbook while the game is paused, they can see the ‘bad’ spells there.

It didn't occur to me to delay the application of effect. While reading the old threads I got the idea that the 172 opcode is kind of permanent no matter what kind of timing mode you choose. I resorted to adding an ability to every level in CLAB too, but I'll have to play around with the delay as well. It might be good enough solution.

As for seeing the 'bad' spells on pause, I am afraid these are just limitations the players will have to accept. There isn't any way to hide the 'bad' spells during the char creation either. They go away only after you're done with the "skills" section of character generation.

Quote

2) On the latest EE engine, you can use a kit exclusion flag on the spells, and add that flag to your kit. Should be a kit that normally doesn’t interact with divine spells, (so nothing that can multi/dual with cleric) and any item exclusions with the same flag will be unusable by your kit - so e.g. the Cavalier flag might be bad if your kit wants to use missile weapons. In this case, a bard or paladin flag might work best. This can work very well, you just need to be very careful with the use of such flags, and consider what other mods might do with them. Also some flags may or may not be functional with some spells on the pre-EE engine.

Could you clarify a bit more on the flags, please? Or point me at the example of implementation to study in greater detail. Looking at the documentation of the SPL format, I'm not entirely sure which field is responsible for these flags. I assume it is not the default 0x001e? Generally speaking, bard/paladin kit should be ok since I'm modifying the shaman class (unless I misunderstood your comment about divine spells: it's ok for my class/kit to use divine spells, but not for the provider of the supposed exclusion flag?). Conflicts between mods aren't really a problem, since my mod is completely stand-alone and it is EE-only.

I tried to apply the same AP_* ability I use in CLAB but via a script block upon hitting XP threshold. The spell gets removed from the spell book correctly. So something is definitely wrong with the order of application when it happens automatically via CLAB during the level up.

So, this have been discussed in the past before, like here, for instance. I'm running into the same problem.

Situation: I want to remove a normal spell from spell book for specific kits/classes. I prep an ability that applies a permanent 172 opcode with the necessary spell and put it into a CLAB 2da as "AP_*" at the appropriate level. Everything works initially during character creation. The spell is gone. After a level up, it keeps coming back. I've tried adding the AP_* ability at every level up, and it gets applied (judging by the debug Display String opcode I've added to it) but the spell keeps sitting in the spell book nonetheless.

What's up with that? Is it fundamentally impossible to achieve because the game processes the CLAB file first, after a level up (and the 172 opcode gets applied, but there's nothing to remove yet), and then re-populates the spell book? Or am I missing something?

Cheers

I'll just chime in and say that sometimes a space symbol is not just a space symbol, especially at the end of the line. You might get a lot of headache trying to figure this out, since the files could've been saved under different operating systems and have various hidden line termination symbols applied, etc.

To match any space symbol this snippet could be used:

[ %TAB%%LNL%%MNL%%WNL%]+

This matches a group consisting of one or more spaces, tab characters or linux/mac/windows new line symbols. Enjoy.

Well, it works. A bit hacky, though. You can't simply put a #273 opcode inside the spell itself, because it dispels its own projectile. I've had to wrap it into a #148 opcode (cast spell at point) in order to achieve a workable solution.

Yep, looks like I missed the second part of your post. AND the footnote in the description of the #273 opcode, despite having read it numerous times. I'll give it a go and see what happens.

It's an AoE cloud-based party-only healing spell. I want to prevent abuse by stacking multiple castings, but the solution you've proposed already solves this. A player could cast multiple instances, but only one heal would apply per round due to the #206 opcode. Having the previous version dispelled would be a more intuitive way for the player to understand the limitations. But, of course, simply blocking multiple applications via #206 and leaving the rest for the player to figure out by trial and error is good enough if there are no cleaner alternatives to achieve this.

True, it protects from any rival copies as well. It's a decent solution, although I'd preferred to dispel the previous instance upon casting a new one.

Following up on my previous question. Is there a way to dispel an AoE spell based on its specific projectile (not with ZoSA via clearair.2da)? I would like to enforce having only single instance of an AoE spell active. Since it applies a list of effects every round to the creatures inside the AoE, I can't use the #206 opcode to apply total protection from the spell's effects.

Wow. Thanks for the help. That wasn't obvious at all. "Ignore center" is really ambiguous. Neither does IESDP's "bit 4: Do not affect direct target" sound very clear.

Hello, everyone.

I've been trying to figure out something. Let's say we have two spells: the shaman's writhing fog (SPPR250) and the wizard's Web (SPWI215). I'm trying to understand what is the difference between projectiles (writhing.pro and web.pro). Why does Web affect the caster and Writhing Fog doesn't?

I've compared the projectiles and spells, didn't find any meaningful difference. Would appreciate some pointers.

Cheers,

critto

PS: sorry, posted it here by mistake instead of the "Modding Q&A" section.

Hey David.

It appears that modify_breach.tpa patches Spell Shield to protect from Breach whereas the readme states that it doesn't penetrate Spell Turning. Which it probably will since ST does not have a #226/#228 opcode set to protect from the Breach's new secondary type. Which behavior is supposed to be correct, in the end?

Thanks guys. I completely forgot that you actually have to specify the amount of charges when placing/creating an item. Figured it would be something simple in the end.

However, if that's the case, what does the "# of charges" field do exactly? If I use CreateItem command (from the console, at least), I can create the item with the number of charges higher than the one specified in the ITM file.

There's this item on BG2:EE, Gem of Seeing (ohrscrl1.itm), that casts True Sight per day (recharge after rest). I am trying to convert it to have a limited amount of charges instead. This should be trivial enough in theory, one would think, but I've spent three or four hours today and it frustrates me to no end.

Things I've done so far:

- set the Magical bit in the Flags field

- played around with "maximum in stack" field (set it to 1)

- in the "Magical" header: set "drained" field to zero (item remains), set number of charges to 10, remove "recharge after resting" flag, tried to switch around the projectile (it has "None" by default)

At some point, I've just started to compare the item with another one that behaves in a desired fashion (any wand, basically) and change things around. Nothing helps. The item still ends up having one charge, after that it remains drained. My only theory is that something is up with the kind of effect it uses (146, cast spell from resource).

What am I doing wrong?

Cheers,

critto

Thank you very much for tests and publishing a bug report!

However, if one uses a patch mentioned earlier in this thread, you can summon lots of rabbit even if their gender is SUMMONED because their allegiance is set GOODCUTOFF. I am not sure if this should be mentioned in the ticket as well. Probably, it does.

So yeah, I've studied some of the existing solutions you guys have proposed.

In the d0Tweak Pack, as Jarno has described, the author introduces another gender and replaces all references to it in the game's files.

In the Tweaks Anthology a simple patch to summlimt.2da is employed.

While all this is interesting, it is not much of a help, sadly. As was stated above, the creature (WISH01.CRE) does not have its gender attribute set to SUMMONED. Therefore, tinkering with gender.ids probably wouldn't help.

I tried to play around with the Genie creature's attributes and see if anything positive would come out of it. Nothing did.

If the limit of summoned creatures is not yet reached, I can cast Limited Wish however I want and even summon a couple of rabbit hordes. After that I can still summon up to 5 of the usual summons. Then it's over, no more Limited Wish. I guess there's some kind of engine-level counter which is increased when a player-controlled char summons a creature, and "indirect" summoning (as is the case with Limited Wish's rabbits) is not considered the same thing.

Is there any way to ask the devs from Beamdog directly to comment on this?

This is somewhat a continuation of this thread from the Beamdog forums.

Could somebody please clarify why the genie from Limited Wish and similar things count towards the summoning limit? His allegiance is set to Neutral and Gender to Niether which does not correspond to the info I've found on the subject so far (basically, the stuff described in the thread linked above).

Cheers,

critto

 

I've discovered a bug in the script action TakeItemListPartyNum() which heavily affects the item importation process during the SoD/SoA transition. ApparentlyTakeItemListPartyNum() doesn't properly transfers items found in bags or cases. The items are removed from the inventory, but not added to the target container.

 

For what it's worth, I have discovered a bug with TakePartyItemNum as well. If several calls of this function that take the same item are present in a single code block, only one would actually take place, i.e.:

TakePartyItemNum("potn24",1)   DestroyItem("potn24")
TakePartyItemNum("potn42",1)   DestroyItem("potn42")
TakePartyItemNum("potn42",1)   DestroyItem("potn42")

This only happens when the items are located in the characters' inventories. If they are sitting in bags or containers, the game will take all the items properly. Quite strange. The solution is to use a single call with an appropriate amount of items which appears to be working fine.

It might be a bit of a strange scenario and not entirely relevant to what argent77 said but I thought I'd mention it just in case for anyone who's interested.

Check out this thread http://gibberlings3.net/forums/index.php?showtopic=28095