Let's face it: J1E, while supremely useful, is almost completely lacking in documentation. Most of what it does can be inferred by reading through the various notes files of the Jazz Graphics Pack, but that can be confusing sometimes because it uses J1CS terminology. With J1E's new release a renewed burst of interest can only be expected, so if you have any questions about how to use any aspect of the program at all, feel free to post them in the thread and experienced J1E users will be happy to answer them for you.
(by which I basically mean me, because I haven't actually asked anyone about this, but if others want to chime in then feel free!)

I would be quite happy to answer any questions about J1E or Jazz1 levels in general too.

I think a good starting point in terms of documentation would be a list of hotkeys. I found a few, but only by luck. Since they all seem to be different from JCS, having an easy way to know all of them would make things easier.

Those I know of are Q (add background), W (remove background), E (equivalent to Shift+E) and R (equivalent to .). Hotkeys are pretty new to J1E, although they certainly boost production speed considerably.

I have documents on how the levels and events work, though I don't think anyone cares.

And I refer to both frequently. ;D

I'm quite tempted to start a couple of pages on the ERE wiki. Maybe we could centralize things there.

How do you play custom levels in JJ1

• You could give Jazz Swapper a try, but I suspect it only works for LEVEL#.### files because those were all that could be edited when it was released.
• The most basic way is to extract the custom level(s) into your JJ1 folder and overwrite the default files, after making sure you have a backup of everything.
• If the only files being overwritten are .000, .001, and .002, you can also install a shareware version, patch it accordingly to work on your computer, and overwrite the files there.
• If you don't have JJ1, and the files are of number higher than 002, and were made in J1CS (not J1E), you can use Openjazz.
• If they're of number higher than 002, they were made in J1E, and you don't have JJ1, conceivably you could use J1E and such to change all their numbers to something that the JJ1 shareware would read.

So I was thinking of making this thread and then it turned out I had already made it over a year ago! I'm good. Question-answering still stands, although it's sort of a basic part of the whole JCS forum so that should come as no surprise, but I'd also like to redirect conversation a little. What do people feel is most in need of documentation, and what would be an ideal format for such information?


In related news, because with the current lack of documentation I have nowhere else to say this: the bug where Jazz loses two lives on falling off the bottom of the level is due to him still being at the bottom of the level when the death animation finishes playing the first time, thus causing it a second time. However, if you put a line of warp events at the very bottoms of such pits, Jazz will only lose one life, just as you'd expect.

I have a question!... Or two...
What's J1E's version of "Magnitude" and "Y-Axis"(These are names said in a text file I have that says stuff about Warps in JJ1) and also, are there any other J1CS variables that are different for J1E, and what are their J1E versions?

Let's see if I can get this right:

J1CS	J1E
Magnitude	Direction
Bridge Length	Bridge length
Y-Axis	Variable #2
Hits To Kill	Strength
Added Score	Score
Movement sp	Movement speed
Anim. sp	Animation speed
Enemy Shot sp	Attack frequency
Byte #13	Attack
Multi Purpose	Variable #1
Medivo B. Len.	Moving platform length
Medivo B. Direct.	Moving platform start
Reflection	Reflection
Byte #21	(Event Number)
Byte #22	Sound
Byte #28	(TNT)

(J1CS has a field "Enemy Shot" that does not really work because it confuses byte 15, an unused byte, with 13, which is the actual enemy shot field.)
(The "Event Number" field is not visible in J1E because it's next to useless. Rumor has it that the HOCUS cheat makes reference to it, but otherwise I don't know of any reason to worry about it.)
(The "TNT" byte is one of six bytes that TNT pickups in official levels have set to 9, the other five being Bridge Length, Moving Platform Length, Moving Platform Start, Variable #1, and Variable #2 -- which is to say, all the five variable parameters whose functions vary greatly by behavior and modifier. One thus assumes that the TNT byte was supposed to be a sixth parameter available for some behaviors/modifiers, although AFAIK it is never actually used?)

Wow. Thanks a bunch! Dude, you should get a medal or something, you've helped me with J1E so much! Anyway, I'm gonna now try to complete my J1E Test Level(Yeah, I'm making a level just so that I can experiment with stuff)... Oh yeah, one more question, just to keep things going, is the next version of J1E going to have proper documentation? If not, will any version ever have proper documentation?

As for proper documentation: probably never . Ideally I would want some sort of website with tutorials on it. But considering the time I have to work on J1E itself, it will probably never happen.

I do have some plans for the next version that should make things easier. Like an events screen with reduced difficulty, which only shows the properties that you are likely to edit for the specified modifier/behavior. I will still allow more sophisticated events by adding an advanced mode though.

Another something I want to add is a wizard to help you kick start a level.

While we are talking about it. Does anyone prefer the old J1CS event property names over the newer J1E ones? I might change them back. I changed them because I thought the old ones were kind of vague (I never really was fond of magnitude, y-axis and multi-purpose).

Well, I don't think you can make any case for Variable #1 and Variable #2 being less vague, but I'm pretty neutral on that point. Variable #2 does relate to the y axis surprisingly frequently, but not fulltime. Ideally, though, you'd see JCS-like behavior where the five variable bytes rename themselves accordingly depending on the modifier and behavior. That would take more work, and you'd need occasional double-duty for cases when both modifier and behavior referenced the same byte, but it would be a lot more user-friendly.

Yeah, it would be nice to have auto-renaming Variable/Byte Names. It would make it easier to understand what's going on.