Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007779opensim[REGION] Script Functionspublic2015-12-11 17:322018-10-20 19:26
Reporterslow putzo 
Assigned ToRobert Adams 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformAMD 64 bit 8 coreOSFedoraOS Version22
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0007779: llPushObject not working
DescriptionThis script written by another scripter does not work on any of my regions nor on any of the sandboxes. It does work just fine on the region where her store is located.

I do not know if this is a bug, or some obscure setting that I can not find to set.

// Moving Sidewalk Escalator
// Pushes avatar when stepped on or detected within area of prim.
//
// v0.1 vegaslon plutonian (2013) working concept.
// v0.2 Lani Global (2013) added sim restart reset.
// v0.3 Lani Global (2013) added description setting of push force.
// v0.4 Lani Global (2013) changed to collide only instead of volume detect.

default

{
        state_entry()
    {
        float OBJECTDESC = 10; // set the default push to 10.
        llSetTextureAnim(ANIM_ON | SMOOTH | LOOP , ALL_SIDES, 1, 1, 1, 1, -0.07); // animate sliding texture.
    }
    collision(integer num_detected)
    {
        float OBJECTDESC = llGetObjectDesc(); // gets description of prim and use it as push force in z axis.
        llPushObject(llDetectedKey(0),<OBJECTDESC,0,-12>, <0,0,0>, TRUE); // push on the avatar a little.
    }
     changed(integer EVENT)
    {
        if (EVENT & CHANGED_REGION_START) // detect if region has been restarted.
        {
            llResetScript(); // reset the script
        }
    }
}



This object is like the moving walkways you see in an airport.
The working version can be seen at: Lani Mall on osgrid.
Steps To Reproducedrop this script into a prim
step on the prim

You should be pushed along the prim to it's end.

This script is used in an airport moving walkway.
TagsNo tags attached.
Git Revision or version numberOSgrid 0.8.3.0 (Dev) 41b2855: 2015-10-21
Run Mode Grid (1 Region per Sim)
Physics EngineBulletSim
EnvironmentMono / Linux64
Mono Versiontrunk
ViewerCool VL
Attached Files

- Relationships

-  Notes
(0029803)
UbitUmarov (administrator)
2015-12-12 00:21

llPushObject was fixed to work as spec
suggestion for correction for that case:

    collision(integer num_detected)
    {
        float OBJECTDESC = llGetObjectDesc(); // gets description of prim and use it as push force in x axis.
// correct impulse according to pusher orientation (region axis)
        vector imp = <OBJECTDESC,0,-12> * llGetRot();
// the local parameter is relative to target axis selection, not pusher, so needs to be false (region axis)
        llPushObject(llDetectedKey(0),imp, <0,0,0>, FALSE); // push on the avatar a little.
    }
(0029806)
slow putzo (reporter)
2015-12-12 09:53

I added your modification and it still does not work. I run bullet physics as it is the default. I try to keep things the same as the defaults as much as possible.

I discovered it works fine when I select ODE, so the problem is in bullet physics.

I can't run the current version 0.9.0 because too many things give me problems including the hang again when trying to shut down.

The modification you made appears to only be using FALSE rather than TRUE and correcting the original scripters error in identifying the axis in her comment.

I need to put this back to bullet physics as I have updated all the vehicles to work with bullet and do not want to revert back to the old ODE physics.

Can this be made to work correctly in the bullet physics engine?
(0029807)
UbitUmarov (administrator)
2015-12-12 10:48

The original also doesn't seem to work in 0.8.2 bullet
what is the version where you see it working with bullet ?

Previous opensim code assumed that local option was about pusher object axis when pushing avatars, and target axis when pushing prims.
In current code is always target axis.
So i also add the rotation to compensate the change.
(0029809)
slow putzo (reporter)
2015-12-12 12:20

Sorry for the confusion. It does not work in bullet physics either. When I tried your script modification it did not work, so I switch the region I was testing on to use the ODE physics and that did worked. I then switched back to bullet physics because I need that for all the vehicles to work right.

I have all my regions at OSgrid 0.8.3.0 (Dev) 41b2855: 2015-10-21 and now and then I try the current version to see how it works on just one region. I had been running "git opensim-0.9.0-121-gca026ac" but when I updated to "OSgrid 0.9.0.0 (Dev) 7d8b783: 2015-12-05" the hang at shutdown was back, so dropped back to the "OSgrid 0.8.3.0 (Dev) 41b2855: 2015-10-21" version. Everything seems to work fine in that version other than this llPushObject problem. I suspect it has always been broken and never reported. I had not had any objects that used that before. A new resident of mine was trying to make it work and asked me for help. I found that it did not work anyplace other than at the store where she had got it from. Most likely because most of the regions are running bullet physics now.

I did miss that you added the rotation, but I tested ODE with the new revised script you have up above.

The failure I see is that no movement at all happens.
(0029810)
UbitUmarov (administrator)
2015-12-12 12:32

made a little change on bullet, and the avatar does move for a bit.
But a few moments later the engine stops it.
Hope RAdams can fix this
(0029848)
slow putzo (reporter)
2015-12-21 20:05

I have set up a test region with the latest git (opensim-0.9.0-216-g6437a94).

I have the different objects that have the scripts on this region so I can easily test the progress of the mantis fixes.

This problem is exactly as you say it is for bullet, but it does work in physics = ubODE.

It has the following difference. In this statement:
vector imp = <OBJECTDESC,0,-12> * llGetRot();

If OBJECTDESC value is 10 the movement is very slow. in ODE it is much faster. To equal the speed of ODE the value needs to be 100 so I am guessing the force of the push is 1/10 the amount in ubODE.

The current speed using bullet does appear to be 10 times faster using the value of 100. But as you say, it stops on it's own before the script tells it to stop.

I have uncovered another bug using NPC's and will open a mantis on that but not tonight. My mind is too tired to even come close to an accurate bug report.
(0029851)
UbitUmarov (administrator)
2015-12-22 04:02

Ok rechecked, avatar motion control code does kick in even in ubOde if a collision is detected like on this object case.
Guess I only tested pushs with a vertical component :(

So push intensity is not the issue now.
(old ode one does depend on avatar density setting)

tested the object at SL
Movement is also very slow there mb a bit slower than ubOde
But worse, sometimes the avatar animation changes from stand to walk, even run and in this later case it speeds up a bit
So a lot worse than ubOde or even bullet
Seems SL avatar motion control also does like pushs like this :(
(0029857)
slow putzo (reporter)
2015-12-22 14:08

It actually works quite well by just increasing the push intensity to 100. In a way that gives you 10 times more control over how intense you want the push to be.

My point was not to suggest the original bug was not fixed in obODE but rather there was a difference. A simple change in the script gave me the ability to perfectly match the avatar speed with that of the moving texture in the object.
(0029935)
Robert Adams (administrator)
2016-01-10 16:47

I just modified BulletSim in OpenSImulator master branch to enable llPushObject to push avatars with about the same force as in ODE and ubODE. I used a moving sidewalk system from Lani as my scaling test.

Tell me if BulletSim is now about right or if more tuning is necessary.
(0029939)
aiaustin (developer)
2016-01-11 04:02
edited on: 2016-01-11 04:04

Not sure if this is related or if I should add another mantis issue.. I have noticed that in the last few weeks the avatar after arrival on a region creeps forwards or upwards very slowly... and that continues until the avatar is moved explicitly.

It is happening on very latest dev master as of today... opensim-0.9.0-240-g22501ea.zip ... I am using the default BulletSim on all regions.. but was happening before... I first noticed it maybe before the new year.

(0029941)
slow putzo (reporter)
2016-01-11 08:28

I have tested the current git master opensim-0.9.0-240-g22501ea: 2016-01-11 on the region "tsim test" on OSgrid and have found the following:
With bullet physics when I step on the moving sidewalk I am hurled at high speed off the sidewalk, and can not stop. My avatar continues off the region, and will continue traveling through other regions.

Switching the region to use ubODE physics, I travel along the moving sidewalk at exactly the speed of the moving texture on the sidewalk.

I will leave the region with bullet physics if you would like to go to the region and see the failure.

The region only contains a few objects with different scripts I am testing to see the operations between the different physics engines.

Of particular interest is how the swim ball physics differs between these two physics engines.

The ball works very well with ubODE but refused to dive below the hover setting, and the hover setting will not change to accommodate the difference needed to give the visual effect needed because of the hip joint reference point used for both the "treading water" and the "swimming" animations.

Bullet physics reacts differently with what happens when a collision with an object or land occurs as well. However this could be because of the inability to have it hover by lowering the ball deeper into the water than it presently will allow.

That issue is not part of this mantis, but wanted to point the problem out since this test region exists purly for me to verify the two physics engines so I can get off of opensim release 0.8.3 which is the last stable version usable for general residents who have scripts from many different sources.

I am using the same moving sidewalk script with slight modifications to match the texture speed, and the change made that Ubit pointed out at the start of this mantis.

Here is the script:

// Moving Sidewalk Escalator
// Pushes avatar when stepped on or detected within area of prim.
//
// v0.1 vegaslon plutonian (2013) working concept.
// v0.2 Lani Global (2013) added sim restart reset.
// v0.3 Lani Global (2013) added description setting of push force.
// v0.4 Lani Global (2013) changed to collide only instead of volume detect.

default

{
        state_entry()
    {
        float OBJECTDESC = 250; // set the default push to 10.
        llSetTextureAnim(ANIM_ON | SMOOTH | LOOP , ALL_SIDES, 1, 1, 1, 1, -0.07); // animate sliding texture.
    }
// collision(integer num_detected)
// {
// float OBJECTDESC = llGetObjectDesc(); // gets description of prim and use it as push force in z axis.
// llPushObject(llDetectedKey(0),<OBJECTDESC,0,-12>, <0,0,0>, TRUE); // push on the avatar a little.
// }
    
    collision(integer num_detected)
    {
        float OBJECTDESC = llGetObjectDesc(); // gets description of prim and use it as push force in x axis.
// correct impulse according to pusher orientation (region axis)
        vector imp = <OBJECTDESC,0,-12> * llGetRot();
// the local parameter is relative to target axis selection, not pusher, so needs to be false (region axis)
        llPushObject(llDetectedKey(0),imp, <0,0,0>, FALSE); // push on the avatar a little.
    }

    
    
    
    
    
    
     changed(integer EVENT)
    {
        if (EVENT & CHANGED_REGION_START) // detect if region has been restarted.
        {
            llResetScript(); // reset the script
        }
    }
}

The way I switch between physics engines is to uncomment the following three entries I have placed in my "gridcommon.ini" file. I do not recompile the scripts on region startup at present.

If this restart procedure is flawed, I will correct it to make sure my testing is done properly.

;; MY CHANGES

[Startup]
    TextureOnMapTile = true
    PIDFile = "/var/opensim//tmp/OSG-TSim-Test.pid"
    ; physics = OpenDynamicsEngine
    physics = BulletSim
    ; physics = ubODE
    ; meshing = ubODEMeshmerizer
[XEngine]
    DeleteScriptsOnStartup = false


This region runs on a Linux Fedora server with mono stable 4.2.1.102
(0029945)
Robert Adams (administrator)
2016-01-11 22:10

The shooting off the end of that walkway is how it was before I made the BulletSim changes. The region 'BulletSim10' has that walkway on it and in your region ('tsim test') I do shoot off the end, while on BulletSim10 I don't. I'm not sure what the difference is. BulletSim10 is Linux, mono 3.2.8, BulletSim on heartbeat thread.
(0029967)
aiaustin (developer)
2016-01-15 02:55
edited on: 2016-01-15 02:56

I noted the recent issue with avatar drift on BulletSim regions separately at http://opensimulator.org/mantis/view.php?id=7813 [^] as I have had other users report this too now o Openvue grid (Windows 10, BulletSim, opensim-0.9.0-235-gee15c51).

(0029991)
Robert Adams (administrator)
2016-01-18 10:54

BulletSim has some logic to allow slow pushing of avatars. The shopping walkway now works for me. Please test.
(0030000)
slow putzo (reporter)
2016-01-18 15:23

Robert,

I tested the commit of today with the following results.

The sidewalk does work better but still not like ubOde.

I have the push value set to 100 and that will cause the avatar to speed up and end up at the region edge before stopping. That value works perfectly with ubOde and matches the texture movement exactly.

If I drop that value down to 10 which was the original value bullet does not move the avatar at all. I discovered that the value of 30 will start the avatar moving but as it travels down the sidewalk it continues to accelerate and ends u many meters from the end of the sidewalk.

I had switched my region back to ubOde for testing another problem, but it is back at bullet should you want to give it a try.

You can try different push values by simply changing the value in the object description.

I do have a question that relates to the proper way to actually test this.

I build my binary using windows on my desktop, but test it on Linux Fedora. I have been doing that for awhile, and it always appeared to me to work just fine. The reason I do it this way is because I have never figured out how to do the compile on Linux, and on windows it is literally two mouse clicks with nothing to install or learn.

I hope that this is not messing up the validity of my testing. I can also test it on windows as I do run a development region on my desktop where I usually will write my scripts first. Primary reason for this is I avoid interruptions from friends who are online on the grid.
(0030001)
slow putzo (reporter)
2016-01-18 15:27

Robert,
On another issue, have you looked at mantis

http://opensimulator.org/mantis/view.php?id=7768 [^]

The testing for that is also on TSim Test next to the sidewalk.
(0030640)
slow putzo (reporter)
2016-06-21 14:40

I tested this today after doing some testing on mantis 7768. I had created three regions for that testing.

TSim-Test running git opensim-0.9.0-345-gce7fa72 ubODE
TSim-Test2 running git opensim-0.9.0-345-gce7fa72 bullet
TSim-Sandbox running osgrid-opensim-10212015.v0.8.3.41b2855 bullet

This mantis addresses a different scrip issue and only can be tested on the V 0.9.0 regions.

For some reason this script now does not work at all on either region. No motion at all is seen.

The script is exactly identical to the last updated script example here in this mantis that was working on the previous test region I had made. Unfortunately I had taken that region offline and deleted all the files so I can't verify if it was still working on that exact region or not. The only difference as I understand it is that since that time all of the OSgrid services have been updated to the V0.9.0 code level. That probably has nothing to do with it at all. I did try testing it on my standalone V0.9.0 system and it does not work there either.

It would appear that we have lost ground on this fix.
(0030877)
slow putzo (reporter)
2016-07-06 17:23

Today after updating to the latest git, I was testing this on my local development system and discovered that somehow my test object had been set to "phantom" I am not sure if it has always been set this way or if this is a change from my original testing. Anyway by unchecking phantom, the llPushObject function seams to be working almost totally correctly. I actually do not want the object to be phantom so if this functions should only work with non phantom objects, then consider this bug almost solved. I say almost because about 8 out of ten times using the moving sidewalk the avatar is pushed along to the very end and exits correctly. The other two times it will stop partway along the sidewalk and you need to give the avatar a nudge yourself with the forward arrow key to get it moving once again.

The other thing I noticed is that after about the first second of push movement there is a noticeable "jitter" and then the avatar slows down a small amount. It always occurs exactly at the same time period on each test. It's like something in the function times out and something else takes over. If the avatar did not have the stopping issue, this jitter is really not all that objectionable, but it could have something to do with why the avatar is stopping at times.

I have not changed the test script, it is still this script:
// Moving Sidewalk Escalator
// Pushes avatar when stepped on or detected within area of prim.
//
// v0.1 vegaslon plutonian (2013) working concept.
// v0.2 Lani Global (2013) added sim restart reset.
// v0.3 Lani Global (2013) added description setting of push force.
// v0.4 Lani Global (2013) changed to collide only instead of volume detect.

default

{
        state_entry()
    {
        float OBJECTDESC = 250; // set the default push to 10.
        llSetTextureAnim(ANIM_ON | SMOOTH | LOOP , ALL_SIDES, 1, 1, 1, 1, -0.07); // animate sliding texture.
    }
// collision(integer num_detected)
// {
// float OBJECTDESC = llGetObjectDesc(); // gets description of prim and use it as push force in z axis.
// llPushObject(llDetectedKey(0),<OBJECTDESC,0,-12>, <0,0,0>, TRUE); // push on the avatar a little.
// }
    
    collision(integer num_detected)
    {
        float OBJECTDESC = llGetObjectDesc(); // gets description of prim and use it as push force in x axis.
// correct impulse according to pusher orientation (region axis)
        vector imp = <OBJECTDESC,0,-12> * llGetRot();
// the local parameter is relative to target axis selection, not pusher, so needs to be false (region axis)
        llPushObject(llDetectedKey(0),imp, <0,0,0>, FALSE); // push on the avatar a little.
    }

The current git I am testing with is:
opensim-0.9.0-418-g4119e60: 2016-07-06

I have not tested this on OSgrid as the grid is down at the present time.
(0033208)
slow putzo (reporter)
2018-10-20 19:26

This has been totally fixed for some time now.

- Issue History
Date Modified Username Field Change
2015-12-11 17:32 slow putzo New Issue
2015-12-12 00:21 UbitUmarov Note Added: 0029803
2015-12-12 09:53 slow putzo Note Added: 0029806
2015-12-12 10:48 UbitUmarov Note Added: 0029807
2015-12-12 12:20 slow putzo Note Added: 0029809
2015-12-12 12:32 UbitUmarov Note Added: 0029810
2015-12-21 20:05 slow putzo Note Added: 0029848
2015-12-22 04:02 UbitUmarov Note Added: 0029851
2015-12-22 06:39 Robert Adams Assigned To => Robert Adams
2015-12-22 06:39 Robert Adams Status new => assigned
2015-12-22 14:08 slow putzo Note Added: 0029857
2016-01-10 16:47 Robert Adams Note Added: 0029935
2016-01-11 04:02 aiaustin Note Added: 0029939
2016-01-11 04:04 aiaustin Note Edited: 0029939 View Revisions
2016-01-11 04:04 aiaustin Note Edited: 0029939 View Revisions
2016-01-11 08:28 slow putzo Note Added: 0029941
2016-01-11 22:10 Robert Adams Note Added: 0029945
2016-01-15 02:55 aiaustin Note Added: 0029967
2016-01-15 02:56 aiaustin Note Edited: 0029967 View Revisions
2016-01-18 10:54 Robert Adams Note Added: 0029991
2016-01-18 15:23 slow putzo Note Added: 0030000
2016-01-18 15:27 slow putzo Note Added: 0030001
2016-06-21 14:40 slow putzo Note Added: 0030640
2016-07-06 17:23 slow putzo Note Added: 0030877
2018-10-20 19:26 slow putzo Note Added: 0033208
2018-10-20 19:26 slow putzo Status assigned => resolved
2018-10-20 19:26 slow putzo Resolution open => fixed


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker