To be serious for a second, what I’d want to see from a project like this is a serious effort to achieve gameplay feature parity before going into the weeds. Renderers and editors and extensions are a lot more fun to write than gameplay code, but that stuff can be a harmful diversion. I don’t just mean because they take time away from the real work, but moreso because overinvesting in those systems can ossify gameplay code and data structures that turn out to be wrong.

Really what I mean by ^ is for it to be done.

Another thing I’d like to see is, well, tbh, the source code. I don’t know strike but I do know some of his friends, and I’m not gonna run any of his code that I haven’t read and compiled myself. I know it’s guilt by association, but his associates have also worked very hard to be untrustworthy. I’m skeptical enough about code from engineers who purport to be professionals, so I’m really not sure what to make of a software project that’s been voluntarily associated with that side of the community.

Another thing I’d like to see - something totally selfish. A compilation of reverse engineering efforts. The main reason I stalled out on Gorc is because to go any further I’d need to do some serious reverse engineering to figure out how the template parameters and flags worked. If someone already did that work (and I mean really did it, like collect data for real, don’t just say **** like “slippery” or “air drag”) then I’d probably do more work on Gorc again. I know this sounds like picking at the bones of another project, and it is. Like I said, it’s selfish and I know it’s selfish. But it’s honest, I’d love to have a real spec for that stuff to work from.

Another thing I’d like to see is, well, tbh, the source code. I don’t know strike but I do know some of his friends, and I’m not gonna run any of his code that I haven’t read and compiled myself. I know it’s guilt by association, but his associates have also worked very hard to be untrustworthy. I’m skeptical enough about code from engineers who purport to be professionals, so I’m really not sure what to make of a software project that’s been voluntarily associated with that side of the community.

Jon`C is your obsession with the exact template flags or whatever just because you want an exact copy of the original gameplay experience or what? I'd love to walk around in some rough approximation (on modern hardware with modern rendering and whatever else) and deal with having drag or physics or whatever "feel" a little different. It doesn't seem like this game needs "perfect" emulation like the original Super Mario Brothers or something.

Jon`C is your obsession with the exact template flags or whatever just because you want an exact copy of the original gameplay experience or what? I'd love to walk around in some rough approximation (on modern hardware with modern rendering and whatever else) and deal with having drag or physics or whatever "feel" a little different. It doesn't seem like this game needs "perfect" emulation like the original Super Mario Brothers or something.

No, there were reverse engineering tasks that were hard blockers for Gorc. I havenít worked on it in four years so I honestly donít remember what the problem is anymore. The goal was only ever to be good enough to play through the official single player campaign, I never intended to be bug accurate.

Iím obviously not obsessed with it because I didnít keep working on it.

The datamaster and jkspecs are just wrong and incomplete. They were good enough for modding back in the day I guess, but theyíre both full of blatant speculation to the point that they arenít useful for writing an engine recreation.

A few months ago xzero told me about a new discovery: there are hard-coded global variable symbols in cog. The original single player levels depend on this behaviour. Jkspecs and datamaster document the globals as messages, though, which is just wrong and more importantly random. Like they dumped strings from jk.exe and assumed they were just messages. Itís stuff like that. Our tribal knowledge is full of red herrings and you donít know whether something is subtly or incredibly wrong until you individually validate everything.

And then thereís the pile of unknown flags. JK actually uses a lot of them and we have no idea what they do - but ****s broken without them implemented right.

So Iím really not kidding, 90% of the outstanding work is reverse engineering. At least for me! I know BAH has been doing this work, so their emulator has a more promising future than mine does.

As someone who knows nothing about reverse engineering, I spent the last couple minutes pondering just what very general search techniques could possibly be used to disassemble whatever state machines might be controlling the various hidden flags in the engine, e.g., by running jk.exe on a vast array of parallel machines and mutating the machine code and observing the behavior of instances that don't crash right away, or maybe trying to extract features from jk.exe with a neural net, or whatever else in the kitchen sink one could throw at it (SAT solver???). But in the end I realized that I have no idea what I am talking about, and that somebody would have already done this already. So if reverse engineering is really that hard, it makes me wonder what an executable game really "is": we can run it on our computer and we know how it should run, but without the source code, our understanding of just why it does is no better than why the genes of a human being create a functioning organism and not a fatally flawed one. And the wrong mutation is usually fatal (in both the case of organisms and programs).

In other words (now to consider merely the idea of attempts at imitation rather than complete reverse engineering), I feel that engine remakes are doomed to only be as convincingly game-like as artificial robots are convincingly human-like.

Well, in some ways, such robots are actually better than humans (even though they can't do all the things you'd expect a human to do), and likewise something like Gorc would fix most of the defects of the original jk.exe. But it still isn't compatible with what jk.exe expects, just like robots aren't compatible with what humans expect other humans to look and act like.

Actually, rather than attempting to recreate JK.exe, perhaps a more enjoyable activity would be to replicate the correct subset of its functionality, and then automate the conversion of the majority of existing game data to a saner spec: that is, treat game data that relies on unknown engine behavior as a bug in the data. And then fix all those "bugs" manually, by re-implementing them with tools, like a modified version of JED which generates game data for a new engine that can only parse game data conforming to the sane spec.

The question arises: what subset of JK game data will run at all in any sensible way whatsoever on a sane engine that doesn't reproduce bugs?

Maybe the solution is to run a neural net on the game data and train it to find places it relies on undefined engine behavior, and try to guess what the game data would have meant to say (in a sane universe, where the game data is written in a language with only well-defined behavior).

...that is visually indistinguishable from JK, and for which there exist automated tools to convert JK assets to run on.

Actually, I do remember that somebody wrote a program that would import JK level data into Radient for use with JK2. Needless to say, it didn't even come close to reproducing the behavior or even appearance of JK.

I wonder if there are many portal-based rendering engines around these days, and if any are open source and maintained. If so, one could envision writing a tool to convert the JK assets to run on one of them.

Actually, I do remember that somebody wrote a program that would import JK level data into Radient for use with JK2. Needless to say, it didn't even come close to reproducing the behavior or even appearance of JK.

I remember that! The level output wasn't scaled properly too so you get levels that are too tiny compared to Kyle's height.

I wonder if there are many portal-based rendering engines around these days, and if any are open source and maintained. If so, one could envision writing a tool to convert the JK assets to run on one of them.

Yeah. It was for JK2Radiant too, the inbred cousin of the Radiant family. Looking back, Jedi Outcast did NOT age well visually.

I was watching the opening cutscene for JK2 a few weeks ago, and the skybox animation (the one with the stars drifting by) just struck me as really ugly. I'd be more convinced by the ambiance that I was inside a flying spacecraft if I were in a Disneyland ride (wait a minute, what am I saying, those rides are pretty convincing).

Every single JK level has overlapping sectors you walk through. Not far apart either, the very first level you walk around a corner and youíre in a room that overlaps the hallway you were just in. All of the levels also have zero-width walls. I donít know how to import them into a modern engine without major rework.

The only assets you wouldnít have to redo are the sounds and textures.

imho it would be easier to black box reverse engineer and do a normal engine recreation.

Every single JK level has overlapping sectors you walk through. Not far apart either, the very first level you walk around a corner and you’re in a room that overlaps the hallway you were just in. All of the levels also have zero-width walls. I don’t know how to import them into a modern engine without major rework.

I think this much at least would be pretty trivial to deal with in Unreal, since it just uses meshes for level geometry. The most you'd have to do is split up the overlapping chunks of the level in Maya or Blender or something. No idea abt anything beyond that though.