|
|
|
Odd, from casual inspection of the code it appears to be working right. The pseudo code looks something like this:
if ( !( (mVehicleFlags & VEHICLE_FLAG_HOVER_UP_ONLY) In other words... if VEHICLE_FLAG_HOVER_UP_ONLY is TRUE and hover effect would push DOWN then do nothing. I'll have to play with a bugged vehicle to see why it doesn't work. Perhaps the flag is getting reset somewhere?
Anyhow, just sent you a bugged vehicle. The airship in question ought to be prevented from hitting the ground or dipping into the sea (i.e. prevented from descending below the hover height), but otherwise should be able to fly normally. In fact, it's stuck at exactly the hover height above the ground/sea, unable to rise, and if you whip it out and get in at high altitude, you're dragged down to the hover height. I know that this definitely worked in one vehicle I made. It's an inner tube, and originally I had it using VEHICLE_FLAG_HOVER_UP_ONLY off. I decided that I wanted it to be able to bob up out of the water and only have gravity pull it back down, so I turned on VFHUO, and voila, hovering was only applying upward forces. You can see the inner tube in the center of The L Word South.
Perhaps it's getting reset for VEHICLE_TYPE_AIRPLANE?
I always follow a call to llSetVehicleType with calls to llResetVehicleFlags and llSetVehicleFlags to make sure each flag is set the way I want (defensive coding – I don't trust the defaults). In theory, it shouldn't matter what the vehicle type is. But you never know...
I looked at the inner tube, but it was no modify, and without being able to set buoyancy to 1.0, there was really no way to tell if it was being pushed downwards or not. What do you mean by "it uses full vehicle buoyancy"? If it's fully buoyant (buoyancy = 1.0), it shouldn't drop back to the water's surface at all if you pull it up. Since it does, it would appear the tube is as affected by this bug, just like every other test I've seen. If you have any object where VEHICLE_FLAG_HOVER_UP_ONLY actually works, I'd love to see it, but it doesn't appear to be working on the tube at all.
Huh... you're right. Maybe I'm remembering wrong...
I checked the code, and vehicle buoyancy IS on 1.0, and so the thing shouldn't be dropping back down at all, right? It looks like this: llSetVehicleFloatParam( VEHICLE_HOVER_HEIGHT, [some height] ); I distinctly remember that turning on VFHUO fixed a problem I was having where the tube would bash itself into a floor prim if it was rezzed on that prim at higher than the hover height. Once I turned on VFHUO, only gravity seemed to pull the tube down... exactly what it says it's supposed to do. Aha! Here's why I set vehicle buoyancy. The linden vehicle tutorial says this about buoyancy: ========================================= 11.13. Buoyancy The vehicle has a built-in buoyancy feature that is independent of the llSetBuoyancy call. It is recommended that the two buoyancies do not mix! To make a vehicle buoyant, set the VEHICLE_BUOYANCY parameter to something between -1.0 (extra gravity) to 1.0 (full anti-gravity). The buoyancy behavior is independent of hover, however in order for hover to work without a large offset of the VEHICLE_HOVER_HEIGHT, the VEHICLE_BUOYANCY should be set to 1.0. ========================================= And under 11.14, Hover: ========================================= Hover is independent of buoyancy, however the VEHICLE_BUOYANCY should be set to 1.0, otherwise the vehicle will not lift itself off of the ground until the VEHICLE_HOVER_HEIGHT is made large enough to counter the acceleration of gravity, and the vehicle will never float all the way to its target height. ========================================= So I think, in order for VEHICLE_HOVER and VEHICLE_FLAG_HOVER_UP_ONLY to work, you have to have 1.0 or nearly 1.0 buoyancy. It looks like hover and buoyancy are coupled, and that the vehicle is actually affected by gravity if it's above the HOVER_HEIGHT if you have VFHUO on. That's all well and good, but my vehicle doesn't need to be independent of gravity because it's using the linear and angular motors to fly.
If I turn hover off, pitch up (with the angular motor or just setting rotation), and pump the linear motor, I take off. If I leave hover on, pitch up, and pump the linear motor, I'm stuck to the hover altitude. Do you have vehicle buoyancy on, though?
I think what I'm seeing is that, paradoxically, turning vehicle buoyancy, vehicle hover, and VFHUO on will still make gravity affect you when you're above the hover height, but it won't push the vehicle down to the hover height as per the hover parameters. I have VEHICLE_BUOYANCY set to 0.05 at all times, to give it a little extra lift. I suppose I could use non-vehicle buoyancy or force instead.
That doesn't sound like a "paradox", mind you, that sounds like a "bug". When I can get in world again I will. In the meantime...
The way I read it it's describing the relationship between VEHICLE_HOVER and VEHICLE_BUOYANCY. VEHICLE_HOVER also works independently of VEHICLE_BUOYANCY, as demonstrated by the fact that I can set VEHICLE_HOVER with VEHICLE_BUOYANCY and, well, hover. Lex: Actually, what you're describing is consistent with VEHICLE_FLAG_HOVER_UP_ONLY not working at all. Your tube would smash down before because you had both gravity and hover pushing it down. When you set buoyancy to 1.0, you removed gravity entirely, causing only hover to push it down (because VEHICLE_FLAG_HOVER_UP_ONLY isn't working).
In my own test vehicle, I do have VEHICLE_BUOYANCY set to 1.0. In that condition, it makes it quite obvious that VEHICLE_FLAG_HOVER_UP_ONLY isn't working. You get pushed down, not as fast as gravity would take you, but you're still inexorably pushed down. Ok this is definitely bugged, and I have a fix. Unfortunately, the fix breaks some boats (and who knows what other vehicles).
Turns out there was a genuine bug in Havok1 vehicles that was somehow making things work unexpectedly. When I look back at the Havok1 code I wonder how these Hover + Buoyancy vehicles ever worked the way the did – it just doesn't make sense. The Havok4 code got moved around a bit but is currently doing what it appears Havok1 should have been doing... but wasn't. Would it be possible to change the value of VEHICLE_FLAG_HOVER_UP_ONLY so that old compiled code (which would continue using the old constant's value) continues to exhibit the old behavior, while freshly compiled stuff uses the correct behavior? If possible, that might save the pre-Havok4 stuff from failing. But otherwise, I suppose a few things are just going to have to be tweaked for Havok4 in any case...
Gaius, I just tested a vehicle you gave me... "DTA-2011 Hover-Up-Only Fails" in Havok1 and it was working the same as Havok4. That was odd... so I recompiled the script, just in case it was a Havok4 compile problem... same behavior. Then I went into the Beta Havok1 regions and tested there... same behavior – I can't get it to float up at all.
I now need another demo vehicle that works differently in Havok1 and Havok4. I'll see if I can find Lex's floating tube and test it in Havok1. Ok, perhaps I misunderstood this bug. Which sentence best summarizes this bug:?
(1) Vehicles that used VEHICLE_FLAG_HOVER_UP_ONLY now work differently in Havok4 than they did in Havok1. (2) VEHICLE_FLAG_HOVER_UP_ONLY doesn't do what the documentation says it should, and never has. That would definitely be a (2). This has never done what the documentation says it should do, as far as I know, although I can't say anything definitive beyond two years ago.
I certainly wouldn't consider this a high priority bug – we've lived with it a long time. But it'd be nice if someday the behavior described in the docs was actually possible, either by making this flag work as documented, or leaving it broken for legacy purposes and making a new flag that implements the behavior documented. Whew! That agrees with what I was finding in the code, and what I found when testing. Originally I was under the impression that it was (1) – I guess the timing of the Havok4 release and the creation of this bug had me wiggin' out.
I don't think I'll ever be able to recover the intended behavior – there are too many vehicles that rely on VEHICLE_FLAG_HOVER_UP_ONLY behaving the way it does. I'd have update the documentation to agree with the actual behavior, and add a new very specific flag. This brings up some projects I've been thinking about for a while: should the current vehicle be enhanced with new flags and other parameters? Or should we instead just make new vehicle API's, such as llSetAirplaneParams() and llSetBoatParams()? (two entirely different vehicle implementations) Fodder for office hours perhaps. Ooh, I've got one idea for a new vehicle flag that I'd really love to see: VEHICLE_FLAG_MOTOR_ABSOLUTE or something like that. Basically, it would change the motors from being continuously local in reference to being statically global in reference. For most vehicle models, the continuously local motor concept makes a lot of inherent sense. But for one specific project, it was the reason that I had to essentially reimplement a good portion of the vehicle system in LSL, using all impulses and llRotLookAt() rather than getting the efficiency and code-simplicity benefits of using the Vehicle api.
The script is for my automated vehicle props in Suffugium. If you stand around on a street for a few minutes, you should see a car drive by at some point. These follow a set track of waypoints, using some pretty nifty dynamics code to smoothly drive along a multi-segmented path, rounding corners and banking while turning. The algorithms are resilient, so that a car can be shoved off its path and it will make its way back to the path in a graceful fashion. I would REALLY have liked to use the Vehicle API for this, but I couldn't because the motors were continuously local in reference. I found that my script couldn't update the motors fast enough to compensate for the fact that, relative to the object's local axes, the target kept moving around as the vehicle moved. I needed to be able to specify a target velocity in world coordinates, so I had to use repeated llApplyImpulse calls. If you want me to show you the code and explain it, I'd be glad to... or you can take a look on your own time As to llSetAirplaneParams() and such... are there any reasons to factor out different vehicle types? Orthogonal functionality that can't be handled by flags? Efficiency? Because I like the generality of the vehicle system... making llSetAirplaneParams() strikes me as akin to going from llParticleSystem() to llMakeExplosion(). Some airplane builders might appreciate a vehicle that was modelled on LIFT, DRAG, and STALL_SPEED. Also, if we were designing a new vehicle API then we could get rid of the general vehicle's motor decay and perhaps also directly connect the keyboard controls so they trigger motions automatically instead of making the LSL script parse the control flags.
The current general vehicle code is kinda nice, but the implementation is complicated and fragile – I worry about adding too many new features to it and introducing all sorts of new bugs. On the other hand, it might be worth the trouble to try to add the direct keyboard controls I mentioned above and a few easy behavior flags. The problem I really have with the current vehicle code is that there's already too much distinction between vehicle types. My "Moewe" has to do some creepy stuff to behave like Nausicaa's Mehve does: she's able to do things like power-diving and immediately transitioning to skimming across the desert, and pulling other tricks that are utterly impossible (like a flip-remount in front of a running jet engine - luckily SL doesn't simulate jet intake airflow yet).
A real flight simulator in SL would be useful for people interested in flight simulation, but the "cartoon physics" of the current vehicle scheme are fine for people interested in gadding about in anime style. If anything, I'd rather have more keyboard control in LSL. I'm using CONTROL_LEFT and CONTROL_RIGHT as hard bank left and hard bank right, which isn't quite ideal... once you're banking pressing and releasing shift does not behave as one would expect. It would be best if i could independently detect the use of the shift key, and make SHIFT-UP, SHIFT-DOWN, SHIFT-FWD, and SHIFT-BACK do something useful. Won't finish.
This bug has become a misfeature, and too many vehicles now depend on it. I updated the wiki.secondlife.com page here: https://wiki.secondlife.com/wiki/Linden_Vehicle_Tutorial#Buoyancy Perhaps someone can fix the French and other translations. Also, I couldn't update the lslwiki page again because I've lost my password and Catherine Omega hasn't been able to recover it yet: Yeah, I was afraid the brokenness of this flag might be unresolvable at this point, given all the vehicles that have been built under the borked behavior. I've opened a new feature request, SVC-2188, requesting a new flag that does what this flag was original described as doing but never actually did. It would be a nice feature to have.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Normal
VEHICLE_FLAG_HOVER_UP_ONLY doesn't seem to do anything
VEHICLE_FLAG_HOVER_UP_ONLY
Hover doesn't push down. Use this flag for hovering vehicles that should be able to jump above their hover height.
What happens in reality:
Hover most definitely pushes down. You become locked into exactly your HOVER_HEIGHT, unable to fall below or rise above it. If you're below or above the hover height when you activate this, you are quickly pushed to that height, and remain there. In short, you see exactly the same behavior you would see if you hadn't set the flag. As far as I can tell, VEHICLE_FLAG_HOVER_UP_ONLY does nothing at all.