Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007132opensim[REGION] OpenSim Corepublic2014-04-25 12:122017-06-05 19:02
Reporterdanbanner 
Assigned ToRobert Adams 
PrioritynormalSeveritymajorReproducibilityrandom
StatusassignedResolutionopen 
PlatformOSOS Version
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0007132: Collisions stop for no apparent reason on BulletSim
DescriptionCollisions randomly stop working until region is restarted. I only noticed this occurring after switching LBSA to BulletSim.
Steps To ReproduceNo known way to trigger this, as it seems very random, usually after a day or two.
I will add more info as I am able to gather it.
TagsNo tags attached.
Git Revision or version numberr24620
Run Mode Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineBulletSim
EnvironmentMono / Linux64
Mono Version3.2
Viewerany
Attached Fileszip file icon physics-logs.zip [^] (1,002,622 bytes) 2015-08-08 18:42
png file icon jk_collision_test.png [^] (516,788 bytes) 2015-08-15 11:32
zip file icon physics-logs2.zip [^] (1,114,316 bytes) 2015-08-21 21:16

- Relationships

-  Notes
(0025900)
smxy (reporter)
2014-04-25 12:46

I've been experiencing this problem for at least a year now. I have teleport gates that work off collision_start. When it stops working, it stops for all the gates in the region, at once. Instead of being teleported, you just thud into it. Resetting the scripts in the object doesn't help. Restarting the region always fixes it, though I seem to recall that I had to set DeleteScriptsOnStartup = true, in order for that to fix it. Today, I discovered that if I trigger a feature of the gate, where it goes phantom if the destination is down and restores itself once the destination is back up, made that gate work again. It was the following two lines that are pertinent:

This:
llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0.1, PRIM_PHANTOM, FALSE, PRIM_COLOR, ALL_SIDES, <1,1,1>, 0.1]);

Followed by this:
llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 0.0, PRIM_PHANTOM, TRUE, PRIM_COLOR, ALL_SIDES, <1,1,1>, 0.0]);

... made collision_start work again, *without* a region restart.

I *think* this started happening after I switched to BulletSim, but I cannot swear to that. I never see anything logged - they just stop working. I did add an llOwnerSay inside collision_start, which fails to get run when that gate "goes bad".

Like dan found, the frequency is random and can be from a day to several to weeks (though usually not that long). I know of no way to make it happen, aside from just waiting.

On a possibly related note, I had a sim today, where touch_start failed to work, until a region restart. No "hand", when moving the cursor over the object, no ability to touch it from the menu (greyed out). Additionally, I had yet another region where collision_start didn't work, but touch_start did.
(0025939)
Dev Random (reporter)
2014-04-30 18:12

Managed to reproduce this issue, but it seems it was just by waiting long enough. Two regions running in separate instances, both started within a minute of each other, same machine, seem to have happened at same time.

Resetting script had no effect, but when I made a trivial edit to the script (added a space to a line) and re-saved it, I was teleported to the destination although I was not in contact with the object (a stored collision event?).

Mono 3.2.8 on Ubuntu 14.04 x86_64 on AMD
(0025981)
smxy (reporter)
2014-05-08 06:18
edited on: 2014-05-08 09:26

I've now had an occurrence of this issue. I can't make it happen, so just had to wait. I've refrained from restarting my region or updating code while waiting on this to eventually occur, and have been monitoring the script in one of my gates, as Justin suggested.

What I'm seeing is that the monitoring is showing that the script is still responding to at least some events, because every hour it'll log this (which is normal, as the gate checks the remote destination, hourly, to see if it's up):

06:43:33 - [SCRIPT INSTANCE]: Processing event timer for Instant Hypergrid Jump/Blamgate v3.2se WC(2349133141)/Blamgate v3.2se WC(ddb293b4-ef93-443d-8bed-aed963454069) @ <149, 128, 342.8744>/Eld
06:43:34 - [SCRIPT INSTANCE]: Processing event http_response for Instant Hypergrid Jump/Blamgate v3.2se WC(2349133141)/Blamgate v3.2se WC(ddb293b4-ef93-443d-8bed-aed963454069) @ <149, 128, 342.8744>/Eld

I'm still getting those messages.

Before this testing period started, days and days ago, I'd added an llOwnerSay as the first thing that runs in collision_start(). Every time anyone would use the gate, I'd get a message like this:

[20:19] Blamgate v3.2se WC: In collision_start.

Now, when I or anyone else tries to use the gate, we just go "thud" when we collide, nothing happens (no teleport), and I get no message from collision_start().

I know that it was working at least until 11:19 PM Eastern, on the 6th, as that was the last time I got a message from collision start, when someone used the gate.

All this time, I've also been running with physics logging turned on, and I have gigs of logs.

I have resisted the temptation to restart my region, in case we want to do any more testing/checking while it's in this state (pun half-intended, heh), but this does mean that my approx. 80 gates are non-functional at the moment, so I'd like to not wait too long before a restart.

So now what?

(0025982)
smxy (reporter)
2014-05-08 06:23

In my original note on this mantis, I'd also mentioned an issue with touch_start() failing, as well. I've left out a prim that tests that, this whole time, and I can report that while my gates aren't getting collisions, the prim still responds to being touched.
(0025983)
smxy (reporter)
2014-05-08 06:26

My gates also have a touch_start() event handler, to force an immediate check of the destination. I just tested this, on the gate being monitored and that still works:

09:23:43 - [SCRIPT INSTANCE]: Processing event touch_start for Instant Hypergrid Jump/Blamgate v3.2se WC(2349133141)/Blamgate v3.2se WC(ddb293b4-ef93-443d-8bed-aed963454069) @ <149, 128, 342.8744>/Eld
09:23:44 - [SCRIPT INSTANCE]: Processing event touch for Instant Hypergrid Jump/Blamgate v3.2se WC(2349133141)/Blamgate v3.2se WC(ddb293b4-ef93-443d-8bed-aed963454069) @ <149, 128, 342.8744>/Eld
09:23:44 - [SCRIPT INSTANCE]: Processing event touch_end for Instant Hypergrid Jump/Blamgate v3.2se WC(2349133141)/Blamgate v3.2se WC(ddb293b4-ef93-443d-8bed-aed963454069) @ <149, 128, 342.8744>/Eld
09:23:44 - [SCRIPT INSTANCE]: Processing event http_response for Instant Hypergrid Jump/Blamgate v3.2se WC(2349133141)/Blamgate v3.2se WC(ddb293b4-ef93-443d-8bed-aed963454069) @ <149, 128, 342.8744>/Eld

So, it seems it's only collision events that the gates aren't getting, right now.
(0025984)
smxy (reporter)
2014-05-08 09:28

I see this is assigned now - yay. :) Is there anything further you want me to test, check or do, or can I stop filling my disk with gigs of physics logging and restart my region so my gates work again?
(0025988)
danbanner (manager)
2014-05-08 10:01

recompiling the script does seem to make the collisions work again
(0025994)
smxy (reporter)
2014-05-08 12:45

I can confirm that, as well. All approx. 80 gates went bad at once, but I *could* fix them, one at a time, like this (though I'm not likely to do it that way).
(0025995)
Dev Random (reporter)
2014-05-08 16:52

In my script, I also added code to increment a counter on collision_start, and decrement it on collision_end. The counter value increases , but never returns to zero... so looks like collision_end is not firing (I assume it's because the collider has teleported away).
(0025996)
smxy (reporter)
2014-05-08 18:40

I certainly believe you - we talked about it before - but it sure seems weird. You'd think that once they teleported away, the collision would end, since they aren't actually there and in contact with it anymore. That's got to be a bug. I wonder if, after enough unfinished collisions happen, that's why new collisions stop firing.
(0025997)
smxy (reporter)
2014-05-08 19:00

Actually, that might explain the varying timing of when this occurs and the inability to make it happen on-demand. If it's the cause, however, I ought to be able to reproduce it by setting up two local gates and just popping back and forth through them until it happens. First, though, I should modify my script to verify I'm seeing the same thing you are.
(0026022)
Robert Adams (administrator)
2014-05-10 13:58

I've looked at this a bit. From your description, it does seem to be a race condition somewhere. I don't see a way for collisions to just stop but there are also several lists where collisions are recorded in order to do the first/last collision computations.

Is there a way to duplicate this? What should I build in order to make this happen for me?
(0026023)
smxy (reporter)
2014-05-10 14:19

We've not been able to make this happen, so far. In my previous note, I suggested a way that I might be able to trigger it. I'll work on setting up that scenario now and will report back, later, on my results.
(0026024)
smxy (reporter)
2014-05-10 14:36

I'm working on setting this up, but I can confirm one thing the Dev_Randome saw, and which I've seen before - collisions store up. If I bump into a gate or multiple gates, in rapid succession - I've only seen this when the result was a transport within the same region - you will teleport repeatedly as each previous one completes, until the run out. It can be a real PITA. :)
(0026034)
smxy (reporter)
2014-05-11 17:52

I deleted my last three notes from this mantis, as they were 100% incorrect. The 25 second delay I was seeing was the result of an llSleep(20) plus 5 seconds before osTeleportAgent let the script move on and process the collision_end event (I wish it were more immediate, but 5 seconds isn't as horrendous as 25).

I've cleaned up the script and am continuing to try to repro the original problem of collision_start not triggering after some time.
(0026041)
smxy (reporter)
2014-05-11 23:27
edited on: 2014-05-11 23:30

My first, serious, attempt at causing the issue failed. It did have benefits, however. In setting up my test case, I found a few flaws in my Blamgate script, and fixed them. Nothing that would have caused the issue we're seeing, but that the script could just do smarter.

For the test case, I rezzed 100 Blamgates out, horizontally. Each was configured to teleport you to just slightly above the next one, so you'd drop into it and be automatically teleported to the next gate in the chain. It takes approximately 1 minute to complete the circuit of 100 gates. Once that was working nicely (re: script fixes), I then chained the last gate to the first and had an avatar hop on.

Using ODE, I had an avatar stay on the circuit for approximately 1800 chained, in-region, teleports. Usiing BulletSim, I had an avatar stay on the circuit for approximately 2000 chained, in-region, teleports. (I'd let them off the endless loop by editing the final gate to go somewhere other than the start gate.)

In both cases it went flawlessly. For every incrementing of the counter to one, in collision_start, it was decremented back to zero, in collision_end.

The only thing I don't like, as mentioned in my last note, is that osTeleportAgent causes a 5 second delay in collision_end being triggered, whereas without it it triggers instantly (i.e., when bumping into a prim that does nothing but tell you when the two events trigger).

My next case will be between neighboring regions. We know that you can't do instantaneous A->B->A->... teleports, as there has to be a delay in order for things to "settle", so I'm going to have to experiment with ways to delay the automatic teleport back. Perhaps drop them from a high enough point above the gate that it takes X amount of time to reach the gate. Or, perhaps better yet, have them arrive on a platform that is just above the gate, and have it turn it self phantom, briefly, X amount of time after the avatar lands on it, so that it delays them falling onto the gate for the return trip ...

The plan is to try this between neighboring regions, then non-neighbors, then between grids ...

(0026070)
smxy (reporter)
2014-05-13 11:57
edited on: 2014-05-13 12:18

My current test is between neighboring regions (different simulators, both 1:1). I have it set up so that every 30 seconds or so, I make the next hop in A->B->A->... After letting it do that for about an hour, I decided to enable the gates' debug mode and I immediately see what Dev_Random was seeing: the counter is being incremented in collision_start, but never decremented in collision_end, nor is the llOwnerSay in collision_end being executed, which suggests the event is never triggering after the Agent teleports out of the region.

I'm just off of HEAD, so I'm going to update and start this test from scratch and let it run, to see if this will cause collision_start events to fail to trigger, after enough collision_end events have failed to trigger.

I should note that I'm using BulletSim currently. I'll followup with ODE after I see the results of this test.

(0026085)
smxy (reporter)
2014-05-13 21:50
edited on: 2014-05-14 11:40

Further testing showed that this skipping of collision_end happens with ODE as well as BS. Several of us discussed it in IRC and at Justin's request, I filed Mantis 0007168 about it, as we all feel that it makes logical sense that if the avatar is no longer there and colliding with the object, then the script should recognize that and trigger collision_end, just as it correctly does if the teleport was an in-region teleport.

As to whether these missing collision_end events are the cause of, or at all related to, the failure of collision_start to trigger, we have no idea. I have currently performed 1600+ automated teleports, 30 seconds apart, between neighboring regions, using ODE, with no failure of collision_start to trigger. I'm going to let it run overnight and tomorrow I'll switch back to BS and restart the test. Update: ODE test was stopped after 2000 teleports. Switching to BS for the next 2K. (I clear all script state and other stuff, when I switch, so everything starts clean.)

(0026149)
smxy (reporter)
2014-05-20 19:09

I did run another test of ~2K A->B->A teleports, between neighboring regions, with BulletSim. I saw some odd behavior that I didn't, with ODE, so I want to run the test again when I can be watching it more closely. The way I was doing the teleports, with a 30 second delay between them, was that rather than having each gate rez me just above the other gate - which would mean an instantaneous TP back - I had each gate rez me just above a platform over the other gate. The platform would perform an llSleep(30), then slide itself out of the way, dropping me onto the gate for the return TP. 15 seconds after sliding out of the way, the platform would slide back, so it would be in place when I arrived 15 seconds after that.

That worked flawlessly, and consistently, with ODE. With BulletSim, I saw that, frequently, one of the platforms was sliding out of the way only 13 seconds after I landed on it, then in second 0000014, I'd be teleported, and just as I'd rez over the other platform, I'd see it complete its 15 second wait and slide in under my feet just as I'd start to fall. Also, sometimes one of the platforms seemed to be sliding out of the way okay, but in the opposite direction from the way I'd programmed it to.

So, I am going to try this experiment again, this weekend, and pay close attention to what's going on.
(0026338)
Robert Adams (administrator)
2014-06-21 20:10

I checked in some critical region checking that I hope solves some of this problem. Please test and report if collisions keep going away. Detailed physics logging really helps.
(0026346)
smxy (reporter)
2014-06-22 06:32

I'll update later today. Keep in mind that it can take weeks to manifest, so you may not know for quite some time.
(0026354)
smxy (reporter)
2014-06-22 18:21

I'm in the process of updating now. I can say that the issue still existed as of this, as I just found my gates ignoring collisions. Let's hope your latest fix fixes it.

Still broken in:

OpenSim 0.8.0 Dev c915791 - r24842 2014-06-08 12:18:49 -0700 [CentOS 6.5/Mono 3.6.1] (Unix/Mono)
(0026358)
smxy (reporter)
2014-06-23 12:17

I updated to this an hour ago. Now we wait.

OpenSim 0.8.1 Dev ca2379e - r24897 2014-06-21 15:38:38 -0700 [CentOS 6.5/Mono 3.6.1] (Unix/Mono)
(0026384)
smxy (reporter)
2014-06-26 16:48

I'm re-running the A->B->A tests, mentioned in comment 26149, as another test of your recent collision changes. Hopefully they run better this time. :)
(0026392)
smxy (reporter)
2014-06-27 10:40

While we still don't know if the issue at the root of this mantis is resolved or not (only time will tell, since we can't manually repro it), I can say that your recent changes have improved collisions. My automated A->B->A test (with BulletSim) has reached the halfway point, having flawlessly performed 1000 round-trip (so, 2000 consecutive) teleports between neighboring regions, 30 seconds apart. I was not able to do that previously, without weird stuff happening.
(0026410)
smxy (reporter)
2014-06-28 05:04
edited on: 2014-07-05 06:04

The second half of the test finished fine. Status:

1) 2000 consecutive in-region teleports - OK
2) 2000 consecutive A->B->A teleports between neighboring regions - OK
3) 2000 consecutive A->B->A teleports between non-neighboring regions - OK
4) 2000 consecutive A->B->A teleports between grids - OK

*In all cases, except 2, the regions involved had/will have no neighboring regions. In case 2, there were no neighbors other than the two involved in the test. All regions involved in the above tests have been/will be 256x256 in size.

**Test 1 was successfully repeated in a 768x768 varregion.

On to recreating tests 2-4 with varregions ...

(0026483)
smxy (reporter)
2014-07-15 05:54

My gates have stopped recognizing collisions again, so this is still an open issue. :(
(0026484)
smxy (reporter)
2014-07-15 05:58

Interestingly, it has happened at the same time to gates in two different regions, in different simulators, on the same server. And it has only happened to *most* of the gates in the regions, but not *all*.
(0026578)
Robert Adams (administrator)
2014-07-24 21:40

I created a test setup that drops balls through four volume detect objects and accounts for all the collision starts and ends. I also created scripts to analyze the logs to make sure all the collisions are accounted for. So far, I've dropped more than 1 million balls with no collisions lost. This is with separate BulletSim threads but on a standalone region.

So far, I haven't found the condition that causes collisions to stop. I'm wondering if teleports are required to cause the problem.
(0026582)
smxy (reporter)
2014-07-25 05:53

I'm not using volume detect collisions at all. Just the normal collision that happens when one bumps into a prim. If teleporting in-region, the start and end of the collision will both be triggered. If teleporting out of the region, the collision end will not be triggered. However, no amount of test collisions and teleports - 4000 at a time, which is way more than my visitors ever do - has ever triggered the problem. Only a variable amount of time seems to do that.
(0027363)
smxy (reporter)
2015-01-27 10:36

Just updating this to say that it is still an ongoing problem. I see it less often as I have been proactively automatically restarting my region of gates every night, but even then it still bites me now and then.

I sure wish we could figure this out.
(0028637)
smxy (reporter)
2015-06-07 08:26

After two years, this is still a problem.
(0028647)
Diva (administrator)
2015-06-09 08:47

I haven't been following this too closely, but from the description I suspect the problem might be XEngine, and not physics.
(0028727)
danbanner (manager)
2015-06-14 13:38

This doesnt happen if a simulator is running ODE
(0029081)
Robert Adams (administrator)
2015-08-03 06:36

I just added a feature to OpenSim to use FireAndForget for passing script collisions to the script engine. Normal operation is unchanged but setting "[Startup]ShouldUseFireAndForgetForCollsions=true" in your INI file, will enable this.

Could you test this and see if it 'fixes' the collisions going away? While maybe not a perfect solution, if this changes things it would point to something to fix. If this doesn't change the collisions going away, I'll add more instrumentation to BulletSim.
(0029087)
smxy (reporter)
2015-08-03 14:22

I'll be sure to try it out. Thanks. Works got me very busy, so I may not be able to update my grid until the weekend, and then it may take days for the problem to re-appear, if it's going to, but I'll let you know.
(0029127)
smxy (reporter)
2015-08-08 18:28

Two weeks ago, I set up a test of 10 pCampBots TPing back and forth between two non-neighboring, legacy-sized regions, each running in their own simulator, continuously, every 30 seconds. Additionally, in one of the regions, I had a single NPC continuously TPing around the four corners of the region, making a circuit every 2 seconds.

After a week, they stopped TPing, when objects in the region stopped registering collisions.

This past week, I repeated the test, but with physics logging enabled for both regions. Again, they all stopped and collisions aren'nt being registered.

In a moment, I will attach the two physics logs that cover the period when the teleports stopped (4:36 AM). Hopefully they will shed some light on the issue.

These regions are running:

Version: OpenSim 0.8.2.0 Dev 017d2cf - r26083 2015-06-17 15:55:07 -0700 [CentOS 6.6/Mono 4.0.1] (interface version 7)

Tomorrow, I'll build and update to HEAD and restart the test again, still with physics logging.
(0029128)
Gavin Hird (reporter)
2015-08-09 04:41

FWIW I tested [Startup]ShouldUseFireAndForgetForCollsions=true and I could not notice any (performance) changes.

I then came to test with Bulletsim not running on own thread, and collisions improved. Stairs that were a bit bumpy to climb improved for instance. Sim crossings improved too. SIM frames run consistently closer to 90-91ms vs 94-95 ms with bullet on own thread.

Could it be that with bullet running on own thread chances are the physics frame does not always complete in time for the next sim frame to complete, and therefore creates issues? Or does the sim frame have to wait for the physics frame to complete?

NOTE that I run async_call_method = Thread and not SmartThreadPool on mono, which could influence the difference.
(0029130)
Robert Adams (administrator)
2015-08-09 15:50

The jumpiness when running on own thread can happen. Normally the simulation steps are synchronized with sending out updates (since the physics calculation is done on the main simulation thread). If the physics simulation gets out of sync with the main thread, it can get jumpy. For vehicles, I found that one needs to speed up the physics clock (simulate more often) if running physics on its own thread.
(0029131)
Robert Adams (administrator)
2015-08-09 15:56

I spent much time pouring over smxy's logs of collisions going away. It is not 100% clear why the occurrence of an avatar TPing within a region (a case where the simulator removes the avatar from the physics engine and then immediately adds it back with the same LocalID, etc) would stop all avatars from getting collisions. Collisions are handled per object so everyone stopping is odd. That plus avatars added after collisions have stopped do get their collisions.

I just checked in some changes that eliminate some potential race conditions and also a potential problem with locking the list of avatars in the region. This latter problem is the most likely thing that would cause what I see in the logs.

Please test and see if collisions stay around.
(0029158)
smxy (reporter)
2015-08-15 10:22
edited on: 2015-08-15 10:44

To document our IRC chat (I've edited out chat not pertaining to this):

[12:16] <smxy> misterblue: As you may recall, one of my tests involves teleporting an NPC around a sim in a continuous, never-ending, loop. The original version of that script works in both ODE and BS. I made a different version of it today, which I've discovered works in ODE, but not BS.
[12:17] <misterblue> how does it 'not work'?
[12:17] <misterblue> TPing around a single region was the problem my last patches were fixing
[12:18] <smxy> Let me describe the test. I put a flat prim in each corner of the sim, then drop an NPC on the first one, which immediately TPs it to the next one, etc..
[12:19] <smxy> It takes about 2 seconds to hit all four.
[12:19] <smxy> However, there is a 5 second delay built into osTeleportAgent.
[12:21] <smxy> So, I set up three more "inner loops", such that it takes longer than 5 seconds from the time it hits one until it hits it again, which means that it does 16 TPs before starting back at the first one.
[12:21] <smxy> With me so far?
[12:22] <misterblue> I get the geometry but you say that osTeleportAgent has a 5 sec delay? So there are multiple NPCs?
[12:22] <smxy> No, just 1 NPC.
[12:23] <smxy> But once a prims TPs it, that prim cannot TP it again until after 5 seconds have passed.
[12:23] <smxy> So I just set up a long series of TPs so it didn't make it back to the beginning before 5 seconds were up.
[12:24] <misterblue> ugh... yes... the code has a ScriptSleep(5000) after doing the FireAndForget on the RequestTeleportLocation()
[12:24] <smxy> That's the test, and it works great with the original script. The NPC goes around and around forever. Over a million times in one test.
[12:24] <misterblue> ScriptSleeps also tie up processor threads, but that's another story
[12:25] <smxy> And that original script works in both ODE and BS.
[12:25] <smxy> Let me pastebin that script.
[12:26] <misterblue> are you doing this on your own test grid?
[12:27] <smxy> All 16 prims had a script like this, with only the coords different: http://pastebin.com/WjYgSbaQ [^]
[12:27] <smxy> Yes, on my own grid.
[12:27] <smxy> It's about as minimal as you can get, as you can see.
[12:27] <misterblue> indeed
[12:28] <smxy> Now, I have had issues with queued events in my other teleporters, so I did a little research and learned that all queued events are thrown away on a state change.
[12:28] <smxy> So I modified my script accordingly. This new script works perfectly on ODE. Let me pastebin it.
[12:29] <smxy> http://pastebin.com/2h2uetXj [^]
[12:29] <smxy> Still very minimal.
[12:30] <smxy> All it does is ensure that when I come back to the default state, there are no queued up collisions left over from when the NPC last landed on the prim.
[12:31] <smxy> I changed the start prim, of the 16, to use that script. Everything works in ODE.
[12:33] <smxy> In BS, if I drop an NPC on it, it will send it off to do a complete circuit of the 16, but when it gets back to this prim, it doesn't get the collision event, so it doesn't TP anymore. If I remove the NPC, and drop it on it again, it will again make one full circuit, then stop when it returns to this prim again.
[12:33] <smxy> :)
[12:34] <smxy> I know the script doesn't get the collision event, because I had a version of it that did an llOwnerSay when it entered either state or collision_start.
[12:35] <smxy> When it gets back to this prim, it says it entered the default state, but doesn't say it gets into collision_start.
[12:35] <Plugh> smxy: You could add a state_entry in default to verify if it does return to the default state after the TP.
[12:35] <smxy> Plugh: see my last statement. :)
[12:37] <smxy> Maybe it's incorrect to say the prim/script doesn't get the collision_start event. Maybe it's more correct to say that the script never registers it, for whatever reason.
[12:37] <smxy> Thus it doesn't proceed to state two and TP again.
[12:38] <smxy> This is a 256x256 region, if that matters.
[12:39] <smxy> Has to be or I couldn't test with ODE.
[12:40] <smxy> misterblue: With my description, and those two scripts, you should be able to recreate the test in your grid.
[12:41] * misterblue is thinking about TPs and collisions
[12:46] <smxy> misterblue: One thing to remember, is that, when TPing in-region, the script does get a collision_end event. When TPing out of a region, the sending script never sees a collision_end event. This appears to be true regardless of ODE or BS and I have no idea if it is related to this problem or not.
[12:48] <misterblue> the computation of begin/end events is tricky... there is a lot of logic for that... and this seems to be about the bounding conditions (what happens when starting or stopping an object)
[12:49] <smxy> I just switched back to BS and sure enough, the NPC made one circuit, then stopped on the first prim.
[12:50] <smxy> In case there's a difference between an NPC and my avatar, let me try it.
[12:51] <smxy> Okay, there's a slight difference. I went around 3 or 4 times, before I stopped.
[12:52] * misterblue cringes over the thought of race conditions... a real avatar has more state so it will take a little longer in some places
[12:52] <smxy> No, I erred. :)
[12:53] <smxy> my 4 times was just one full circuit.
[12:53] <smxy> Then I stopped. Same as the NPC.
[12:55] <smxy> I note, also, that just like removing the NPC and dropping it on it again, makes it go another circuit and stop, I can jump once after I stop, and go another circuit again. So that behaviour is the same too.
[12:59] * smxy feels great, having finally come up with a reproducable collision issue for misterblue to fix. :)
[12:59] <misterblue> smxy, could you create an OAR of your test region? An empty 256 region with just the TP circuit course?
[13:11] <smxy> misterblue: clicking the flat prim near the center of the region creates the NPC and drops it on the starting prim. Clicking the white ball removes the NPC. Here's the OAR: https://dl.dropboxusercontent.com/u/16941610/s25_20150815_130700.oar [^]
[13:13] <smxy> The starting prim contains both versions of the script, with the version that works in both ODE and BS commented out.

(0029159)
JeffKelley (reporter)
2015-08-15 11:31

@Robert Adams : > I'm wondering if teleports are required to cause the problem.

Teleports are not required to cause the problem. I have a test bench with physic cubes going back and forth through volume detectors. The detectors turn red when they did not register a collision fot the last 10 seconds. I see occasionaly all cubes reds when I log in the region, however this can take days. If it may help, I can package this setup as an oar. See attachment jk_collision_test.png
(0029160)
smxy (reporter)
2015-08-15 11:36

Jeff: There are two issues here. The one I see, that has nothing to do with volume detect, as I don't use it, and then what you and nebadon see.

Buried down in the code of OpenSim or BulletSim, they may be related, but from an end-user perspective, we are describing two different problems.
(0029354)
smxy (reporter)
2015-08-21 21:21

misterblue: I ran the 10-pCampBot test again, where they TP back and forth between two regions, every 30 seconds. After several days, the test has once again ended with teleports halting, as collisions are no longer being reported to the scripts.

I did NOT have the other test (the single NPC continuously TPing around one region) running during this test, as I had done before.

Please see the attached physics-logs2.zip file for the physics log from both regions, covering the period when the TPs stopped.
(0029357)
smxy (reporter)
2015-08-22 04:29

misterblue: Ubit and I were chatting about this. He suggested two things: 1) That I make sure you know I've been running BS on its own thread, and 2) That I rerun my last test without it running on its own thread.

I'll restart the test later this weekend.
(0029366)
Gavin Hird (reporter)
2015-08-24 01:42

The latest commits r/26199 and r/26200 did not work for me at all. It is like the avatar hitting a brick wall on region crossings and if you turn to walk back, the avatar just drifts into the next region border.

The console logs the following


2015-08-24 10:35:52,442 ERROR (bulletunmanaged (Ghul)) - OpenSim.Region.Physics.BulletSPlugin.BSScene [BULLETS SCENE]: ProcessTaints: BSCharacter.create: Exception: System.ArgumentException: An item with the same key has already been added.
  at System.ThrowHelper.ThrowArgumentException (ExceptionResource resource) [0x00000] in <filename unknown>:0
  at System.Collections.Generic.Dictionary`2[System.UInt32,OpenSim.Region.Physics.BulletSPlugin.BSPhysObject].Insert (UInt32 key, OpenSim.Region.Physics.BulletSPlugin.BSPhysObject value, Boolean add) [0x00000] in <filename unknown>:0
  at System.Collections.Generic.Dictionary`2[System.UInt32,OpenSim.Region.Physics.BulletSPlugin.BSPhysObject].Add (UInt32 key, OpenSim.Region.Physics.BulletSPlugin.BSPhysObject value) [0x00000] in <filename unknown>:0
  at OpenSim.Region.Physics.BulletSPlugin.BSScene+<AddAvatar>c__AnonStorey0.<>m__0 (OpenSim.Region.Physics.BulletSPlugin.BSCharacter aa) [0x00000] in <filename unknown>:0
  at OpenSim.Region.Physics.BulletSPlugin.BSCharacter+<BSCharacter>c__AnonStorey0.<>m__0 () [0x00000] in <filename unknown>:0
  at OpenSim.Region.Physics.BulletSPlugin.BSScene.ProcessRegularTaints () [0x00000] in <filename unknown>:0
(0029367)
Gavin Hird (reporter)
2015-08-24 01:54

Reverting r/26199 lets the avatar cross the region border, reverting r/26200 eliminates the console spew. I have not tested only r/26200 to see how this works in isolation.
(0031995)
smxy (reporter)
2017-06-05 19:02

A little over three years later, I still have to restart my regions every day - sometimes, several times a day - because this has never been fixed. :(

- Issue History
Date Modified Username Field Change
2014-04-25 12:12 danbanner New Issue
2014-04-25 12:46 smxy Note Added: 0025900
2014-04-30 18:12 Dev Random Note Added: 0025939
2014-05-08 06:18 smxy Note Added: 0025981
2014-05-08 06:18 smxy Note Edited: 0025981 View Revisions
2014-05-08 06:19 smxy Note Edited: 0025981 View Revisions
2014-05-08 06:23 smxy Note Added: 0025982
2014-05-08 06:26 smxy Note Added: 0025983
2014-05-08 07:33 Robert Adams Assigned To => Robert Adams
2014-05-08 07:33 Robert Adams Status new => assigned
2014-05-08 09:26 smxy Note Edited: 0025981 View Revisions
2014-05-08 09:28 smxy Note Added: 0025984
2014-05-08 10:01 danbanner Note Added: 0025988
2014-05-08 12:45 smxy Note Added: 0025994
2014-05-08 16:52 Dev Random Note Added: 0025995
2014-05-08 18:40 smxy Note Added: 0025996
2014-05-08 19:00 smxy Note Added: 0025997
2014-05-10 13:58 Robert Adams Note Added: 0026022
2014-05-10 14:19 smxy Note Added: 0026023
2014-05-10 14:36 smxy Note Added: 0026024
2014-05-10 14:44 smxy Note Added: 0026025
2014-05-10 15:07 smxy Note Added: 0026026
2014-05-10 15:08 smxy Note Edited: 0026026 View Revisions
2014-05-10 15:09 smxy Note Edited: 0026026 View Revisions
2014-05-10 16:00 smxy Note Added: 0026027
2014-05-10 16:00 smxy Note Edited: 0026027 View Revisions
2014-05-10 16:03 smxy Note Edited: 0026027 View Revisions
2014-05-10 16:05 smxy Note Edited: 0026027 View Revisions
2014-05-10 16:10 smxy Note Edited: 0026025 View Revisions
2014-05-11 17:47 smxy Note Deleted: 0026027
2014-05-11 17:47 smxy Note Deleted: 0026026
2014-05-11 17:47 smxy Note Deleted: 0026025
2014-05-11 17:52 smxy Note Added: 0026034
2014-05-11 23:27 smxy Note Added: 0026041
2014-05-11 23:30 smxy Note Edited: 0026041 View Revisions
2014-05-13 11:57 smxy Note Added: 0026070
2014-05-13 12:18 smxy Note Edited: 0026070 View Revisions
2014-05-13 21:50 smxy Note Added: 0026085
2014-05-13 23:13 smxy Note Edited: 0026085 View Revisions
2014-05-14 00:15 smxy Note Edited: 0026085 View Revisions
2014-05-14 07:51 smxy Note Edited: 0026085 View Revisions
2014-05-14 08:01 smxy Note Edited: 0026085 View Revisions
2014-05-14 11:40 smxy Note Edited: 0026085 View Revisions
2014-05-20 19:09 smxy Note Added: 0026149
2014-06-21 20:10 Robert Adams Note Added: 0026338
2014-06-22 06:32 smxy Note Added: 0026346
2014-06-22 18:21 smxy Note Added: 0026354
2014-06-23 12:17 smxy Note Added: 0026358
2014-06-26 16:48 smxy Note Added: 0026384
2014-06-27 10:40 smxy Note Added: 0026392
2014-06-28 05:04 smxy Note Added: 0026410
2014-06-29 19:41 smxy Note Edited: 0026410 View Revisions
2014-07-01 05:23 smxy Note Edited: 0026410 View Revisions
2014-07-05 06:04 smxy Note Edited: 0026410 View Revisions
2014-07-05 06:04 smxy Note Edited: 0026410 View Revisions
2014-07-15 05:54 smxy Note Added: 0026483
2014-07-15 05:58 smxy Note Added: 0026484
2014-07-24 21:40 Robert Adams Note Added: 0026578
2014-07-25 05:53 smxy Note Added: 0026582
2015-01-27 10:36 smxy Note Added: 0027363
2015-06-07 08:26 smxy Note Added: 0028637
2015-06-09 08:47 Diva Note Added: 0028647
2015-06-14 13:38 danbanner Note Added: 0028727
2015-08-03 06:36 Robert Adams Note Added: 0029081
2015-08-03 14:22 smxy Note Added: 0029087
2015-08-08 18:28 smxy Note Added: 0029127
2015-08-08 18:42 smxy File Added: physics-logs.zip
2015-08-09 04:41 Gavin Hird Note Added: 0029128
2015-08-09 15:50 Robert Adams Note Added: 0029130
2015-08-09 15:56 Robert Adams Note Added: 0029131
2015-08-15 10:22 smxy Note Added: 0029158
2015-08-15 10:25 smxy Note Edited: 0029158 View Revisions
2015-08-15 10:26 smxy Note Edited: 0029158 View Revisions
2015-08-15 10:26 smxy Note Edited: 0029158 View Revisions
2015-08-15 10:28 smxy Note Edited: 0029158 View Revisions
2015-08-15 10:29 smxy Note Edited: 0029158 View Revisions
2015-08-15 10:30 smxy Note Edited: 0029158 View Revisions
2015-08-15 10:31 smxy Note Edited: 0029158 View Revisions
2015-08-15 10:33 smxy Note Edited: 0029158 View Revisions
2015-08-15 10:34 smxy Note Edited: 0029158 View Revisions
2015-08-15 10:36 smxy Note Edited: 0029158 View Revisions
2015-08-15 10:44 smxy Note Edited: 0029158 View Revisions
2015-08-15 11:31 JeffKelley Note Added: 0029159
2015-08-15 11:32 JeffKelley File Added: jk_collision_test.png
2015-08-15 11:36 smxy Note Added: 0029160
2015-08-21 21:16 smxy File Added: physics-logs2.zip
2015-08-21 21:21 smxy Note Added: 0029354
2015-08-22 04:29 smxy Note Added: 0029357
2015-08-24 01:42 Gavin Hird Note Added: 0029366
2015-08-24 01:54 Gavin Hird Note Added: 0029367
2017-06-05 19:02 smxy Note Added: 0031995


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker