DRAFT TEXT, REMOVED LATER -------------------------- we have multiple textures to use as diffuse map if we have multiple skins regarding the data format (ddxml) there is a simple solution remember the wildcard thing? yes we leave the format as it is, but extend it the everything but region it will be allowed to add tags below a tag each skin tag has attributes region,country,filename region,country are strings that are lists of valid codes, separated by comma yes if none of the skin-nodes match, the default filename is used (given by the map-tag) so we have all functionality we want you agree? yes seems logical :) fine, then comes the bad part the implementation as code :) since the map could use different textures, which is decidec when loading a mission, i have somehow to manage this there are 2 options: 1) while loading a model 2) while displaying a model 1) is rather easy hrm, how big is a co of dd ? 2) is more flexible, but harder to achieve hmm tx2rx, bigger some 70mb i think tx2rx, will all data including devel data? 200mb or less ? < 200mb for sure most likly I think, without the devel-data tree, which isn't really needed, some 70mb cool, just cleared 200mb on here, this devel-data has mostly graphics not yet implemented if you co only the dangerdeep/ directory you get all you need (game-data + code), should be 25mb or so tjordi, about skin loading here! what was the question? ;) hmm, makes sense, i mean, we can have 3 instances of the same model, with different skins regarding option 2) i mean 1) doesnt make much sense i think so, i mean, this should be specified and parsed in the mission file, so that when mission starts, everything is ok unload + reload the model only to change period skin? another option would be i mean if, if we have 1 model, with for instance, 3 instances, and there are 3 available skins, that satisfy the conditions of the mission perhaps some pseudoramdom choice in summary we need to be able to have 2 instances of the same model with only different skins at the same time ingame yes ok, then option 2) is the only solution while displaying model it can be done in multiple painful ways lol my idea is this: we already have a texture cache atm textures of a map are stored with the map i would change it so that map only references the texture in the cache unused skins are not loaded, and thus not cached good :) when a map/texture is needed, its loaded and stored in the cache * tx2rx reads the code guide so no memory waste tx2rx, hey matt, the code guide is way to short atm, mostly about coding style ;) thats fine, just looking for the cvs url, is it on the site ? rconstruct, ok, then i would store a *list* of textures for each map tx2rx, cvs url? to do a co, unless your using subversion ? 1m, you need anonymous access unless you have developer acess already rconstruct, the user gives region + country for the model and the display-function then chooses the right texture map for display in that case is cvs -z3 -d:username:ext@dangerdeep.cvs.sourceforge.net:/cvsroot/dangerdeep co -P dangerdeep after export CVS_RSH=ssh cvs -d:pserver:anonymous@dangerdeep.cvs.sourceforge.net:/cvsroot/dangerdeep login cvs -z3 -d:pserver:anonymous@dangerdeep.cvs.sourceforge.net:/cvsroot/dangerdeep co -P modulename rconstruct, hmm the cache doesnt work that way. there is no way to tell when a cache entry is obsolete rconstruct, it gets obsolete when an object is deleted that uses a certain skin hmm, no way to make some sort of list before the mission starts, with required model+textures ? rconstruct, so we rather need a function to register a certain region/country code and to unregister it rconstruct: it's ok, found the sf page, don't use cvs much, well, that would be a cache... rconstruct, with the register approach this can be achieved automatically means each instance would need an unique ID, and this unique ID in-game, would be associated with one of the preloaded skins rconstruct, it is so, that i just realized the problem with the approach i described above :) rconstruct, more like instead calling model::display(regioncode, countrycode) yes use model::register(regioncode, countrycode); display(); multiple until ship is sunk, then model::unregister(bla); otherwise the cache *can't* work the register function then would check if it needs to load new textures, the unregister vice versa each map still needs a list of skins with country code and region code each so in the ddxml, only change would be the addition of the required tags costs only a little bit more memory, but only a few kb rconstruct, ddxml yes so no need to bug eris with this, emacs will do the trick yep :) good and i just realized how i can code it phew good that we talked about it i would have run into that problem when coding let me copy the text for later research ;) 1.) add sub-tag support in model reader, store extra-texmaps with model::material::map. 2.) test skin support: add fields for country/region in ship.cpp or above store this with data (savegames/mission) 3.) optimize skin loading/handling - no memory waste by unused skins region,country and date for skin must be given for *every* call to model::display() to let the model class choose the correct skin texture. texture selection is stored in the display list at the moment, which is incompatible with skin selection.