Jump to content

Items that simulate spells


Miloch

Recommended Posts

retard.cre (name: ANGELO) isn't even in BG2. It's BG( X != 2) where the .cre appears.

 

These items are still undroppable-robe-of-Vecna magnitude of lame, and they have different ascii trash than the spells do in their effects' resref field, so they're probably this way on purpose :(

Link to comment
retard.cre (name: ANGELO) isn't even in BG2. It's BG( X != 2) where the .cre appears.
Ah. Well I was referring to galdor.cre (Angelo), which is used and has some of the same items.
they have different ascii trash than the spells do in their effects' resref field, so they're probably this way on purpose :(
Could you explain that please, or point out an example. Not sure I'm seeing the same thing.
Link to comment

A v1 effect structure has, at 0x14, a resref field. Even though few effects actually use this field, there's generally some unused junk written there (devSin theorizes that it's just whatever was resident in the editor memory at the time, and that's as good an explanation as you're likely to get). It's not ascii text, it's just random non-null bytes.

 

If the devs were copying an effect from a spell to an item, one would expect the effect's parameters to be the same in both cases. But they're not, magebrac.itm has 0x000000a414450004 in the resref field, and spwi406.spl has 0x0000801e2c000400. So either the devs copied the effect, and for no reason only updated the field that isn't at all used while forgetting to update the fields that are, or the spell and the item were created seperately and there wasn't any copying.

 

The effects are also in a different order and there's a different total number of effects.

 

The only real advantage to sourcing spell effects from an item is that you can script removal of that item and thereby get rid of those effects and only those effects which are tied to the item, which can't be done with spells. But these items have a duration attached to their effects, so removing the item doesn't do anything, so that potential advantage is mooted :(

 

Pointless.

Link to comment
Even though few effects actually use this field, there's generally some unused junk written there (devSin theorizes that it's just whatever was resident in the editor memory at the time, and that's as good an explanation as you're likely to get).
If that is true, memory could've been highly variable, and could've changed before and after such a copy. What if this field were merely a "date/time last changed" stamp or the like? Plus, we don't have any idea what in-house develpoment tools they may have had to make such a copy, do we? I know I don't anyway, but they could well have tools that cloned and copied certain things and not others (particularly not "unknown/unimplemented" bytes).

 

Also note I'm not suggesting this for the fixpack - it's for a mod (and I haven't decided which mod... for now I'm using the routine wherever I touch one of these CREs since the items bug me). So I don't really want to get into Yet Another Argument about developer [lack of] intent. I've long given that up anyway, since I've realised no one will ever agree :).

But these items have a duration attached to their effects, so removing the item doesn't do anything, so that potential advantage is mooted :( Pointless.
They *had* a duration, until my fix/tweak/whatever above. Unless someone can confirm the duration [re-]activates every time a PC is sighted, is "while equipped" good enough? Yes, if I were modding CREs and their scripts from scratch, I would give them Mirror Image or whatever, and a script that casts it at the beginning of combat, but that isn't always feasible. For my current purposes, I'm just trying to correct existing ones without being too intrusive.

 

Oh and while you're here, do you mind if I pinch your "EFFv1>EFFv2 updating code" for another mod. I'd ask in Lvl1npcs or weapprof or whatever, but I forget where I got it originally and the thread is getting quite cluttered without a proper forum. Just want to make sure this part of your code at least isn't buggy (as far as you know). I've used it successfully, just haven't playtested it at all (that would be foolish: it might actually point out a bug, and we wouldn't want that ;)).

Link to comment

The various unused fields aren't timestamps, that much is fairly certain.

 

These items in their original state will have their duration begin when equipped, and in the case of a creature where the item is already assigned to an equipment slot, the duration begins when the creature is created. Sighting won't make difference, and the player would have to re-enter the area to begin the duration again (or run one of the scripting actions that force an inventory rebuild, I don't recall offhand which).

 

Steal away (thanks for asking, but it's free game). It won't be necessary in BG1 (and would be harmful without Totsc!); BGT I don't know about (the devs converted most of the leftover BG1 resources when they assembled the .bifs for BG2, including all but a handful of the unused .cres).

Link to comment
Steal away (thanks for asking, but it's free game). It won't be necessary in BG1 (and would be harmful without Totsc!); BGT I don't know about (the devs converted most of the leftover BG1 resources when they assembled the .bifs for BG2, including all but a handful of the unused .cres).
It's only relevant for Tutu. BGT NPCs already use v2 EFFs, and BG1 CREs don't use attached EFFs (they use the bytes at 0x6e etc. for proficiencies), though I skip it if the platform is BG1 anyhow.
Link to comment

Well, NPCs don't use EFFs by default in BG1, for proficiencies (or anything else). Like I said, they use the bytes at 0x6e etc. instead.

 

The reason I'm using the EFF code is I'm allowing in "Gnomes" the changing of weapon proficiencies for Quayle and Tiax, which are pretty wack. They get completely different proficiencies in Tutu and BGT than what they had in BG1. Partly the reason for this is they didn't have the STR requirements for the weapons. In BG1, this requirement is ignored (or not implemented/enforced). So in Tutu, Quayle gets a mace instead of a flail. Well, he doesn't even have the STR for *that*. And he gets a quarter staff in BGT, which I think is pretty silly. A real quarterstaff is about 6' long, twice the height of a gnome. You can't proficiently wield a quarterstaff that's twice your height - it's just absurd. And a half-sized one obviously wouldn't inflict as much damage.

 

Anyway, my point is I don't have to mess with EFFs in BG1 for proficiencies, since I can just WRITE_BYTE the proficiency differences. In some ways, this is derivative of some functions in your "Level 1 NPCs" mod, but I wrote most of the code from scratch (I guess as a learning experience), the only thing I swiped was the EFF changing code for Tutu cause I couldn't be bothered to figure it out on my own ;). Plus I wanted to simplify the functionality for "Gnomes" and, well, Lvl1NPCs isn't officially non-beta yet. Not that the next version of "Gnomes" *is* but... I'll race ya! :(

Link to comment
Well, NPCs don't use EFFs by default in BG1, for proficiencies (or anything else). Like I said, they use the bytes at 0x6e etc. instead.

 

They use V1 effs (the same 0x30 structure you'd find in a spell or item) every time an opcode is applied to a cre. That includes LOCALS and various ad hoc timing mode 4096 effects that the engine applies automatically. Proficiencies are stored differently in BG1/PST/IWD, but effects aren't used differently.

 

Cast a spell, save your game, and take a look.

Link to comment
Well, NPCs don't use EFFs by default in BG1, for proficiencies (or anything else). Like I said, they use the bytes at 0x6e etc. instead.
Is that clearer? ;) By "by default" I mean as they're delivered by the game. Obviously, I wouldn't be modding CREs in people's saved games, before or after any funky spells are cast on them :(.
Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...