 |
Redesigning the blackjack system probably should wait until 2.08. |
 |
I'm moving this to 2.09. There's no time during 2.08 beta to do/test the amount of work required. |
 |
Asset rev 16605 and 16606 Source rev 10078 |
|
|
Commit #10079 (source code) and #16607 (assets): cvar tdm_blackjack_indicate added (boolean, defaults to 1) to allow enabling/disabling the knockout preview indication new spawnarg added to the blackjack, knockout_range melee_distance controls the distance within you can hit the enemy, knockout_range is the maximum distance between the point were the trace hits the enemy and the enemies eyes below which a hit is taken into consideration for a probably successful knockout. |
 |
@Obsttorte, could you please describe the changes you actually did in the code here? |
 |
added an alternative approach for blackjack hit calculation (the original implementation is untouched, the respective code gets executed via the animation frame command system) - the code performs a box trace that, when hitting the enemy at a point close enough to the head, will execute the same code that in the previous implementation was executed when hitting the enemies head with the blackjack - spawnargs were added to control the box trace's properties - during a successful knockout approach the blackjack model is nonsolid, so it can't get hung up on ceiling beams et al. - the code changes apply to weapon.cpp/h a blackjack preview system was implemented that signals the possibility for an successful knockout - the code deciding whether or not a blackjack would be successful is the same as the one used to perform the actual knockout - the code changes apply to player.cpp/h This is still WIP and I am awaiting feedback |
|
|
UPDATE: Also there is a check that hit was done "sufficiently behind", depending on various helmet settings. Now it uses main orientation (body orientation) for determining what direction is forward/backward, previously it used head direction (causing major issues when guard turns head around). Do we really need spawnargs for box trace properties? Usually providing some configurability (especially to mappers) where it's not necessary results in major headache later, in case someone decides to actually configure it =) |
|
|
"Do we really need spawnargs for box trace properties?" Their main purpose is for me/the team to be able to tweak those stuff . There are spawnargs for all kind of properties that, if altered between missions, could also create quiet some different gaming experience (or major headache, as you name it). I would leave them for now. re UPDATE: yeah, forgot that one. That was a request by Dragofer that seemed logical to me. |
- Anonymous
