I changed back to saving the mob's entire content list, and so far everything seems to be working fine.
After my vacation I'm planning to remove all my custom saving code and start auto-saving the player object (which will contain the player's two mobs in addition to other attributes) -- that will save me a lot of typing!
I'm also going to be rethinking the dbitem class from the Deadron library. I'd kind of like to remove it (I doubt anyone else is using it anyway), but there is a basic requirement for the Forum code that I can't get around: not everything can be loaded at once, because all the text might take up infinite amounts of memory. Therefore actual message text (and entire portions of the tree) should only be loaded when needed, and removed from memory as soon as possible.
Anyway, with the Forum code as a big exception, I'm expecting to do all my saving/loading through the new BYOND functionality.
ID:138386
Sep 14 2000, 5:08 am
|
|
In response to Dan
|
|
On 9/14/00 6:35 pm Dan wrote:
Initially, you would load things in with the normal Read() and then later you could call LoadData() when you need the full text. Very nice -- this makes the automated save functionality several times more useful to me. So I'm definitely glad we've gone through this savefile bump! |
To accomplish that, you could mark the message text variable as 'tmp' and load it on demand rather than when the 'index' object is loaded. To manage that, you would need a way to find the entry for the object in the savefile at a later time. There are a variety of ways to do that if you structure the savefile yourself, but if you let the default Write() do the job for you, it would still be possible if you are willing to take advantage of the way the new savefile format works.
Here is roughly how you could do it:
<code> </code>
Initially, you would load things in with the normal Read() and then later you could call LoadData() when you need the full text.
This technique would not have worked with the old savefile format, because the directory containing the object data existed only temporarily during Write() and Read() and was packed up into a serial buffer at other times. Now you can count on the object directory being persistent.