ensiform

Debug it. Find location of crash.

Per Didz, the Builds page will be down until Red Hat has fully fixed the shellshock exploit. It is back online now!

I'm sure that's how you all feel of course but in reality its not going to be very easy to support the SP community. SP still has way too much shit different, hence why supporting just MP for now was the correct route to take. SP is also less modifiable in a generic sense than MP is which is another reason to steer towards MP first. (A lot of things are more attached between server/client, and the game dll and engine/renderer).

Since day 1. Some of it may be pause/idle time but in comparison to the total its probably not a lot.

My Borderlands 2 has 1335 hours.

SP isn't getting this tech for a long time regardless

Set a model2 key on a door and it will render a model with it. Make a tiny single box to specify the origin where the model will appear and apply system/origin texture. This brush must be part of the func_door entity itself. Hammer is shit.

I don't have the time to really help out but I can provide some insight on how to make image based progress bars work. You'll want the background empty image. And then an overlay of just the progress portion at 100% with the rest transparent. Then with the code you can draw the progress portion with the necessary texture coords via the draw stretch pic trap call to cut off an amount when you don't have 100% etc. You'll need some major changes from the JKA hud code/menu files in order for this to work. As JKA doesn't really support custom HUDs as nicely as it could.

They will just be default value ie 0. If stored in the ent or client structs upon loading. They won't be explicitly saved iirc unless you tell it to save them in g_savegame.cpp

http://builds.openjk.org

Code it, or use a mod that includes it like JA+. And read said mod's server documentation.

If it required a modded bsp thats not a good change.

Playerstate variables are networked (MP) And usable by the local player and stored within their snapshot. (Concept still applies to SP even though there is no networking) But raven does abuse this by being able to access the gentity in cgame since it is all 1 module. I still don't see the point of just throwing out any old variables at me like NPC->health. Its just a variable stored in a struct. The ones that are off limits are ones which are shared between the engine and mod, as entitystate and playerstate are. gentity_t and gclient_t are also semi save changers in SP as well. But only if certain variables within them are being told to be read/written in g_savegame.cpp. Should be lists at the top.

How would it look in mobile theme Mobile theme is all kinds of bad though in general. Doesn't even show which forum newest posts come from when in a sub-forum.

Hmm, that trigger is supposed to have a wait time of 1 second so I don't know. Most definitely not fixed that's for sure

So there are some siege related/or just gamecode in general but seems to affect siege more type bugs that have been fixed already. But there are still some that have not. Siege glitches seem to mostly have been left out as of lately in terms of fixes. Trying to think off hand what has been fixed either directly by OJK or through the modbase merge would be (please feel free to add to this list if I forgot any or isn't actually fixed): Detpacks near objectives and switching/disconnectingGhost player due to reconnect in walkerTrip mines doing incorrect damage on explosion (slot 0 vs rest of players)Door unlockingGlowing lights on players/bodies/siege specsShooting self with disruptorSlot 0 "+use bugs", and really almost all slot 0 bugs in general are fixed now iirc. Some NPC ones may still be left though.Fast teamswitchFixed memory corruption in the advanced log code when an NPC fires a weapon or picks up an itemFast disconnect-reconnect causing items to disappear into the ether shouldn't happen anymoreShow siege dead spectators with dead information on the teamoverlaySiege spectators cannot be followed anymorecgame prediction for flying through certain entities like the big turrets on hoth while siege deadPortable sentries that die because of nodrop volumes (big lifts on hoth) will now properly clear sentrydeployed flag.Some double doors had problems where real spectators could not teleport through them. A few angled / height difference on both side ones are still broken (probably wontfix).Dying in lava should no longer cause the lava sounds to stick while siege dead.More consistent tempspectate checks.Don't allow /kill when siege dead.Prevent crash when NPCs are knocked down.Siege voice chats didn't play per character sounds even if they existed. ( See: http://jkhub.org/files/file/2051-fixed-vchat/ for the pk3 of fixed sounds )Some that are possibly known already but not fixed (please feel free to add to this list): Hoth bridge exploit and similar. (There's a fix from the old LF community but we aren't using it)Floating eweb on disconnecting players ( have fix, untested )Non detpack projectiles can still probably damage objects on teamswitch/disconnect.Glitches with the codes not spawning at a reasonable location after destroying the droid on hoth. IE: flying up into the ceiling and beyond. ( OJP has fix, but not used iirc )Siege file(s), siege team and class files buffer issues. Probably won't really do a fix here because to fully have the effect wanted you want the server and client to be fixed. And dynamic memory allocation isn't always the best option.I had others in my old mod which were optional or things like anti taking the codes backwards etc. Or cutting through the wall holes on desert before the wall was destroyed was fixed via a level fixes with solid brush until wall was destroyed. Don't really feel like digging through that mess at the moment

Add them to gentity_s or gclient_s or some other sub-struct to either of them same as you would in MP? I have no idea what you mean regarding forceRageRecoveryTime.

Those files are only for MP. Having to edit ps/es basically means you are no longer making a mod fwiw. The game crashes because you've changed the size of structures that are save-load affected. So you would only be able to load new saves created with the change. If at all. I could not find any specific areas that actually load the ps/es directly though. So they must only be written/read during the entity / client portions of save code. No we will not be adding support for those files or similar files to OpenJK at this time so don't request it please. The structs are non-POD too which makes it even more complicating to attempt it anyway.

And those are personal reasons. Still doesn't change the fact that we will not provide any support to people wishing to run it with OpenJK.

So play on the servers which do not have mods installed at all.

It comes with/is the 1.01 patch... assets0-2 are gold release, assets3.pk3 is 1.01

Why would we care to? So he can change the protocol version and run a, `still buggy jampgame.so file` from 1.00 without the gamecode fixes. Big whoop. And no it was not. assets3.pk3 only contains 1,2,4,5.

You people are weirdos. "Buggy" and "glitchy" in the same sentence as "fun". I don't even... And no, you will not be running any sort of official OpenJK with 1.00 (Codebase is 1.01 forked with no history). Kind of defeats the purpose of the project as it is. Actually it has a bit, but nothing saber core-gameplay wise. All of the ctf maps also got re-bsp'd also except for ctf3.

Glad to see you are keeping it up to date =] Most forks are behind/stopped grabbing updates.