eezstreet

No. You need to edit the already existing lines in order for them to look like my lines.

@@Szico VII: Fixed in OpenJK as of https://github.com/Razish/OpenJK/commit/e71ab51ad58b7bdb0045473e93dae4a1f6c8c6e7

#define MAX_SHOWPOWERS NUM_FORCE_POWERS-5

#define MAX_DPSHOWPOWERS NUM_FORCE_POWERS-1

Yes. MAX_SHOWPOWERS should be NUM_FORCE_POWERS-5

MAX_DPSHOWPOWERS should be NUM_FORCE_POWERS-1

I think it's limited to 16 force powers. Don't hold me to that.

I'm talking about the list that has FP_SEE, FP_LEVITATION, etc in it

what position is FP_STUN in the force powers enum? also what is the value of the last number, and are you sure this code is being called (set a breakpoint on the first line of ForceStun using the debugger)

It'd help if we knew what exactly you were trying to add/do.

Don't think it's supposed to have sound.

Are you talking about for MP or SP? If for SP, it's the same setup as in JK2 -> a misc_camera entity, pointed at by a usable object (trigger_multiple with USE_KEY spawnflag set, a func_usable, misc_model_breakable, etc) and pointing at an info_notnull.

Please read the front page of JKHub and try again.

I don't know what you mean by refactoring per se, but I was more or less talking about making the code compile under C++. Sorry for the confusion. I'd like to make classes for some of the things (eg missiles)

"if"

https://github.com/razish/openjk/tree/coop

Oh, absolutely possible. Just fork OpenJK, and pull from it on GitHub, and you can continue to keep your code up to date. I think most people are going to rely on mods of OpenJK, as OpenJK has some extra trap_ calls and things which modders can take advantage of (eg manipulating the segments of an .efx file)

The lightmaps lump (afaik) limits it to 128x128. If you're talking about external lightmap via shader (which I hate the idea of using anyway), I don't know if there actually IS a limit (but if there was, it'd likely be either 1024x1024 or 8192x8192). Increasing internal lightmap dimensions could potentially break base map support but I haven't looked into it enough to know for sure. It'll definitely disallow any sort of usage for that map on base though.

Also you need to use a special version of q3map2 to take advantage of said feature.

That's not refactored, just compiled as C++

I never claimed it was refactored. It's compiled as C++ with all the erroneous material removed (well most of it, the only thing that's breaking is cvars atm)

I never said it was impossible, just that it wasn't going to make its way into OpenJK.

The code would surely benefit from some refactoring and doing that in C++ wouldn't hurt either, but it's just such a massive task that I don't know if anybody is going to do it. (And finish.) I'd like a nicer version of the code myself and I do like C++, but I'm not sure that even with my love for Jedi Academy I'd be able to do this. I may try though, but that won't be a part of OpenJK, it'd be my own project.

 

If done properly it could hardly be done without breaking compatibility with existing mods though.

https://github.com/eezstreet/OpenJK/tree/CPlusPlus

way behind but mostly functional and doesn't break mod support

You'd still break base client compatibility if the server is using modified .wpn files or whatever.

Because the game is limited to 128x128 lightmaps.

A func_door, with angles set appropriately and a target_delay linked from the door which links back to the door. A trigger_always targets the door.

Or a func_bobbing.

@@Szico VII: I'm talking about using -export/-import to embed lightmaps into the actual BSP itself, not overriding it with some silly texture method.

orrr just toss the lightmaps, replace the textures, rebuild some geometry, add in much improved dynamic lighting, add in normalmapped shaders, add in either stencil shadows (Doom 3 method, code is partially there already) or shadow volumes (Crysis method), add specular highlights, environment maps, postprocessing (motion blur, color grading, HDR, bloom, SSAO/HBAO, DOF, sun shafts, et al), phong shading for terrain, LODs for BSP areas, improved PVS, probably better animations and physics for actor models, upgrade the GL version, remove dynamic glow, replace the flare system, use vertex shaders for the transforms and improve the particle physics

With Unity, you already have to do most of that crap anyway (minus like, upgrading the GL version and fixing the FPS bottlenecks), plus remaking the game's animations on probably a different format and remaking the entire saber combat system, as well as all the other gameplay, AI, cinematic, scripting, and crap associated therein.

It isn't worth it.

Wait a minute, when did I become the person to add normalmaps? D:

Yea, the limit might actually be 1024x1024.

What Raz0r posted doesn't appear to be external lightmaps though. I believe that's something else.