<res2k> Jorrit: perhaps your contribution could be explaining what regions were initially intended for. I'm not entirely sure of that, either :)
<Jorrit> res2k: defining collections of objects for the purpose of loading/unloading was the original intention.
<Jorrit> res2k: with the idea that everything in one region can be easily unloaded from the engine.
<thebolt> however, they don't work as that anymore.. or not only as that at least ;)
<res2k> I suppose the point were reality kicks back is that a resource can actually be shared over multiple regions
<Jorrit> res2k: yes, and that's not bad either.
<Jorrit> res2k: in that case the resource would go away if both regions go away.
<Xordan> yes
<Jorrit> i.e. in the usual sense of how ref counting works.
<res2k> although "go away" in engine terms is not quite the same as deleting the object
<Jorrit> I'm not saying it is a perfect system. But that was the original goal.
<res2k> particularly, as long as an object exists, the engine lists should keep track of it
<res2k> otherwise it can't be reused
<Jorrit> res2k: provided there are no leaks/bugs and the app doesn't have its own references it should usually amount to that.
<res2k> but then there are methods such as DeleteAll() which sort of break that idea by deleting from the engine lists as well.
<thebolt> Jorrit: problem is that it won't go away
<Jorrit> res2k: well you can't force the engine to keep the last reference.
<Jorrit> thebolt: why not?
<thebolt> Jorrit: load an object in two regions, remove both regions and then it will still be in engine lists
<thebolt> because all three keeps references to it
<res2k> or
<res2k> load two regions, unload one
<Jorrit> actually no
<Jorrit> That's not true
<res2k> some object may have been removed from the engine lists, although it's still used by the other region
<res2k> load another region
<Jorrit> Check csRegion::DeleteAll()
<res2k> which happens to use the same object
<Jorrit> It does remove the objects from the engine lists.
<thebolt> Jorrit: yea, and that gives the problem res says
<res2k> whoops - not reused!
<thebolt> Jorrit: that when an object is in two regions its unloaded as soon as the first is removed
<Jorrit> yes
<Jorrit> Never said it is perfect :-)
<Xordan> Which is why I want to improve it ;P
<Jorrit> Xordan: might be a bit difficult while trying to keep compatibility.
<Jorrit> I think it is better to introduce a new concept.
<Jorrit> And deprecate regions.
<thebolt> Jorrit: so redo it completly for 2.0 ;)
<Jorrit> Or add new concept and deprecate.
<Jorrit> I think it should be possible to do it gradually.
<Xordan> I don't mind doing that as well
<res2k> Jorrit: you think anyone is relying on the broken behaviour?
<Jorrit> res2k: zone manager uses regions.
<Xordan> res2k: Well, most people don't know it's broken
<Xordan> Only those who check their memory usage and go "Hey..."
<res2k> also, we have UnusedResourceHelper now
<Jorrit> It depends of course on how extensively you plan to change it.
<res2k> why not add a call to that after some region cleanup?
<Jorrit> But I can easily imagine things breaking if you're not careful.
<Xordan> res2k: Because that doesn't really do the job either, there's still other issues
<Xordan> like lightmaps never being freed
<thebolt> res2k: i much rather fix the underlaying issue
<Xordan> shaders too
<res2k> lightmaps are just textures, too ...
<Jorrit> I think best way is to try to introduce a new concept.
<Jorrit> That way we can find a better name as well.
<Jorrit> Instead of region.
<Xordan> Yes, but things keep references to them so they never die :)
<Xordan> and I have no idea what
<res2k> rob some graves, call them "collections"?
<res2k> Xordan: Things as in thing mesh?
<Xordan> no, I don't think so
<Xordan> things as in, something which isn't a Thing ;)
<Jorrit> res2k: collection is one possibility yes.
<Jorrit> Can't immediatelly come up with a better name.
<thebolt> i think one possibility is to move down "primary ownership" one step.. that however might have issues with finding objects..
<thebolt> (ie don't have primary ownership in engine but in "collection".. or possibly the "engine-private ref" we talked about sometime earlier..)
<Jorrit> thebolt: the methods in engine to find objects could delegate that to the collections.
<res2k> always have one 'region', and if it's just "the default 'region'"?
<Jorrit> One 'problem' might be that finding becomes more inefficient if objects are in multiple collections.
<res2k> yes
<Jorrit> But that's perhaps rare enough to not worry about.
<Jorrit> Building an alternative hash structure on top of all objects (maintained by engine) might be useful too.
<Jorrit> Some lists in the engine already have hash lookups for fast finding.
<res2k> fwiw, I'd rather much define a desired behaviour wrt loading/unloading levels with shared resources before further daddling in possiblities
<Jorrit> yes
<Jorrit> We need to define what and how we want things to work here.
<thebolt> definitly
<Jorrit> Another word besides collection might be 'group'.