To Vaporlinx:
Hellcat's 3do heightmap generator. (First item on the list.)

omg yes!

And in the future, Flexor will release Dark Tempest SE with all the levels and extended, high quality soundtracks for the levels (w00t!); this mp3 idea would significantly make the file smaller.
** i have no proof, so don't take my word for it **

this post better not get me shot :p

Wait, what did I miss? Fill me in, someone, on this plugin.

It's like CleaveLight but, you know, not crap. About time someone who could program actually...programmed. I wish I as not so lazy.

http://www.txstate.edu/~an1047/lighter.zip

Here's a link to the thread where we talked about it, if you're interested. It was in the main editing forum.

http://forums.massassi.net/vb/showthread.php?s=&threadid=27295&perpage=40&pagenumber=3#post378684

Basically, it does the same thing as cleavelight, but it produces far fewer cleaves in complex cases and, uh, you can actually use it on complex cases
It is very fast and so far it seems to work in pretty much all situations. It allows you to light everything or to only light a selected layer (all sectors/lights in that layer are used), and it also uses JED's undo system, so you get 5 undos. Cleavelight couldn't have the undo system, because it actually used the undo system when it was making cleaves, and also you had to run jed's lighting calculations afterwards. With my plugin, it will do the lighting for you (so don't use jed's lighting on sectors you run the plugin on, jed's lighting is actually too inaccurate to work with it).

LucasArts probably would've gotten pretty pissed off if this had happened 5 years ago. Although I bet the reason no one has heard from them about this is that they dont know about it yet.

Hmm are those patchs compatible with JK 1.01? I get CTD when loading my adjoin-limit-busted level with the 2nd patch run on JK.exe(starts fine with normal 1.01 exe).

It's no big problem, hardly anyone uses 1.01 anyway I don't think.

Most people don't know JK was patched anyway.

Yeah, the patch is just a stupid joystick and voodoo bug fix I believe.

Uh, congratulations; your patch borked my JK.

Good. :p

HR, need a mirror for your patchesstuffs? My server needs traffic.

Yeah, JK was still fairly popular back then. No one can say for sure, but I bet they would be turning up the jerk meter back then.

Oh HR might hear from them yet... you never know... just cause the game is so old doesn't mean they can't still be jerks about it if they see fit.

LEC aren't know for being community friendly so its certainly a possibility.

As for the patches, If you're taking requests I'd of course like to see the adjoin limit patch for MotS as well...and what I really want is a way to save variables to a file. There was a discussion about it awhile back on the main editing forum and some one there was supposedly working on a program that read from memory address in JK to do just that.

It would be a real boon for those of interested in the possibility of making a multiplayer RPG like world.

LEC aren't know for being community friendly so its certainly a possibility.

As for the patches, If you're taking requests I'd of course like to see the adjoin limit patch for MotS as well...and what I really want is a way to save variables to a file. There was a discussion about it awhile back on the main editing forum and some one there was supposedly working on a program that read from memory address in JK to do just that.

It would be a real boon for those of interested in the possibility of making a multiplayer RPG like world.

Actually, that's not why 3do based terrain is used. Even my first experiments with 3do terrain was using segments that could be culled in the distance using the first RVTCS. The framerate benifits, not having to worry about the adjoin limit, and being able to make more complex terrain was a bonus.



The only real advantage I can see is being able to use surface triggers in cogs for specific places on the terrain. However you loose the use of dynamic lights throwing realistic day-night transitions completely out the window.



Other then the use of surface triggers (which you can ussually get around by determining the xyz coord over the intended 3do surface), what other costs are there? (and yes, 3do terrain can be lit quite nicely with dynamic lights....)

http://forums.massassi.net/vb/showthread.php?s=&threadid=17347

http://forums.massassi.net/vb/showthread.php?s=&threadid=17321



It does indeed open the doors for using sectors to do outdoor terrain. It's certainly a viable option now. I just don't think that I would use it. But that's just my opinion...

I'm still holding out for a break in the apparent sector size limit...

What the hell are you talking about? Sector size is limited probably only by the size of an int or float in memory. There's no way you'd ever cross a huge sector without 100000000000000 star force speed. I've tried.

Yeah.. you can make sectors the size of serbia i've never not been able to create a sector no matter how big i've tried to make it.

Okay, this is probably at least the third time I've mentioned/explained this on the forums now. At ~800JKU's and perpendicular to the look vector of the camera, a surface is created that has HOM. Of course, it doesn't matter if you cleave the sector up, it's still treated as a single sector for rendering purposes. I have only recently ran into this problem (I first noticed it when I created a sector that was 1200^2 JKU). I have yet to find a work around for it.

I guess I've never made a sector that huge before and actually tested it. I have noticed that very long surfaces will produce weird effects sometimes. But this can be alleviated by cleaving them in half.

Sounds more like hitting the depth buffer limit than a surface being created. This should be fairly easy to tweak if it's a coded limit.

Everyone else is. :p Just be sure that the downloads and warnings and crap are like over @ http://www.hellraiser64.com/JK/

Yeah, it's not a true surface.

Hardly the same thing as a sector size limit. Clarify your words...

It's an imposed limit on the editor (person, not the program) based on the size of the sector. I wasn't aware there was such a thing as a "depth buffer limit" (especially since I've played POC's that had hallways much much longer then 800JKU's. The hallways were apparently small enough that at 800JKU, the view size of the HOM was negligible). It was the first time I had ever encountered it. Thus, I described it the best I could given what I observed in my tests.

Yeah, I see what you mean, but the way you said it was pretty clearly physical size. But anyway. Can't you cleave it up into a few smaller sectors? I heard that helped, never tried.

I mentioned in my earlier post that cleaving the sector doesn't help. Since now that we've concluded that's it's most likely a depth buffer limit, this would make sense seeing how the depth of what is being viewed isn't changing...requardless of the 'not rendered' adjoins present (created by cleaving the sector).

I expect there's a hardcoded variable which defines what the maximum distance the engine draws, basically it saves memory and increases framerates. It idea is that if it's just larger than the maximum distance that you expect to need to see in the game then you'll never be drawing anything beyond that distance.

You can easily see something similar in gtkradiant, even if you turn off distance clipping in the 3d view, it'll still start clipping automatically if the level is large enough.

If i'm right and this is just a engine-designed limit, then it should be just as easy as the other limits to override.

Isn't dicking around with the engine like this making the game rather unstable? I mean those limits where set for a reason... I know when I program every limit has it's place and is set for a reason... I know my low end C++ programs have alot more room to play with but something massive like this... has anyone hit some bugs yet?

Well, the changes at the moment seem to be simply removing the limits altogether which is fairly reckless. It would be better to simply increase the limits.

Remember, these limits were imposed for a time when most people had about 32mb of RAM, 166mhz processors and didn't even have a 3D accelerator.

There's been some stability issues which are just plain unknown right now with the adjoin patch. The Thing Limit patcher shouldn't have (hasn't had afaik) any problems at all though, so long as JK 1.0 is patched, and not 1.01 or whatever.

And limits like the ones in JK are for Pentium 90's with 16mb of RAM with no 3d accel. JK is hardly what I would call massive. :p

Hell, if the Depth Buffer Limit could just be upped to like 3000JKU(^2JKU?), I could work with that. Right now, my entire project is on hold because of this. Sure, I could scale it back and scale it down....but it's simply not what I want and it's not what I want the people who play it to experience. If this limit is pushed back so that I can do this, you'll be able to do in my mod what you can't do in any game to date!

...and the worst part is...almost all of the art assets are already created!

I've created a 99994.15 JKU long sector before, I originally aimed for 1(maybe 2, I forget) orders of magnitude higher, but JED refused to play ball. This sector was a bit on the narrow side though, not a skybox type thing, so you couldn't really see the other side. There was no screw-up on the 99994.15 JKU length surfaces though.

The last major limit I can think of is the 32768 surface limit for SP save-games that Sylvolicus(sp?) found.

I haven't tried the adjoin patch yet, need to reinstall JK, I'll post before and after screenshots when I can.

So the whole screen goes HOMish?

Is it possible it's a "Sector Volume" limit?

No, not the whole screen. It's as if there is a HOMed surface that is created perpendicular to the look vector of the player camera ~800 JKU away. I first noticed it in the corner of the level. So as I got closer, it slowly disappeared into the corner. If I looked up, it was V shaped (that's how I knew it was perpendicular to the look vector). If I moved further away from the corner, it got larger. At ~800JKU, it's non-existant, but begins to form after that.

Get what I'm saying? It moves with the player as if it's attached to it, ~800 JKU away.

Ok, if it's not the whole screen, couldn't you just have a Drazen Isle-esque Viewsave.cog?

Doesn't viewsave just remove the adjoin? the problem is that things you are looking at are beyond the maximum rendering distance, so the engine doesn't render anything (this is what causes HOM, it uses the last frame for that screen location).

I hate to bring it up, but what about that whole thing with multiple translucencies? Fixable?

It makes adjoins visible/not visible based on your distance to them. So JK doesn't render whats behind it, that would effectivly take out that far distnace HOM, no?

Not if there's no adjoin between you and the distance of doom.

Additionally, if you're using a skybox around your entire level then it's going to be beyond the furthest playable area so if you used viewsave there would suddenly be a solid wall between you and the sky if you got too far away from it. This isn't an issue in games with portal skies, it would be in JK.

I think Friend14's point is that he wants to see beyond this distance, he doesn't care about whether the problem causes HOM or just a solid wall, he wants the problem to go away.