Alternatively, we could move all posts containing 'New Forum Structure' and all 'New Forum Structure'-adjacent posts into one section, and all the rest into one dump.

Then iterate this algorithm over all possible variations of that sentence...and, et voilà, we have invented... threads (i.e., what we have now).

We should move all posts containing non-train related posts and all non-train adjacent posts into one section, and all the rest into one dump.

(OK, now I've really derailed this thread. Banned?)

Sigh. You’re making it worse.

Eh, not a problem, I've included links to the on-topic posts in the OP.

A more efficient data structure than a list of off-topic posts is a list of users banned for making off-topic posts.

[Unable to find specified attachment]

http://www.jkhub.net/project/show.php?projid=829

Impressive work.

Wow! Super neat.

lmao

This is really cool though! Beyond graphics updates, what pipe dream stuff would you guys want to see from a project like this?

I want JK but an imsim RPG

Bug accurate emulation

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.

Oh yeah, I wouldn't recommend downloading it or anything just yet.

Huh, what'd they do?

Multiple CFAA violations to CM alone.

Oh yeah, weren't there a group of JK players who tried hacking Massassi a while ago?

The video itself looks cool.

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).

Just make a new game then.

...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.

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

No chance in hell the copyright owner would make it public domain?

All of them but functionally none of them.

Honestly using JKL2OBJ to take JK levels into Unreal or Unity would be faster & easier than trying to wrangle the Radiant thing, and you'd get a more modern engine for your trouble.

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

Haha, so it wasn't just me. The scaling was definitely off.

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).

I don't think it was a skybox even. It was literally a scrolling texture.

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.

I’m not sure what a neural network would contribute to this process.

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.

Not only that, but dr0id's JKL->JK2Radiant converter also didn't take kindly to overlapping sectors.

I don't take kindly to your FACE