Re: [CODE]..

From: Mysidia (
Date: 06/18/00

On Sun, 18 Jun 2000, Del wrote:

> One simple way of fixing this problem.
> When it asks if you want to save internally, I make a call to the
> appropriate
> save_to_disk function.
> This way everything is saved when you select yes.
> I never did see a purpose in saving internally, and not to disk.
> It might even be better to insert another question:
> Do you wish to save to disk? (Y/n)
> make the call on default and yes.

   Let's see.. you have optimizations.. saving to disk does take a sum
of cpu time -- opening and writing to a file is an expensive operation
and can take significant system processing time during which the entire
mud must wait for the physical save's completion -- an update to
the internal status is quick; though sometimes buggy

(for example; stock Oasis2 has glitches in how zedit_save_internally
 removes invalid resets, how create_new_zone fails to update
 world[].zone, and how redit fails to deal with ->contents or ->people
 correctly --).

   'saving internally' simply means updating the online status; there is
such a thing as making a temporary change to something and not
wanting the change to be a permanent one -- once you save to disk, the
change is committed meaning 'no matter how bad' it is you can only
revert if you have a backup.

    And being a little buggy means you -definitely- shouldn't save after
every edit, and you should prolly backup and diff the changes between saved
and pre-save copy just to be safe.

   I think it actually might be interesting to have an option in oasis
zedit/redit/medit/oedit/sedit to revert the current subject
(be it an object, room, mob, zone data, or room's zone resets)
 being olc'd back to its on-disk state -- and a way to save/load 'just one
element' without re-saving or re-loading the entire file <chuckle> (yeah,
I know that's definitely not simple if possible to implement with ascii
worldfilesm, and not worth the time).


     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  |

This archive was generated by hypermail 2b30 : 04/10/01 PDT