ensiform

The game doesn't even handle steam master server protocols anyway (not to mention, which are part of the non-GPL steamworks API)

Seems to me like theres an error happening but its not displaying the error popup. Did you check the console?

Say what? Those are executable names.

You can only play Jedi Outcast Single player with "openjo_sp" OpenJK does NOT support Multiplayer of Outcast for the foreseeable future, and if it ever does it will likely not be compatible with original mods. "openjk" is Jedi Academy MP." "openjkded" is Jedi Academy MP Dedicated Server "openjk_sp" is Jedi Academy SP. This information is in the readme: https://github.com/JACoders/OpenJK/blob/master/README.md#jedi-outcast-support

You didn't look very hard, it was newest commit in cl_input.cpp: https://github.com/JACoders/OpenJK/commit/337687913865ffe7f79bf5ce754127edc5217469

As long as they are using the cgamex86.dll provided from the OpenJK builds they can use it. This is of course the client plugin module.

Its a command in OpenJK's cgame module. The engine being used is irrelevant. https://github.com/JACoders/OpenJK/blob/master/codemp/cgame/cg_consolecmds.c#L104-L142

https://code.google.com/p/ojpa/source/list

LLVM is not relevant at all, don't know where you decided to pull that out of. You do realize that C++ is a subset of C right? The issues you need to solve are the differences between the codebases mostly. Some of the files may not even contain any C++ as it is. I think you should probably wait until someone with experience decides to take up the task of bringing SP to MP engine for coop.

Because the original codebase was all C (Quake 3 Arena). And because the SDK in Q3A and JK2MP were only using "Quake Virtual Machine" which only supports "C". The decision to drop QVM support for JKA MP was done later on in development but it retains C. Mind you most of the rest of the codebase is still C or C-like even though it is .cpp. There are differences in how C++ handles some things which is why it fails to work out of the box. For example you cannot cast a void pointer (void *) to any old type in C++ like you can in C. And enums are more strong typed in C++ than in C as opposed to being simply integers. Among other things.

OJP had access to parts of the single player code. This is no task for someone who is too new to programming general honestly. The reasons for your errors is because the MP sdk is only C, not C++. Plus there are tons of differences of course in the AI files themselves that wouldn't be compatible with MP out of the box.

You should not alter any of the asset pk3 files ever. Replace the ui.shader in a new pk3 with the same folder structure.

No it cannot. Its a message that comes from servers to anything that sends a getstatus request to the server. It does not contain the numbers. The numbers are local during the parsing and added as the loop iterates. So it is not even showing client numbers. (First client in server is 0, second is 1 etc) You should rely on the mod to provide a client list cmd that shows real client numbers. Pretty sure OJK and JA++ cgame have a cmd for this. Some mods may even implement a cmd in g_cmds.c which is avail for clients but doesn't require cgame. In the OJK cgame the command is clientlist.

This looks basically like you have a shaders folder sitting in base or a mod folder for mapping. The shaders in here, are not compatible with playing the game. gfx folder shouldn't affect anything shaders wise, which is what appears to be the issue.

Will need a bit more details other than that? system specs + OS, install location (where the openjk.x86.exe is), How did you launch it, Were there any sort of error messages at all or any console window showing up with error? Did you even "install" it correctly so that it could find your assets?

The fact that vid_restart crashes unless you're sitting at the main menu in SP is one of the reasons for the problems with how things are set up in SP atm with rendering and sharing with the server. When we moved it to a modular renderer it now tries to reference renderer stuff from the gamecode, and when you do a vid_restart while the game code is running you end up with an access violation in any number of places that calls the renderer dll. (Relative to comments that xyc said to you)

That was always the assumption. Someone has been spreading the FUD because they didn't know otherwise.

They weren't even being attacked initially. Its still down because their IT hasn't figured out how to get the firewall situations figured out as previously mentioned.

Could always release the patch with no-cd and prevent the anti-tamper from triggering.

Hex edits will flag them as no-cd type patches and fail to pass checksum checks.

Neither of the two cvars you mentioned actually affects the true intensity of the dlights. r_dlightBacks 1 causes it to skip rendering the dlight if the backface of the dlight is not visible. This feature was stripped from MP by raven software back before the game was released for supposed hacking. (So MP acts like it is "0" which always checks the backface) Probably going to make this the case for SP too at some point in OJK. r_dlightStyle 0/1 uses more expensive extra pass for rendering the dlights if set to 1. Effect probably shouldn't be that visible at all like you said. Default is 1.

Its in the hands of the IT people to figure out whats wrong with their firewalls at the office.

OpenJK only works if you also use the OpenJK ui module. Aka running custom mods will not give you the option to select the others in the menu. Still being maintained mods can of course choose to implement it. I'm not yet sure if it is in JA++ yet or not.

At this point the only other thing I could recommend doing is using OpenJK. But you will probably have to re-configure everything.

First time I've heard it happen.