more ref business

i think this ref business is going to work out well. it took a bit of going in circles with other solutions to realize that i needed nothing else beyond ref to solve the problem.

Code:

----------------------------
robote/models/MrDonkey.model

this=new file://robote/glyphnodes/Donkey.glyphnode()
{
TheModel=new cli://robote/code/Donkey()
{
};
};

-------------------------
robote/maps/fancyland.map

this=new cli://gamebasis/code/Map()
{
GlyphNodes/MinimumCapacity=1;
GlyphNodes~=ref file://robote/models/MrDonkey.model
{
   Name=[[donkey_friendly]];
   LocalPosition={10.0 0.0 0.0};
   TheModel/Meanness=0.0;
};
};

what happens when the map creates donkey_friendly is it first loads in the MrDonkey.model and then it configures it via the statements in the next scope. initially i was worried that after a load/save cycle the scope would contain the complete state of the object (including hierrarchy!). i kept trying to fix that and then realized.. so freak'n what. the overrall goal of the ref was still attained. that is.. a composite object was created and configured at runtime.

now there is the problem of overrides. say you wanted to force some parameter of MrDonkey to some value. for new objects it would just work, but for existing objects it won't. when you set it in the MrDonkey file it will be set, but as soon as the next scope in executed, it would be overriden. this could be solved by another keyword that did some funny business to hint the execute order (yuck). it could also be solved by making the change at runtime in your map tool. it would search for anything that referenced it and make the change to existing objects. any new objects would just work.

one of the others reason to have these configurable objects is because data constantly changes during development. i'll use my favorite golfcart example from my old gbscript posts..

say you built a fancy articulated golfcart in max and exported it out. then you put a bunch of them in your map. when you saved out your map that golfcart just got embedded into your map. if you change your golfcart in max and save it out again, your map would still be the same as before. only new golfcarts placed would show your changes. having a configured object (basically just a level of indirection) fixes this.

two issues still remain. one is what happens when you remove pieces from your golfcart. say your fancy golfcart originally had an articulate trunk or something else you didn't want anymore. you may have references pointing to that trunk. doh! this issue is pretty much impossible to solve, but at least it is trivial to detect when it happens. you could spit out warnings or allow your tool pop up a dialog asking if you want to delete the stuff that points to the missing references.

the other issue is changing the hierrarchy. this is a difficult one. if there is an ordering change for any given level of the hierrarchy that is easy enough to fix just by having the parser look at the children names. if changes occur across hierrarchy levels there is not much you can do. i guess it really is not all that bad, maybe some configuration that you did in the map might be lost and become reset. oh well.

i think i am getting pretty close to something useful now. what's missing is quick load/save and network mirroring.