ensiform

 

Note: if your function is in a different file altogether, you need to extern it like so:

extern qboolean WP_SaberParry( gentity_t *victim, gentity_t *attacker );

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

No, if I recall we didn't want to give designers the ability to access any cvar they wanted - that would just be chaos.  It would open up a bunch of features to them that we didn't intend, they didn't need and which they wouldn't entirely know the effects of.  And some would work in development (like cheats) but not release.  Instead if they needed a specific command to do something a cvar or console command could do, we wrote an ICARUS command for it.

 

However, I imagine something like this could fairly easily be written.  At least, someone could probably write a function to stuff a command to the console (like "\set g_sex f") or call Cvar_Set and Cvar_Get...

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.

What do you mean? w_saber.c:CheckSaberDamage() is full of Q_irand() calls.

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.

Didn't know that ICC was used for linux. Kinda strange not seeing any preprocessor quirks for it, must have been a solid compiler :-) I don't understand how ICC not being free is relevant to anything though (the question being about original compiler).

If you know exact MSVC version then what's the problem again? Did anyone try producing matching binaries with it?

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.

 Heh... maybe install Windows 98, NT, 2000 or XP on an old machine, install Visual Studio .NET or VS.NET 2003 (or was it VS 6.0?) and try compiling it on that?  

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.

 

I've already tried re-installing before when I had this issue AND restarting Steam but yet nothing changed :\.

 

EDIT: I got this error now when I try and use the MB2 Launcher to power up the game (just starting from jamp.exe doesn't produce this):

 execing default.cfg

execing jaconfig.cfg

couldn't exec autoexec.cfg

Z_Free(): Corrupt zone header!

 

Going to try re-installing MB2 as I'm out of options

 

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?

@@MGummelt

 

Would you happen to know if the .menu files were made by hand in a text editor, or the devs used a program?

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.

Agreed. This isn't EA. EA are only the Publisher. DICE is the real one's behind the scenes, here. Although, DICE is now pretty much an EA subsidiary.

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.

Maybe MGummelt could give EA Battlefront team some much needed advice on saber system building.

Words like..

 

Wasted talent

Needs to be involved in EA Battlefront 2

Ligtsabers not glow sticks

Under appreciated skills

 

Come to mind...

They aren't going to be consulted for EA's works at all.

Hmm.  I have a hard time believing the game shipped with such an obvious bug.  Does the retail (patched or unpatched) version behave this way?  Or just the JKA source code when compiled?

This is comparing retail versions of both games to the best of my knowledge.

@@Grab can maybe chime in more which versions were verified during testing.

It doesn't need to be in any fit state to be released to go on GitHub.  I won't be able to help, I don't have VS because I'm not on Windows.  I also wasn't really intending to help, just wanted to see the code get released and then others can help.

You should definitely upload it to GitHub or something. Then you have fewer issues with your source dying from hard drive failure. And can keep track of changes, handle releases, issues etc!

https://help.github.com/articles/adding-an-existing-project-to-github-using-the-command-line/#platform-windows

What do you think, @@JaceSolarisVIII? This topic might be helpful for your SerenityJediEngine.

Could I have a link to the source code?