Here's what's been done so far:

version 0.96
- Thing limit in JKL is raised to 2*thing number+100
- Added a check for thing count in Consistency checker (warning if over 400)
- Added infromational messages when saving a JKL that hits thing limit
- Added an option to ignore JKL thing limit
- Added an option to dock the item editor, toolbar and 3D Preview windows
- When you try to select one of the several sectors/surfaces/edges/etc. that are on top of
each other JED now cycles through them in order of increasing distance from you.
- In frame mode JED now draws a line connecting the frames (thus showing the elevator
paths and such)
- Added a "Preserve tx coordinates" flag for surfaces. Surfaces like this retain their
U,V coordinates for most editing operations
- Added an option to change U,V coordinates for specific vertex. To do that select the edge
that starts with the desired vertex and use Ctrl+Shift+left,right and Ctrl+Shift+,.
- Removed minor memory leak in cleave procedure
- Added Scaling, Rotating and Flipping of vertices in the Tools dialog. Be careful with
those: careless rotating and scaling will mess up adjoins and flipping will turn sectors
inside out!



Not all operations has been adjusted to work properly with "preserved U,V" yet, but 'm working on it. Which bring me to the next point - pretty soon I'll have a version ready for beta-testing. Anybody up for that? There are severeal requirements to beta-testers:

- Be precise and thorough in reports - I have to be able to reproduce the problem in order to fix it.
- Be prompt and responsive. Beta-testing goes on for only so long. So the faster you respond the more gets done.
- Do not distribute beta copies.

Anybody has what it takes?

I'll help with testing. I can provide *usful* information, I won't just say "looks cool thanks bye" because I wanted an opportunity to use it before everyone else. I'm a computer science major at RIT, and my programming skills aren't *that* great yet but I can probably know what's going on most of the time.

I do not have what it takes, but I had to drop by and say thanks for the hard work!

I would test if I had more ideas to make things in JED.


btw, the most technical definition of UV unwrapping I could think of would be aligning all the texture coordinates on the same plane, without losing much/any surface area. It usually outputs a preview or saves an image of the "unwrapped wireframe" to paint over for a texture to fit onto.

I can help with testing. I will not be able to test every new feature (or old one) because I have only used it for simple things.

Everyone knows I've beta tested every project, program, and whatever for JK since 2002. I sure hope my renowned beta testing reports won't be wasted now :-D

BTW, I'll beta test :-P

Cool. I'll probably have the beta version relatively soon (2 weeks maybe?).

BUT I CAN"T WAIT THAT LONG FOR RELEASE!!!!!

Er...

:p

(I'm just really excited)

Also, I'm not asking to be a beta tester... I'll leave that to the people who actually have the skills to do that.

pfft, i've seen JED951 for a plate, bwaha

I'd be happy to test, since I've used JED numorous times, and I also have experience as a beta tester with Sony and their online project, Planetside.

I can be extremely informative....:D

BTW, concerning one of the suggested features, specifically:



How's that meant to work and what is it needed for?

It was specifically for UV wrapping.

I would also put in a check to see if the number is over 1000 or not. If it isn't, then make the number equal to 1000 (or some other arbitrarily high number)

For example, we don't want poor bob to make a level with 4 objects in it and a ship cog that eats away the thing limit (aka me) and only have 108 objects to work with. FYI this is a REAL situation and I AM hiting the thing limit every now and then.

We don't want the thing limit to be low if the total number of things is low since we don't know how much cogs will need.

And how it needs to work?

Another one: somebody please point me to 16 bit transparent MAT textures so that I can test JED with it.

Scratch that one - the obvious solution was to download Mat16 and make my own.

Good point about the thing limit, SG-fan. I say just keep it at 640, JK's maximum. Have a simple dialog with an option to set it to an arbitrary number, should the user be making a level designed for the no thing limit patch.

Here's how I changed it.

JED calculates thing number*3. If it's <640, JED sets thing limit to 640.

If it's over 640 it depends on whether "Ignore thing limit" is checked.

If it's checked then JED writes thing number*3 as limit and displays a warning that patched JK version is required.

If it's unchecked then JED writes 640 as limit and displays a warning that the level is pushing thing limit.


Also, consistency checker displays a warning that the level is pushing thing limit if you have >210 things.

Works?

My skills in JED are solid, i'll gladly test. I'll write my reports how I would expect somebody to write reports for me. I have some simple bugs/ideas written down somewhere that i've been collecting over the years...I wish I could find what I did with them.

What I'm saying is that I have a level that currently only has 3 objects total (2 ghosts and a player) that would give me only 9 objects to work with. I need 4 ghosts for the guns, 2 ghosts for the cameras, 1 ghost for a teleporter, 2 objects for the ship itself, and 1 more for the shield. That's a total of 13 objects when my limit was just set at 9

(all of this is from the checked version) There needs to be another conditional that if the button is checked it will set it to AT LEAST 1000 because it's probably checked for a good reason. (or you could always let the user enter in the amount he wants thus ending all my recommendations right now ;)...)

I model in JED like it's my religion; I'd gladly beta test.

If I understand what you are saying, then what he said here solves the problem:

BTW, odd thing about collision spheres. Perhaps I'm confused as to how they are supposed to work... but I can't get them to show anything meaningful. They either spread over area about 3 times or 1/2 of what they should depending on how I do it.

It doesn't seem like displaying them would be of any use unless somebody has some insight.

collision spheres can REALLY get in the way if you're trying to build a level with sexy 3DOs, but good gameplay. Shooting through bars and whatnot is difficult to determine without loading the level up and seeing for yourself. At least, I've always wanted this function, especially for things like metal detectors, and other doorway 3DOs.

JediKirby

If you know how collision spheres work do tell. I have no clue. The ideas I have tried give me nonsense.

Collision spheres? What do you want to do with that? Draw collision spheres for things so you can see if they would be too big or something? Just draw a sphere with the radius of the template's field 'size', with the sphere's vertex at the origin of the model.

Thanks, I must have skipped that line.

Do you know for a fact that that's what used for collision detection? Because there's a number of other places where it's specified: for instance a radius parameter inside the 3DO, and a radius parameter in every mesh.

The point of collision sphere is not "draw some sphere" but to "represent JK collision as closely as possible".

It seems to me JK collision detection is a little more sophisticated that just "assume everything's spherical". From some conversations with JK programmers I was under impression that each mesh has a collision sphere and that's how it work. It doesn't seem that way, though.

BTW, the sphere resulting by "size" parameter is off too. It reaches maybe to knee level of actor things.

Maybe they are treated as cylindrical, not spherical?

I concur with Emon's recommendation of using the template param 'size' as the radius of a thing's collide sphere. [Edit: Bender, the collide sphere going from head to knees is correct.]

Yes, there must be more that the JK engine uses in different circumstances, but none of us know for sure, and the size param gives reasonable results in most of my tests. [Second edit: The 'size' seems to be used for player colliding with level surfaces. The 3do and mesh radii seem to be used for projectiles colliding with players.]

It might be nice to also show the sphere based on the radius given in the 3do file and the radius given by the 'movesize' template param. (Showing each mesh radius does not seem valuable.) While we are on the subject of thing spheres, having a sphere showing the range of a thing's light value (dynamic light) would be nice, as well. There is a calculation for this used by the engine that Sige figured out.

So, in all, there would be four different spheres for a thing: 'size', 'movesize', 3do sphere, and thing light range.

Thanks.

That's simple enough.

How about when I try to convert a JK level to MotS. In the Mots jkl I don't have to manually input all my custom 3do's and templates

You don't know need to do that now. What you need to do is put all your templates in "mots.tpl" instead of "master.tpl" and that'll do the trick.

YES!

Wow, it's nice to see some work is being put into this. I haven't used JED in at least 4 years but that might change very soon if Sith2 lives up to expectations.

Too bad this thread isn't on the editing forum though. I hadn't noticed it till now.

Nope, that's right. Remember how an unflagged floor will drop the player to his knees, literally? When it's flagged as floor the player is attached to it. Otherwise he just collides and floats on it.