Every room a save room

[Brytta Léofa]

https://gdb.armageddon.org/index.php?topic=54775.0;

Let's run with this idea, assuming that hardware/game performance isn't an issue. What do we gain? What do we lose (or have to mitigate)?

I've really enjoyed seeing the persistence changes to shops: any shop that will purchase stuff is now selling a bunch of items that aren't on their default "many are available" list. It's cool. The economy is vibrant! The best economy.

How many bone swords need to be stored in a bedroom before they're given out to every character out of char-gen because 'my character is a nice person and I have plenty of these'?
How many sets of mekihorrmet plate-great-armors does the gameworld need to contain until they're just too common that their functional price is negligible and their benefits are dismissed because everyone else also has the same benefits?
How many hunters need to find 10000 coins on their first day adventuring because, honestly, all the people who die in similar locations adds up real quick.

Yar, but most of these specific problems (I don't say there aren't others) are already mitigated:
- Apartments have weight limits and are already save rooms.
- Expensive armor is either: stored in a save room, lost due to death, or reimbursed. People aren't really losing expensive stuff because they set it down just before the game crashes.
- Bodies already sink into the sands. (Wait, do they leave their gear behind? I'm such a noob.)

Given the rarity of reboots these days, I think the problem of object sinks is largely solved: when the game's up for a week or two at a time, rebooting and clearing non-save rooms just isn't the main factor.

But what cases do get changed by universal persistence?

(Obviously the main reason I want this is so I can bury stuff in remote corners of the world and retrieve it later. Though that's already being done with save rooms, so.)

[deskoft]

I find an intense amount of problems resulting from this initiative. For now, I will toss one:

- We don't have yet the systems to allow for simulation of endless items being dropped at X place where the VNPCs would pretty much just wipe it out. For example, roads. We don't want to see endless of Y item.

What I am a fan of is the script being given the tools to have MORE save rooms and include MORE save rooms where it would make sense and start to do the code work that will allow for simulation of VNPCs lifting or cleaning up unnecessary clutter with time.

That said, with so many projects that our coders can take and limited manpower in terms both of C coding and javascript coding, as players we have to ask ourselves: Is this truly something that can push Arm to the next level or just something 'cool' we want?

[mansa]

We could have a limit to how long an item remains in the game world, similar to the discarding of corpses.

Imagine that golden quest dagger that some pickpocket lost in the sewers lasting 4 real life weeks before it being "swept away"

Or that Magick chalice that makes you younger, that some NPC randomly picked up and has in their inventory for 3 months.

[deskoft]

I think that what I can see happening is having the limit of save rooms increased and having a script that makes a simulation of randomized disappearances of items. That way, the builder can CAREFULLY design how a room will interact with left items. There's a randomized chance of X kind of item being removed.

The problem with such a system is also making the player aware of the 'game rules' so to speak. If you see 'SAVE' in a hallway and then you leave a piece of furniture there and it disappears, it's unfair. Unless you somehow have a clear system for it. There are many rules that would need to be coded in this system. It's not as simple as making a generalized system that will just randomly disappear systems. The game manages a complex amount of types and in a game with so many items as ours, these rules need to be carefully studied.

Not impossible, though. I just think it's worth it to reroute this conversation to what is the smallest step we can take this way that allows us to test and design (and redesign) a system that allows for more save rooms.

[Brytta Léofa]

I think that what I can see happening is having the limit of save rooms increased and having a script that makes a simulation of randomized disappearances of items. That way, the builder can CAREFULLY design how a room will interact with left items. There's a randomized chance of X kind of item being removed.

"If object value > x and object weight < y in populated room", it gonna get snatched.

I just think it's worth it to reroute this conversation to what is the smallest step we can take this way that allows us to test and design (and redesign) a system that allows for more save rooms.

One very incremental step would be to make [Save] toggleable per room, i.e. how everybody tends to assume it works. (IIRC there are exactly two zones that save, and all save rooms are in those zones rather than in the same zone as their surroundings.)

Another incremental step would be to retain the Save flag as an indication of predictability: if this room is marked Save, you're guaranteed the room has no purge policy. Everything else can have a custom purge policy, where the default is "blow away the contents every Wednesday night" (simulating a reboot).

[Brokkr]

Probably less of a conversation around items and more of a conversation around NPCs.

That HG that some templar leaves in an apartment hallway that also respawns back where it normally does?  That, except for everything.

[Brytta Léofa]

Ugh, right.

Which, that's a problem even today. I suspect there are a number of NPCs stuck in weird places because a zone got staff-saved while they were there. The answer might be better overall ability to manage NPCs.

[Cerelum]

Probably less of a conversation around items and more of a conversation around NPCs.

That HG that some templar leaves in an apartment hallway that also respawns back where it normally does?  That, except for everything.

Is this what causes there to be sixteen of the same NPC walking around Allanak?

[Synthesis]

What are the circumstances where an item would dupe?

#1:  An item is force-loaded into a room on every reboot.  Now that the room is a save room, every reboot adds one more of the item to the room.  This would result from a poor implementation of the save room code, really.  I can imagine infinite chairs being spawned in the Gaj, for example.  You'd have to put a load-check in for every item being loaded on a reboot:
Begin loading process
Generate list of items to be loaded
For every item on list:  is item already in room?
If yes: don't load item; move to next item on list
If no: load item; move to next item on list

#2: An item is force-loaded into a room on every reboot.  It's a commonly-traversed room, and the item is both collectible and non-consumable.  So on every reboot, a new item gets generated, a PC collects it, and moves it to another room, where it is saved.  I feel like the duplication would reach an asymptote at some point, though, where everyone already has a copy of the item, so nobody bothers to pick up the "new" one generated by the last reboot.  If item-picker-upper NPCs traverse the room, however, it could possibly lead to a scenario where every NPC that could reasonably wander past that item will eventually have an inventory full of that item.

#3: An NPC loads every reboot, but gets ganked by other NPCs that don't pick items up.  E.g. carru ganking tribal NPCs.  NPC drops items, items get saved.  Repeat ad infinitum.

I suppose the solution would be to have a different room-type.  Regular save rooms act just like they do now.  Implement a new "partial save" (PSave) room, that has different behavior.

Some potential rules for PSave rooms:
1.  Abundance-based decay.  Every item sitting in a PSave is subject to a periodic check to determine whether it decays.  The more of an item that exists in the world, the higher the chance it will get burned randomly.  The decay could be implemented in a number of ways:  a) on a timer, where the item will "sink into the sands" or something randomly or b) on reboots, so if an item is flagged for removal by the decay code, it will persist in the gameworld until a reboot, at which point it will not load again on reboot (if a PC picks up, moves, or otherwise manipulates the item, the no-load flag will be removed).

2. Hard caps.  A PSave room could be set with a low hard-cap weight limit for saved objects.  Any objects attempting to load beyond the weight cap would simply not be loaded on reboot. Alternatively, it could be a number-based hard cap:  if a PSave room has a hard-cap-item-type limit set at 5, only 5 of each type of item would be loaded on reboot, regardless of how many of the item was present prior to that.  A PSave room could also just have a straight generic item limit:  the last 10 items in the list get loaded, everything else simply doesn't load on the reboot.

3. "Unique item" checks.  As an exception to the above rules:  if an item flagged for non-loading isn't loaded, it undergoes an additional check for uniqueness.  If, at the end of the loading process, there is not a another single example of that item loaded in the game, then the item gets loaded.  Alternatively, you could set the check to be any number of items.  This way, unique items (steel swords, magickal artifacts) would never get burned by a reboot, and rare/uncommon items would have a better chance at persisting through reboots than common/detritus items.

Beyond that, you could have different default defined types of PSave rooms:  City PSave has different rules than Desert PSave, TribalCamp PSave, ClanCompound PSave, etc. etc., each with a set of rules that's more or less stringent about what gets saved and what gets zorched.