ACR Resting system

[AcadiusLost]

Hmm, guess I didn't explain that observation very clearly- the issue is with multiclassed casters who have access to both divine and arcane spells, or both innate and studied spells, for example. A multiclass cleric2/wizard2 would have both their cleric and wizard spells refreshed by praying, or by studying, whichever they did first. Likewise, a Wizard3/Bard2 would see their bardic abilities also refreshed by studying their spellbook. Ideally- only a caster's divine spells would be refreshed by praying- only their innate spells would be restored by resting, etc. Unless we can control the memory slots more specifically, it's not something I think we can work around. On the other hand, I'm looking through acr_spelltrack_i, and perhaps we have the tools after all, via a combination of the tracking on the PC skins, and functions like DecrementRemainingSpellUses(oCaster, nSpellId). I might play with it this week if I can find the time.

with regard to the "flash studying" concern: the actual code from the studying function looks like this:

Code: Select all

AssignCommand(oCaster, ActionPlayAnimation(ANIMATION_LOOPING_MEDITATE, 1.0,       HoursToSeconds(ACR_REST_STUDY_DURATION)));
AssignCommand(oCaster, ActionDoCommand(_playerRestoreSpells(oCaster, GetCurrentHitPoints(oCaster))));

So cancelling the looping animation really shouldn't have any effect on whether or not the spells are restored- it's a separately assigned action (unless cancelling the animations clears the action queue in NWN2). The Rest events /do/ have this sort of functionality, since OnRest is called both at the beginning and the end of an attempt to rest- with local variables indicating whether it was fully and successfully completed. As such, it's a far more robust vehicle for enforcing a full rest cycle to renew caster abilities. That said- a caster can only pull one such "flash renewal" before needing to rest, so maybe it won't be as big a concern as it seems.

[edit: Also, should we be restricting the conditions under which spellbooks are studied / spells are prayed for? Requiring a legitimate trigger rest zone seems a bit much for it- but perhaps at least checks to make sure there isn't combat going on at the time- potentially concentration checks for extreme weather as well, once that's in.]

[ç i p h é r]

Hmm, guess I didn't explain that observation very clearly- the issue is with multiclassed casters who have access to both divine and arcane spells, or both innate and studied spells, for example. A multiclass cleric2/wizard2 would have both their cleric and wizard spells refreshed by praying, or by studying, whichever they did first. Likewise, a Wizard3/Bard2 would see their bardic abilities also refreshed by studying their spellbook. Ideally- only a caster's divine spells would be refreshed by praying- only their innate spells would be restored by resting, etc. Unless we can control the memory slots more specifically, it's not something I think we can work around. On the other hand, I'm looking through acr_spelltrack_i, and perhaps we have the tools after all, via a combination of the tracking on the PC skins, and functions like DecrementRemainingSpellUses(oCaster, nSpellId). I might play with it this week if I can find the time.

Ah, now I understand. As you indicated, we can solve this by tracking which spells have been cast (probably via spell hook). It's a more involved solution I think but it's become a necessity, unless we create separate spell ID arrays for divine and arcane spells through which the scripts loop.

So cancelling the looping animation really shouldn't have any effect on whether or not the spells are restored- it's a separately assigned action (unless cancelling the animations clears the action queue in NWN2). The Rest events /do/ have this sort of functionality, since OnRest is called both at the beginning and the end of an attempt to rest- with local variables indicating whether it was fully and successfully completed. As such, it's a far more robust vehicle for enforcing a full rest cycle to renew caster abilities. That said- a caster can only pull one such "flash renewal" before needing to rest, so maybe it won't be as big a concern as it seems.

Any time a player moves, it resets the action queue, so in order to successfully refresh spells, the player's action queue must remain intact for the duration of the prayer/study animation. The script queues everything up in the proper order - pray/study animation then refresh spells - so unless NWN2 just "fast forwards" through the action queue when a player interrupts it with a move request, it should function correctly. Are you observing this "flash rest" behavior or were you just trying to determine how things work?

Also, should we be restricting the conditions under which spellbooks are studied / spells are prayed for? Requiring a legitimate trigger rest zone seems a bit much for it- but perhaps at least checks to make sure there isn't combat going on at the time- potentially concentration checks for extreme weather as well, once that's in.

If I understood the question, praying/studying shouldn't require a rest zone trigger. It just requires an activation method, but you can only pray/study once per rest cycle.

[ç i p h é r]

Hmm, guess I didn't explain that observation very clearly- the issue is with multiclassed casters who have access to both divine and arcane spells, or both innate and studied spells, for example. A multiclass cleric2/wizard2 would have both their cleric and wizard spells refreshed by praying, or by studying, whichever they did first. Likewise, a Wizard3/Bard2 would see their bardic abilities also refreshed by studying their spellbook. Ideally- only a caster's divine spells would be refreshed by praying- only their innate spells would be restored by resting, etc. Unless we can control the memory slots more specifically, it's not something I think we can work around. On the other hand, I'm looking through acr_spelltrack_i, and perhaps we have the tools after all, via a combination of the tracking on the PC skins, and functions like DecrementRemainingSpellUses(oCaster, nSpellId). I might play with it this week if I can find the time.

Ah, now I understand. As you indicated, we can solve this by tracking which spells have been cast (probably via spell hook). It's a more involved solution I think but it's become a necessity, unless we create separate spell ID arrays for divine and arcane spells through which the scripts loop.

So cancelling the looping animation really shouldn't have any effect on whether or not the spells are restored- it's a separately assigned action (unless cancelling the animations clears the action queue in NWN2). The Rest events /do/ have this sort of functionality, since OnRest is called both at the beginning and the end of an attempt to rest- with local variables indicating whether it was fully and successfully completed. As such, it's a far more robust vehicle for enforcing a full rest cycle to renew caster abilities. That said- a caster can only pull one such "flash renewal" before needing to rest, so maybe it won't be as big a concern as it seems.

Any time a player moves, it resets the action queue, so in order to successfully refresh spells, the player's action queue must remain intact for the duration of the prayer/study animation. The script queues everything up in the proper order - pray/study animation then refresh spells - so unless NWN2 just "fast forwards" through the action queue when a player interrupts it with a move request, it should function correctly. Are you observing this "flash rest" behavior or were you just trying to determine how things work?

Also, should we be restricting the conditions under which spellbooks are studied / spells are prayed for? Requiring a legitimate trigger rest zone seems a bit much for it- but perhaps at least checks to make sure there isn't combat going on at the time- potentially concentration checks for extreme weather as well, once that's in.

If I understood the question, praying/studying shouldn't require a rest zone trigger. It just requires an activation method, but you can only pray/study once per rest cycle.

[AcadiusLost]

Committed my PreRelease ACR version of this code.

Changes: Both praying and studying use ANIMATION_LOOPING_SITCROSS, as MEDITATE, WORSHIP, and many others seem to be overridden by normal ambient animations despite the 120 second duration. These function as they should- PCs moving, fighting, etc will need to try again, waiting until the animation loop is finished to get their spells. The blueprints for base palette spellbook and holy symbol items describe this, but it's likely to confuse people until they get the hang of it.

Resting no longer blanks out casters' spell memory, whether successful or unsuccessful (cancelled, etc)- they come out of the attempted rest with the same remaining spells they had when entering it (except for innate casters). This should be the desired behavior, as I understand it.

[ç i p h é r]

Nicely done.

[AcadiusLost]

An observation with testing this system on 003: We're currently using the standard ~ 9:1 time compression (7 real-life minutes per game hour), and the scripted duration of studying and praying for spells is set for one IC hour (meaning 7 Real-life minutes).

Should we scale this back for playability? We've still got "resting" taking the default time (15 seconds?) as the code doesn't enforce the 120-second constant we set in the header of acr_resting_i.nss - so innate casters get off pretty light by comparison. I'd got the impression (likely due to my early test module's time ratio settings) that we were using 2 real-life minutes for the prayer/study duration, which seemed enough to emote a bit, etc. Seven seems somewhat excessive as a mandate- if nothing else if we're keeping it there, I'd like to update the holy symbol and spellbook descriptions to reflect the actual duration.

[Thangorn]

on the testing side of things..

In my Template Inn: Since you sent me the updated hak Acadius, the resting triggers are working ie. you cant rest anywhere else but the trigger.

however they are just allowing normal 5 second rest at this time.. is that what they are supposed to be doing?

[AcadiusLost]

I'd guess the earlier problems were from other scripts that hadn't compiled thanks to the nomenclature change on "Prot. from Chaos." with 1.06. Anything that had acr_spawn_i included anywhere would have had problems.

I don't think our scripts are using the ACR's intended 120-Real-life seconds for resting, it's possible we're not set up to override the default rest duration yet. I'll look into it when I've got a module open, though I'm holding any commits on the acr_resting_i.nss file until Cipher finishes the NWNx4 retrofit.

[ç i p h é r]

The rest durations are handled by 2DAs. Looks like I never committed that to the repository! Easily rectified. You can grab it here if you want it:

http://alfa-bmf.svn.sourceforge.net/vie ... a?view=log

[AcadiusLost]

We will probably be adding the 120 sec resting with the ACR update, so people can try to get a feel for whether it's really disruptive to play or not.

One thing I wanted to ask about though: currently resting outdoors can only occur within the bounds of an "exterior rest trigger"- and PCs have no way of knowing where those are. For some PCs (druids/rangers/barbs) it may be more IC to pitch a tent in the woods than to buy an inn room- it should also be an option (albeit an undesirable one) for PCs who can't afford a room for one reason or another.

Should builders be defining large swathes of their areas as rest-able, or did we have some mechanic in mind which would allow a pitched tent or bedroll to drop a "rest zone" AoE of some kind? If so, did we want to restrict that at all for weather or other factors?

There was also a request for an OOC report to the player on failed resting attempt (not tired enough) that indicates how many game-hours need to pass before they can rest. I can script that part up, shouldn't be hard.

Do we want to also include a mechanism by which the need for rest is waived if the PC has been logged out for >= 24 game-hours? This would save PCs having to find a restable area and run the 2-minute timer at the start of each session, if they logged out with some spells used.

[indio]

Should builders be defining large swathes of their areas as rest-able, or did we have some mechanic in mind which would allow a pitched tent or bedroll to drop a "rest zone" AoE of some kind? If so, did we want to restrict that at all for weather or other factors?

Love this idea. I wouldn't factor weather in myself.

There was also a request for an OOC report to the player on failed resting attempt (not tired enough) that indicates how many game-hours need to pass before they can rest. I can script that part up, shouldn't be hard.

Yeah, that's helpful OOC info.

Do we want to also include a mechanism by which the need for rest is waived if the PC has been logged out for >= 24 game-hours? This would save PCs having to find a restable area and run the 2-minute timer at the start of each session, if they logged out with some spells used.

Definitely.

[AcadiusLost]

On the "off-camera" resting topic: in re-reading Cipher's system description, I noticed he'd planned to allow you to log in fully rested if you'd logged out within the bounds of a legitimate rest zone (and been logged out for the requisite 8 or 24 game-hours). I'm not sure offhand if this part is coded yet, though I'd be tempted to switch it to give this behaviour even if you log off outside a rest trigger. If you only play monday nights, for example, it's reasonable to assume your character got some rest offcamera in the long span between sessions. One could argue that they're getting away with rest and healing without paying for inn rooms, etc- but I'd argue that it's even less desirable to have them still tired/lacking spells/fully wounded after that timespan.

I also wonder what happens if a PC camping in the woods logs out at their campsite- should it despawn until they log back in if they're alone? If it persists, other players may discover it (though the PC would be nowhere to be found)- which makes for odd RP- more so if they decide to strike the camp and walk off with the tent before the camping PC logs back in and wakes up lying on a rock in an empty field, hah.

The joys of scripting systems for a persistent world.

[ç i p h é r]

Yes I had planned for it, but I'm not certain that I implemented it fully as a result of persistence hurdles with PC skins. By the time the OnClientLeave script executes, the player object is already gone (albeit information about the their character still lingers) so storing timer info on the PC skin at that point wouldn't actually be saved.

With NWNx4 however, this becomes feasible. Character data can be stored persistently even on log out - I cached the requisite player info for writes to pwdata on the pc object. I know the rest logout timer is being saved to the database since the NWNx4 retrofit, but I didn't think to test whether that part of the system works. Something to re-examine. IIRC, the rest check occurs on login and only if the PC logs into a rest zone, which I have no objection to removing. It may have been a compromise between various view points at the time.

[AcadiusLost]

I set the ACR_REST_CYCLE to 24 game hours (2.8 actual hours by our current compression), and altered the ACR_STUDY_TIME and ACR_PRAY_TIME to be floats, to allow us finer control over them- set for 0.25 game-hours for now (1 minute and 45 seconds). I'll see how it feels ingame, we may try something a bit longer.

In terms of the logging in rested perk we discussed, I cleaned up the code to check to make sure a rest cycle has passed since last login, then removed the _PlayerCanRest() conditional (since we're already checking the time validity externally on the RestOnPCEnter, the only thing it was adding was the rest zone check, which we wanted to circumvent anyway).

The system still uses _PlayerRestFinish() to mediate the login/rest, so that will have to be switched for a new function (or just new code) that accomplishes the same thing with the following caveats:
1. Allows greater healing, if the PC has been logged off for several rest cycles.
2. Does not update the last rested timestamp, so the PC doesn't have to wait another 24 IG hours (2.8 RL hours) to be eligible for another rest.

[ç i p h é r]

Sounds good.