[T2] Vengeance mod

Okay, just to clear it up:


- The first release is a pretty cheap one. Until you hold down the fire button, it applies force to you in the direction of the grapple point. When you release fire, it does the same, but with more power.

- The second release is a terrible mess and should be forgotten.

- The third release is what actually the second was supposed to be. It doesn't affect you at all if you're closer to the center than you were at the moment of the grappling (because the rope is 'slack'). When holding fire down, it tries to keep you on a circular path. The redius of that path is constant (the distance at the time of grappling). Releasing fire reduces the rope's length and applies more force towards the center. The speed of reeling in is constant.


Of course you can always add to your speed by jetting. The old grappler though (first release) could increase your speed all by itself. The only problem with the new one (third release) is compensating the effects of gravity without slowing down radial movement.
 
KillerONE said:
:ugh:
Click to expand...

Compensating for the effect of gravity is the point I dont understand. These things are all linearly independant. Gravity is already dealt with. You only need to deal with any new 'forces' you introduce and linearly 'add' them. You are just adding one force which will result in a pivot about a point with the possibility of the addition of a 'reel' force - or not if the radius is fixed. Even the 'jet' force is dealt with elsewhere. If you were 'shot' and received an impulse that would be dealt with else where as well. How? It will manifest itself in a new %vel value for the player. You just need to apply your 'reel' force to that based on possibly the moment arm and perhaps the player mass.

You are trying to keep the player tangent to the circle described by the radius of the hook rope. That is what vector addition with the force/velocity of the hook does.


^ <------- player velocity at an instant in time
|
| / <--- resultant vector (tangent to the arc described by the hook radius)
| /
| /
| /
|/
-------------------------> <------- force/velocity of the hook

This is basically what the beta 4 hook does. It calculates a new player %vel by adding a 'hook' velocity to it.

%vel = %obj.getVelocity();
%mass = %obj.getDatablock().mass;
%pos = %obj.getWorldBoxCenter();
%rad = VectorSub(%obj.grapplePos, %pos);

%dist = VectorDist(%pos, %obj.grapplePos);
%force = VectorScale(%rad, %mass / (9 * %dist));
%tracVel = VectorScale(VectorNormalize(%rad), $TractorPower);
%newVel = VectorAdd(%vel, %tracVel);
%obj.setVelocity(%newVel);

This works because it interates over small increments of time. (differentials).
 
Last edited:
Well I am done with the rocket pod. I had to remove the smoke trails from the missiles because they do not follow the missile when its target is reset in flight. But you can still see them. They will follow a blue beam of death :)

I'll wait for Amadeu5 to get his hook straightened out so it works on a dedicated server as I mentioned in a previous post. Meanwhile I'll look into the aa turret.
 
ZOD said:
Well I am done with the rocket pod. I had to remove the smoke trails from the missiles because they do not follow the missile when its target is reset in flight. But you can still see them. They will follow a blue beam of death :)

I'll wait for Amadeu5 to get his hook straightened out so it works on a dedicated server as I mentioned in a previous post. Meanwhile I'll look into the aa turret.
Click to expand...

Thanks. The rocket smoke trail issue sounds like the hook rope graphic issue.
 
The beta 4 hook is good in principle (and might be superior to the new one), but I'm not sure if it always applied the right force (in terms of either direction and/or amount). Once I get home I'll experiment a bit more with it. The main problem is that the whole F(cp) = m*v^2/r thing only works when the object is already moving in a tangential path. Hmm... maybe using onGrapple to set it to the current tangential path and using the beta 4 method in grappleObject will work... gonna try that.
 
rotcon.gif

:cat:
 
Amadeu5 said:
The beta 4 hook is good in principle (and might be superior to the new one), but I'm not sure if it always applied the right force (in terms of either direction and/or amount). Once I get home I'll experiment a bit more with it. The main problem is that the whole F(cp) = m*v^2/r thing only works when the object is already moving in a tangential path. Hmm... maybe using onGrapple to set it to the current tangential path and using the beta 4 method in grappleObject will work... gonna try that.
Click to expand...

Right.

But what does that mean really? That only means that there is no component of the player velocity that is orthogonal to the hook rope. (And is non-zero) Meaning, either the velocity is equal to the hook rope as a vector (scaled) or the velocity is zero. Either way you wouldnt expect any tangential movement.

But that's what should happen. :)
 
btw, for some time now I get a grey console message saying "line always evaluates to 0" whenever I execute the script. What does that mean?
 
Amadeu5 said:
btw, for some time now I get a grey console message saying "line always evaluates to 0" whenever I execute the script. What does that mean?
Click to expand...

Although this probably isnt it, that sounds like an optimization message. (An expression that evaluates to a constant - zero).

I suppose it could be a message from the interpreter (virtual machine) saying that a line is a 'null' expression.

But I'm not sure. Do you know which line or is it more vague than that?
 
Correction, it says string always evaluates to 0. It also points at this line:

Code: 
%force = VectorScale(VectorNormalize(%rad), %radVel);

Both %rad and %radVel are declared a few lines earlier.
 
Amadeu5 said:
Correction, it says string always evaluates to 0. It also points at this line:

Code: 
%force = VectorScale(VectorNormalize(%rad), %radVel);

Both %rad and %radVel are declared a few lines earlier.
Click to expand...


Sounds like one of those variables (rad or radVel) is a string and is being 'cast' but doesnt contain data that is 'castable' to a vector. "xx yy zz" might cast while "hello world' wont. Check the format of the data in rad and radVel. unlikely that it's VectorNormalize(). <<<<==== unless VectorNormalize() returns an 'error vector' as a null vector. (I doubt that - but hey).
 
Last edited:
Turns out that $GrapplePoint has 4 words, but the 4th is always 0 as far as I can tell. %rad is calculated with a VectorSub function in which one of the parameters is $GrapplePoint. I just tried cutting off the last word, but the message is still there. Doesn't seem to affect the script itself in any way though...
 
JimBodkins said:
This is basically what the beta 4 hook does. It calculates a new player %vel by adding a 'hook' velocity to it.

%vel = %obj.getVelocity();
%mass = %obj.getDatablock().mass;
%pos = %obj.getWorldBoxCenter();
%rad = VectorSub(%obj.grapplePos, %pos);

%dist = VectorDist(%pos, %obj.grapplePos);
%force = VectorScale(%rad, %mass / (9 * %dist));
%tracVel = VectorScale(VectorNormalize(%rad), $TractorPower);
%newVel = VectorAdd(%vel, %tracVel);
%obj.setVelocity(%newVel);

This works because it interates over small increments of time. (differentials).
Click to expand...

Theory seems reasonable, but this part looks out of whack to me:
%force = VectorScale(%rad, %mass / (9 * %dist));
%tracVel = VectorScale(VectorNormalize(%rad), $TractorPower);

Instead, I'd think:
%stretched = (%dist - %currentLineLength) / %currentLineLength;
if (%stretched > 0) { // only act if the line is "stretched"
%accelScalar = (%stretched * $grappleForce) / %mass;
%accelVec = VectorScale(VectorNormalize(%rad), $TractorPower);
%newVel = VectorAdd(%vel, %accelVec);
%obj.setVelocity(%newVel);
}

The $grappleForce coefficient would need to be tweaked in concert with number of updates per second. That is, if this is run 30 times per second, the value would need to be half as large as if it was run 15 times per second.

I would think the reeling in effect could then be achieved by scheduling reductions to the current line length, and letting this velocity updater handle the resulting movement.

If the result is too bouncy, one could try squaring %stretched.

Or so it seems to me... been a long time since college...
 
Amadeu5 said:
Correction, it says string always evaluates to 0. It also points at this line:

Code: 
%force = VectorScale(VectorNormalize(%rad), %radVel);

Both %rad and %radVel are declared a few lines earlier.
Click to expand...

If radVel is a vector then it will error, you can only feed vectorScale a single number to multiply a vector by.
 
Back
Top