|
|
|
I've definitely fixed the hover case, and I think all the other modes of script energy consumption, but I haven't yet verified them all. Also, the fixes did not get checked in before the most recent freeze-for-testing-the-next-update event, so these fixes will take two updates to get out.
FYI this also happens with llGroundRepel
Andrew, I am also seeing a similar issues with major energy differences between H4/H1. In my case it is a multi-avatar zero gee platform that uses llPushObject. It works great under H1 and falls totally apart in H4. I can add details if this bug report is the right one to use.
I have a zero-F plaftform which creates a uniform vertical field using llPushObject (avies float above it). It consists of multiple linked prims each with a push script. Avies are assigned to a script & prim when they enter the field. This is how I worked around the push energy unevenness problem when one uses a single prim to attempt to float multiple avies. Now in H4, the behavior of the platform is back to the extreme unevenness, as if all the prims were being treated as one unit. Only the first avie gets to float and the rest remain on the ground.
The is also a general probme even with the first avie. The script modulates the push by 9.8m * mass * delta_dist ** 2.9 (roughly) to create a linear field. With H4, the avie barely floats and the field not nearly as uniform as in H1. Also, instead of a smooth floation, in H4 it is quite jerky with long moments of no push whatsoever. If you need a copy of the platform to demonstrate this problem, please contact me. Most of the energy consumption bugs have been fixed. I'm leaving this open to remind me to check on Balpien's zero-F platform described above.
Some bugged content that are not fixable are those that were right at the edge of their "script energy" budget in Havok1. Some of those objects may have less script energy in Havok4, but I'd expect most to actually have slightly more, which causes them to suddenly start working a lot more efficiently (at pushing other objects, for example). The main bit of content that comes to mind is a diving board we were given that pushes too hard in Havok4 – the magic numbers in the LSL script were tweaked to work in Havok1, and were in interaction with delicate details of script energy consumption. Andrew, I'm sending you a copy of the zero g platform along with a notecard.
Andrew, I went back and carefully worked through the two observations I noted. The multi-prims acting as one unit problem is my own bug, I must have changed the link order of the prims in my platform without noticing during my testing. So, this is a non-problem. I apologize if I sent you on a wild code chase.
The 2nd problem can be mitigated. H4 tends to apply more energy per initial unit of push than H1 and then apply much less energy than H1 on subsequent pushes. Replenishment is also more coarse grained than H1. But, for my usage, I have added velocity compensation to the iterated pushes and this gets the avies floating the same between the two physics engines. I doubt many other applications of push are continual, so it is better to get the initial push energy tuned up - diving boards and trampolines ought not slam the avies harder. Since this platform is a new product, and I have the means to have it operate properly in H4, consider my problem resolved. Ok Balpien, I'm closing this for "won't finish" since you have a workaround.
If you read the wiki pseudo code that describes how llPushObject() works you'll notice that there is a bug (that cannot be fixed since it would break a lot of content) that is now a "feature", where the energy cost also scales by the mass fo the pusher (instead of the pushee). You want more "script" energy so you want your pusher to be BIG, however the energy cost also goes up by the pusher's mass, so I suspect there is some sweet spot for the pusher's mass, that is not too big but not too small. http://wiki.secondlife.com/wiki/LlPushObject/Havok4Implementation For best results you want the pusher very close to the pushee. You might try seeding the hover zone with phantom prims that don't collide with the avatar but can exist with centers very close to where you want the avatar's center to be. Good luck. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Energy constraints are wildly different in Havok 4
I've run an llGetEnergy() on a timer under Havok 1 and it reported 100% energy at all times, but I would guess this wouldn't be the case under Havok 4 (although I'm yet to actually verify this).