Game Development Community

New Player Jetting Code Problems (+fixes)

by Henry Todd · in Torque 3D Professional · 05/14/2009 (4:31 pm) · 12 replies

*Edit: In retrospect to the discussion below, I've simplified this post to just address the actual bug.

Looks like someone tried to put jetting back into the Player object. I have no objections, but it looks like it didn't get any testing.

First the actual bugs. Energy is drawn in two places, and the second time it pulls the wrong amount.

Find this line in Player.cc:
if (move->trigger[1] && !isMounted() && canJetJump())
Scroll down a bit and you'll find:
if (mJetting)

First, this feels excessively redundant. Second, it draws energy in the first if() and again in that second one. I see that the second check exists specifically so that an energy drain this tick can turn mJetting off, but that actually seems wrong; if we had enough energy to turn mJetting on this tick, we should wait until next tick to turn it off. Maybe I'm missing something here?

Anyway, you'll see that the second energy draw takes minJumpEnergy instead of the correct value, jetJumpEnergyDrain.

I personally just crammed these two sections of code together into the first if(), but that's just me.

#1
05/14/2009 (5:00 pm)
I actually gutted all of that jetting code and use this one instead -- it feels much better than the walking on air jetting.
#2
05/14/2009 (5:08 pm)
That actually looks like a potentially far more complete solution. I was just going for a quick fix to the code they're including.
#3
05/14/2009 (5:20 pm)
The code, as it currently is, I have found to be extremely easy to modify. This may be the reason it is also so basic in function.
#4
05/14/2009 (7:36 pm)
Well, I was specifically trying to address the fact that it's actually broken. Uses incorrect values for energy drain and creates Z+ thrust only, which is basically useless.
#5
05/14/2009 (7:47 pm)
"Uses incorrect values for energy drain" Yes this would be a bug.

"creates Z+ thrust only, which is basically useless" This is an opinion of design. For what i use it as, I only need the Z space feature and use air control settings for x/y movement.


And I was commenting on the fear of a more complex system with extra fat being added in the current Jetting Code's place. T3D do not need more proprietary fat. I enjoy the base features and functions to be as simple as possible for flexible easy modifications; a starting point example not an end point solution.

#6
05/15/2009 (4:27 am)
I actually completely agree in that regard, which is why I brought it up at all. Bloat is even worse if it also doesn't work. :P

To get technical.. jetting on the Player was pulled from TGE long ago for that exact reason. I personally don't think it belongs there at all; it's specifically a feature of Tribes, not a real "general purpose" FPS feature. Swimming, crouching, these are all pretty standard, but I actually can't think of a game since Tribes that featured jetpacks as a standard system of movement.

I would vote for removing it entirely, but if it's getting thrown back in, it should at least be better than a messy hack. I certainly wouldn't suggest putting that resource in, but I think redundant (and incorrect) code, inconsistently-named datablock values, and dubious functionality at best all come together to say "why bother." It actually doesn't even use the existing trigger for jetting, it hijacks the altFire trigger instead.

This is the kind of code that just sticks for 4 years.. new users are left wondering, "is this supposed to make sense?" TGE was full of that stuff when I first picked it up.
#7
05/15/2009 (4:56 am)
Im not really a programmer(but know enough to make Torque do what i want), so would not know 'hack code' when i see it(most of my own code is very much HACK and a bit of SLASH).

I do know T3D is far more complex then TGE just from reading it(excluding the obvious features, it a much more advanced/skilled level of programing). Much of the old leftover TGE bits of unused code were great as example for someone like me to learn from. TGEA had alot of leftover code who was no longer being used at all- redundant functions what made it very difficult for me to follow along(editing code what looked like it was who i wanted only to find hours later the function was not even being called anymore-argh- replaced by new functions but never removed).

I hope T3D receives a final code sweep to cut the fat once its ready, but i rather see the accessory functions left as simple and easy to understand as possible.
#8
05/15/2009 (5:08 am)
I actually learned a ton from the strange Tribes 2 leftovers in the engine. Many of those are still in there, especially as far as ShapeBase is concerned.

In this case, almost twice as much code as is needed is used.. to actually break it. Remove that excess code, and that fixes the issue.

I'll admit that I was trying to shoehorn what was essentially new functionality into a bug fix (I was assuming an intended result based on the engine's heritage). It was 2 lines of the code equivalent of an earmark in legislature. The issue with the energy drain is still an actual bug, though. :P

I think it's too late for this. Everything I write is long and inexplicably in an English accent.
#9
05/15/2009 (6:16 am)
I only mentioned the other jetting code because it's what I was used to using and never noticed the actual bug in the current code.

The current jetting code in question was actually added circa TGEa for whatever reason.... I personally don't care for the air-control mechanics of it, but it's simple enough to alter or remove it.

And hey, an actual bug is a bug so maybe it will indeed be addressed.
#10
05/16/2009 (4:34 am)
I see what you mean. This block of code right here?

if (mJetting)
   {
      F32 newEnergy = mEnergy - mDataBlock->minJumpEnergy;

      if (newEnergy < 0)
      {
         newEnergy = 0;
         mJetting = false;
      }

      mEnergy = newEnergy;
   }

That is totally unnecessary, the work has already been done, and its not even correct to boot. So I just deleted that whole block.
#11
05/16/2009 (4:50 am)
That is also the way it is found in TGEA1.8.1
#12
05/16/2009 (8:02 am)
... and James got to it before I did. I bet if someone were to point that out to Alex Scarborough he just might fix that for TGEa also.