Looks good, but IIRC these handle collision poorly so they are primarily aesthetic?



If I touch Zed editing again I'll have to look into that.

Yeah, moving things have/come up with all sorts of collision issues. In fact, I had forgotten that there is indeed an AttachThingToThing; issue in TODOA when you activate the train - the stand for the switch moves slightly (or just falls through the floor) after being activated when the train 3DO starts moving. Ah, #jksux and all that.

Also, I took the easy way to enable DF-style rotating doors in JK (https://vimeo.com/43301117), whereas GBK went for the effort route:

isn't RotatePivot(); used for translation?

by the way Jon'C, demo for that interceptor when

"Rotates a thing to the orientation of one of its frames. The thing will be rotated around the position of the frame used. If only the orientation of the thing should be changed, then the thing and its frame should have the same position."

IDK, sounds like it does what movetoframe does but with only rotation vectors? Unless it rotates using a different function than movetoframe, then it seems not very helpful. It would be nice to be able to rotate correctly around any given vector, not just the position of the thing.

In my quest to confirm whether or not moving 3DOs have collision issues, I discovered that even static ones do:

https://vimeo.com/322640478

Goddammit, JK

Yuhhhh, I just tested it and there's basically three (and a half?) ways to make a rotating door in JK:

The first door is the "naive method" where everything is lerped. Somehow the timing on both works out the same, but usually the rotation lerp arrives at a different time from the position lerp which looks really weird. In any case you can clearly see the door going into the wall so, strike that.

The second door is the "new 3do" method, where the rotation looks smooth and is completely reliable, but there's simply no collision at all. This would be my preferred method for any thing which the player can't touch, I believe I used this on the Gromas Mines map for the augur bit.

The third is a proper attached thing method. Now using a normal door cog with a ghost attached to the door, it handles collision by moving the door and ****ing up the attachment vector so that your door is permanently shifted from its original position and will do all sorts of gross things.

In the video is a modified door cog I wrote which does the attached rotation, then immediately detaches, resets the door and attaches again after the hinge successfully arrives. Which gives you a really awkward door flying through the player. It's better than the second option for collisions, especially when the door runs into the player swinging out it does great. But it's still janky.

The issue is you can't throw the blocked message from collision with an attached thing. If you could, this wouldn't be an issue really.



Also, the dgVoodoo wrapper from Steam JK sucks and won't respond to keyboard inputs frequently unless I esc in and out of the menu. How can I get JK working on 64 bit Windows 10 without this wrapper?

That's pretty bad. Jesus Christ.

You should try my method if it works:
https://forums.massassi.net/vb3/showthread.php?56665-Jedi-Knight-issues&p=1224745#post1224745

And yeah, those doors remind me that it's no wonder that JK's door COGs have all sorts of flag changes to the adjoins/sectors/whatnot involved even for a simple door going from frame 1 to 2 (or 0 to 1 in JK terms).

Damn, now I remember how much I fought with real doors in my JK level only to give up and just use sliding doors. I would never have thought that that was a problem that would haunt the pros to this day.

I'm pretty sure Drazen Isle used RotatePivot(); on the rotating doors and I remember then functioning perfectly. IIRC last time I did a realistic door I just used a class cog with keyframes (as missing door collisions weren't an issue once they were open), but mostly out of laziness.

And FGR, to be fair, the adjoin flag things in doors are just to disable rendering through the adjoin so the engine doesn't try to render stuff behind it

Turns out you're absolutely right, I apparently don't know anything about JK editing.



Apparently JK does allow for rotating objects cleanly, and you can do cool stuff like that.

It's just far, far, far more effort than it's worth.

BTW, is it just me or does RotatePivot take in pitch and yaw backwards??

RotatePivot applies its rotations in a totally random order which has never been documented successfully. When I implemented it for Gorc I just mashed em together randomly until I got something that worked.

Current interceptor status: all of the intercept work is done!

It handles windowed and fullscreen, software and hardware modes. Menus, HUD, and cutscenes all render correctly. Everything is drawn at 32 bit with no mode switching between levels. This resolves all of the compatibility issues I’ve had with JK on Windows, without any other patches installed (not that any of them ever worked for me). That makes this a worthwhile effort even without any of the fancy stuff I still want to do.


Remaining work:
- Renderer needs to be finished. Currently it only works on Nvidia cards, and not all of the necessary features have been implemented. The game is completely playable but does not look quite right.
- - Once this is done, I will put it on GH/upload an alpha version for people to test. Like I said, this is the only way I’ve been able to get JK running on Windows, so someone else might find it helpful.

Then:
- Tooling for materials.
- Materials/material injection.

Therefore...



Same! In my defense, all this veers more into the programming part of things which I've never claimed to have any skills in.

That sounds pretty good, Jon. I assume this means that stuff like the JK13 sabers could be implemented far better with the interceptor - and wouldn't necessarily require any of the JkSetSaberFlags; stuff to make them transparent (since while they still look great, you can see that the sabers are transparent even in the plain white parts)?

I'm not sure what the technical issues are there (jksetsaberflags / transparent core), but I'm sure something could be figured out.

Not sure what the specifics are, but essentially Xzero enabled multiple blending with the sabers (at least).

The muzzle flash mod on JKHub also enables fancier blaster shots that utilize the blending technique, but I can't remember simple ordinary transparent surfaces being affected (which might have more to do with the textures themselves).

With the JK2013 patch, all surfaces flagged as translucent (0x2 face flags IIRC) that use a transparent mat will use additive blending, and that's about it. jkSetSaberFlags is used to make the saber surface translucent, so that it will also use additive blending (and therefore look fancy).

I remember suggesting additional blending modes for unused face flags (anything above 0x4) but apparently that's a risky thing to do as it might trigger unexpected side effects (unknown flags etc)



From my experience, I believe the transparent cores are (mostly?) caused by level tinting (via sector tint or newColorEffect), as the tinting will cause the saber core to become less than completely white and therefore less than completely opaque

Sounds like what you really want is a material emissive channel.

A) Awesome screenshot

and B) I guess that makes sense, considering how many tinted sectors i used in TODOA. Matter of fact, at the very least, if you look at the "flagship screenshot" at the part where the saber intersects with the lights on the floor, you can see the slight translucency.

what a baller thread, keep it up guys

Honestly one thing which has changed dramatically since the introduction of automated matchmaking is that hackers absolutely ruin first person shooters. Every major FPS is littered with hackers, hack detection systems are crap and not hard to subvert.

It's why I gave up on games like Rainbow Six: Siege. You know, often you don't see hackers and there are plenty of good people at the game. But I tried playing the rated version and some of it was just so obvious. Like you'd be running up stairs before exposing yourself to an instant death. When you see the killcam you just see their crosshairs tracking you up the stairs through a wall. The most obvious wallhacking. Not even hiding it. And there's nothing you can do about it, you just lose to it.

Same with PUBG, Tarkov (which I mentioned in another thread), and now there are posts about how common they are in Apex Legends (which I have not played at all and don't plan to).

At least in the good old days of Counter-Strike, a server could ban suspected hackers without question. Now everyone is forced to stay in lobbies with these douchebags. I don't get why anyone wants to do it. A single death to a hacker just steals the fun of any game.

I came across this today: https://github.com/r1sc/OpenSith

JKL/3do renderer for Unity engine. I guess rendering these is the easy part because everybody seems to stop there.

You don't need to guess.

lol, hacking in JK was basically rampant on zone.com. It wasn't even hard to crash the game by spawning some outrageous number of things.

Ah, yes, the good old days of being spammed force destruction shot from a repeater in the face. Or being turned into a rotating door.

Well yeah, JK didn't have dedicated servers. That was more of a 00's era thing to be fair.

Sadly, in my case all instances of "did that guy just cheat or do I suck at this game this much" have been the latter 100% of the time.

Stupid Solitaire.

(Pretty much how I felt whenever I joined a public UT2003 server and got link-guned in the head to death in the first 5 seconds of being spawned)

Awrighty, here's the injector so far:

https://github.com/jdmclark/jkgfxmod

I put a prebuilt version on the release tab.

Well, it runs at 1024x768 (and looks the part on my 2560x1440 monitor), trying any higher resolutions won't scale properly on the screen so putting 2560x1440 in the .json file results in only the upper left corner being visible (and a screenshot taken in-game turning out completely purple).

(Had to set both JK.exe (taken straight from the original CD) and inject.exe to Windows XP Service Pack 2 compatibility mode, though... can't believe it worked)

- Don't use compatibility options.

- This hasn't been tested with other patches, and will probably not work with them.

I'm also impressed by JK instantly going to the menu when Esc is pressed in-game.

But yeah, without the compatiblity modes it refuses to run on my end ("Failed to launch JK.exe", the injector says).

I vaguely remember vanilla JK having issues with transparencies when firing the ST rifle at windows like this, now it looks proper.

[Unable to find specified attachment]

I just fixed an abort() caused by playing an end-level cutscene. Oops. New version up. Hopefully nobody else downloaded it first.

Odd. Is this the original CD-ROM version of JK.exe?

In compatibility mode, it actually works with JK2013 and T-O: DOA 2 as well, but the saber appears weird due to the translucency stuff we covered earlier:

[Unable to find specified attachment]

(Also, it actually runs JK properly at 2560x1440 with JK2013 instead of just showing a corner of the screen)

Some noticeable laggy twitches in this level, though.

Yeah, freshly dug up from the original CD, in fact!

Even in compatibility mode, it doesn't want to run TODOA TC MP (or any other subdirectories, actually). I tried changing the "command": "jk.exe" part in the .json file to read "command": "jk.exe -path TODOATC_MP" , resulting in the "Failed to launch JK.exe" error.

Guess it doesn't read JK's command lines yet.

It's pass-through. Run "inject.exe -path TODOATC_MP".

I'll check that out.

In the meantime, I wish those SUPERHOT type games didn't exist so I could be the pioneer with these kind of visuals:

https://www.dropbox.com/s/osqdqq9j2caghup/rubenpot.mp4?dl=0

Here's a TODOA 2 playthrough with the injector (got to try the original version with the 2048x2048 textures next to see if it still keeps on crashing):

https://www.dropbox.com/s/ivtjxzl5oioqn3i/TODORT.mp4?dl=0