Request - Better persistence!
superfly2000
Member Posts: 76
Its really a chore to get most things truly persistent in a so called "persistent" world.
I think there is a whole lot of scripting thingies that could make it easier.
I know there is a plethora of scripting system for this on the vault but now we have a proffesional company that can make this really easy right? ;-)
I mean espacially to get loot respawning in chests...as well as getting the traps and locks to respawn...
I think there is a whole lot of scripting thingies that could make it easier.
I know there is a plethora of scripting system for this on the vault but now we have a proffesional company that can make this really easy right? ;-)
I mean espacially to get loot respawning in chests...as well as getting the traps and locks to respawn...
0
Comments
Trap and lock respawnning are already fairly simple scripts. While there will be some common behaviors across PW's there will be details that differ. Loot tables are a big one. For example Avlis doesn't drop items with Forgotten Realms references.
Speaking of pain points placeable inventory is one big fat ball of agony. The Bioware implementation was so bad that I had to abandon them in favor of using a dialog based interface for persistent storage and merchants.
The first issue is that placeables have a fixed capacity. While there's plenty of space for dungeon loot it gets far too tight for personal or guild storage.
The API for walking the inventory did not report exact positions which, thanks to Inventory Tetris, made restoring chest contents an exercise in frustration.
Ultimately it was item stack handling that made placeable inventories absolutely unusable. Drop a partial stack on a stack inside the container and it would only report -one- of the two stacks. Sure you could rewalk the entire inventory and compare it against your database but that's ridiculously slow.
Do you know if any of these script functions have stopped working?
CreateTrapOnObject
CreateItemOnObject
CreateObject
DestroyObject
Location
GetLocation
Vector
GetLastLocked
GetLastUnlocked
GetLocked
SetLocked
SetLockLockDC
SetLockUnlockDC
GetTrapDetectDC
GetTrapDisarmDC
GetTrapActive
SetTrapDetectDC
SetTrapDisarmDC
SetTrapRecoverable
SetTrapOneShot
SetTrapDisarmable
SetTrapDetectable
SetTrapActive
SetTrapDisabled
If a company tries to make a script for each request it might not be what you want, one shoe wont fit every foot. It's better that they make the lego blocks and people assemble them how they like. Perhaps what you might want to suggest is they make some very basic PW tutorials or a basic PW starter pack.
Normal doors and traps can not be placed/replaced if destroyed/disarmed.
A PW door needs to be indestructible with special scripts to handle checks or have a huge buffer of HP. (or have a fake door-like object that pretends to be the door)
A PW trap needs to spawn disarm-able objects tied to the trap and other complications. A spell like "Find Traps" will permanently destroy any traps unless changed.
Having a "ResetTrap" function would simplify things.
I can only guess at how doors are stored internally. Since PWs are such a big part of the game, maybe damaged doors are not really destroyed, just go into a destroyed state. Then a 'RecreateDoor" type function would 'respawn' it.
I also remember that respawning Encounters seem to remember the CR of the previous party. So you get the wrong difficulty if you happen to follow the wrong party.
The ability to iterate and insert areas is great!
Being able to change the scripts assigned to areas and other things could simplify things as well.
[I am just reading the forums now and have not done antthing with the EE edition yet]
- Extended the scripting command EffectHeal(), so that it now also works on doors and placeables.
This was part of the support for respawning door systems, which are definitely now possible.
Patch 1.67 also added a lot of support for trap & door stuff:
DM Client:
=-=-=-=-=-
- Added the ability for DMs to spawn in traps on doors/placeables through the creator (and quickbar slots dragged from the creator menu).
- Made custom triggers and traps from the DM creator menu spawn in correctly (rather than spawn in as a default trap).
Neverwinter Nights Aurora Toolset:
=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=
- Added a boat-load of new scripting commands (check the Toolset for more information):
GetHardness()
SetHardness()
SetLockKeyRequired()
SetLockKeyTag()
SetLockLockable()
SetLockLockDC()
SetLockUnlockDC()
SetTrapDisarmable()
SetTrapDetectable()
SetTrapOneShot()
SetTrapKeyTag()
SetTrapDisarmDC()
SetTrapDetectDC()
CreateTrapAtLocation()
CreateTrapOnObject()
SetWillSavingThrow()
SetReflexSavingThrow()
SetFortitudeSavingThrow()
GetTrapRecoverable()
SetTrapRecoverable()
GetKeyRequiredFeedback()
SetKeyRequiredFeedback()
GetTrapActive()
SetTrapActive()
- As if the above wasn't enough, we also added new parameters to the following scripting commands:
SetTrapDetectedBy(object oTrap, object oDetector, int bDetected=TRUE)
I haven't worked with the trap stuff personally much since before that patch, but the function set was enriched quite a bit by that patch.
-Dave
@superfly2000 That would require some level of hard coding which only moves things from a script to the engine programming. I assume the benefit would be having a tab in object properties that sets certain behaviors instead of inputing variables or typing in script names. It would add minimal convenience for something that's less flexible to personal designs.
I'm not technically inclined but I've spent a year or so experimenting with NWScript and there are many things you can do and a lot of it is like constructing lego bricks or solving a puzzle.
On the other hand you could also discuss what persistence really means and what greater persistence might entail. Respawning chests and monsters infinitely already exists but maintaining a persistent world state so nothing respawns or resets and instead emerges from ecology and economy scripts would be more complex. Consider a possible life cycle of a chest in a scripted world.
It didn't hit me until I read FLB's response .. area instances solves the basic problem completely: OnEnter spawn a copy of the area & linked areas, tweak the areas a little, then transport players there. (Party/players can go back to their version of the area for a time... )
The life cycle is interesting. Even the simplified (4,5,6) would add character to a PW. (quest to get somebody's stuff back, find somebody else's personalized items & return them to lost & found, etc)
This is exciting.
Btw, EPOlson nice to see you. I use a hacked up version of your stuff in my world. Good stuff there, thanks!
State persistence between resets is also heavily reliant on database usage and could do with something more built in like being able to load and save an image that the server automatically continues with when it's back online.