A better scrollbar in the Tileset menu. Having to scroll all the way from the top through 600+ tilesets everytime the cursor moves off the bar is VERY ANNOYING.

AFAICR, that's the 4th time someone suggests that XD that change is actually rather obvious, as that scrollbar bothers everyone (if it doesn't bother you, then go away and don't come back unless you made a level ;p this thread is only interesting for levelmakers anyway)

A better scrollbar? How about a whole "Choose Tileset" window which would tell you the name, the filename and the compression version of the tileset, show how many animations can it hold, and output a preview of the tileset.

Originally Posted by cooba

and the compression version of the tileset

I think people would really just settle for being told "1.23" or "TSF" or something like that.

How about being able to search for a tileset quickly by typing the name in a textbox? For example, say you wanted to use the Castle 1 tileset, you type "Castle 1" in a textbox, then it would instantly load up that tileset. It would save a lot of time in finding a tileset, especially if you have a lot of them in your JJ2 directory.

Originally Posted by cooba

A better scrollbar? How about a whole "Choose Tileset" window which would tell you the name, the filename and the compression version of the tileset, show how many animations can it hold, and output a preview of the tileset.

I did think about that, but would it be possible?

How would it be impossible? :/

ok...

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 love the new ideas, and would love to see as many as possible implemented into a new JCS.

<3.

So what would be the use of macros and scripts in this format if they'd be lost when saved to .j2l?

Originally Posted by Neobeo

Stronger password (debatable)

2048-bit crc + base64 + md5 lol

other than that, the new features seem interesting

Originally Posted by cooba

So what would be the use of macros and scripts in this format if they'd be lost when saved to .j2l?

not if 1.23+ would be made to support it

Sounds great, Neo! Though I think no jazz2 changes should be needed to run levels made with this level editor, that would simply suck.

You could also include a tileset recompiler 1.24->1.23. if it has too many tiles, JCS+ can just show a small window like the layer view but then without the layers (lol) which 10 tiles wide and a set number of tiles high, so you can rearrange the tiles in the 1.24 tileset. JCS+ will then generate an 1.23 tileset.

Oh, and what do we need 2048-bit crc, base64 and md5 for? It's just a level project file :/

Make it work on Linux. Natively.

Is somebody even trying to do something to JCS?
Or are you just talking about those updates?

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.

OMG!!! Im late from school!

Originally Posted by cooba

So what would be the use of macros and scripts in this format if they'd be lost when saved to .j2l?

I probably didn't explain myself to clearly. Let's say you have a hotel level and you created a macro called MakeNewRoom(guest_name) which automagically makes a new room at some location or other. My point is basically that when you load up the project file, this macro will already be stored in it, and available for use. As compared to just opening a J2L file, which has no scripts attached to it. Alternatively, all the macros/scripts could be placed in a global file. (Or EvilMike's response below)

Originally Posted by finnish pro

Is somebody even trying to do something to JCS?
Or are you just talking about those updates?

This will be a brand new JCS, if completed.

Originally Posted by EvilMike

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.

I like this idea very much. At this point I have some concerns, mainly about the version conflicts (1.10, 1.23, 1.24). But overall I think the pros outweigh the cons, so I'd like to try and get this implementation to work.

Originally Posted by Neobeo

I like this idea very much. At this point I have some concerns, mainly about the version conflicts (1.10, 1.23, 1.24). But overall I think the pros outweigh the cons, so I'd like to try and get this implementation to work.

Since you're interested in going for this method, I'd also suggest making a similar sort of file for tilesets. For example, if you load tileset.j2t, tileset.j2t.jcs gets loaded too. The #1 thing I can think of which could be stored in such a file, is what would best be called "templates" - I think I discussed this idea with you before. Templates would basically be groups of tiles placed in a special window, which you can select the same way you select tiles from a tileset. You would also be able to place tiles or events in them, just like you do for a normal level. The purpose of templates would be to provide the mapper with an easy way of selecting common groups of tiles. For example, a hill, or a wall, or some sort of eyecandy pattern, or a cluster of food pickups that go well with the tileset.

The nice thing about this feature would be that it would greatly speed up the level making process, and trying it to tilesets in the tileset.j2t.jcs way would mean templates would not have to be remade for every new level. In fact, tileset makers could even supply a pre-made template with their tileset, to give people a head start.

Thanks for Neobeo

Great ideas Mike! The idea of a .j2l.jcs file will have another advantage: the Save and Run only needs to save the .j2l file, instead of a project file and then a .j2l file.

I dont know if thats a JCS or a jj2-issue, but trigger-Crates with trigger-Id and delay would be nice

Well I've always been under the impression that Trigger Crates have had a TriggerID

And delay is possible with an animated tile.

Also, have the "Save and run" able to launch either 1.23 or TSF (Preferably as two options on the file menu)

Originally Posted by n0

And delay is possible with an animated tile.

I tried to get a animated trigger tile to delay, but the animation would not start after the trigger is set.

One more suggestion for JCS2, let it be able to edit diffrent version type levels. Such as the battery check levels, 1.20, 1.23, 1.24, and (if possible) ones ending in .lev

Originally Posted by Puffie40

I tried to get a animated trigger tile to delay, but the animation would not start after the trigger is set.

Just do a (-) lot of starting tiles before anything actually happens

Originally Posted by n0

and (if possible) ones ending in .lev

Then we can finally play race4 it's my favourite Epic race level, honestly

And make a feature to convert between versions as far as possible, with the program warning you about features that won't work when converting to an earlier version. As for 1.24-only tilesets, maybe if there's an 1.23 version, one could appoint what tiles should become what tiles in the 1.23 version (since not all tiles will align properly, most likely.)

Originally Posted by Saphir

Just do a (-) lot of starting tiles before anything actually happens

I tried to do that, but when the trigger is tripped, nothing happens.

Maybe you are using Trigger Zone ID 0? or you just don't wait long enaugh ;p

Take a look at the survivor levels. That's where I learnt how to do this for the first time.

IMO that 'trick' is rather obvious... I used it in one of my first n00b levels ;p

Okay... So that everyone believes me...

The Trigger ID is #2. It is a Crate. The Idea is to have the green light come on when the Computer finishes scrolling through the data.


I trip the trigger, and wait.... and wait... and wait... Nope, that green light does not work...

I think the problem might be in the fact there is only one different tile...

The green light must be placed on the second to last frame, not the last. The last frame is omitted completely.

I advise that the animation is made longer, though. For a better visual effect.

See, Trigger Scenery is based on all the other block events like Destruct and Collapse scenery, which end in the second-to-last frame because the last frame falls away in four pieces. Granted, they removed the falling pieces for Trigger Scenery, but the second-to-last-frame rule still applies. Shove whatever you want in the last frame - if you have a tileset with letters in it, get a bunch of animations spell out your name or a swear word or whatever floats your boat.

The trigger animation will stop at the penultimate tile.

Back on topic, .lev files are seemingly useless. Would there be any use at all in messing with their format?

No.

Yes. We could break the animaniacs levels and the older beta levels.