Brush should stop movement in woods

[LKP]

Yes, brambles blocked movement, and yes, they caused rubberbanding. Yes, rubberbanding is caused by the client thinking it can move somewhere but the server telling it that it cannot. The client makes the move request, predicts that it will be approved, and shows the character moving. The server denies the move request, and the client "takes back" the move, thus causing the rubberband effect.

RunUO contains objects called blockers that require at least a counselor access level to see. GM and above can add them freely. They block movement, but not line of sight; LOS blockers are a separate object. Finding every bramble and placing a blocker there would be time-consuming to say the least, but it might be possible to add them all at once using a command like "[shard add blocker where...[some property unique to brambles] = true." You might be able to pull it off with serials or object ID's. It would take some tweaking and testing though, as I'm not even sure you can use modifiers on the [add command.

So I believe it could be done, but that leaves the question of whether it should be.

[the bazookas]

RunUO contains objects called blockers that require at least a counselor access level to see. GM and above can add them freely. They block movement, but not line of sight; LOS blockers are a separate object. Finding every bramble and placing a blocker there would be time-consuming to say the least, but it might be possible to add them all at once using a command like "[shard add blocker where...[some property unique to brambles] = true." You might be able to pull it off with serials or object ID's. It would take some tweaking and testing though, as I'm not even sure you can use modifiers on the [add command.

Adding blockers sounds like a decent solution (assuming it was decided by staff that these tiles should block). However, it might cause some issues with housing. Did brambles / impassable rocks, etc. block housing placement?

I imagine there would be a way to write a specific command for RunUO that would automatically search the world for those impassable tiles and place a blocker on them (unless they are under a house). I'm going to look into it a bit.

Personally I think having these less-visible blocking tiles is a good thing, since, as I said, it actually takes skill to avoid them, and without something like brambles, etc., running away on a horse is way easier than I it should be (and easier than it was in-era). I believe, however, that unfortunately people can use something like the "stump" mod to modify the tiles into highly visible ones, creating a disadvantage for others. In spite of that, I personally still think it'd be worth having the blockers (and no, I don't use that lame mod).

[Kaivan]

Unfortunately, blockers do not solve the problem any better than making brambles impassable on the server, as it causes the same problems for the client in both cases: rubberbanding.

The problem at its heart is the fact that the client interprets each of these once impassible objects as a normal object that can be passed through. This presents a problem because the client will encounter one of these map tiles which is stored locally, and will assume that it can walk over the tile, because the tile data indicates that the particular tile object can be passed through. If the item cannot be passed over, the client attempts to move over the object, and is promptly told by the server that it cannot do that. This causes the client to 'roll back' the attempt to move onto the next tile, creating the rubberbanding effect. In both of the solutions presented: setting these item types as impassable on the server, and placing invisible blockers, we run face first into this problem.

The only workable solution to this problem would be to set these item types as impassable on the server and to modify the client tile data to indicate that these items are not passable. This would force the client to block attempts to move onto tiles with these objects, and thus cure the rubberbanding problem. The issue with this solution is that it requires some sort of custom client modification or installer, which runs into the same problem we have with requiring Razor: restricted access to the server.

[Mikel123]

So I believe it could be done, but that leaves the question of whether it should be.

If it could be, it should be. They were definitely a major factor in running in T2A. I was surprised when they didn't block movement here.

I'm also pretty sure they blocked housing - I think the housing placement rules on this shard are significantly more relaxed than they were in 1999 - and IMO we should adopt a grandfathering policy on such things immediately. (I.E. existing houses are fine, but brambles and flower patches and whatever else will block house placement going forward).

[Mikel123]

Unfortunately, blockers do not solve the problem any better than making brambles impassable on the server, as it causes the same problems for the client in both cases: rubberbanding.

Why is this a problem? This is IDEAL, as that's exactly what happened in 1999.

[the bazookas]

Unfortunately, blockers do not solve the problem any better than making brambles impassable on the server, as it causes the same problems for the client in both cases: rubberbanding.

I'm about 95% sure that the tile used in the RunUO Blocker object is such that the client actually interprets it as impassable (and yet still invisible to regular players). This means no rubberbanding

I ran a quick test on the default RunUO server by creating a custom command to place Blockers on all brambles / rocks / saplings throughout the world, and it appears to successfully add Blockers at those specific tiles (no rubber band lag as far as I know, but still blocks).

Also some more good news (at least for those who think brambles etc. should block): It also didn't appear to affect already-placed houses, but if those houses were pulled up (as Kaivan noted), then you would be unable to place another house in that spot since these Blockers "block" it (go figure). Furthermore, I believe the "blocker" tile has a height of 4 (brambles do too, but Rocks have a height of 2) which means things placed on it could potentially be slightly higher than they technically should be... but I don't personally see that as a big issue, and possibly something that can be fixed in the code (haven't looked into it yet, though).

Obviously UOSA has many differences from the default RunUO server, but I think this is still possibly feasible.

Code: Select all

public static void Initialize()
        {
            CommandSystem.Register("brambleson", AccessLevel.Administrator, new CommandEventHandler(BrambleRockSaplingBlockers_Command));
        }

        public static void BrambleRockSaplingBlockers_Command(CommandEventArgs e)
        {
            int mapWidth = Map.Felucca.Width;
            int mapHeight = Map.Felucca.Height;
            int[] bramblesRocksSaplingIDs = new int[] { 0x1773, 0x1774, 0x1777, 0x1778, 0x177B, 0x177C, 0xCEA, 0xCE9, 0xD3F, 0xD40 };
            int numBlockersAdded = 0;
            for (int x = 0; x < mapWidth; x++)
            {
                for (int y = 0; y < mapHeight; y++)
                {
                    StaticTile[] tiles = Map.Felucca.Tiles.GetStaticTiles(x, y, false);
                    
                    for (int i = 0; i < tiles.Length; i++)
                    {
                        foreach (int j in bramblesRocksSaplingIDs)
                        if (tiles[i].ID == j) 
                        {
                            Blocker blocker = new Blocker();
                            blocker.MoveToWorld(new Point3D(x, y, Map.Felucca.GetAverageZ(x, y)), Map.Felucca);
                            numBlockersAdded++;
                            break;
                        }
                    }
                }
            }
            Console.WriteLine(numBlockersAdded + " Blockers added.");
        }

Here's some screenshots:
What GM's would see:

Blockers staff.jpg (43.21 KiB) Viewed 3903 times

What regular players would see:

Blockers regular player.jpg (81.04 KiB) Viewed 3903 times

Inside a house, what a GM sees:

BlockerInHouse.jpg (45.08 KiB) Viewed 3903 times

Inside a house, players can walk over the Blocker

BlockerInHouseOK.jpg (44.36 KiB) Viewed 3903 times

Running this command took about 5 seconds on my crappy laptop (froze the server for that time, of course) and it added 89,687 Blockers. I imagine it could be done over a timer, in order to not affect the server in anyway, but since it's a 1 time thing, I don't think it's a big deal to run once.

It wouldn't take much to alter this script such that you keep a list of all these blockers such that you could do a reversal if you wanted (or if it had some undesired affect).

[Kaivan]

I just got to sit down at a computer with UO installed and I can confirm that blockers will properly move a player around brambles and other blocking objects on UOSA. This may possibly be a workable solution for this problem, although it will require a lot of extra work to make it behave correctly with respect to the housing system.

[rouss]

This command you speak of adds extra 90k objects to the world, augumenting the load and save times, also it is a dirty solution; the "clean" solution : impassable brushes can be easily implemented on the client side just by editing tiledata.mul : you can set different flags to each and every tile in the game; "passable" is one of them. In this case client doesn't predict the movement through brushes so there's no rubberband.

/edit : whoops, Kaivan basically said the same thing. i should read before speak.

[the bazookas]

This command you speak of adds extra 90k objects to the world, augumenting the load and save times, also it is a dirty solution; the solution can be easily implemented on the client side just by editing tiledata.mul : you can set different flags to each and every tile in the game; "passable" is one of them.

True, and I agree that it is a more "elegant" solution, but

The issue with this solution is that it requires some sort of custom client modification or installer, which runs into the same problem we have with requiring Razor: restricted access to the server.

Also

although it will require a lot of extra work to make it behave correctly with respect to the housing system.

It will definitely require a lot of testing, but based on this preliminary test, these Blocker objects
1) block placing housing (just like other objects)
and
2) are basically ignored when underneath an existing building.
I can't think of any other issues off-hand (but doesn't mean they don't exist)... so off hand, I can't really think of any extra work needed (i'm sure there's some, I just can't think of it right now)

[rouss]

This command you speak of adds extra 90k objects to the world, augumenting the load and save times, also it is a dirty solution; the solution can be easily implemented on the client side just by editing tiledata.mul : you can set different flags to each and every tile in the game; "passable" is one of them.

True, and I agree that it is a more "elegant" solution, but

The issue with this solution is that it requires some sort of custom client modification or installer, which runs into the same problem we have with requiring Razor: restricted access to the server.

well in this case this modification wont restrict anything per se; it just makes the game more convenient.

[the bazookas]

well in this case this modification wont restrict anything per se; it just makes the game more convenient.

Ahh, you've made a very good point. It's on the other side of the coin from the Razor restriction issue; restricting razor is where we don't want the player to have something that the player (generally) wants to have. In this case, just enable the rubber banding and provide the updated .mul files to all players who want them, and most players (at least the semi-technically savvy ones, which would leave some people out) will happily apply the patch in order to avoid rubber banding. On the other hand, however, an extra step for a new person joining the server must take to fully enjoy the server is not ideal. It could be included in the installer in some way, but again, a number of people might still have issues with it.

As a side note, apparently there are 8 million items currently in the game, so 80,000 is 1%, which means adding blockers would probably increase save time by a bit less than half a second .

[rouss]

As a side note, apparently there are 8 million items currently in the game, so 80,000 is 1%, which means adding blockers would probably increase save time by a bit less than half a second .

By all means thanks for your efforts to write this script, but seeing how Derrick sweats blood to slice off another 1/8 second from save times... I really don't see that coming

Anyway, to make this modification (and use it) we should hear Derrick's approval as by rules any client modification of this sort is forbidden/may lead to ban.

[the bazookas]

I thought of a possible issue that would need to be resolved: house steps could be blocked by these Blockers (if the house happened to be placed with the steps over a bramble / rock / sapling).

I also have thought about Kaivan's statement (years ago) that "some" saplings and rocks blocked; I do seem to remember some blocking and some not blocking when I played in-era. However, I don't know what determined whether it was blocking or not... based on the UO:98 demo, it seemed like every different type of rock / sapling / bramble was blocking (rubber-band style).

If there really isn't a way to know which ones are blocking and which ones are, the script could just be modified so as to not add Blockers if they are in a house and / or on the steps... Or, just block them all, and manually delete the problematic ones as people complain about it . I don't know.

Anyway, yes, obviously Derrick must ultimately decide whether he wants to do anything about this stuff.

[Kaivan]

That's part of the client side rubberbanding I was talking about. If you use a fresh installed copy of the T2A client with the demo, it doesn't do that because of the tiledata.mul which has the proper items as impassable.

[the bazookas]

That's part of the client side rubberbanding I was talking about. If you use a fresh installed copy of the T2A client with the demo, it doesn't do that because of the tiledata.mul which has the proper items as impassable.

Indeed. It makes sense that there isn't rubber banding, but I guess what I was trying to say is that in determining which rock / sapling tiles should be impassable and which ones are passable, what is the best approach?

I'm would think that if the UO:98 demo server is rubberbanding you, it would mean that it's one of those impassable tiles (changing client would just prevent rubber banding)... so when you said previously that some of the saplings / rocks were impassable (meaning that some were passable), should not the UO:98 demo server not rubber band you back when you walk on those tiles? In my somewhat short jog around the UO:98 demo server, I was unable to find any rocks / sapling that did NOT rubberband; do we have any indication of which (if any) of these bramble / rock / sapling tiles shouldbe passable?