It would warp an item 255 pixels left/right at most. That would be... about 8 tiles. And it couldn't go anywhere else. For example, it goes 8 tiles on a belt, then warps back to the beginning. So, if you have use for this, go ahead and tell me

Target Practice. It would move an Enemy like this and it would continually generate Enemies that would act as Targets, the player would have to shoot upwards to shoot at them. 8 tiles is enough.

Heh, unfortunatively hitting an enemy is easy
But the warp thing can be used for eyecandy too.

There, right there, you just gave it a use. Sure, it's just Eyecandy, but let's face it, what's a level without Eyecandy?

Originally Posted by Jake

It would warp an item 255 pixels left/right at most.

128. It's a signed parameter.

So, folks, this is a lovely discussion, but given that I wrote the book on moving stuff around with belts, I'm pretty sure I'm qualified to say that Jake is overall correct about what JJ2 can or cannot presently do. It would be nice to have some sort of advanced support for belts, but creating elaborate paths is probably not the right way to go. Elsewhere cooba has described a proposal for MCE support in DJazz's WebJCS, and while I'm not too fond of it because I don't see the use of the vertical line, it is nice because it's an actual proposal with specific interface repercussions.

One idea I've had that probably won't be too hard to implement is allowing the user to replace the standard parameter boxes (or lacks thereof) for a single event with the MCE Event parameters (with Event maybe titled Speed/Event to indicate it is also used for belt speed), so you don't have to edit the .ini file just to give Watermelon a speed parameter you're never going to use in any other level. This would be a checkbox or something in the event selection window. Is that along the same lines as the path idea? If not, please feel free to give a more specific proposal for implementation (and usefulness).

...and all this is still per-game, not per-level, but perhaps I should just give up on that distinction. Maybe simply no one has ideas yet for editing modes.

Originally Posted by Unknown Rabbit

Maybe simply no one has ideas yet for editing modes.

The biggest advantage MLLE has over JCS is that the earlier is actively developed!

By some particular-to-me definition of "actively." But yes.

Originally Posted by Unknown Rabbit

128. It's a signed parameter.

So, folks, this is a lovely discussion, but given that I wrote the book on moving stuff around with belts, I'm pretty sure I'm qualified to say that Jake is overall correct about what JJ2 can or cannot presently do. It would be nice to have some sort of advanced support for belts, but creating elaborate paths is probably not the right way to go. Elsewhere cooba has described a proposal for MCE support in DJazz's WebJCS, and while I'm not too fond of it because I don't see the use of the vertical line, it is nice because it's an actual proposal with specific interface repercussions.

One idea I've had that probably won't be too hard to implement is allowing the user to replace the standard parameter boxes (or lacks thereof) for a single event with the MCE Event parameters (with Event maybe titled Speed/Event to indicate it is also used for belt speed), so you don't have to edit the .ini file just to give Watermelon a speed parameter you're never going to use in any other level. This would be a checkbox or something in the event selection window. Is that along the same lines as the path idea? If not, please feel free to give a more specific proposal for implementation (and usefulness).

...and all this is still per-game, not per-level, but perhaps I should just give up on that distinction. Maybe simply no one has ideas yet for editing modes.

Well, the paths could allow things like -- for example -- a coin to move from left to right on the ceiling of something, really fast(Or, if you can only make it go in one direction, it could go in one direction, then teleport back to the beginning), and you can only go to a certain part of the level if you have that coin. That would be useful... Sort of.

You actually can move some events (crates and pickups, I think) up. It's just really hard.

Anyway, I'm pretty sure it would be easier to make the "path" manually than it would be to use any special interface for it, unless it were very limited in what it could do.

Well, you get the idea, right? Advanced mode would allow some features that non-Advanced would lock off. Oh yeah, another thing Advanced Mode being off could do is a Tutorial, which would turn off if you have Advanced Mode on. And by Tutorial, I don't mean the built-in documentation, I mean a full-fledged, properly made Tutorial. I've been using JCS for as long as I can remember, and I only found out that you can flip tiles about 6 months ago. Let's face it, there's so much about JCS that isn't documented that should be, MLLE is also full of features that should be documented properly for beginners(The one you're working on, not the one used by the Developers for the first 2 OEM Versions). I remember that up until a few years ago, I didn't know what the Animated Tiles Dialogue was for, or how to use it. So, please consider this idea.

I assure you that flipping tiles is documented. It's in the JCS help file in the Layer section. Animated tiles and their properties are in there too. I don't think I could say much in a tutorial that wouldn't be covered in a help file for those who'd care to read it, and help files are far less work than interactive tutorials.

By making a Tutorial, I mean making the Help File show up every time you start up JCS, but not Full-Screen(As in, the Help File's not Full-Screen). Also, there are some things that aren't documented, so I suggest that you change the Help File to be more helpful. It would make JCS more user-friendly for new users.

What you are suggesting reminds me of those 'tip of the day' welcome messages some programs feature. Although I personally switch those off, I think such a feature could be used to highlight MLLE's more advanced/less obvious possibilities to new audiences?

As UR is making a new editor from scratch I think it's not really a matter of changing the help file, it's more a matter of making a better one for MLLE. If you just look at JCSref you'll realise how much is actually 'undocumented' in JCS's help file. In fact, we now know things the creators of the game probably didn't even know to be possible.

MLLE test release #1
To install: extract all files into a single directory (not necessarily your main JJ2 directory). Open MLLE.ini and replace the folder names in the [Paths] section with those appropriate to your own computer. Run MLLE.exe. Requires .NET runtime environment, I guess.

Major features missing in this release, aka my (partial) to-do list:

• ✓Tile layout editing
• Reworder-esque functionality
• ✓Help string editing
• ✓Animated tile editing
• Tileset compilation/conversion
• Search & Replace Events window
• Tile Type selection window (although you can just use the popup menu)
• ✓Functional Multiplayer mode checkbox
• ✓Differentiation between Battery Check and 1.00o
• ✓Conversion to AGA
• ✓Proper 1.00g/h translucent tile support
• Most error messages
• Mac and Linux versions
• Documentation
• ✓cooba's icon, because I got an error trying to convert it to an .ico and then never got around to trying again
• Support for AGA events not included in the demo, because I only have the demo

You can probably tell that this release is really pretty low on actual layout editing capabilities. You can clear and resize layers, and change the events around all you like, but that's about it. This release is intended to determine whether I've got pretty much everything else taken care of before delving deep into that stuff.

I'm particularly interested in looking for any mistakes in saving, loading, and converting between versions, although any and all errors are of course welcome. I've only really been testing this in Windows 7, so if stuff looks broken/ugly in other versions of Windows, screenshots and such would be great. I've included a .pdb debugging file which should produce some nice informative errors for you to copy the text of. A short list of known bugs, off the top of my head:

• Editing a Generator event (by pressing E or clicking the Select Event menu item over it) produces an error and/or a jarbled mess of parameter setup boxes.
• The vertical scrollbars will stop redrawing themselves from time to time. Not sure how to fix this.
• Certain combinations of window and layer sizes lead to errors with the scrollbar values, but I haven't determined exactly the source of the problem, so if you run into this, details about what you did to cause it would be appreciated.
• Scrollbars don't always get updated with the proper dimensions of a layer/tileset right away. Again, not sure what's up, so step-by-step ways of triggering this would be appreciated.
• Scrolling in parallax view while selecting a layer with speed 0 doesn't have any effect. This makes sense, since layers with speed 0 just don't move, but it makes it harder to edit some of the tiles. Maybe more of a design issue than a bug proper.
• The game profile .ini filenames are currently hardcoded instead of being specified in MLLE.ini, so 11o Style and JCS Style never actually get read.

Finally, besides generally looking for mistakes in loading/saving/converting and other errors, I'd love a volunteer or two to help me with AGA events. Right now, even though only the events used in the demo are supported, there are literally hundreds of parameters whose functions need to be determined in order to build a proper .ini file. While a lot of them are almost certainly repeated across similar events, that still leaves a whole lot of stuff to discover, and I don't really want to tackle it all alone.


tl;dr: Download this and you can look inside 1.00g/h and AGA levels for the first time ever! Just let me know if anything goes wrong.

Besides thanks to everyone who's worked on the various file formats at play here, thanks go also to EvilMike and Jerrythabest, whose JCS.inis I make use of.

Aaaah it's awesome! Absolutely brilliant how you did the events window, it's great! (Although, in BC, elevators go up or down, not left or right )

Two minor suggestions (just some polish though)
-When one of the menus is opened (say, File) and you slide to the next (Edit), make it so that the next menu is opened
-For event parameter checkboxes, display the parameter name only once

Anyway, I'm impressed... MLLE is coming out REAL GREAT!


EDIT: Also, I must say, even though it's just a temporary logo it plays nice with Windows 7's folder icons!

Yeah, you can tell I didn't test some of those dropdowns at all. Will fix. As for your suggestions:
- I haven't actually figured out how to do that yet, but I agree with the sentiment.
- I wasn't sure what to do there. If I only had one line -- the checkbox itself, with the label on the right -- the spacing would look weird compared to all the other parameter input types. Putting no text on the right of the checkbox at all, or something generic like "True," also looks weird. Nothing really looks right.

How about this? It doesn't look too bad I think

Suggestion: Down-scale the picture in your first post and place the link there.

No! UP-scale it and make that the link! Links to MLLE should be HUGE!

Everytime I try to open it, it freezes. FPS: 16000+ Elapsed: 50+ . After 2-3 mins, it gets normalized, FPS: 60, Elapsed: X+ . But, once I press a mouse on something inside the window, it freezes again. What could cause the problem?

P.S. I had to install .NET Framework today, version 4.0something.

Just to be sure; you did extract all the files into the same folder and set up all the path names (or at least JJ2) in MLLE.ini, yes?

Yeah, I did.

I'm not familiar enough with the runtime framework to know if you did everything right. I would suggest finding something else that requires .net, downloading that, and seeing whether that other program works if or if the problem is within your installation. I've certainly never experienced the behavior you describe.

Quick suggestion: what's the feasibility of implementing a small code to randomly fill in a given space using set parameters? I'm tired of 'randomly' filling in blank spaces.

Planned and has been planned pretty much since the beginning. I am well familiar with how much time gets wasted when using tilesets like Castle or Carrotus.

In other news, animated tile editing is going pretty strong. You can clone and delete animations, add flipped or animated tiles as frames, and associate events with animated tiles just like with regular tiles. (I've tried making entire animated tiles translucent, as opposed to just their individual frames, but unfortunately that has no effect in JJ2.) Still a number of issues to work out, though, including making sure you can't embed an animated tile within itself and trigger a stack overflow error. Also selecting a generator event works properly now, and 1.00 translucency support is almost done.

Hey, I never knew about that 'crazy animations' thing! That's just awesome.

I wonder though, do 1.00, BC etc. also support crazy anims?

*uses MLLE to check*
Yes. Ah, the beauty of a shared engine.


ETA: In the progress nobody really cares about department, here's a window for choosing which sound effects an AGA level will use for various (mostly unidentified) purposes.

Such an interface would probably also be useful for Ambient Sound (it could possibly list associated sprites for MCE's too!)

Anyone who wants string descriptions for ambient sound is welcome to edit the .ini themselves to replace the textbox with a dropdown.
ETA: ...although it occurs to me that MLLE might not actually read a single .ini line of such a length. Well, I can fix that.

My string descriptions for ambient sounds will be about which sprites they load.

It would be good if we can hear the sound effects in JCS, so we can decide what fits the most.

Yeah, we don't know anything about how those work.

++filled rectangle tool

(And no, since it's a rectangle, it doesn't handle slopes and such. That's rather more complicated and won't be done until later.)

That will save so much time trying to get a natural-looking Diamondus ground! Oh, and I only have TSF(And BC, and AGA Demo), will I be able to use the flipped Tiles in Animations thing?

I guess you could download one of the levels in that thread and try playing it in TSF...

Just tried it out and thought it was freaking awesome, so far. =)

Okay, I've tried the Crazyanims level, and the very frame the level started, this happened:

Originally Posted by Access Violation

Jazz Jackrabbit 2 has caused an access violation at address 0046B34Ah by attemting to "read" from address 00000000h.

    DS = 0023h              EAX =    51CA00h
    ES = 0023h              EBX =        20h
    FS = 003Bh              ECX =    46B33Eh
    GS = 0000h              EDX =  FFFFFFFFh
CS:EIP = 001Bh:0046B34Ah    ESI =         0h
SS:ESP = 0023h:0012ECB4h    EDI =    12ECC8h
SS:EBP = 0023h:0012FC30h    EBP =    12FC30h

So, I tried Crazyanimstsf, and it didn't look strange. All that really looked strange was the flowers embedded in the ground, and even that wasn't very weird.

Okay, since you did that research, I'll go into a little more detail, as much as is possible. Short answer is: I don't know why that error occurs. If you download practicalexample.j2l, for instance, that level does run in TSF. Some levels crash TSF, others don't, and I haven't yet figured out (read: bothered to figure out) what the distinguishing factor is. My guess is, once the technique becomes easy to implement, either here or through WebJCS, someone will figure it out without much difficulty and that will be that.

As for crazyanimstsf: shoot the flowers. They're destruct scenery, even though their initial frame is animated. You should have seen the same effect with the multi-color stomp blocks, although people tend not to notice those for some reason. There's another example in DryLava here which should also run in TSF.

*appears*

First of all, awesome. Thanks for being awesome, Violet.

So, documentation. I used to have a dream about jcs being linked to either ERE or jcs.ref documentation-wise. I'd suggest making it very easy to get ERE info on most events, and perhaps on some of the properties. You could link to one overall article for things (f.ex animations) or to specifics (belt left)

*vanishes again*

How about this: you hold the mouse over an event, and it shows a summary of the event (and perhaps even a picture?), and if you press it with right click or something, it takes you to the ERE page?