Item expiry effects

[devSin]

CamDawg: split from this thread, which is why this reads so randomly. /edit

 

I'd dallied on doing that in case the expiry were intentional, but when would it ever be?

Never. And we still have no idea exactly how the engine determines when to delete the item (the value is only ever set by the create item effect that specifies a duration in days, and it's the only value used to track the duration).

 

Most of these won't have an appreciable effect, but anybody who picks up bullets for Jaheira from the duergar in Irenicus' dungeon might have noticed that they up and disappear after a day or two (taking any "clean" bullets that were later added to the stack with them).

[Nythrun]

And we still have no idea exactly how the engine determines when to delete the item.

 

Using the Create Item opcode with a non-zero duration applies a Remove Item embedded .eff to the relevant creature; the duration field here is, I think, ( (Game Seconds Elapsed + Create Item Duration) * 15) - the duration field in the item isn't even used (you know this already I'm sure).

[devSin]

All the create item effects behave this way except for the one that specifies the duration in days. This effect doesn't add the Remove Item effect, but simply sets the duration field of the attached item structure to some value, and the engine uses this exclusively to determine when to destroy the item.

 

We had a discussion back when I was doing a lot of research (it's somewhere in the IESDP forum), but I wasn't able to easily see how the value is used (but it wasn't important enough to really investigate).

 

The problem here is that those non-zero values are tricking the engine into thinking these items were created with the effect, so it dutifully removes the items after some amount of time (however the duration corresponds to the value at +0x8).

[Nythrun]

Much like the duration field in the embedded effects, this isn't a duration field at all, it's the elapsation time

 

Rather than a short, it's a pair of byte fields:

 

First byte: Hour (Zero days zero hours into the game is actually hour 23 here)

Second byte: Number of 256 hour cycles that have elapsed, beginning with 01.

 

Thus, casting Enchanted Weapon on day 10 hour 0 (roughly 72000 on the game clock) would yield 0x07 0x02 in these fields, and casting it one day earlier would have yielded 0xef 0x01.

 

This explains why items that have 0x0001 in this field always disappear immediately, as they're already living on borrowed time

 

Edited to add:

 

Also, and this is actually somewhat important, the engine is applying an opcode 0, timing mode 4096 effect to the character casting Enchanted Weapon with the duration field filled by the A.I cycle at which the created item should be destroyed. This effect persists for one A.I. cycle only (so unless you save directly off of an auto-pause, you'll never see it). Meaning that duration effects are using opcode 0 to create ad hoc placeholder effects. Meaning that little Miss Smartypants who created an axe that sets AC to 10 and prevents modifications of that stat while granting damage reduction and a chance of Enrage on hit is really just klutzily breaking things again.

 

Opcode 0 joins secondary type 1 in the growing pile of That Which Must Not Be Forbidden, Silly Modders.

 

Edited to add to the addition:

 

Of course, this still doesn't answer what happens when the second byte here is zero and the first byte is non-zero - such items don't disappear immediately though.

[devSin]

I'm not quite visualizing this as I should, and since I don't have the game installed to look, you're going to have to clarify.

Much like the duration field in the embedded effects, this isn't a duration field at all, it's the elapsation time

I assume you mean "expiry" time? (All stored timers are really just expiry time, and the game just does a simply cur_time >= expiry to figure out if it expired.)

First byte: Hour (Zero days zero hours into the game is actually hour 23 here)

Second byte: Number of 256 hour cycles that have elapsed, beginning with 01.

 

Thus, casting Enchanted Weapon on day 10 hour 0 (roughly 72000 on the game clock) would yield 0x07 0x02 in these fields, and casting it one day earlier would have yielded 0xef 0x01.

Why does 0:0 start at 23? Does this decrement (from 23 to 0 and wrap), meaning that after 0 comes Day 1?

 

Is this "256-hour" or "256 hour-"; does it wrap around to 0 at 255 (with 0 being the last cycle in the hour)? Or is it capped at literal 255 (wrapping around to 1)?

 

Are you saying it's writing (8h 0x2, 9h 0x7) or in the order you've written (I'm assuming from the values that you're stating LE 0x702 and 0xef01)?

 

You state that this is storing elapsed time, but I assume you mean expiry time (tracking when the effect was run doesn't really help you figure out when it should expire)? (The values are never updated after they're assigned, right?)

This explains why items that have 0x0001 in this field always disappear immediately, as they're already living on borrowed time

If the bytes are storing a simple counter for determining the expiry time, care to post a few examples of values for this field converted to actual in-game expiry time so I can better see the relation here?

[Nythrun]

You're going to have to clarify.

Ok

By "elapsation time" I mean "time at which the effect elapses", equivalent to "expiry time" == "time at which expires". It doesn't store elapsed time at all. If you prefer the expiry nomenclature, no problem, it's just not a duration, which would properly be a linear function which is the antiderivative of this constant

Why does 0:0 start at 23? Does this decrement (from 23 to 0 and wrap), meaning that after 0 comes Day 1?

It starts at 23 because Enchanted Weapon has a duration of one day (actually twenty-three hours and change).

does it wrap around to 0 at 255 (with 0 being the last cycle in the hour)?

Yep

 

A mapping of the game clock (ignoring the particulars of any individual spell or effect) to this field would look like this:

Day  0 Hour  0	 Game Seconds 000000	 00 01 h
Day  0 Hour  1	 Game Seconds 000300	 01 01 h
Day  0 Hour  2	 Game Seconds 000600	 02 01 h
Day  0 Hour  3	 Game Seconds 000900	 03 01 h
Day  0 Hour 12	 Game Seconds 003600	 0c 01 h
Day  0 Hour 23	 Game Seconds 006900	 17 01 h
Day  1 Hour  0	 Game Seconds 007200	 18 01 h
Day  2 Hour  0	 Game Seconds 014400	 30 01 h
Day  3 Hour  0	 Game Seconds 021600	 48 01 h
Day 10 Hour  0	 Game Seconds 072000	 f0 01 h
Day 10 Hour 15	 Game Seconds 078500	 ff 01 h
Day 10 Hour 16	 Game Seconds 078800	 00 02 h
Day 10 Hour 17	 Game Seconds 079100	 01 02 h
Day 10 Hour 18	 Game Seconds 079400	 02 02 h
Day 21 Hour 07	 Game Seconds 153300	 ff 02 h
Day 22 Hour 08	 Game Seconds 153600	 00 03 h
Day 22 Hour 09	 Game Seconds 153900	 01 03 h

 

I too would have expected this to just be a short that incremented from zero. Anyway, I see two likely interpretations of 0xXY00 values in this field:

 

Hour XY of the current day, (where 00 becomes the trivial case) or

 

Over seven game years from the starting day (if this also wraps around)

 

If you've seen sling bullets with a shelf life, the former is strongly indicated

 

Edited to add:

 

Every single one of the values the above code seeks to correct is of this format ( 0xXY00 ) and is probably the result of a stack quantity being written into the expiry field.

[devSin]

I still don't see the exact equation beyond the limit of each track, but I understand what they're doing here now, thanks.

 

I doubt the value wraps around, so I'm not sure how track 0 runs. IIRC, I'm usually in Waukeen's when the bullets vanish, but I don't think I ever payed attention to see exactly how long it took after they were created for them to vanish.

 

The cases of this in the CRE files are indeed just junk (likely then propagated through lazy copy/paste).

[devSin]

Bump for Avenger.

 

This thread came from the fixpack forums but took a while to get here.

[aVENGER_(RR)]

I just noticed something interesting - when you call opcode #122 from a SPL by using an EFF, the expiry duration specified in the EFF gets ignored and the duration from the SPL is applied instead.

 

For example, I wanted to make the Magic Flute created via Bard HLA disappear after 8 hours rather than pointlessly sticking around for 24 hours, so I modified BRDFLUTE.EFF to use opcode #122 instead. So, I set the duration to 2400 in the EFF but, for some reason, the item kept disappearing a mere second after being created. I tried a bunch of different time values with no effect and then, in desperation, I changed the timing directly in SPCL921.SPL. Bingo! For some reason, this timer seems to be applied to the created item rather than the one which was specified in the EFF itself. Very odd.

[Avenger]

Is there any timing that is honoured in an applied .eff?

Or it always inherits the timing of 0xb1.

[devSin]

Yes, duration in the effect takes precedence (see summoning, item creation, etc.).

 

I'm not aware that duration is ever honored (nor timing mode or target); probably not dispel/bypass or probabilities, but saving throws and min/max level fields are respected (also from the effect, so you'd save once for the Use EFF effect and then again for the actual EFF for instance).

[igi]

Added. Thanks (I guess).