I am playing around with some ideas, related to direct manipulation of M15 data, but there is a strong limitation of the loading command.

The loading command accepts a specific "FileName" and expects a specific "ImageDir", which it uses to load the data from files, based on those locations and names.

This requires a little effort to get models to load, and load correctly under certain situations. (In my case, it is partly due to my 3D program not exporting the desired information needed. File-names have to first be manually entered into the M15 file, and the generic names removed, and the numbers have to be matched to the file names. Quite a task for a 1000 vertex object, with 20 images.)

My thought was that we could send a raw "String" with the full data of the M15 as the "FileName", while we could also send a raw "String" with a valid image-set (CSV). EG, "image1.bmp, image2.bmp, image3.bmp".

I was also thinking that a nice function to GET and SET individual "Image-maps" would be another great set of commands. As opposed to trying to cycle through each vector, to see which ones belong to image1, and hope that image1 is "TextureA".

Ok, last suggestion... If GET and SET are made... The ability to set a TextureIndex from a loaded texture-image would compliment that function real well. That would give the LoadTexture command another justified use, besides only for private-vector creations. That would also go well with the first suggestion, about the CSV, but that would require an array of image indexes, and deem another whole new command-style for loading M15. (So not a suggestion at the moment.)

The purpose of those commands would be to do something like this...

LoadM15 (MyDragon1$, {PurpleSkin$, GreenEyes$})
LoadM15 (MyDragon1$, {GreenSkin$, YellowEyes$})
LoadM15 (MyDragon2$, {PurpleSkin$, OrangeEyes$})
LoadM15 (MyDragon2$, {GreenSkin$, BlackEyes$})

That would normally require 4 separate M15 files, each having the skin-mod in them.

But, like above, there is only 2 M15 files, and the entire image-sets can be customized at the point of loading. With the second suggested command, we could GET and SET those values, as needed, without another reload of those same four models. Also, without a complex stepping-code to walk through all the vertex points, seeing if it is part of an image that requires a change.

We would also be able to load one file, store it in memory, and alter data directly, if desired. (Without altering any live-object in memory. Then, load it as a new object if desired, or recycle it by replacing an existing object. That would make cool morphing!)