Edit: Turning problems detailed in this post have been solved, and some of the conclusions proved incorrect - see above.---
One would think that
llLookAt and
llRotLookAt would be the ideal functions for use with a guided physical projectile that one wishes to have pointing in a certain direction. Certainly,
in the wiki, it says "this function works for both physical and non-physical objects".
Does it? No, unless I'm doing something horribly wrong.
This evening I have been engaging in a little rocket science, trying to build a projectile that
(a) accelerates constantly in the direction that it is pointing until it runs out of fuel. This is fairly straightforward, it just requires using
llSetForce. I added in a drag co-efficient that represents air resistance, proportional to the current velocity, as well, so as to limit the speed.
(b) moves to point in the direction that it is moving in, more or less. (Aerodynamic objects tend to do this - think paper aeroplanes.) It's easy to make vehicles do this, there are automatic parameters to set, but for physical objects I can't see any mechanism apart from applying a force or impulse myself. And that's where I'm having the problem.
First things first; the basic motor. (I was told earlier on today that I didn't post enough code examples so I'm doing a little of that now.) Here are my global variables:
float gFuel; // current fuel
float gFuelMax = 10.0; // seconds of flight time
float gMaxSpeed; // calculated based on FPS
float gAcceln = 10; // metres per second per second
float gTimer = 0.2; // check every X seconds
On entry,
gFuel is set to
gFuelMax, and
gMaxSpeed... well, that is set to
llGetRegionFPS() * 1.5. Why? Well, the rocket itself has an invisible central prim that is 1.5m long, for collision detection, and I am assuming that
llGetRegionFPS() will give me the physics framerate. Any faster than the above and there will be "gaps" between the positions of the rocket meaning that a collision might not be detected. See the previous post that I made about bullets for more on this.
Anyway, also on entry we set a timer with a frequency of
gTimer. All that the timer event does is call
set_engine(llRot2Fwd(llGetRot())), to set the engine going in the rocket's current forward direction.
set_engine is a function that takes a direction as a parameter and consists of the following code:
set_engine(vector dir)
{
vector vel = llGetVel();
vector drag = vel / gMaxSpeed;
llSetForce((dir - drag) * gAcceln * gTimer, FALSE);
gFuel -= gTimer;
if (gFuel <= 0) explode();
}
The value of the vector
drag varies depending on the current velocity, and is a push in the opposite direction to the rocket's current
movement - note, not the direction parameter sent to the function. At maximum speed,
drag will have a magnitude of 1, which should cancel out the rocket motor if that is acting in that direction. Okay, the drag should really be different for different directions, since the forward drag on a rocket is much less than the drag on other axes, but give me a break, it's only alive for a few seconds. Er, I mean, that's an optional project for advanced students.
That all works fairly well it seems. The problem is that the rocket should really turn in the direction of movement - real rockets do that. Only I can't seem to get that working. I can't use
llSetRot, that's only for non-physical objects, and when I try to use
llLookAt or
llRotLookAt, they just don't do anything at all. I tried building a sensor object that used those functions to look at the nearest avatar to test this. When it was non-physical, it turned fine (and I've used this many times before). When it was physical, it just didn't move.
I don't know if I'm screwing up some parameters or not - I'm
sure I've used
llLookAt with physical objects before - but it is annoying me greatly at the moment. Once I find a solution (if ever) that doesn't involve the use of
llApplyRotationalImpulse, which I don't understand and which scares me, I'll post something on the matter.
As a post scriptum,
hold_R_bazooka is all very well as an animation, but why on earth does
aim_R_bazooka have to involve your left hand entirely changing position?
I have often complained about the lack of suitable animations in Second Life of use to a designer of mechanical items, such as myself. I have often complained at quite tedious length, in fact; I was doing so just yesterday. The issue is that the standard method of creating these thing is a program called Poser, which I'm sure is a fine piece of software but seems not only over-featured for use with SL, but also overpriced.
The basic launching device is quite simple, just a paper aeroplane that you hold in your hand and which throws a sub-aeroplane of identical appearance but quite different behaviour. The sub-aeroplane (which I shall term the plane, as opposed to the launcher, for convenience's sake) is the issue here. It's quite simple to give the plane a high buoyancy and just let it fly across the landscape or classroom:
