Did you try to contact spark to see what was his status on his zmd project on blender?
Would be interesting to have his opinion or help on this.
Now on the format changes, I copy/paste what I wrote in RZ:
Aukemon0NL wrote:What type of virtual files would you like?(.rar/.zip/.vfs so on)
I wonder if we would really need one at all. I liked the fact with the "old" iRose client that all files are freely accessible, directly in folders
Aukemon0NL wrote:What type of table files would you like? (.xml/.stb so on)
This is a tricky question. Somehow .xml or other would be nice but people are used to .STB so I guess we should stick to STB / STL system. Loaders are easy to code so it shouldn't be a problem.
We could discuss about more "client" problematic files, like zsc to do something easier, xml would be nice for them.
As for the .con, .aip, .qsd well editors do exist I guess, though it could be translated to "simple" lua (or whatever script language) quite easily I guess.
Then there is the "port" to server since we load .aip and .qsd...
I guess we could keep .aip and .qsd since they are quite known now and perhaps change the .con to something else easier, lua only or something, no need to "compile" them in .luc for example, directly lua scripting.
Aukemon0NL wrote:What type of model files would you like? (.3ds/.obj/.zms so on)
I'll let that to the 3D "experts" ^_^
Though the more you change file formats, the more adapters you'll need to write so it should be done wisely.
As for osRose dev rev, we load .aip, .qsd, .ltb, .stb and .stl. As long as you don't touch those file formats it's fine with me
And I don't think you should touch them since it's pretty basic and easy file systems.
But we should talk about .ifo... Surely the .ifo format is quite bitchy and could use some simplifications but once again the format is quite known too and it's the job of map editors to handle them. Perhaps not touching that would be a good idea so it remains compatible with existing map editors.
I don't know, we should do a complete list and see if it's cool to change some formats or not or what it would imply.
Purpleyouko wrote:It seems a good idea to actually do the primary hosting of teh project at osrose since that's where the more technical users seem to go for information anyway.
I'm not so sure that we need to be uber careful not to change the formats of files.
It might actually be more beneficial to develop an offshoot of the dev rev specifically for the custom client since we are always adapting it to work with the real game and to plug its stupid security holes and stuff.
Think how much nicer it would be to actually design the server and client to actually mesh properly from the start.
It will still be kind of like rose but a whole bunch better.
I'm happy enough leaving the files such as STB, STL, LTB, AIP and QSD. I'm even ok with CON to be honest though it's a pain in the ass that they each have their own encrypted LUA files built in.
I really don't see a lot of point in stuff like VFS structures. I say just leave the files open and unprotected.
1) It's open source and free
2) If you try to protect the files I will give it about a week before somebody cracks it anyway. look how long Arua's AFS lasted.
I totally agree on the osRose subset of course. Keeping track of two separate clients in one server would be a pain, especially if we add or change packets.
The only thing I was saying is to see if we really needed to change file structures osRose was using (.qsd, .stb, .stl, .aip, .ltb), but it's only my lazy side which arises ^_^
@PurpleYouko:
You mean you're ok keeping those files formats as they are right now? Sorry for asking but I'm dead tired ^_^
Edit:
Anyway if people really want to do somekind of VFS, they could always change the client's source code and do their own "vfs" (or whatever) interface.
That would be quite easy for them.