It seems like even when diligently using "save", if I've moved things to and from a chest, or packed a kank within about 15 mins of a crash, there's sure to be a loss/dupe problem (with the chest or kank) when the Mud comes back up.
Could we add an argument to the "save" command? With no arg save would act as it normally does, but with an arg save could be applied to objects/hitched mounts in the room, such as chests or kanks.
Examples:
save 3.chest | A bone chest's contents have been saved.
save saffron | A saffron kank is not hitched to you.
save saffron | A saffron kank's contents have been saved.
This could cut down on annoyance for both players and the poor imms that handle loading after a crash.
Thoughts?
Quote from: "SailorMars"Examples:
save 3.chest | A bone chest's contents have been saved.
Thoughts?
> save 3.chest
A bone chest's contents have been saved.
> get coins 3.chest
You get 10000 obsidian coins from a bone chest.
> put 10000 coins 2.chest
You put 10000 obsidian coins into a wooden chest.
> save 2.chest
A wooden chest's contents have been saved.
(..I'm sure you don't need me to repeat the exercise for mounts.)
Good point. However, even after "saving" the next tic of the Mud would update all the information as normal. So, making out on that cheese would be pretty unlikely. No more likely than doing the same thing with people as it is now... then again, I've always been in favor spontanious combustion for PCs caught cheesing. ;)
Quote from: "SailorMars"However, even after "saving" the next tic of the Mud would update all the information as normal.
If the mud updated the chest contents (saved to disk) on a tick-by-tick basis (and it doesn't), what would the point be of adding a
save container function outside of duping equipment?
I'm pretty sure your kanks packed contents are saved when you save, at least when you quit out with a kank hitched to you, the packed items are still there. So it would stand to reason that when you save, they save with you.
QuoteIf the mud updated the chest contents (saved to disk) on a tick-by-tick basis (and it doesn't), what would the point be of adding a save container function outside of duping equipment?
I don't know how long the ticks are on Arm. However, it seems to take roughly 15 RL mins for a chest to store what is in it. So if you could save the chest, and the Mud crashed, the chest wouldn't be affected. Then whenever the Mud saves containers to disk, the containers would be handled automatically as per usual. Save chest would essentially get you from the change you just made, to the next time the Mud automatically saves them, in the event of a crash.
It seems damage from crashes in the form of lost equipment comes from that window -- between when a chest (or whatever) is used, and the next auto-save. Save chest could avoid that... or, at least that's what I'm trying to think of a solution for. :P I'm open for any ideas on cutting down on lost stuff after crashes.
The best way to reduce the size of this item-loss window is to save yourself BEFORE ridding yourself of an item (in any way), and AFTER gaining an item (in any way).
Without some changes to the way the mud manages the "transactions" of losing and gaining items, the possibility of losing an item in this way will always be there regardless of whether or not we allow you to control when saves happen for those items/rooms/mounts. The only thing this specific save functionality would do is allow you to duplicate items easily.
-- X
Quote from: "Xygax"The best way to reduce the size of this item-loss window is to save yourself BEFORE ridding yourself of an item (in any way), and AFTER gaining an item (in any way).
Without some changes to the way the mud manages the "transactions" of losing and gaining items, the possibility of losing an item in this way will always be there regardless of whether or not we allow you to control when saves happen for those items/rooms/mounts. The only thing this specific save functionality would do is allow you to duplicate items easily.
-- X
How much of a pain would it be to save the entire room (if it's a saveable room that won't lose things in it when it crashes) when a PC in there types save?
Wouldn't that be a relatively easy solution?
Everything is possible. But that change would be far from trivial.
-- X
Again, what you're doing then is extending an opportunity to dupe items (as well as increasing the i/o overhead tremendously).
QuoteThe best way to reduce the size of this item-loss window is to save yourself BEFORE ridding yourself of an item (in any way), and AFTER gaining an item (in any way).
Cool, that's good to know. Thanks.