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