DRAFT TEXT, REMOVED LATER
--------------------------

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