ensiform

Perhaps you shouldn't be standing still :thinking:. Always moving. Avoid death. Adding the alleged extra animation won't happen in this project. If it's not in the table of animations currently, we definitely can't support it. This was found out by adding the missing animations for the hazard trooper crouching which breaks saves. And in multiplayer it just makes people be the T/Jesus pose. This feature isn't really necessary considering controller support doesn't really exist.

Perhaps you need to show us how and where index is being set. It seems index should be set per item based on what you are doing with the sounds, no? As right now it's just reusing the same index value for all of the cases you've made.

@@MGummelt can you shed some light on why you guys decided to gut the core functionality of the Team Arena menu system for HUD usage so that it was no longer possible to create HUDs with allowing people to add their own items etc? The ownerdraw features and such were very powerful but seems to be mostly unused in JKA. I imagine it should have been easily capable of having the "tic" code handled via an ownerdraw somehow while retaining full capability of modders and users to use the full painted menus for HUDs. My guess would be performance I suppose but many other tech3 variants utilized it. Including RTCW, Wo:ET, Tremulous, etc. Plus Quake Live now-a-days expanded it even further for their game.

Sounds like cheating tbh.

Big time.

Actually, the standard doesn't require that -- only for variables.

We actually did add support for it in OpenJK project for JA single player. Not sure about JK2 SP. And pretty sure not for JAMP. (We still don't support jk2mp and probably never will because jk2mv exists)

JKA uses a different rand (based on MSVC) implementation in many places. I'm not sure if we changed it further or not as far as sabers are concerned. Q_irand / Q_flrand. Also mind you, Rand_Init is only ever called in the engine and not for mod code. (JKA)

Ideally, if you could replicate the normal behavior in a debug build of the original games etc and get the outputs with saber interactions and compare them to a current build that might be helpful but I'm not sure a debug build of the older VS would produce the same results, either. Mostly you'd just want to see what the assembly output looks like and the floats in real time and where they seem to drop off. Has anyone ever actually tested SP saber stuff compared to base? Because I'm thinking it might be tri_col_test related.

Ah yes, but not susceptible to being problematic like the ones that are inconsistent using the RandFloat function atop that file which is for deflecting and pushing projectiles away.

The random number generator has no effect on saber blocking or damages VS humans in normal MP codebase.

The original codebase obviously would still compile with those (if you wanted to have that crappy of a vs version, nobody wants to, its too old) OpenJK will not compile with < 2013 as of last year.

Thing is, code won't compile for it anymore because we fixed some of the bad C++ code and now (though somewhat unnecessary as a whole) use some semi-modern C++ in SP at least. @@mrwonko replaced the genericparser2 in SP with some C++11/14 code which is used for EFX/dms.dat and some other stuff maybe.

We've known about the icc compiler for linux for a long time. But they used MSVC 2003 for Windows ofc. ICC is also not free.

"The answer is because OpenJK SP is not compatible with SP version of my mod." -- Why is that? JASP doesn't support code mods in mod folders even, so this seems like a useless thing to try to get around. "Besides OpenJK (for MP) has many drawbacks, it's pretty unstable and I refuse to use it at least in current version which is far from perfect." -- I call bullshit. If your excuses here are but I can't do "/qui gon" anymore or some other crappy console combo I will not see any argument from you as valid. If on the other hand, the issue is "dismemberment" The answer I have to that is: It never changed at all and more specifically never changed to "disallow" it. So if you want it fixed, it needs to be investigated as to what crappy code no longer functions as originally intended. The code in question by your request above was already fixed in OpenJK SP as well as evidenced by the very same commits you linked on some of them, and checking the commit history for the UI folder for SP. I don't see why its so hard to port those yourself. You are dangerously approaching help vampire status by @mentioning everyone for a request like this.

I'm skeptical of using misc_dlight for real lights being stored in the map file.

You can still post on closed issues unless it's been explicitly locked. Continuing discussion in a single place etc. This wouldn't have been making the issue tracker not clean. A new tracker issue would have, yes. Looking at the unknown command part won't help. It's explicitly handled in Console_Key in cl_keys.cpp for MP. Might be better to allow the command to be customizable instead of enforcing it to be nothing or "say", no?

I don't see why you needed to take the discussion from GitHub issue that still exists (just closed) to a separate forum post. Regardless, it is unlikely to be switched back even with a toggle. Use the chat box for talking as you're supposed to or type the respective say command "say" "say_team" before typing into the console. Not that difficult to adapt. And correction its been possible since Q3A, which pre-dates jk2 of course. Seeing as there isn't a lot of activity from anyone of the maintainers at the moment, this is more the reason why it won't get included unless a pull request has been provided and accepted. You are free to do so or implement in your fork for your personal use.

From this exact post here it looks like you are running SP not MP. default.cfg belongs to SP. jaconfig.cfg belongs to SP. Z_Free() warning doesn't exist for MP afaik. The other thing eez didn't mention that it could be is a lack of having the proper MSVC redistributable installed for whatever version the MB2 devs are using.

Check your logs in the OpenJK documents folder.

You can use dynamic lights but the effect won't be that great. The engine does not allow creating real light sources in-game in real time. Because it uses lightmaps in the compiled BSP. JK2/JKA is only slightly better than Q3 because you can at least sorta light up darker areas whereas in Q3 it doesn't work if the area is totally black.

IMO would be cooler to have them outlined like TF2 https://wiki.teamfortress.com/w/images/b/b9/Killicon_back_scatter.png?t=20140619115621 / other possibility maybe https://cdn.discordapp.com/attachments/203263040680886273/281088019883229187/c_icon_infantry.jpg As it is now, you can't differentiate many of the icons, they're just blobs. Also: Need to be able to differentiate between trip mine proxy/laser kill me thinks? Flag icons: Taken, Dropped, Captured, Returned Wampa, Rancor, Howler Seeker drone Flying vehicle of some kind as generic flyer kill icon ATST as a walker NPC kill icon @@Circa still around these days?

You do realize they didn't create the .menu file system, right? It came from Q3: Team Arena. And it was all by hand in text editor almost certainly. They may have prototyped what it should look like in some design program, however.

They have been (officially) since 2006 but worked with them before that. And they started the process all the way back in 2004.

@@MGummelt, another question/observation would be with regards to the saber system in general. I'm sure many others can chime in but, simply recompiling the originally released SDK (also linux vs windows) even will cause differences in blocks and damages, more ghosting (visual hits that aren't hits) supposedly according to many people in the game and mod communities. I guess the problems might stem from different floating point precisions etc and the original codebase being super picky about values in the collision code and w_saber.c. But nobody has ever really nailed down what the causes are. And obviously, most people aren't going to want to use ancient compiler versions anymore, its not realistic. Someone had asked earlier on Discord what computer specs were used to compile JKA for Windows anyway? And this problem isn't exactly new. It's been highly debated and contested for many years as far as pure basers won't even use mods because the feels are different even if the code remains the same.