As I said, PSP (and apparently GIMP) do it that way. I'm trying to envision level editing as roughly analogous to a paint program, and so it is paint programs that make the most sense to look to for design. Shift is pretty common for adding to a selection in other programs too, like Windows Explorer, though Control does admittedly vary.

Paint.NET uses Ctrl to add. And so does Windows Excel. And PowerPoint. And Explorer (to select additional specific files). And...

Photoshop, too, which makes me very :! about this getting implemented.

(Except it's Alt that subtracts, but who cares)

...screw it, you'll get to choose.

Yay, your JCS just got better :)

I just need to figure out where, that is, where the settings will be stored. JCS puts everything in the registry, but that doesn't work as well if you're hoping to have Mac and Linux ports whenever you get around to figuring that out. They could be stored in an .ini or .xml or whatever file in the same folder as MLLE, but I'm designing it to have multiple copies in different folders, e.g. a JJ2 folder, a TSF folder, a Battery Check folder, and so on. Thus each one can have its own .ini file with its own particular list of events and texture effects and so on, but presumably things like keyboard shortcuts would be universal settings that one would want to hold for every copy in every folder. I guess I just need to figure out where appropriate settings folders are for various operating systems... and various versions thereof... blegh.

(The alternative, I guess, is to keep MLLE in one folder and one folder only and edit everything from afar, loading different .ini files each time a level is loaded or a version is changed. That would make filename code a bit more difficult, but more importantly, loading things would take a bit longer, and there's absolutely no internal difference between Battery Check and v.10o levels. Hmmm!)

I'd suggest you to make a ./settings directory, and store the setting files like ./settings/123.ini, ./settings/124.ini, ./settings/battery.ini... That shouldn't be that hard to make, just load the appropriate .ini after checking the level version.
E: and it would make editing them easier for power users, since they're easily available.

add an include command to the .ini parser and include a globals ini from every game-specific ini?

I'd also prefer one copy/folder.

For BC/1.10o detection I'd see three solutions:
1) Probably the nicest way is to try to derive the file type from the only true difference: event usage. Many events simply don't exist in BC, so the easiest guess would be: assume BC, unless non-BC events are used. Maybe it's also possible to look at event parameters. It's probably not very difficult to come with a pretty good algorithm. The only caveat would be that work-in-progress-levels with little events set could be misclassified.
2) Another way would be to place a simple, empty file inside (for example) the BC folder, named "BC" or something like that. If the level file is in the same folder as the "BC" file, it's a BC level, otherwise it's an 1.10o level. If you store BC levels in a seperate folder, just create a "BC" file in that folder for MLLE to work correctly. This would make it difficult to store levels from both games in the same folder though. If MLLE is going to store seperate settings in .ini files inside game folders, it could also look for the ini file.
3) Unless it's possible to detect the correct game 100% accurate, a BC/1.10o toggle button is pretty much unavoidable.

Regarding 1.00o vs. BC, I think what I might do is take advantage of some of the unused bytes in Data1 and just stick a flag in there somewhere to indicate what kind of file it is, probably for the BC levels. It wouldn't work for the original three (Binnen, Rain, Boss), but it'd work for anything made afterward.

An issue I see with only one copy of MLLE on a computer (as spread among multiple games) is that it wouldn't work very well for starting new levels, since where would you get the list of tilesets from?
ETA: Duh, each version profile .ini could just include the filepath. Hmm. I guess putting everything in one folder will work, and hopefully it won't slow down loading times overmuch. Problem solved?

Seems like the easiest way to handle settings would be to let the user provide the location of the settings file. This makes it easy to use the same settings file for multiple copies of MLLE, or to use different settings files for different copies.

Also, would there be an option to choose which Jazz2.exe runs the file when you Save & Run?

Yes. There is a "SaveAndRun" setting in each game profile .ini file that gives the name of the program to pass the level to on saving. If SaveAndRun is blank or removed from the file, the menu option is grayed out, since AGA and the Jazz2 betas don't support command line level playing. (Battery Check, for whatever strange reason, does.)

BC does? :O I've done all testing for BCCS by editing/replacing Binnen.j2l! In fact, I've actually removed the Save & Run menu option :roll:

Well, you'd have to change the string in JCS.exe from "Jazz2" to "Battery," which might or might not be possible given that they're different lengths, but dragging levels onto it does work for me.

Will this editor have any problems with the LK Avalon version of TSF?

I'm pretty sure the level format is the same for LK Avalon, so it won't be an issue?

What Troglobite said. LK Avalon TSF and, um, non-LK Avalon TSF may differ in their internal coding, but they are both able to read the same level files and both may have levels passed to them via command line, which are the only ways this program really interacts with such executables.

So, folks, tell me about the Multiplayer checkbox in Level Properties. Do you ever use it? (I don't.) In your ideal world, what function would it have, if any?

I use it, but I'm not really sure why because it has no actual function whatsoever. I would just remove it outright given the option.

Perhaps it could turn some certain events to MCE's? The fly carrot, for example.

I sometimes use it as an event filter to make searching for events a bit faster, however default JCS.ini definitely fails at defining which events shouldn't be used in MP. Still, imo it works alright for simple MP levels.

Keep it in, you don't know what could turn out useful when people finally find out what else it does.

I never use it. For me it's just a waste of space(The MP Button), but clearly, some people like it, so keep it anyway.

*superstition*

Perhaps I should clarify. I don't believe it has any effect in-game, although I'm open to being corrected. As far as I know, its only function is to make JCS restrict the events it lets you select and in turn warn you upon saving if you're using any others. Currently, the checkbox appears in MLLE's Level Properties, although you can configure the game-specific .ini file to remove it like almost every other setting in that window. However, it doesn't do anything right now. So it's not just a question of removing it or not, there's also the question of could it do something else that people would find more useful, and if so, what?

Well, although I might be thinking inside the box now, imo there's definitely no point in making it limit SP levels in any way, because SP can use all events and MCE's MP can. There should be no MP-checkbox-only features, because that'd be just annoying, having to switch it whenever there's a need to do something reserved for MP for some reason. That said, I think the only possible use of that checkbox is making it an event filter, like in JCS, limiting the possibilities when checked.

You could replace it with an advanced mode setting or something?
Or a Multiple Events per Block Setting(With a little box next to it where you put in a number saying how many events per block are allowed)?
Or perhaps just remove it, because it has no useful function.

You wish ;-)
It's a JJ2 limitation.

Yeah, I knew there was a reason no-one had thought of that before. :lol:

And on the matter of this:
The main reason we're discussing whether MP checkbox should make it in and how should it work, is because it's kept in the j2l file unlike any other checkbox Violet decides to add. Or rather (since it's possible to change some stuff in the file structure afaik) because this checkbox is commonly used in level files already. As such, if there is a need for any kind of "advanced mode", there can be just another checkbox added and there is no point in changing the existing one. Editor mode checkboxes don't need to be kept inside of the level file, because that's rather pointless in most cases. On the other hand, drastically changing the meaning of the box could affect levels that already have it checked, depending on the changes. That's why I personally ask for leaving it as it is, because I use it as it is, but if there are better ideas I might change my mind. It doesn't seem there are any though.

I checked, and apparently 16% of the .j2l files in my JJ2 folder have it checked, so I guess my never using it is not quite as absolute a tendency as I had hoped. I'll see what I can do, although I wouldn't expect it to be functional in the first test release when I finally get around to that. Thanks for the feedback.

That said, that byte is used for a checkbox in JCS, so its values are only ever 0 and 1. That means it could easily be replaced by a dropdown menu of level modes, with up to 256 different options of which "generic multiplayer" or somesuch would only be the second one. So... tell me about this "advanced mode," I guess? And yes, as SE points out, this would only be useful for stuff that's set on a per-level basis and yet only pertains to the editor experience.

I'd say advanced mode could give way to MCEs. No?

Again, looking for things that one might want to set on a per level basis, not a per game basis. Any sort of MCE support I feel like adding would presumably be enabled or disabled within the game profile .ini files, and would thus be available for all levels made for that game/version. I don't see any reason you would want, for instance, a shortcut for the black swinging vine MCE in foo.j2l but not bar.j2l if they're both JJ2 levels.

Well, maybe if you have it on, the MCE Event appears(As in, it doesn't appear in the Select Event Dialogue if it's unchecked), and maybe it could allow you to set events to move with a specific path(User Defined, with it so that in every event which would support it(This would work brilliantly with Generators), there would be a thing where you select a premade path or something? Maybe you could have this menu somewhere that lets you make paths and MLLE would give it a number(Like with Text) and you put in a number on the event, and it does the movement)? I'm not sure. There are loads of things it could do, but my mind's blank at the moment. I'll edit this when I think of some better ideas.

This is an editor, not a game. It's still making levels for JJ2; it has to obey JJ2's limitations.

Hmm... True... True... But, again, I don't know all the limitations of JJ2. But, then again, maybe my ideas don't have to bend the rules, it could -- temporarily -- create Belt events under the Event for Side-to-side movement, and -- believe me -- that's all you really need. You could find another work-around for moving them up/down, and another suggestion is to have the paths have a setting to make them loop, and another to have them have a ping-pong loop(As in, they do the path, then they do it reversed, then they do it normally, then reversed etc.) setting. Although, I'm not sure temporarily creating events is possible. Unless you have it so that it changes its speed between one you define and zero by storing the numbers in a Variable?

No temporary events.
No up movement. Items such as ammo can be shot down, though.
It's possible for an item to move right and then teleport a few tiles left. This works for enemies too.
It isn't.
I wish with you.

Hmm, maybe your idea, then?
I think that could work for Paths. I mean, it wouldn't be that customizable, but it would work. Sort of.

How so? It can only teleport a few tiles, and not up or down. Again, shooting it would move it down but the teleport part sounds a bit unnecessary for this.

Well, it would work because it would move left/right. Some people might need up/down, but -- from what I can tell -- it's impossible to move things up/down. Shooting things would make it go down, but maybe that could be useful(For example, imagine you want to make a Shooting Gallery or something(Where you shoot a moving target that's above you), but you can't figure out how. You could use a Path to move some Enemies and Pickups left/right).