Quote:
Originally Posted by Neobeo
Something I have been pondering upon for a while now:
Another file format (e.g. a project file), from which you can compile it into a j2l file of a version of your choice. Think something like how you create PSD files in photoshop, and then when you are finished you "reduce" it to a JPG or PNG. Similarly, you can save and load projects in this superformat, and then export it to a J2L.
A new format would be able to store, among other things: - Bookmarks
- Undo/redo buffer
- Macros and scripts
- Stronger password (debatable)
- Batch compiling info (for multiple versions)
- Cache linking (e.g using trigger scenery on layer 3)
In a sense, cache linking can be created on a J2L file, but there would be no way of knowing if it was "linked", due to the way the J2L format works. Meaning that if the J2L file was opened on JCS+ and re-saved the cache links will be lost. But a new format would be able to preserve these links.
Of course, JCS+ will still be able to open the humble J2L format, and save as the new format. But still, before I actually implement this idea, I would like to find out what people think about it, whether it is necessary at all. The problem I have with this is probably that it needlessly over-complicates a file format that was already so simple to begin with.
|
I think this is a good idea and I basically assumed you would add something like this. However I have a few suggestions.
Instead of making the format in the way you are thinking of it, why not just have a simple auxiliary file which is loaded alongside the j2l file automatically? For example, you load "level.j2l", and jcs+ automatically loads a file like "level.j2l.jcs" or something. The .jcs file would contain all the extra data you mentioned, but would not contain any of the actual level data stored in the j2l file. This method would probably be easier to work with and implement into the editor. It would also be a lot simpler.
Also, depending on the complexity of the data, you could maybe even make the .jcs file human readable by storing it in a plaintext (maybe xml?) format. But that might not be practical.
|