|
|
|
Francis Chung made changes - 17/Feb/08 02:52 AM
Francis Chung made changes - 17/Feb/08 02:52 AM
Francis Chung made changes - 17/Feb/08 01:03 PM
Hi Lex
 Yes, I'm referring to the vehicle buoyancy system here.
llSetVehicleFloatParam(VEHICLE_BUOYANCY) to set, and llApplyImpulse to add the bobbing motion. I'd rather not post the source code publicly here, but if you're really interested, contact me in-world. LL already has all the code and can reproduce this. This bug has been previously reported - it is just being re-reported here for tracking purposes. Oh, it's okay... the important bits are VEHICLE_BUOYANCY... I'm assuming you've set this to 1.0. When you said that the shadow would bob in havok 1, I was assuming you were using the VEHICLE_HOVER_TIMESCALE and VEHICLE_HOVER_EFFICIENCY, which purport to allow for bobbing handled automatically by the vehicle system. It sounds like I was wrong, though, and you're just handling the bobbing yourself using llApplyImpulse().
It might be useful to know whether the vehicle is running out of energy. If it is, it could be that a downward impulse is succeeding, but then an upward one is failing due to lack of energy, so the shadow keeps going down. This might indicate some kind of change in the behavior of energy, which could be the source of this bug. Lex: I don't think so. I see essentially the same behavior in vehicles that don't use llApplyImpulse. In my SSA-1901 airship (which Sidewinder, Andrew, and Simon all have copies of at this point I think), in Havok1 when you hop in, it remains stationary until you start moving, and when you stop moving, it drifts to a stop and stays still until you command it to start moving again. Also, if you apply forward throttle, it flies forward while maintaining a constant altitude. In Havok4, as soon as you hop in, in starts descending slowly towards the ground. If you rise, it'll eventually come to a stop and remain stationary, but if you move forward or turn, it starts descending (and continues to descend, even if you stop turning or moving forward. Also, as a consequence, you can't fly forward without losing altitude. All this is while using llSetVehicleFloatParam(VEHICLE_BUOYANCY, 1.0). Basically, under havok1, Buoyancy 1.0 gives you neutral buoyancy, under Havok4, 1.0 still causes you to fall. Setting higher than 1.0 has no effect, so, in fact, there appears to be no way to achieve neutral buoyancy, except in the weird case where you just straight up ascend – when you drift to a stop after ascending straight up, you'll hold altitude until you touch another control.
By the way, you could probably drop the "for moving objects" from the title of this bug. Buoyancy just isn't the same, period. Incidentally, this was one of the issues mentioned in Cubey Terra's "general vehicle problems list" (
I was surprised to see that bug has been closed, considering the issues on the list aren't all fixed yet, but perhaps it is best to file the remaining bugs separately. If you leave off the "for moving objects" from the title, this bug covers it, I think. I'm upgrading the priority of this one. I for one will scream bloody murder if this bug makes it to the main grid intact. Buoyancy needs to be fixed if we want any kind of vehicles other than flying bricks (aka heavier-than-air aircraft) to work properly.
Gaius Goodliffe made changes - 22/Feb/08 02:38 PM
lindenrobot made changes - 28/Feb/08 05:52 PM
Harleen Gretzky made changes - 03/Mar/08 01:48 PM
Andrew Linden made changes - 05/Mar/08 11:12 AM
I did an audit of the script energy consumption code and found several problems across the board, caused by hidden (and incorrect) units being used. Although I've already fixed them, my checkin failed to get in before the freeze for the next update, so the fix won't be in for at least another week beyond today.
Andrew Linden made changes - 05/Mar/08 11:17 AM
Harleen Gretzky made changes - 07/Mar/08 01:01 PM
I found this while testing my submarine. Vehicles should have neutral buoyancy when VEHICLE_BUOYANCY is at 1 (where 0 is full gravity and 1 is no gravity). However, in Havok 1 sims, neutral buoyancy is achieved by setting buoyancy to just under 1 (for this vehicle, 0.977). In Havok 4 sims, the same vehicle sinks even if VEHICLE_BUOYANCY is increased to 1.
To test this, use the freebie script from my sub in The Gnubie Store: This effects vehicles that aren't using buoyancy at all. Mehve flies in Havok1 with VEHICLE_BUOYANCY set to 0, but sinks in Havok4 if it's less than 1.0.
Argent Stonecutter made changes - 09/Mar/08 07:29 PM
@ Andrew Linden
I have sent you a "Balloon Float (Random) H4 test". Rez it, SIT on it, and TOUCH it to float around the H1 region. The script uses physics to simulate being blown around by the wind nicly under havok1. Let it float into a havok4 sim border and it comes crashing to the ground. This is the same fault described above, but it is not using the vehicle settings. It is using the indevidual LSL commands. I post my comment here as it is probably related. Darling. As I mentioned above: fixed internally, not yet deployed.
According to the blog, this has not been completely fixed.
i know this hasn't been completely fixed in the new version, but now it seems "worse" than before, i.e. it's not using buoyancy values at all for llSetBuoyancy as of 3-15-08 at 09:00 Sl time
For what it's worth, 82355 does appear to fix the slowly sinking problem that all my airships were displaying. They all work fine now. So, setting VEHICLE_BUOYANCY to 1.0 now works fine as far as I can tell.
However, as noted in blog, bobbing vehicles (e.g. Dominus Shadow) still sink. It appears upwards impulses aren't as effective as downward ones. Also, although all my own airships work fine, my copy of the Terra Airship 4.0 still sinks. This might be related to Cubey's tendency to use 0.977 for buoyancy; I've always used 1.0, which always seemed to work fine for sufficiently large vehicles, it just caused smaller vehicles to rise, which is rarely a problem for me. As far as I can tell, llSetBuoyancy works fine, too. (And if someone sees a rogue floating box wandering around Dogfight Atoll on the beta grid, let me know where it is. This should probably be be changed to refer to vehicle lift, to distinguish it from the buoyancy issues in
Whats the status on this. Is this fixed in the ready for release havok4, or is it a behaviour change that will need effected items updated so VEHICLE_BUOYANCY is 1 if its ment to float?
I believe the answer to that would be neither. It's not "Fixed", nor is the current behavior permanent ("Won't Fix") – instead, the status is "In Progress". It's neither fixed nor a permanent behavior change, it's a still unresolved issue that wasn't considered a show-stopper for roll out, but is still considered serious enough that a fix will be made in the upcoming weeks.
However, I think the "In Progress" part may just be the part where up pushes are less effective than down pushes of equal magnitude. To the best of my knowledge, VEHICLE_BUOYANCY now works as it should (1.0 is neutral, less than that sinks). In any case, that's what the release notes a couple weeks back that mentioned this bug implied: the buoyancy part is fixed, the pushing part is still broken. The particular bug here is that the Dominus Shadow gradually sinks when in "hover" mode.
It turns out it also sinks in Havok1, however much slower than in Havok4. I think the main reason for this is that it uses a buoyancy setting that is a little bit less than unity. The bobbing comes from some oscillating push, and the slightly low buoyancy causes it to lose altitude. Meanwhile... there was a bug where some hover vehicles weren't getting all their buoyancy. Basically VEHICLE_FLAG_HOVER_UP_ONLY was being assumed in one spot of the logic and Cubey Terra brought that to our attention. I fixed that just yesterday and now when I check the Dominus it loses altitude very slowly, approximately at the same rate as on Havok1 – I think the Dominus was suffering from the bug that Cubey identified. I'm closing this as fixed. Try it on the 1.20.0 version being deployed to the world today and you should find it fixed.
Andrew Linden made changes - 01/Apr/08 03:18 PM
Oh, that reminds me. VEHICLE_HOVER_UP_ONLY doesn't seem to do what I think the documentation says. I read the documentation to read that VHUO means "push up when you're below the hover altitude, otherwise do what the linear and angular motors say". Instead, I found that pitching back and pumping the linear motor didn't lift me, it acted as if VHUO wasn't set at all. Instead, I have to turn hover on and off in Mehve because when it's on pitching back won't lift me.
Argent, are you sure you aren't also using VEHICLE_FLAG_LIMIT_MOTOR_UP, or whatever it is called?
Just checked, no.
llSetVehicleFloatParam(VEHICLE_HOVER_HEIGHT, 3.0); That's what I turn on when I switch to hover mode. I don't find anything resembling LIMIT_MOTOR_UP anywhere. Now I haven't tried it without the hover switch in a while, I'll check it after the Havok 4 rollout is soup. llSetVehicleType(VEHICLE_TYPE_AIRPLANE);
Oh yeah. That's completely unrelated to this bug, and was in Havok1 as well as Havok4, but yes, VEHICLE_FLAG_HOVER_UP_ONLY doesn't do anything even remotely like what it's supposed to do (if it does anything at all). I can confirm that in spades.
Do we want to start working on bugs that are were in Havok1 and still are present in Havok4? There's a bunch of stuff in vehicles that's just never worked right (like this). OK, that tell me two things.
1. I was worried that I was like totally misunderstanding the documentation. If you read it the same way I'm probably not totally out to lunch. 2. I probably ought to open a new JIRA entry. Done. Ooooh I understand the confusion now.
VEHICLE_FLAG_HOVER_UP_ONLY means that the hover effect won't push you DOWN, only UP. That is, suppose you were a hover craft that stayed a couple meters above the ground. If that vehicle were moving quickly and hit a jump (a small hill in the terrain) then as it leaves the peak of the hill it will either jump higher than its hover height allows, sailing through the air, or it will be pulled down, forced to hover a couple meters above the ground. It turns out that if VEHICLE_FLAG_HOVER_UP_ONLY is TRUE you get the first case – the vehicle can jump because the hover effect will never push DOWN. If it is FALSE, then you get the second case – the hover effect will push down to force the vehicle to hover the specified distance above the ground. So, if you set it FALSE, then the hover effect will probably defeat any linear motor you give it to push it higher than its specified hover height – the expected behavior would be as you describe it. Suppose you wanted an airplane that flies around but lands like a hover craft – you'd set VEHICLE_FLAG_HOVER_UP_ONLY = TRUE, set VEHICLE_PARAM_HOVER_HEIGHT to a few meters, and the rest of the script would be regular airplane stuff. Suppose you wanted to make a dirigible that could float up and down – you's set VEHICLE_FLAG_HOVER_UP_ONLY = FALSE and use the VEHICLE_PARAM_HOVER_HEIGHT to higher and lower as necessary. Ah I see... now that I read
Sue Linden made changes - 13/Nov/08 12:09 PM
Sue Linden made changes - 13/Nov/08 04:41 PM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Critical
buoyancy values aren't the same for moving objects
)
Could you post your buoyancy values? I don't have the vehicle API in front of me right now, but I think there are two or three values that determine how often the vehicle bobs when buoyant. It might help LL to reproduce the bug.