[Opensim-dev] Questions about Vehicle scripting calls

Mon Jun 11 15:55:14 UTC 2012

llKeyframedMotion is quite usefull. On Avination i am currently using it to
create a roller-coaster though it takes forever to generate the keyframe
map if your doing anything requiring high detail of motion (I.E. rotations
and curves) . i still haven't got all of the key frame points positioned on
the coaster, but once that is done creating the strided list of frame data
is simple. It actually inspired me to write an article on the subject on a
possible veiwer improvment to make this kind of work easier. The article is
at
http://blog.slackdog.com/article.php?story=Yoshis_ideas_on_llSetKeyframeMotionif
you wanna read it.

On Mon, Jun 11, 2012 at 7:36 AM, R.Gunther <rigun at rigutech.nl> wrote:

> i looked at the wiki and it looks very intressting. i really need to test
> that command in uhmm sl.
> It sounds a very p[romesing command for opensim. and solve some headaces.
> like cant us smooth movement or be stuck with but phyics and high timeings.
>
>
>
>
> On 2012-06-11 04:18, Mike Higgins wrote:
>
>>    llKeyframedMotion is key (pun intended). I'd be willing to bet that
>> after discounting cars and airplanes and such, 99% of the remaining
>> physical objects in SL are only physical to try and get smooth liner
>> motion. I assume that llKeyframedMotion is easier on the SIM than physical
>> objects and vehicles. And a lot of the vehicles that use the physical
>> vehicle API could probably be done as non-physical objects with
>> llKeyframedMotion. I encourage you to donate this to OpenSim soon Melanie,
>> so people will get used to using it and save us from using physics.
>>
>> On 6/7/12 5:52 AM, Melanie wrote:
>>
>>> Hi,
>>>
>>> we use a module that is been developed for us as custom work. It
>>> allows running unmodified SL vehicle scripts - well, mostly. We also
>>> have llSetKeyframedMotion() for things that don't really need to be
>>> physical. The latter will be donated to OpenSim at some point.
>>>
>>> Melanie
>>>
>>> On 06/06/2012 19:41, Bengt Falke wrote:
>>>
>>>> Does anybody know what kind of physics Avination use? Physics works
>>>> better there if I remember correctly?
>>>> Void Pipe
>>>>
>>>> 6 jun 2012 kl. 19:10 skrev James Hughes:
>>>>
>>>>  I have been experimenting with trains in SL and would like to make a
>>>>> physical one that works in OpenSim. Hopefully these cases aren't some
>>>>> limitation of the physics engines and can have a proper fix.
>>>>>
>>>>> -BlueWall
>>>>>
>>>>> On 06/05/2012 07:46 PM, Mike Higgins wrote:
>>>>>
>>>>>> I was talking to Justin Clark-Casey at the OpenSim developers meeting
>>>>>> this morning, and he suggested that the mailing lists would be the
>>>>>> easiest way to have a conversation about vehicle physics on OpenSim.
>>>>>> Justin you there? Is this where you meant? Anyone else want to talk
>>>>>> about vehicle scripting in OpenSim?
>>>>>>
>>>>>> I am in the process of testing the OpenSim vehicle scripting calls and
>>>>>> trying to find out what works and what can be worked around. I am
>>>>>> submitting mantis reports when I think I see a true bug, issue numbers
>>>>>> 0006039 <http://opensimulator.org/**mantis/view.php?id=6039<http://opensimulator.org/mantis/view.php?id=6039>>
>>>>>> and 0006040
>>>>>> <http://opensimulator.org/**mantis/view.php?id=6040<http://opensimulator.org/mantis/view.php?id=6040>>
>>>>>> for starters. Instead
>>>>>> of submitting 1000 line vehicle scripts that do not work, I am writing
>>>>>> small 10-line scripts that demonstrate a particular problem.
>>>>>>
>>>>>> Issue 0006040 <http://opensimulator.org/**mantis/view.php?id=6040<http://opensimulator.org/mantis/view.php?id=6040>>
>>>>>> is
>>>>>> particularly interesting because if my hypothesis is correct, the
>>>>>> linear
>>>>>> motor direction is being actively projected onto the global XY plane.
>>>>>> I
>>>>>> cannot get an airplane to glide up, or a balloon to rise using the
>>>>>> linear motor. (Hover height works with balloons, but not the linear
>>>>>> motor even with hover height disabled). The interesting thing about
>>>>>> this
>>>>>> is that my hypothesis suggests that there is extra code doing this
>>>>>> projection onto the XY plane. I checked the vehicle flags and there
>>>>>> isn't one that should force this extra projection into the
>>>>>> calculations.
>>>>>> Vehicle type balloon is supposed to have all the flags removed, but
>>>>>> just
>>>>>> to be sure I used the remove call to clear them all. The linear motor
>>>>>> still cannot go up. Can someone familiar with the code look at the
>>>>>> linear motor and tell me why this is happening and if there is a way
>>>>>> to
>>>>>> disable it? (I tried turning flags like VEHICLE_FLAG_NO_DEFLECTION_UP
>>>>>> on
>>>>>> to see if this flag was inverted, and if it applied to the motor
>>>>>> instead
>>>>>> of deflection, but no luck).
>>>>>>
>>>>>> The fun thing is that I can write one kind of vehicle that works well
>>>>>> --
>>>>>> assuming this bug is there. I built a vehicle that has the linear
>>>>>> motor
>>>>>> set to <0,0,20>, pointing straight up. When the vehicle is perfectly
>>>>>> horizontal, the projection of this motor onto XY is <0,0,0> and the
>>>>>> vehicle does nothing. But then when you tilt the vehicle in any
>>>>>> direction, the projection of the linear motor on XY becomes non-zero
>>>>>> and
>>>>>> causes it to start moving in the direction of tilt. This feels a lot
>>>>>> like an RL helicopter, so I used the control keys to pitch down/up to
>>>>>> move forward/backwards, added yaw left and right, and used
>>>>>> page-up/down
>>>>>> to increase/decrease the hover height. I put it in a hacked together
>>>>>> helicopter build and it is a lot of fun!
>>>>>>
>>>>>> I'm looking for work-arounds for the current vehicle routine
>>>>>> behaviors.
>>>>>> One work-around for an airplane is to turn on hover height, check the
>>>>>> airplane speed and pitch once a second in timer(), calculate what
>>>>>> altitude the plane should get to in the next second, and set hover
>>>>>> height to that altitude. The things we do to get stuff working!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ______________________________**_________________
>>>>>> Opensim-dev mailing list
>>>>>> Opensim-dev at lists.berlios.de
>>>>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>>>>
>>>>> ______________________________**_________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at lists.berlios.de
>>>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>>>
>>>>>  ______________________________**_________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>>
>>>>
>>>>  ______________________________**_________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>
>>>
>>>
>>
>> ______________________________**_________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>
>>
> ______________________________**_________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20120611/bb378930/attachment-0001.html>