|
g1rlb0t Troncon
Registered User
Join date: 30 Jan 2008
Posts: 6
|
02-26-2008 16:39
I've heard it's not possible, but do not believe that one bit! So, what are the reasons people believe you cannot make a working vehicle, specifically a car, without using the vehicle parameters?
Why is it "impossible" to create a realistic vehicle using what we are given, minus the llSetVehicle? It doesn't seem impossible...so far the only problem has been friction going through a turn and that can probably be overcome with some thought. Why is everyone so dead against the thought? Just because it's easier to use the vehicle scripts?
|
|
Whispering Hush
™
Join date: 20 Mar 2007
Posts: 277
|
02-26-2008 18:21
Well you get to use all these cool routines if you do. i.e. You get to set the way the vehicle is affected by the physics engine. e.g. VEHICLE_ANGULAR_DEFLECTION_TIMESCALE exponential timescale for the vehicle to achieve full angular deflection. and many more. http://rpgstats.com/wiki/index.php?title=VehiclesSee you at racers 
|
|
Farallon Greyskin
Cranky Seal
Join date: 22 Jan 2006
Posts: 491
|
02-26-2008 18:28
Of course it's not impossible there are non physical vehicles all over the place.
The problem is that in order to get anything CLOSE to smooth movement you need dozens of scripts overlapping the pos/rotate functions. That translates into HUGELY laggy vehicles. Like 10-20 times as laggy as normal ones.
Plus recreating all the functionality of the built in vehicle engine would be a lot of work. Most non physical vehicles are very simple in their expression of movement.
So unless you have some super special reason for making one, using the physical vehicle is much easier and much less laggy, generally smoother and more versitle than creating a non-physical one from scratch.
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
02-26-2008 21:35
Well, you can use physical movement functions too (e.g. llMoveToTarget() and llApplyImpulse()), and probably get a good deal of the smoothness of vehicle functions. But the vehicle functions are pretty optimized for what they do: they don't depend on the mass of the vechicle+avatars; they continue to affect the vehicle between script executions in complex ways; they (mostly) remain relative to the vehicle's reference frame, without the need for complex calculations and hacky workarounds.
Of these, the one about mass is one of the biggest distinctions in my opinion. Though it is an extreme example, you can't make a non-hollow 10m diameter sphere into a flying vehicle with non-vehicle physical movement; it is way too heavy. You can with the vehicle functions (it'll fly like any other vehicle).
The use of non-physical movement for vehicles can be used to circumvent some of the restrictions imposed by the physics engine, of course. You can move through solid objects, you can have a vehicle with more than 31 prims, you can even keep multiple objects synchronized to a degree in a really large build. But it has definite disadvantages too. Generally non-physical movement uses up a TON of script time, and requires complex script systems to get anywhere near smooth. You also can't take advantage of collisions with other objects or the ground, which can often make them very clunky and unreal seeming (driving THROUGH the surface of a raised prim road, for example).
|