From: Jeff F. <je...@mo...> - 2008-07-30 16:51:43
|
Marzo Junior wrote: > I was playing with Valgrind recently and came across a slight problem concerning the deletion of game objects. > > Basically, references to objects can be stored in several places in Exult (the particular case I ran into was a list of tables in Waiter_schedule) -- and keep being used long after the object has been deleted -- for example, due to a cache-out. This happens because there is no way for the schedule -- or whatever may be the case -- to actually know that the object has been deleted. > > I am posting to discuss solutions. I have considered a few possibilities, which I share below; if you have other ideas for solutions, please post them. > > Solution #1: Use something like Boost/TR1/Upcoming C++'s shared_ptr/weak_ptr throughout the code. Massive amount of work required, will likely increase memory consumption, but Exult will probably be a lot safer for it. We might have to provide our own implementation in some cases, and might want to until the upcoming standard becomes more widespread. I am leaning towards this solution, despite the drawbacks. > > It sounds good, but I'm worried about the overhead. > Solution #2: Have reference lists for each object which point to anything which "owns" a reference to the object; when that object is deleted, it notifies everyone to forget about it. Likely to give an enormous increase to memory consumption, massive reworking (maybe not as much as solution 1), not all reference holders will be of the same (or derived from the same) type, meaning we might need several lists. Ugly, ugly, ugly. > > I don't know if it's that ugly. There could be a class, say, "Object_owner", whose only member is the virtual method "object_deleted(obj)". Each object would have a list of Object_owner's that it notifies when it's deleted. In most cases, it would be empty. But this would be more prone to bugs than #1. > If you have other solutions, I'd like to hear them. > > On to another problem, which we want to might tackle at the same time. Currently, there are at least two cases (combat targets and static usecode variables) where it would be useful (if not necessary) to be able to save the "reference" and be able to restore it on load. For example, if I set a static usecode variable to a game object and save the game, it will be set to zero on reload; likewise, the target of an attack (usecode or otherwise) will not be saved/restored -- and someone might save in the middle of an attack, which will be devoid of a target on reload. > > I was thinking that we might want to save the object's chunk and index into the chunk (on other words, how many objects were saved before this object in the current chunk) instead of directly serializing the classes (particular since the relevant portion of the data is saved already). We *would* have to modify saving/loading to save/load the u7ireg files before saving usecode.var or npc.dat/monsnpcs.dat -- or at the very least, to be able to "emulate" the save and get the index of a given object. > > Any other ideas? > > -- >Marzo Sette Torres Junior --+-- ma...@fi... >ma...@ta... ----+---- ma...@ya... > > > > |