Vincent Nacon added a comment - 28/Sep/07 06:39 PM

Vincent Nacon added a comment - 28/Sep/07 06:39 PM It seem that vehicle has different type of friction with the ground. If car's motor offset is closer to center than bottom of the car, it would hung up on the ground and kinda tipping over forward from the front wheels. However, Dominus Shadow seem to work better since it has large cube on the bottom. Seem odd that some vehicle are tilted a bit. Also the drive motor seem to have a delay or so. (script wise lag?)

Gaius Goodliffe added a comment - 29/Sep/07 12:52 AM

Gaius Goodliffe added a comment - 29/Sep/07 12:52 AM I was just testing some vehicles, and I didn't experience any problems with sluggish controls or time dilation, except in Bethel and Sandbox Cordova (both of these sims seem to be experiencing "issues" at the moment). I'd venture a guess that the beta grid was lagging while you were testing and that the sluggish/fps issues were unrelated to Havok4. The 1024m limit is going to be a big bummer for skydiving if it's not fixed. I also observed the buoyancy issues. Not major, but somewhat annoying. Of course, the non-beta grid also has buoyancy issues, but in the opposite direction (airships set for buoyancy 1.0 tend to slowly rise – more noticeably for smaller ones, e.g. the DTA-2011). I haven't measured it, but it felt like I was sinking on the beta grid a bit faster than I tend to rise on the non-beta grid, with the same supposedly neutral buoyancy.

Francis Chung added a comment - 29/Sep/07 08:34 AM

Francis Chung added a comment - 29/Sep/07 08:34 AM @ Vincent The Dominus Shadow only has a large cube on the bottom if you turn on ground shadows AND you don't wear the provided accessories attachment. I try to avoid the "large cube" on the bottom, because it has a tendency to catch prim seams. The large cube on the bottom is only for people who really want a groundshadow, don't want to wear the accessories attachment and don't mind giving up handling ability. @Gaius I have noticed buoyancy issues, but more than that, I think physical object motion is underdamped - eg. If you've got a hovercar (like my dominus shadow) and you're travelling forward, you'll tend to keep travelling forward forever, instead of coming to a stop like in havok 1.

Stylez Gomez added a comment - 29/Sep/07 11:27 AM

Stylez Gomez added a comment - 29/Sep/07 11:27 AM I can relate to things seeming sluggish or underpowered. In the case of my elevators, they either don't have the power to ascend vertically or are too heavy. When physics is enabled they gradually fall to the ground as if lacking the power to counter gravity. If I set the buoyancy to 1.0 it works a little better, but still seems very underpowered. llGetEnergy in all cases reports nearly full energy with buoyancy disabled.

Gaius Goodliffe added a comment - 29/Sep/07 12:14 PM

Gaius Goodliffe added a comment - 29/Sep/07 12:14 PM Another annoying change: I'm getting changed(CHANGED_LINK) messages on every sim crossing. Turns out it's harmless on most of my vehicles, but on a couple it interprets this as a new pilot sitting down and resets all the parameters, so I have to throttle back up, adjust my trim, etc. Just my luck, the two vehicles that reset their throttle to zero when this happens also happen to be my only two non-LTA aircraft, which, in the absence of jet power, display all the aerodynamic properties of a brick with a paper airplane taped to it.

virrginia tombola added a comment - 29/Sep/07 08:01 PM

virrginia tombola added a comment - 29/Sep/07 08:01 PM I tested some vehicles on the grid this morning (roughly 10AM SLT) and experienced the same problems. Sluggish controls, low top speed. One vehicle uses a variable buoyancy--with Vehicle Buoyancy set to -1, it plummeted, and no forward thrust would work at all once it touched down (before, it would sink, but hardly drop out of the sky). Another vehicle used Cubey's DIY flight script, and I found the roll rates and forward thrust considerable diminished. Oddly, the pitch rate was about the same.

Heather Goodliffe added a comment - 29/Sep/07 09:19 PM

Heather Goodliffe added a comment - 29/Sep/07 09:19 PM I've seen the bouyancy issue, as well as the vehicles "going offworld" while you're riding them into the edge of the sim. Personally, I'd like to see vehicles simply stop moving in the direction of the edge, rather than a violent bounce or being returned. Independently, I have some ski and snowboard vehicles in wide use, that should work on both prim objects as ground and linden land as ground. These no longer seem to work when they're not on linden land under Havok 4.

Huns Valen added a comment - 30/Sep/07 02:22 PM

Huns Valen added a comment - 30/Sep/07 02:22 PM I tried it yesterday and today and found low time dilation numbers (less than .5 usually) to be frequent. Obviously this makes everything slow.

Jon Marlin added a comment - 04/Oct/07 05:27 AM

Jon Marlin added a comment - 04/Oct/07 05:27 AM None of my mouselook vehicles work - the vehicle part works, and I can move them back/forwards, but mouselook doesn't seem to steer anymore... I also tried another mouselook vehicle I have that someone else made, same thing.

mathieu basiat added a comment - 06/Oct/07 07:54 AM

mathieu basiat added a comment - 06/Oct/07 07:54 AM VEHICLE_VERTICAL_ATTRACTION_EFFICIENCY seems to be a lot less efficient, causing a lot more bobbing in water craft VEHICLE_LINEAR_MOTOR_DECAY_TIMESCALE or VEHICLE_LINEAR_FRICTION_TIMESCALE are wacked, causing a seeming lack of friction compared to main grid llApplyRotationalImpulse seems a lot less forceful

mathieu basiat added a comment - 06/Oct/07 08:09 AM

mathieu basiat added a comment - 06/Oct/07 08:09 AM llGroundRepel and llSetBuoyancy are not working as expected... and object with: llSetBuoyancy(1.0); llGroundRepel(0.1, TRUE, 1.0); should not be sinking in the water

Gigs Taggart added a comment - 06/Oct/07 05:38 PM

Gigs Taggart added a comment - 06/Oct/07 05:38 PM The bounding box troubles are, I suspect, because vehicles are being simulated as convex hulls. This should improve performance and allow for more prims in physical vehicles.

Al Supercharge added a comment - 07/Oct/07 05:44 PM

Al Supercharge added a comment - 07/Oct/07 05:44 PM A simple vehicle script giving precision control of flying vehicle in 1.18.3 rolls uncontrollably in Havok4. vector linear = <0, 0, 0> ; // declare the value for the linear motor vector angular = <0, 0, 0> ; // declare the value for the angular motor default { state_entry() { // what the pie menu says if you want to get in llSetSitText("Fly") ; llStopSound(); // hearing collision sounds when on the ground would suck, so we mute them. llCollisionSound("", 0.0) ; // where the AV sits (this assumes that the root prim is the drivers seat) llSitTarget(<0.3, 0.0, 0.3>, ZERO_ROTATION) ; // readjust the camera so the driver can see llSetCameraEyeOffset(<-10.0, 0.0, 2.0> ) ; llSetCameraAtOffset(<3.0, 0.0, 1.0> ) ; llSetVehicleType(VEHICLE_TYPE_AIRPLANE) ; llSetVehicleVectorParam(VEHICLE_LINEAR_FRICTION_TIMESCALE, <100.0, 100.0, 100.0>) ; llSetVehicleFloatParam(VEHICLE_ANGULAR_FRICTION_TIMESCALE, 100.0) ; //linear motor: as motor implies the push that makes your craft go // the linear velocity that the craft attempt to achieve. max = 40 llSetVehicleVectorParam(VEHICLE_LINEAR_MOTOR_DIRECTION, <100.0, 100.0, 100.0>) ; // the time it takes to reach top speed min = 0.06 llSetVehicleFloatParam(VEHICLE_LINEAR_MOTOR_TIMESCALE, 1.0) ; // time during which the motor's effectiveness exponentially decays max = 120 llSetVehicleFloatParam(VEHICLE_LINEAR_MOTOR_DECAY_TIMESCALE, 2.0) ; // angular motor: motor that twists the path of the craft // angular velocity (radians/sec) that the vehicle will try to rotate. // max = 4*PI (2 revolutions/sec) llSetVehicleVectorParam(VEHICLE_ANGULAR_MOTOR_DIRECTION, <100.0, 100.0, 100.0>) ; // the time it takes to be spinning at full speed. min = 0.06 llSetVehicleFloatParam(VEHICLE_ANGULAR_MOTOR_TIMESCALE, 1.0) ; // time during which the spin exponentially decays max = 120 llSetVehicleFloatParam(VEHICLE_ANGULAR_MOTOR_DECAY_TIMESCALE, 2) ; // time for craft to stabilize at hover height // **values greater than 300 disable hover** llSetVehicleFloatParam(VEHICLE_HOVER_TIMESCALE, 5.0) ; // height to hover at. what craft will use as the base height // to base this from depends on the flags set // VEHICLE_FLAG_HOVER_WATER_ONLY //| VEHICLE_FLAG_HOVER_TERRAIN_ONLY //| VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT // we will set these (or not) later llSetVehicleFloatParam(VEHICLE_HOVER_HEIGHT, 0.0) ; // min = 0.0 max = 1.0 // 0.0 = bouncey 1.0 = smooth // how tightly the craft adheres to the hover height // timescale will be the oscillation period of the bounce. llSetVehicleFloatParam(VEHICLE_HOVER_EFFICIENCY, 1.0) ; // 0 = normal phsycs apply // 1 = anti-gravity, the force of gravity will not apply // -1 = adds extra gravity to craft llSetVehicleFloatParam(VEHICLE_BUOYANCY, 0.98) ; // linear deflection: any push from any angle will attempt to be // redirected along the axis that the craft wishes to go (forward) // i.e. a car will want to go in the direction its wheels are facing // time till craft moves in direction of outside push llSetVehicleFloatParam(VEHICLE_LINEAR_DEFLECTION_TIMESCALE, 1.0) ; // no deflection = (0.0) max deflection = 1.0 llSetVehicleFloatParam(VEHICLE_LINEAR_DEFLECTION_EFFICIENCY, 0.5) ; // angular deflection: an outside push will attempt to reorient craft // to match direction of push. // i.e. a collision from the side will turn the craft to point // the same direction as the impact was going. // time till craft twists to match direction of outside push llSetVehicleFloatParam(VEHICLE_ANGULAR_DEFLECTION_TIMESCALE, 100.0) ; // no deflection = (0.0) max deflection = 1.0 llSetVehicleFloatParam(VEHICLE_ANGULAR_DEFLECTION_EFFICIENCY, 0.25) ; // vertical attraction: keeps the top side up // i.e. the x axis of the craft is locked to the world x axis // set above 300 to disable llSetVehicleFloatParam(VEHICLE_VERTICAL_ATTRACTION_TIMESCALE, 1.0) ; // min = 0.0 = wobbly max = 1.0 = steady llSetVehicleFloatParam(VEHICLE_VERTICAL_ATTRACTION_EFFICIENCY, 0.75) ; // * Note that by default the vertical attractor will prevent the craft // * from diving and climbing. So, if you wanted to make a airplane you // * would probably want to set the VEHICLE_FLAG_LIMIT_ROLL_ONLY flag // * to allow pitch (nose up/down) // amount of lean during turns // min = -1 lean out of turns max = 1 lean into turns llSetVehicleFloatParam(VEHICLE_BANKING_EFFICIENCY, 1.0) ; // min = 0 = static max = 1 = dynamic // i have no clear idea what this does, in some way it effects // the craft banking while stopped and moving llSetVehicleFloatParam(VEHICLE_BANKING_MIX, 1.0) ; // time to reach the full tilt of the banking llSetVehicleFloatParam(VEHICLE_BANKING_TIMESCALE, 360.0) ; // 2 possible uses. // if your root prim is *not* <0,0,0> you can use this to orient your // craft correctly // or if you need to change the orentation of your craft. // i.e. to tilt up on end for a take off/landing mode. // typically you should not need to set this to anything llSetVehicleRotationParam(VEHICLE_REFERENCE_FRAME, <0.0, 0.0, 0.0, 1.0>) ; // flags to set special attributes or behaiviors to the craft // VEHICLE_FLAG_NO_DEFLECTION_UP Prevents linear deflection parallel to the // world-z axis. or in plain english linear deflection will not push up // VEHICLE_FLAG_LIMIT_ROLL_ONLY Removes vertical attraction for changes in // vehicle pitch allows craft that use vertical attraction to nose up/down // VEHICLE_FLAG_HOVER_WATER_ONLY Hover only pays attention to water level // hover keeps craft at a fixed height above the water height (ignoring terrain height) // VEHICLE_FLAG_HOVER_TERRAIN_ONLY Hover only pays attention to terrain height // hover keeps craft at a fixed height above the terrain height (ignoring water height) // VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT Hover only pays attention to global height // hover at global altitude ignoring terrain and water levels // VEHICLE_FLAG_HOVER_UP_ONLY Hover only pushes up // hover will not push down, hover height will be the lowest the craft can go // VEHICLE_FLAG_LIMIT_MOTOR_UP Prevents ground vehicles from motoring into the sky // keeps ground craft from flying up or steering midair // // VEHICLE_FLAG_MOUSELOOK_STEER Makes vehicle try to turn toward mouselook direction // VEHICLE_FLAG_MOUSELOOK_BANK Makes vehicle try to turn toward mouselook // direction assuming banking is enabled // VEHICLE_FLAG_CAMERA_DECOUPLED Causes the camera look-at axis to NOT // move when the vehicle rotates // flags we are not applying to this craft. // may be unneccessary unless craft will change flags when entering different modes // but seems like a good idea o have them anyway. if the craft will change modes // i.e. enter a staet to be a car not an airplane then you would remove the airplane // type flags and add car type ones. llRemoveVehicleFlags(VEHICLE_FLAG_NO_DEFLECTION_UP | VEHICLE_FLAG_HOVER_WATER_ONLY | VEHICLE_FLAG_HOVER_TERRAIN_ONLY | VEHICLE_FLAG_LIMIT_MOTOR_UP | VEHICLE_FLAG_LIMIT_ROLL_ONLY |VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT | VEHICLE_FLAG_HOVER_UP_ONLY) ; // flags we are applying to this craft //llSetVehicleFlags(VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT // | VEHICLE_FLAG_HOVER_UP_ONLY) ; // keeps craft from moving on rez before driver/pilot is seated llSetStatus(STATUS_PHYSICS, FALSE) ; } // now that the charistics of the craft's handeling are set we need to // add the ability to controll the craft on_rez(integer param) { llResetScript(); } // checks to make sure that the craft owner is the the driver/pilot // by seeing if the links have changed. an AV sitting on something changes // the link status and we are detecting that here. changed(integer change) { if (change & CHANGED_LINK) { // get the key of the AV sitting down key agent = llAvatarOnSitTarget() ; if (agent) { if (agent != llGetOwner()) { // only the owner can use this craft. if you are not the owner // the craft will say... llSay(0, "Off with ye, lest me owner smite thee..") ; // then stand you up llUnSit(agent) ; // and give you a bit of a shove out of the craft llPushObject(agent, <0,0,10>, ZERO_VECTOR, FALSE) ; } else { // if you are the owner you are permitted to sit. // and we reset the linear motor to keep the craft at a stop. linear = <0, 0, 0> ; llSetVehicleVectorParam(VEHICLE_LINEAR_MOTOR_DIRECTION, linear) ; llSetVehicleVectorParam(VEHICLE_ANGULAR_MOTOR_DIRECTION, linear) ; llSetVehicleFloatParam(VEHICLE_LINEAR_FRICTION_TIMESCALE, 100.0) ; llSetVehicleFloatParam(VEHICLE_ANGULAR_FRICTION_TIMESCALE, 100.0) ; // gets permission to make the driver/pilot use the sit anim and // take over the controls llRequestPermissions(agent, PERMISSION_TRIGGER_ANIMATION | PERMISSION_TAKE_CONTROLS) ; } } else { // if the drive/pilot stands up we want to stop the craft so // it dosent wander off. linear = <0, 0, 0> ; llSetVehicleVectorParam(VEHICLE_LINEAR_MOTOR_DIRECTION, linear) ; llSetVehicleVectorParam(VEHICLE_ANGULAR_MOTOR_DIRECTION, linear) ; // angular isnt linear, but its one less vector we need to define // here we use friction to stop the vehicle very quickly // rather than llSetStatus(STATUS_PHYSICS, FALSE) ; which // will work but be far more abrupt. llSetVehicleFloatParam(VEHICLE_LINEAR_FRICTION_TIMESCALE, 1.0) ; llSetVehicleFloatParam(VEHICLE_ANGULAR_FRICTION_TIMESCALE, 1.0) ; // driver/pilot is no longer at the controls, so we stop acting on them llReleaseControls() ; // and we dont need them sitting anymore, as they are standing up llStopAnimation("sit") ; llStopSound(); // and we make the craft non-phsycal to keep it from being moved away. // this also cuts down the load on the sim if you wish to park somewhere. llSetStatus(STATUS_PHYSICS, FALSE) ; } } } // script grants self permissions to act on control inputs run_time_permissions(integer permissions) { if (permissions & PERMISSION_TAKE_CONTROLS) { // these are all the possible controls to act on llTakeControls( CONTROL_FWD | CONTROL_BACK | CONTROL_LEFT | CONTROL_RIGHT | CONTROL_ROT_LEFT | CONTROL_ROT_RIGHT | CONTROL_UP | CONTROL_DOWN | CONTROL_LBUTTON | CONTROL_ML_LBUTTON, TRUE, FALSE) ; // what are true and false doing here? // the first one is refering to accepting controlls, // you want this on in most cases. // the second value is pass_on. what that means is that // it is asking if the commands are sent to the AV also // or just the vehicle. if CONTROL_ML_LBUTTON is used // it will make a mouselook button appere on the bottom // of the screen, but only if the second true/false is // set to false. // turn physics on so we can move llSetStatus(STATUS_PHYSICS, TRUE) ; } } // if each control is pressed, what the craft's responce is. control(key name, integer level, integer edge) { // there are 4 different states of each controll button // it can be either up or pressed down // or being pressed or realesed // yes there is a difference. // i.e. if the up arrow means go forward and held down means go // then as long as the key is held down it will go and when it is realesed // then that command will stop. // if pressed means go then if you tap the up arrow it will go untill // there is another command to tell it not to. // or in other words edge fwd can mean go // not edge fwd can mean stop // then you will only go fwd when the button is down // // sorta, its confusing // // level means the button is down // !level (not level) means the button is up // edge means the button is being pressed or realesed // !edge (not edge) means the button has not been touched // so the act of perssing and then releasing the button would be // edge & level, !edge & level, edge & !level, !edge & !level // // that may be an over simplification, and may be misleading. // it should be noted that i didn't put any speed limits in the script in // the interest of clarity and keeping things simple to follow. // that gives the craft a max speed of about 40 m/s. // 40 m/s is usually too fast for an enjoyable ride, but fast can be lots of fun. // when the up arrow or w is pressed if (level & CONTROL_FWD) { // if we are moving backwards stop if (linear.x < 0) { linear.x = 0 ; } // otherwise go forward else {linear.x += 14.0 ; } } // when the up arrow or w is released else if ((edge & ~level & CONTROL_FWD)) { linear.x = 0 ; } // when the down arrow or s is pressed if (level & CONTROL_BACK) { // if we are moving forward stop if (linear.x > 0) { linear.x = 0 ; } } // otherwise go backwards else { linear.x -= 14.0 ; } } // when the down arrow or s is released else if ((edge & ~level & CONTROL_BACK)) { linear.x = 0 ; } // when shift and the left arrow or shift and a is pressed if (level & CONTROL_LEFT) // strafe left { linear.y += 8.0 ; } // when shift and the left arrow or shift and a is released else if (!(level & CONTROL_LEFT)) // stop strafeing left { linear.y = 0 ; } // when shift and the right arrow or shift and d is pressed if (level & CONTROL_RIGHT) // strafe right { linear.y -= 8.0 ; } // when shift and the right arrow or shift and d is released else if (!(level & CONTROL_RIGHT)) // stop strafe right { linear.y = 0 ; } } // when the left arrow or a is pressed if (level & CONTROL_ROT_LEFT) // turn left // tilt slightly { angular.z += (PI / 180) * 55.0 ; // turn angular.x -= PI * 4 ; } // when the left arrow or a is released else if ((edge & ~level & CONTROL_ROT_LEFT)) // stop turning // level off { angular.z = 0 ; // stop turning angular.x = 0 ; } // when the right arrow or d is pressed if (level & CONTROL_ROT_RIGHT) // turn right // tilt slightly { angular.z -= (PI / 180) * 55.0 ; // turn angular.x += PI * 4 ; } // when the right arrow or d is released else if ((edge & ~level & CONTROL_ROT_RIGHT)) // stop turning // level off { angular.z = 0 ; // stop turning angular.x = 0 ; } } // when page up or e is pressed if (level & CONTROL_UP) // move up { linear.z += 48.0 ; } // when page up or e is released else if (!(level & CONTROL_UP)) // stop moving up { linear.z = 0 ; } // when page down or c is pressed if (level & CONTROL_DOWN) // move down { linear.z -= 24.0 ; } // when page down or c is released else if ((edge & ~level & CONTROL_DOWN)) // stop moveing down { linear.z = 0 ; } } // the following commented out for lack of a good use in my basic example // however these are valid controlls and usefull in many kids of craft. // when the left mouse button is pressed while in mouselook //if ((level & CONTROL_ML_LBUTTON) && (edge & CONTROL_ML_LBUTTON)) //llOwnerSay ("CONTROL_ML_LBUTTON - pressed"); // when the left mouse button is released while in mouselook //if (!(level & CONTROL_ML_LBUTTON) && (edge & CONTROL_ML_LBUTTON)) //llOwnerSay ("CONTROL_ML_LBUTTON - released"); // when the left mouse button is pressed //if ((level & CONTROL_LBUTTON) && (edge & CONTROL_LBUTTON)) //llOwnerSay ("CONTROL_LBUTTON - pressed"); // when the left mouse button is released //if (!(level & CONTROL_LBUTTON) && (edge & CONTROL_LBUTTON)) //llOwnerSay ("CONTROL_LBUTTON - released"); // allows us to alter the speed based on the pilot/driver's input llSetVehicleVectorParam(VEHICLE_LINEAR_MOTOR_DIRECTION, linear); // lets us turn llSetVehicleVectorParam(VEHICLE_ANGULAR_MOTOR_DIRECTION, angular); } }

Argent Stonecutter added a comment - 10/Oct/07 08:24 PM

Argent Stonecutter added a comment - 10/Oct/07 08:24 PM In the first release my vehicles simply lost all forward momentum and had to be restarted when I crossed sim boundaries. Now they seem to be getting all the scripts reset.

HD Pomeray added a comment - 11/Oct/07 06:42 AM

HD Pomeray added a comment - 11/Oct/07 06:42 AM I have tested some of my Motorcycles in H4 along with a few others and found that the biggest problem I am experiencing is that turning is much less efficient. They lead over fine but seem to skid forward with only a slight amount of turning. Other than that they seem to get stuck on the ground now and then.

HD Pomeray added a comment - 11/Oct/07 06:47 AM

HD Pomeray added a comment - 11/Oct/07 06:47 AM errr ... "lean"

ItsNaughtKnotty Cannned added a comment - 11/Oct/07 09:21 AM

ItsNaughtKnotty Cannned added a comment - 11/Oct/07 09:21 AM I'm using some pretty basic motorcycle scripts and I'm finding that they go straight even when trying to turn. If you hold down the forward key and try turning left or right, the vehicle does the usual bank, but it still goes straight. I have to stop going forward in order to turn.

Francis Chung added a comment - 11/Oct/07 03:37 PM

Francis Chung added a comment - 11/Oct/07 03:37 PM @Gigs "The bounding box troubles are, I suspect, because vehicles are being simulated as convex hulls. This should improve performance and allow for more prims in physical vehicles." 1) I believe vehicles only become simulated as convex hulls when the sim is under high load. I think this discussion deals with sims in a "healthy" state. (My notes from SL views here: http://forums.secondlife.com/showthread.php?t=214174) 2) The observed behaviour is that vehicles are colliding in strange ways, being caught by edges that don't exist, and rebounding in strange ways after ground collision. This implies that the physics simulation is incorrect as a result of a bug, rather than being collided as a simplified convex hull.

Blake Sachs added a comment - 14/Oct/07 08:28 PM

Blake Sachs added a comment - 14/Oct/07 08:28 PM It seems that the problems are worse for sculpties. One of my cars has sculpty wheels and experiences the afore mentioned high friction/ and bad steering response at low speeds on both terrain and prim surfaces. Replacing the wheels with conventional cylinders or changing the prim type from sculpted to something else (I tried cylinder and box) resulted in great improvements, though turning still feels a bit strange. Changing back to sculpted brought back the bad behaviour. There also seem to be subtle changes in vehicle mass and friction. In Havok 1 the car tends to roll over when turning sharply at sufficient speeds, this doesn't happen in the beta anymore.

Andrew Linden added a comment - 26/Oct/07 03:28 PM

Andrew Linden added a comment - 26/Oct/07 03:28 PM I just fixed a problem where the center of mass was incorrectly placed at the center of the root prim. This was a bug that was introduced a couple of weeks ago when a LL developer made an optimization pass and started bypassing some recomputes of the object mass that sometimes bypassed legitimate instances. I suspect this fixes a lot of the problems people have been seeing with vehicles. Not only is this fixed in the internal codebase, but I deployed it to a limited set of regions in the Havok4 preview for the pre-halloween weekend: "Bug Island" and "Da Boom". I'd appreciate it if someone could make some preliminary testing to see if any of these problems are fixed, thanks.

Vincent Nacon added a comment - 01/Nov/07 11:26 PM

Vincent Nacon added a comment - 01/Nov/07 11:26 PM Set linear and angular friction are ignored in vehicle param on ground and prim surface, btw. :/

Cubey Terra added a comment - 08/Dec/07 04:24 AM

Cubey Terra added a comment - 08/Dec/07 04:24 AM I don't even know how to report this one. I can't tell what's causing the problem, so I can't really enter a new bug report about it. If I fly my new helicopter near the ground, it suddenly tries to flip itself over on any control input. When it's not near the ground, it flies mostly normally (sluggish, but upright at least). I'll make my helicopter available in Abbotts (beta grid) if anyone wants to see this bug in action.

Creem Pye added a comment - 08/Dec/07 05:43 AM

Creem Pye added a comment - 08/Dec/07 05:43 AM I'm also experiencing the extreme ground friction with taxiing airplanes. In my case, the airplane bodies are "reclined" approximately 15 degrees during taxi, although the vehicle reference frame is set up to invert this rotation (so that the vehicle's "forward" direction is parallel to the horizon). In Havok1, the airplane's angular deflection parameters are set so that the airplane's body gracefully lifts its rear wheel while approaching takeoff speed. In Havok4 however, the airplane's rear wheel is lifted even at extremely low speeds (like 0.5m/s), and the friction between the wheels and the ground is so great that the airplane is unable to reach takeoff speed. The wheels are normally sculpts, but changing them to another prim type (sphere, cylinder, etc) does not appear to affect friction. Also, changing the wheels' "material type" to a low-friction material like glass doesn't fix the problem. Right now the only way to take off is to drive the airplane off the side of a cliff... Also, have you other aircraft creators (Cubey, Gaius, etc) noticed any buoyancy quirks when crossing between H4 and H1 sims? About half the time I cross from a Havok4 sim into a Havok1 sim, my vehicle's buoyancy skyrockets, such that it moves directly upwards. When this happens, I'm unable to lower the buoyancy with script calls, and the vehicle is essentially "broken".

Creem Pye added a comment - 08/Dec/07 05:55 AM

Creem Pye added a comment - 08/Dec/07 05:55 AM Cubey, I just tried your CTH-100, and experienced the stability problem. The helicopter didn't fully flip over, but it would bang its tail rotor on the ground during initial takeoff and whenever I tried to land it. The problem only seemed to occur whenever the ground rails were within a few cm of the ground. My first guess was that you were using llGroundRepel(), and that this function gets unstable when the helicopter is very close to the ground, but the helicopter reacts the same way when I start it on an elevated prim (although the helicopter is OK if it's suspended in the air at startup). What initial buoyancy are you giving the helicopter when physics are enabled?

Cubey Terra added a comment - 08/Dec/07 06:02 AM

Cubey Terra added a comment - 08/Dec/07 06:02 AM Creem Pye, Nope, I'm not using llGroundRepel() or doing any calculations based on ground height. The helicopter should fly the same 1m above the ground as it does 100m above the ground. Vehicle buoyancy is set to 0.98. You can actually see the effect better if you try to hover over flat ground. Fly it down to within a couple of meters, then try to move vertically or forward/back. It only seems to happen when a linear motor is applied. (Also: For testing purposes, it's best to turn off the rotor damage effects using the helicopter's menu.)

Creem Pye added a comment - 08/Dec/07 06:18 AM

Creem Pye added a comment - 08/Dec/07 06:18 AM Regarding the buoyancy isssue when crossing fromHavok4 to Havok1 sims, it now seems possible that the Havok1 sims in ADITI are simply broken. Just now I tried Cubey's CTH-100 in both "Fame Havok1" and "Fortuna Havok1" sims, and the helicopter is immediately repelled upwards at a speed of ~30m/s. Perhaps these sims have an incredibly high "buoyancy mulitplier" that somehow triggers if the vehicle had been in a Havok4 sim sometime in the past. Cubey, did you fly the CTH-100 for sale at Abbotts in a Havok4 sim prior to adding it to the vendor? If so, then I think my airplanes and your helicopter are both being "corrupted" by Havok4, in that the buoyancy becomes irrecoverably high.

Drew Dwi added a comment - 17/Jan/08 06:53 PM

Drew Dwi added a comment - 17/Jan/08 06:53 PM DEV-7968: Mouselook steering for vehicles is now working needs to be re-opened, mouse look steering is almost completely uncontrollable and functions nothing like havok1 I guess this is better than nothing though like before though

Les White added a comment - 01/Feb/08 02:18 PM

Les White added a comment - 01/Feb/08 02:18 PM Les's vehicle issues , havok4, class4 sim Misp on main grid: 1. Vehicle banking functions are toast. They lean, but any dynamic interaction with lean to turn as per LSL vehicle script functions is not happening. 2. Prim seams...this is really bad. A ground vehicle will catch on perfectly level prim seams and sometimes stop outright or bounce straight up in the air. 10 times as bad as havok1. A show stopper IMO. 3. Hover vehicles are not updating viewers correctly. If they are stopped (or moving at consistent rate of speed and direction) they may sink off world until the object does an update with some other method. Doing something silly like forcing object updates with continuous llTargetOmega(<0,0,0>,0,0) calls seems to keep it floating. This is nasty and it's been around forever, though with H4 it is really BAD. 4. Hover vehicles (global hover) are spongy with their set hover height even when set to critical dampen to Z 5. Hover vehicles get caught on prim seams they are not even touching! (more testing required... could be releated to issue 4 above) 6. Set a small sphere (0.25m) to hover vehicle. They usually merge into each other slightly and continue to trigger physics with each other non-stop doing a little jerky dance forever. They also do not pass kinetic energy very well. 7. Normal ground vehicles do not get up to speed. They get to full speed when they leave the ground from a ramp, hill or such. Then slow down on the ground again. 8. Avatar interpolation with vehicles is handled with a sometimes violent ejection of the av. Sometimes hundreds of meters into the air. This interpolation happens when an avatar un-sits from the object.

Creem Pye added a comment - 01/Feb/08 02:28 PM - edited

Creem Pye added a comment - 01/Feb/08 02:28 PM - edited I'm still experiencing the same difficulties with vehicles, specifically (7) in Les' remarks, with taxiing airplanes. Taxiing along the ground is slower than expected, preventing aircraft from reaching takeoff speed unless one "drives" off a cliff or steep hillside. It seems that a LINEAR_MOTOR_TIMESCALE of 4.0 is weaker in H4 than H1; changing this timescale to 2.0 or less resolves that problem. Also, the vertical attractor still seems to be weakened by collisions from the ground or objects. So far, playing with the vertical attractor constants and deflection constants doesn't seem to resolve this problem. UPDATE: As of v1.19.0.79349, the problems listed above have both been fixed. There are still some minor differences between H1 and H4, but the behavior is acceptably close now.

Andrew Linden added a comment - 14/Feb/08 10:17 AM

Andrew Linden added a comment - 14/Feb/08 10:17 AM Mouselook steering is fixed. There was a bug where some small or thin prims would be given a larger then normal collision shape. This was breaking the Starling ultralight and probably others --> now fixed. There was bug where planes that were taxiing along the ground were getting extra ground vehicle magic that would attempt to keep them aligned with the collision plane. This has been disabled for vehicles that are not explicitly using "ground effects" such as VEHICLE_FLAG_LIMIT_MOTOR_UP or VEHICLE_FLAG_NO_DEFLECTION_UP. Also, the special magic is disabled if the vehicle is using the "hover" effect. If any of the problems mentioned in these comments are still happening DO NOT REOPEN this bug. Instead, OPEN A NEW BUG with instructions on how to reproduce the problem. If a particular vehicle is involved please drop a copy on my profile, since I'll be needing it to troubleshoot.

Andrew Linden added a comment - 14/Feb/08 02:22 PM

Andrew Linden added a comment - 14/Feb/08 02:22 PM More details... The "ground vehicle magic" is some ray-tracing code that computes some angular and linear impulses on the vehicle in an effort to keep it aligned with the surface it is colliding with whether that is the terrain, or a road, or some other prim surface. The angular impulses are to compensate for the fact that the collision/friction model of Havok4 is subtly different... the vehicle tends to snag its nose and tip into the surface. The linear impulses are to reduce the vehicle from penetrating too deeply into the terrain or road... since otherwise the penetration resolver code (built into the Havok4 engine by default) will engage and tend to stop all forward motion of the vehicle – pushing it straight out. The ground vehicle magic makes some assumptions that the ground is "down". So, making a vertical racetrack and trying to race up won't work very well, however that won't work well with "ground effect" vehicles anyway. As far as I know the ground vehicle magic properly handles non-identity rotations for the VEHICLE_REFERENCE_FRAME feature.

Tiarnalalon Sismondi added a comment - 28/Feb/08 09:49 PM

Tiarnalalon Sismondi added a comment - 28/Feb/08 09:49 PM I will probably open another JIRA after testing this, but there seems to be some bounding box issues with more complex prims being used as the collider on ground vehicles. More specifically I've tested Torii and Tubes used as tires, versus the traditional cylinder or the 'box' bottom like on the Dominus, and the car will appear to drive like it is in sand. Turning is horrible, and the forward momentum will come to a complete halt at random times. I tested using an RC version of a car script so my AV hitbox would not factor into the equation, and simply changing the 'tires' to cylinders...even if they were not rotated properly with the ground, caused incredible increase in response when compared to using tubes instead. Using Torii appears to be even worse. The problem can be temporarily fixed by forcing the vehicle to ride on a box below the tires for now it seems, or by changing the tires to cylinders. All vehicles I've tried that use more complex prims for the tires have this issue.