Feature Specification: Resting

[indio]

Indeed you were. Here is the archive link for the complete Rest Team proposal:

http://www.alandfaraway.org/phpbbforum/ ... hp?t=12060

[ç i p h é r]

So how much of that was actually implemented? These are well defined and I can add them here easily enough.

My take on what was bounced around in the ensuing discussion:

Rest time (healing) - 1 to 3 mins? Two minutes sounds like the obvious compromise.

Nap time (rp only or DM force rest) - standard 10 secs?

Separate "rest" effects (blinding, sleeping, and healing) from praying/studying. We could conceivably do this by having various versions of "resting" activated by appropriate items. For instance, we could have a clerical item to simulate prayer that triggers an engine rest, but would leave out the blindness effect and revert any healing that may occur in the process. Same idea for studying but simply a different animation/simulation. But perhaps I'm overlooking something that prevents this from working the way we'd like.

[Creslyn]

None were implemented, as the time taken to rest is tied to level.

[Blackwill]

None were implemented, as the time taken to rest is tied to level.

I wouldn't like that at all.
A lvl1 PC should nap as long as a lvl12 PC IMHO.

[ç i p h é r]

No aspect of the proposal was implemented?

And I'd have to agree with Blackwill on level based rest times. Where did THAT originate...?

No matter. There are good ideas in that proposal and I'm very much in favor of being as close to canon as possible in our implementation.

[Fionn]

I believe Bioware resting time is tied to level.

There is no reason we can't completely bypass resting and use scripts off the Emote wand (Rest for the night, Study for Spells, Pray for Spells, Nap). These could be set for whatever time we wished, trigger whatever effects we wanted, and use whatever animations we choose.

[ç i p h é r]

Updated to include most requirements from the resting proposal. I left out Coup-de-Grace and the uncanny dodge exception. Reading the rules, there is some doubt as to what takes precedence here: helpless defender or uncanny dodge. In reading the uncanny dodge description, it does state that the benefits of this ability are negated when immobilized, which is the definition of "helpless". So, I'm inclined to think the rules exempt uncanny dodge from applying to a helpless defender. Thoughts?

I believe Bioware resting time is tied to level.

Jeez...I guess I need to play more. Either I've never noticed that before or it was introduced in the last year or two.

There is no reason we can't completely bypass resting and use scripts off the Emote wand (Rest for the night, Study for Spells, Pray for Spells, Nap). These could be set for whatever time we wished, trigger whatever effects we wanted, and use whatever animations we choose.

I didn't think so. I think this is fairly straightforward to script.

I'll add that in using the rest time numbers I posted above. Feel free to comment.

[Ronan]

Some thoughts I had on resting:

I thought to create a seperate system for tracking creature status, since this is something which can be shared by the pet/familiar system as well as be used on PCs. This wouldn't really effect the rest event except to add maybe three lines, ClearCreatureStatusSpellUse(), ClearCreatureStatusFeatUse(), and SaveCreatureStatus(). Data is stored on the PC's storage item, but this is transparent to the resting scripts.

I think a bigger thing is needing spellbooks or divine favor (see acr_deity_i) to prepare spells. We can't keep a PC from regaining spells on one class without stopping him from gaining spells on all classes. But we could send him a message saying he wasn't able to regain spells of class X, and then stop those spells from functioning as they are cast in the spellhook. Its not a perfect solution, but I think its the only one we've got.

[ç i p h é r]

Generally speaking, that's much the same way I presumed it would work, unless NWN2 offers us more granular control over spells. As with everything we do, plan for worst case but be ready to adjust if the opportunity is there.

[ç i p h é r]

In scripting this, I came across a situation that I was unsure about so I'll put it up for discussion here.

Resting is allowed every 8 hours under certain conditions. Spell recovery however is only allowed once per day. At the moment, whether spells are used or not, I assume a spell caster loses all their spells once they rest. Sorcerers regain them automatically and wizards require an hour to study them (and divine casters require prayer), but only once per day and only after a successful rest.

The problem is, if the player has not spent all their available spell uses for the day but opts to rest for the 2nd time on the same day, they will lose all their remaining spells and won't be able to recover them until at least the beginning of the next day. Therefore, my question is, should spell casters keep the remaining spell uses they have until they cast them (or switch them), even after a rest?

Opinions?

[Ronan]

Therefore, my question is, should spell casters keep the remaining spell uses they have until they cast them (or switch them), even after a rest?

I think yes, certainly, but I'm not sure we should limit spell recovering to once per day. Its already a rather large PITA when you go to start a quest, but you can't get any of your spells back when everyone else is resting and preparing, becuase you've rested a few hours earlier. In addtion, the passage of time is pretty abstract, especially during travel.

Though on second thought, all this could be moot if we give DMs a tool to allow a PC to rest regardless of the last time he rested.

Oh, its a small thing, but you might want to forgo the blindness on elf and half-elf characters while they rest.

[ç i p h é r]

I think yes, certainly, but I'm not sure we should limit spell recovering to once per day. Its already a rather large PITA when you go to start a quest, but you can't get any of your spells back when everyone else is resting and preparing, becuase you've rested a few hours earlier. In addtion, the passage of time is pretty abstract, especially during travel.

I have no strong opinion on the subject frankly - I can appreciate both points of view on this one. It simplifies the logic to tie everything to rest certainly but that shouldn't be our benchmark.

Oh, its a small thing, but you might want to forgo the blindness on elf and half-elf characters while they rest.

Because they meditate instead of sleep? It's a good way of dealing with the players "awareness" of his surroundings if that's the case.

[ç i p h é r]

Ok, I committed an initial rev of the scripts to the repository. As mentioned, I haven't optimized spell use management or condition recovery as yet. That will depend in no small part on what features, events, and API extensions we get with NWN2. I also added the module config files per the spec.

Feel free to have a look. Ronan, let me know if you want me to revise anything.

[Ronan]

Glanced it over briefly, and I had a few comments. I'll look it over in more depth later,

acr_pc_persist_i is the script I've been using to access the PC's persistant storage object (c-skin currently). In case this object changes at some point in the future, I though it was best to centralize the access to it. A call to GetPCPersistentStorageObject(oPC) retrieves it from a PC. It was my thoughts that all ACR scripts needing to store persistant data on the PC use those functions. Its my intention to prevent server-side scripts from removing or destroying the storage object by having OnItemUnaquire call the GetIsPCPersistantStorageObject() function in acr_pc_persist_i as well.

acr_game_loc_i is what I was using to store persistant locations. NWN's location datatype is basically an area object id and a vector, so in order to store a unique location which persists across module updates (which often change the object ID), we need to store the area (need both the tag and resref to do this, since we can't retrieve an area by resref alone), vector within that area, and the server Id. The small API within acr_game_loc_i should do this, and it was my thoughts that all ACR scripts should use this API. In hindsight I should have also added functions to persistantly store server-variables as well, but they aren't there currently.

Was also wondering why you didn't use the debugging framework?

Also, how come you stuck everything up under /basemod? I thought to put things under /nwn2 so we didn't get ALFA1 and ALFA2 stuff mixed up.

Edit: I think we should create an event of our own, called OnClientLoad, which fires when a client finishes loading his first area after entering the module. There are a number of things which may need to be run from here, and we can combine them into an event handler (with a corrisponding acf file) for better organization. Any objections?

[ç i p h é r]

acr_pc_persist_i is the script I've been using to access the PC's persistant storage object (c-skin currently). In case this object changes at some point in the future, I though it was best to centralize the access to it. A call to GetPCPersistentStorageObject(oPC) retrieves it from a PC. It was my thoughts that all ACR scripts needing to store persistant data on the PC use those functions. Its my intention to prevent server-side scripts from removing or destroying the storage object by having OnItemUnaquire call the GetIsPCPersistantStorageObject() function in acr_pc_persist_i as well.

Just your simple garden variety confusion. I *thought* that was part of the persistent pc status project, as well as "status" logging and restoring. I'll check it out and adjust as needed. Looks like we duplicated some minor effort, but not a big deal.

acr_game_loc_i is what I was using to store persistant locations. NWN's location datatype is basically an area object id and a vector, so in order to store a unique location which persists across module updates (which often change the object ID), we need to store the area (need both the tag and resref to do this, since we can't retrieve an area by resref alone), vector within that area, and the server Id. The small API within acr_game_loc_i should do this, and it was my thoughts that all ACR scripts should use this API. In hindsight I should have also added functions to persistantly store server-variables as well, but they aren't there currently.

Roger. I'll take a look and reconcile the differences.

Was also wondering why you didn't use the debugging framework?

Because there wasn't anything specifically noted in the specification for debugging or logging. I figured our needs would eventually reveal themselves once we had something functional and we got requests to add certain information. Just to be clear, my interpretation of the intent of a debugging system is to provide builders and server admins with the tools they need to diagnose real time problems, not as a test tool for developers to evaluate their scripts.

On a similar note, for persistent status, I added a few log entries just as placeholders for a more central logging system. I wasn't sure if this should be part of 1984 or debug, to be honest. But I didn't want to forget.

Also, how come you stuck everything up under /basemod? I thought to put things under /nwn2 so we didn't get ALFA1 and ALFA2 stuff mixed up.

I posted a note about this earlier. Given the time remaining before NWN2 arrives and the resources we have on the tech team, I didn't see the purpose in maintaining a repository for both versions. I only wanted NWN1 content in there initially to get a handle on sourceforge and do some testing with file releases, but again, time and resources permitting. At this juncture, I'd rather invest the time and resources on NWN2 and avoid committing anything more to content we intend to replace.

Do you have a different opinion? Do you see a need for separation? I interpretted the lack of response to my initial recommendation as agreement. We still need to migrate the files over, but I didn't want to do that until you were ready.

Edit: I think we should create an event of our own, called OnClientLoad, which fires when a client finishes loading his first area after entering the module. There are a number of things which may need to be run from here, and we can combine them into an event handler (with a corrisponding acf file) for better organization. Any objections?

I was actually hoping/expecting to get an OnSpawn event like we do for NPCs. That should tell us definitively when a player is actually IN the game, unlike the present which requires a small work around (you probably noticed that). Obviously, it's not possible to test an event that doesn't yet exist, though we could simulate it with custom events (for testing purposes) now that I think about it. Nevertheless, it's an easy change we can make once we have an actual list of events from Obsidian.