[BUG-10683] Pathfinding characters drifting around

[sl-service-account]

Steps to Reproduce

Playing the game

Actual Behavior

I built a game using pathfinding. I attach a picture of one of the levels. You see a little skull. That is one of the pathfinding characters. Players need to shoot them to get points. It did all work perfect, but since about a week now, those pathfinding characters are shaking, drift around, rotate or just launch into the air. It is rather extreme and no fun playing the game anymore. It is so bad, that daily average of players dropped from about 20 to only 2 or 3, because you can't really shoot them anymore. The pathfinding characters in this level are Mesh. In another level I use sculptie characters. They are less affected by this, though they are a little shaky too. I did not change anything on the game, the sim runs with full 45 FPS and I did not update my viewer, which also runs with 20-60 FPS. So I suppose it is a problem with a recent server update.

Expected Behavior

Pathfinding characters should move smoothly around, without shaking or drifting.

Other information

The network traffic seems rather high. It is constantly between 100 and 200 KB/s

Attachments

• Snapshot_003.png 2015-11-12 11:59:00

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-10683 | | Summary | Pathfinding characters drifting around | | Type | Bug | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Stephan Gaudio (stephan.gaudio) | | Assignee | Simon Linden (simon.linden) | | Created at | 2015-11-12T16:59:00Z | | Updated at | 2017-05-08T23:48:33Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2015-11-12T14:59:24.306-0600', "Is there anything you'd like to add?": 'The network traffic seems rather high. It is constantly between 100 and 200 KB/s', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Simulator', 'Target Viewer Version': 'viewer-development', 'What just happened?': "I built a game using pathfinding. I attach a picture of one of the levels. You see a little skull. That is one of the pathfinding characters. Players need to shoot them to get points. It did all work perfect, but since about a week now, those pathfinding characters are shaking, drift around, rotate or just launch into the air. It is rather extreme and no fun playing the game anymore. It is so bad, that daily average of players dropped from about 20 to only 2 or 3, because you can't really shoot them anymore. The pathfinding characters in this level are Mesh. In another level I use sculptie characters. They are less affected by this, though they are a little shaky too. I did not change anything on the game, the sim runs with full 45 FPS and I did not update my viewer, which also runs with 20-60 FPS. So I suppose it is a problem with a recent server update.", 'What were you doing when it happened?': 'Playing the game', 'What were you expecting to happen instead?': 'Pathfinding characters should move smoothly around, without shaking or drifting.', 'Where': 'http://maps.secondlife.com/secondlife/Games/172/76/69', } ```

[sl-service-account]

Stephan Gaudio commented at 2015-11-12T19:43:27Z

So, I had a few friends testing this and they all saw the pathfinding characters drifting of or launching into the air. All but one. I went with her through all her settings and statistics and we found that I and the other had set our Maximum bandwidth in Preferences to 500. She had it at 3000. I increased mine to 5000 now and the pathfinding characters all move smoothly as they are supposed to. But my Statistics window shows UDP Data Reveived of 800-1000 KB/s now constantly. That is not normal. I worked before perfectly with a setting of 500 max.

[sl-service-account]

Whirly Fizzle commented at 2015-11-12T20:59:24Z

I can reproduce that at the above location. Spoke to Stephan inworld & the problem actually started when he got a new neighbour. The neighbour has their festive decorations up which unfortunately are pretty spammy with the object updates, especially the trees & the houses: http://prntscr.com/922eo3 I'm not 100% sure the large amount of object updates in that area is the cause of the problem but the higher then normal UDP Data Received reading in stats plus the fact that raising the maximum bandwidth setting in the viewer lessens the problem quite a bit makes me suspect that's the problem. If you cam onto the neighbours land, the UDP Data Received reading is consistently at 2000-2500 kb/s, which is pretty high.

[sl-service-account]

Simon Linden commented at 2015-11-13T21:22:16Z

I looked into the logs and didn't see anything interesting about the performance. I believe the theory about the neighbor updates is likely the cause ... if you cut the draw distance down, does it work better?

[sl-service-account]

Whirly Fizzle commented at 2015-11-13T21:52:40Z

Yeah if draw distance is low enough to not draw the neighbours object it's better. If the neighbours objects are within draw distance but your camera view is facing away from those objects, it's also better.

I can reproduce exactly the same effect as seen at Stephan's place on a pretty empty region when I rez an object that causes a lot of object updates. Pathfinding characters without object update spam: https://gyazo.com/ff5b4a46be8e11de0e095d753bb19ebb Pathfinding characters with object update spam - they just fly all over the place: https://gyazo.com/8f375b44b8b30f43cf91efaf87a322a9

Script used for the PF characters

create_character()
{
//  Clear any previous character behaviors
    llDeleteCharacter();

//  MAX_SPEED is @ 20 by default
    llCreateCharacter([ CHARACTER_MAX_SPEED, 25,
                        CHARACTER_DESIRED_SPEED, 15.0]);
}

patrol_around(vector targetPos)
{
    list points = [targetPos + <5, 0, 0>, targetPos - <5, 0, 0>];
    llPatrolPoints(points, []);
}

default
{
    on_rez(integer start_param)
    {
        llResetScript();
    }

    state_entry()
    {
        create_character();
    }

    touch_start(integer num_detected)
    {
        patrol_around(llGetPos());
    }
}

Script used to create the object updates, placed in a 256 prim linkset :D

default
{
    state_entry()
    {
            llSetTimerEvent(0.1);
    }
    timer()
    {
        float x = llFrand(1.0);
        float y = llFrand(1.0);
        float z = llFrand(1.0);
        llSetLinkColor(LINK_SET,<x,y,z>,ALL_SIDES);
    }
}

[sl-service-account]

Stephan Gaudio commented at 2015-11-14T20:01:28Z

I had a similar problem when we were filming machinima. We had about 50 pathfinding characters rezzed for that and some were flying all over the place too. But usually there are just 11 characters at any time. They use llWanderWithin to move. I think a tiny color changer like Whirly is using, should not be able to break the game. Especially since 2/3 of the sim is empty and there are never more than 2 or 3 people on it. Somewhere is a bottleneck that should not be there. I can't just tell all my visitors to reduce draw distance and increase bandwidth. I have to expect them to run on default settings and it needs to be easy and intuitive for anybody.

[sl-service-account]

Whirly Fizzle commented at 2015-11-14T20:20:18Z

Well, to be fair, that script is running on a very fast timer & when its running in a 256 prim linkset, thats creating a silly number of object updates. I know what you mean though :)

The colour changer script is the repro script from the feature request at BUG-6053. Im pretty sure the repro given on BUG-6053 is demonstrating the same problem as you are seeing with your pathfinding characters.

[sl-service-account]

Stephan Gaudio commented at 2016-07-29T14:58:16Z

Just a reminder, this is still a problem. I just had a new neighbour move in on the sim and the drifting got worse again. The sculptie pathfinding characters move normal, at the same time the mesh characters rotate randomly all the time and get stuck often. Both have the same script.

[sl-service-account]

Stephan Gaudio commented at 2016-07-30T14:52:11Z

So I am not familiar with how things actually work under the hood, but I might have 3 possible solutions. As I mentioned above, things got worse again when a new neighbour moved to the region. Just like the first time, it is a christmas market again. In summer!!! This is just my luck. So he has a lot of fast blinking lights and moving stuff. This seems to cause high network traffic for the object updates, which seem to use fast timers. When I increase my maximum bandwidth setting in preferences, the problem gets better. So, my first idea is, why is there a maximum setting anyway. Couldn't this be set to unlimited by default or detect the available bandwidth of the user somehow and set it accordingly? Why is it set to just 500 by default? The second idea that I had is, why are those color changes not handled locally in the viewer. As far as I see each color change causes network traffic. At the same time a rotation caused by llTargetOmega() is handled locally. Can't those color changes be outsourced from the server to the viewer? A third idea would be to give certain updates priority. A pathfinding update seems to be more important than a color change in my eyes. A slower color change nobody would notice, but a pathfinding update that is delayed causes the character to drift around or launch into the air as described. Would be great if you could give me some feedback, it's already 9 months since I posted this and nothing happened. This is frustrating and I don't know if it is worth further developing this game at all. It was supposed to be a grid-wide game soon. This game started out to be very popular with more than 50 players every day and was featured in the Editor's Picks of Destination Guide as well. Now it is not really fun playing and all the work I put in it and all the money that I pay for the land seems to be wasted. I know you give priority to issues that affect many people and you see me as just one. But I have already 1500 players in my database and many addicts that come daily, so please help to make SL better for all of those.

[sl-service-account]

Whirly Fizzle commented at 2016-07-30T19:56:46Z

When I increase my maximum bandwidth setting in preferences, the problem gets better. So, my first idea is, why is there a maximum setting anyway. Couldn't this be set to unlimited by default or detect the available bandwidth of the user somehow and set it accordingly? Why is it set to just 500 by default?

Setting Max Bandwidth to unlimited by default isn't a good idea. Those with super fast connections could handle it but those with slower connections or limited data usage could not. It matters a bit less these days now that more things have been moved over to HTTP, but it still matters. If a user sets the Max bandwidth too high for their connection they will often run into problems - packet loss, voice connections issues, their chat posts being sent two or more times etc. The Maximum bandwidth setting only governs UDP traffic, not HTTP. Object updates are sent over UDP.

Just to note too, the server caps the maximum Bandwidth at 3000, even though the slider on the LL viewer goes up to 10,000.

[sl-service-account]

Stephan Gaudio commented at 2016-07-30T23:02:54Z

Hi Whirly! Do you know if there are plans to move the object updates to HTTP as well? It got really worse today. The christmas market is twice the size as last year now and my game does not work for anybody with default settings (500 kb/s) anymore. Even at 1500 kb/s it is shaky. "UDP Data received" is constantly above 1000 Kb/s in statistics. Pathfinding characters fly and drift all over the place. Players are so frustrated, they leave right after they arrive. I would close the place down, but I feel bad for the landlord, he renamed the sim to "Games" just because of me a few weeks ago. He had to sell 10 out of his 40 sims lately, because too many plots were empty and I am here for years already. Still half my sim is empty as well and still not enough resources to support the content. I am really frustrated:(

[sl-service-account]

Whirly Fizzle commented at 2016-07-30T23:19:20Z

Do you know if there are plans to move the object updates to HTTP as well? I have no idea if that's planned or even a viable change. A Linden will need to answer that question.

[sl-service-account]

Stephan Gaudio commented at 2016-07-30T23:23:07Z

I hope one of them reads this. It's been 9 months. The status is "Resolved". Why is that? Does that mean they have a solution but did not implement it yet?

[sl-service-account]

Whirly Fizzle commented at 2016-07-31T01:38:28Z

The "Accepted" status & resolution just mean that this issue has been accepted as a valid problem & has been imported over to one of LL's internal JIRA projects, in this case as issue MAINT-5874 (you can see the MAINT number under the History tab on this issue). Once an issue is imported, it's a black hole to us. Usually (not always) LL don't update the public BUG issues with any further information or with what priority an issue has & we need to watch the release notes for the viewers/server to see what's been fixed.