ensiform

com_maxfps? Can you share the config files you have for jamp and openjk? Some settings were increased to accommodate being 2013/2014 rather than 2003. So the requirements are actually higher. You're looking for jampconfig.cfg in your game folder. And the openjk.cfg would be located in one of the mod folders within C:\Users\USERNAME\Documents\My Games\OpenJK\ Please post them on a paste site like http://dpaste.de and link to them here. Also, how are you "setting" one core, the OJK exe already does this on its own by default afaik.

Lightning and thunder storm effects won't ever be integrated though.

What map

fx_wind entity now works (t1_rail)fx_rain entity now actually can be customized same as SP. The count variable did nothing. (Everything should work except for lightning/thunder storm) Acid rain is visible only same as doing it via /r_we or an fx_runnerNPCs with customRGBA now supports all the values ie random1, jedi_hf, jedi_kdm etc (random1 is used with weequay and rodians etc)forcesight surfaces now work with supporting cgame (OpenJK cgame is the only one so far)NPC_human_merc NPCs have a spawn entry now. Since they are pretty common, I thought it odd they weren't spawning in MP (via entity)Extra jedi NPC types (master, random students)Just some quick little fixes for SP related content in MP. These all require new jampgame (the one included with OpenJK) (server side mod) with the changes except forcesight change requires new cgame + renderer.

Yes I know how it looks in SP. Doesn't mean you have to do it that way in MP. As previously mentioned You obviously want items to return to their place if not dropped in MP

Official PC EULA

XreaL had experimental bullet support in its java version of the mod code, but it wasn't really going anywhere. Not even networked. @@Lockgo do you have a video to explain the weirdness you are seeing? I don't really see any reason to be dealing with g_exphysics at all on item pickups. As they already have a think function which also already does simple normal physics as it is.

You shouldn't even need to deal with g_exphysics.c for moving of items with relation to force powers. That could be your issue right there if you have weird things going on if you are.

Are ragdolls even server side at all in MP?

It should be entirely possible to code something similar but you'd definitely run into that issue as mentioned above. We had a forcefield entity in Q3 Fortress/ETF which allowed for 1 direction pass throughs fine so long as you were looking in the correct angles. It might also be hard to have prediction work correctly on said triggers.

Its up to you guys (ie the rest of the community) to make a mod or provide the necessary changes in a patch so long as it doesn't require changing of assets (if to be included in OpenJK).

I had item pushing in my mod years ago. I forget where I got it from. } else if ( em_itemPush.integer && CheckPushItem( push_list[x] ) ) { //rolling and stationary thermal detonators are dealt with below if ( push_list[x]->item->giType == IT_TEAM ) { push_list[x]->nextthink = level.time + CTF_FLAG_RETURN_TIME; push_list[x]->think = ResetItem;//incase it falls off a cliff } else { push_list[x]->nextthink = level.time + 30000; push_list[x]->think = ResetItem;//incase it falls off a cliff } if ( pull ) { //pull the item push_list[x]->s.pos.trType = TR_GRAVITY; push_list[x]->s.apos.trType = TR_GRAVITY; VectorScale(forward, -650.0f, push_list[x]->s.pos.trDelta); VectorScale(forward, -650.0f, push_list[x]->s.apos.trDelta); push_list[x]->s.pos.trTime = level.time; // move a bit on the very first frame push_list[x]->s.apos.trTime = level.time; // move a bit on the very first frame VectorCopy( push_list[x]->r.currentOrigin, push_list[x]->s.pos.trBase); VectorCopy( push_list[x]->r.currentOrigin, push_list[x]->s.apos.trBase); push_list[x]->physicsObject = qtrue; push_list[x]->flags |= FL_BOUNCE_HALF; } else { push_list[x]->s.pos.trType = TR_GRAVITY; push_list[x]->s.apos.trType = TR_GRAVITY; VectorScale(forward, 650.0f, push_list[x]->s.pos.trDelta ); VectorScale(forward, 650.0f, push_list[x]->s.apos.trDelta ); push_list[x]->s.pos.trTime = level.time; // move a bit on the very first frame push_list[x]->s.apos.trTime = level.time; // move a bit on the very first frame VectorCopy(push_list[x]->r.currentOrigin, push_list[x]->s.pos.trBase); VectorCopy(push_list[x]->r.currentOrigin, push_list[x]->s.apos.trBase); push_list[x]->physicsObject = qtrue; push_list[x]->flags |= FL_BOUNCE_HALF; } There's a bit more to it than that, and other stuff that but is general idea of how to actually move them.

Sorry but not in the scope of OpenJK.

The OpenJK folder is the openjk version of the gamecode (MP). Same as any other mod. However... for singleplayer you must have the OpenJK folder with jagameARCH.extension (jagamex86.dll). We don't load the original one that sits in GameData for SP because it crashes. Frankly, some cheap laptops just aren't meant for games. Even older ones since they have poor OpenGL driver specs.

It wasn't about Matt Smith so much as it was about Amy Pond.

https://github.com/JACoders/OpenJK/blob/master/CHANGELOG.txt#L18

http://builds.openjk.org http://builds.openjk.org/openjk-2014-06-30-69ff4e13-windows.zip is the newest presently. Sounds to me like you are experiencing the bug of too many extensions string crash in the base game which happens on some/lots of newer cards depending on drivers if they fake the data sent.

"Maybe you can use your lightsaber to cut those trees down and make a bridge." Welcome to jkhub

Nope. What would give you the idea that OpenJK is using JKG-specific stuff?

OpenJK isn't really planning to or working on changing it at this time.

The bot AI is specific to JK2/JKA. Q3 uses AAS files instead of bot routes with waypoints. The NPC code and the bot code are two completely separate beasts. The bots will only take the routes of the waypoints. If they get off course they just jump spam hoping to get back on course if stuck or whatever. See: int BotFallbackNavigation(bot_state_t *bs)

We aren't planning/going to add any 'good' physics no. And certainly not in a renderer. Not of the main scope of OpenJK.

And those things have absolutely nothing to do with the renderer. Additional addendum: PHYSX SDK (and specifically Apex portions) is not GPL compatible. Therefore not permitted to do so https://developer.nvidia.com/content/apex-sdk-eula

What purpose does moving them into the renderer solve? They don't actually do any sort of rendering. It just makes basic calls to the export system. Don't want to bog it down with even more bloat. The font and language code is still in there and doesn't need to be per-se as it is.