Saber's hitbox

[Boothand]

I haven't had the chance to test this out properly in JKA - but in JK2's multiplayer attack/block system, I have a couple of questions.

 

JK2's no force gameplay is really good. It has so many aspects that I spend hours alone in servers with a duplicate of myself and trying to figure out how it works and how consistent it is.

What I've definitely noticed though is that the blocking hitbox isn't very precise. Most of the time the saber is blocked even when you hit the feet (when the saber is pointing upwards for example), with some variation depending on which angle you hit from. There's a ton of more things I'd like to figure out. Nowadays I'm doing almost scientific experiments with it, repeating every variation of possible hits/blocks under most conditions 40 times per variation, using scripts and teleports to get the exact same circumstances each time.

 

This is interesting, but time consuming and possibly demotivating in the long (very long) run. What I think would be super interesting is:

 

1. A way to visually see the hitbox in-game of the attacking saber and the blocking saber.

 

but also

 

2. A refined hitbox that actually limits to the saber only, and not a variating area around the saber.

 

Are any or both of these possible to achieve in code, without redesigning the whole game? And if so, would anyone be interested?

If JK2 is out of interest, I would love to see this for JKA as well, but as I said, I'm not so sure how precise JKA is compared to JK2. If anyone knows that, please share

 

PS. I realize I'm very nerdy on this topic, and that most people don't share my fascination to this extent!

[Omicron]

I would like to be able to see the hitbox in jka, it would help alot with practicing sabreing, and where to aim. Perhaps as a toggle-able cvar or something for it would be nice, nut not sure how possible that is.

[eezstreet]

You can do this using OpenJK.

Go into q_shared.h, and anywhere in the file, add:

 

#define DEBUG_SABER_BOX

Compile the code, and you shall have a new cvar: g_debugSaberBox. When turned on, it draws a box around sabers, indicating where it's actually hitting.

 

Debug builds of the original game code also have this cvar too.

[Boothand]

@@eezstreet

Compiling the code had no errors, but I got this when I tried to start up a level:

 

'

 

I also didn't get that cvar recognized before that.

I compiled MPCGame, MPEngine, MPGame, MPUI and the UseInternal defaults on the bottom.

[Grab]

Sabers don't use hitboxes to damage. Sabers do damege in specific time of animation.

JK2 sabers are shi... very bad.

[Boothand]

Sabers don't use hitboxes to damage. Sabers do damege in specific time of animation.

JK2 sabers are shi... very bad.

 

Yeah they do, but that doesn't make them bad, to longtime players of JK2 at least. Nonetheless, there must be hitboxes to detect collision, and that happens regardless of the time it deals damage in the animation.

[Onysfx]

Sabers don't use hitboxes to damage. Sabers do damege in specific time of animation.

JK2 sabers are shi... very bad.

They do use hitboxes, but yes about the specific time. (which is why you should never use yellow forward saber )

[Raz0r]

Sabers don't use hitboxes to damage. Sabers do damege in specific time of animation.

JK2 sabers are shi... very bad.

That doesn't specify how collision is tested, only when.

By default, saber<->player collision is per-triangle on the player model, saber<->saber is a procedural triangle mesh based on the blade's motion.

[katanamaru]

They do use hitboxes, but yes about the specific time. (which is why you should never use yellow forward saber )

Would you explain please?

I've wanted to replace that animation for a while since it doesn't seem to effective. What you and others know may help me out here.

[Boothand]

I assume you guys are referring to JKA now, with the forward yellow animation? In JK2, it leaves you open if you do that attack alone, but is very deadly if timed correctly and combined with a side hit. Very quick.

 

If anyone knows what's wrong with my compile though, shout out

[eezstreet]

@@eezstreet

Compiling the code had no errors, but I got this when I tried to start up a level:

 

'

 

I also didn't get that cvar recognized before that.

I compiled MPCGame, MPEngine, MPGame, MPUI and the UseInternal defaults on the bottom.

could not find shader for siege class icon

[Onysfx]

Would you explain please?

I've wanted to replace that animation for a while since it doesn't seem to effective. What you and others know may help me out here.

The hit detection only occurs at the start of the animation and at the end, (from what I've seen). I've tried using it in normal JKA MP, and if it does hit, I only give a slight pinch of damage. In MBII, it can be a very effective kill move on a knocked down enemy, but half the time when it is used, it results in a passthrough. It really is pretty useless.

[Boothand]

could not find shader for siege class icon

 

I realized some of the DLLs should be in base. I got a bit further but run into a very interesting visual concept + another crash:

 

https://dl.dropboxusercontent.com/u/58757568/Screenshot%202013-12-30%2020.35.41.png

 

 

My base should be pretty unmeddled with. What should be done?

[eezstreet]

not sure but try compiling on release, not debug

What maps do you have in your base? What shaders?

[Boothand]

-Added what you said to both q_shared.h I could find. Screenshot.

-Reinstalled JKA, and got some more order in the files.

-Downloaded latest build from http://builds.openjk.org/.

-Game crash upon map load, running openjk.x86.exe.

-Options > Mods > OpenJK loads OpenJK properly

-Runs fine, map loads up.

-Compiled my own code now that I knew it was clean otherwise. Success.

-Replaced files in GameData, /OpenJK and files in the fabulous_openjk.pk3 from the compile folder.

-g_debugSaberBox is nothing.

 

Hope I'm not misunderstanding the proportions of what was necessary to do in Visual 2010. I literally placed #define DEBUG_SABER_BOX "anywhere" and compiled 

[redsaurus]

just to check: you put it in q_shared.h?

[Boothand]

just to check: you put it in q_shared.h?

 

codemp/qcommon/q_shared.h

code/qcommon/q_shared.h

 

See screenshot above for details.

[Boothand]

Anyway, if someone can confirm that adding that single line is gonna do the trick, that would be superb. It must be running my compile, after removing all signs of the OpenJK build I downloaded, but the cvar doesn't show up.

 

What would be even better though, would be if there was an equivalent solution editing the JK2 1.02 source code.