Table Dancing...

[Kaivan]

This also prevents you from walking on tables as well. If the client perceives the table as an impassable object, then you won't be able to walk on it, even if you're above the table.

[Robbbb]

This also prevents you from walking on tables as well. If the client perceives the table as an impassable object, then you won't be able to walk on it, even if you're above the table.

Could you make an If...Then statement to function the same as a stool does when its locked down?

As in If player z-axis >= x then...


Just a thought.

[the bazookas]

This also prevents you from walking on tables as well. If the client perceives the table as an impassable object, then you won't be able to walk on it, even if you're above the table.

Could you make an If...Then statement to function the same as a stool does when its locked down?

As in If player z-axis >= x then...


Just a thought.

This is a good question. In looking into it, however, Kaivan is absolutely right--the client simply won't let you pass over an impassable object, so you can't do anything server side to fix it...

So how do footstools allow you to walk over tables? In the RunUO code, the server has absolutely NO special code regarding footstools. On the client's side, as far as I can tell, there is some logic that goes like this:
IF

• an object has the Surface flag (all flags I refer to are the ones stored in the client-side MUL files)
• AND that Surface object is within 2 z-levels of you
• AND nothing impassable exists 1 z-level above the surface object (e.g. a lava-tile is "Impassable", but you can walk over it b/c it has a height of 0 and the surface you placed it on has. However, if you put a piece of gold down and then the lava tile on top of it, then the Impassable lava tile is 1 z-level above your surface, and therefore you cannot move onto it anymore
• AND that Surface object is NOT Movable (locking it down can set this, or it being a static part of your tower, for example, does this)--note that it seems the client doesn't enforce this condition, but rather the server does, which is why there is rubber-banding for unlocked-down footstools
• AND there is enough room between the top of the surface and any surface above you (like on the first and second floor of a tower)

THEN the client will allow you to attempt to walk over it.

Note that the stool itself does not have the Impassable flag, which is why the SERVER makes you rubber band on it when it is Movable (as previously mentioned). There appears to be no special Foot stool specific code anywhere, so I have to think that the Server treats these NOT Impassable objects that also have the Surface flag this way. Tables have the Impassable AND Surface flag (I really don't believe the surface flag does anything since the Impassable flag appears to pretty much override it).

Anyway, so given this knowledge regarding how footstools allow you to walk over Tables, it seems that the only way you could get the client to allow somebody to walk on the table (without changing the MUL file such that it is not Impassable, which I believe would result in it rubber-banding you just like footstools while unless it is locked down, which would then allow you to walk over it if you are close to the Z level of its top like a footstool), you would have to add some kind of ghost item to the top of all the tables. This would be kind of ridiculous (and, short of making the tables an "add-on", I don't think you can technically combine two items (i.e. where you drag one item and another one comes along), although you might be able to hack a way together that does it. Obviously it would also create a higher item count (though probably not THAT high, since there aren't THAT many tables in the world).

I did find a tile that is a nodraw tile (nobody can see it) with 0 height and which has the Surface flag . Using the Blocker as an example for overriding the packet which is sent to GMs (so it is visible to them), I created a NoDrawSurface object. Could be useful in some situations ... and it would be required if you wanted to put together a way to walk on tables without changing the MUL file (and NOTE that you would NOT be able to fall off of Trinsic bank onto a non-locked down table, it would rubber band you).

The best solution to making it so you can walk on tables (as you can see by now) would be to do MUL patch to change tables to have only Surface without Impassable. However, as I said before, I believe this would make it so that tables rubber band you like stools if not locked down... and of course, doing a MUL patch isn't really on the table (PUN!).

Anyway, here's the NoDrawSurface object:

Code: Select all

using System;
using Server;
using Server.Network;

namespace Server.Items
{
    class NoDrawSurface : Item
    {
        [Constructable]
		public NoDrawSurface() : base( 0x2198 )
		{
            this.Movable = false;
            this.Hue = 0x100;
		}

        public NoDrawSurface(Serial serial)
            : base(serial)
		{
		}

		public override void Serialize( GenericWriter writer )
		{
			base.Serialize( writer );

			writer.Write( (int) 0 ); // version
		}

		public override void Deserialize( GenericReader reader )
		{
			base.Deserialize( reader );

			int version = reader.ReadInt();
		}

        protected override Packet GetWorldPacketFor(NetState state)
        {
            Mobile mob = state.Mobile;

            if (mob != null && mob.AccessLevel >= AccessLevel.GameMaster)
                return new GMItemPacket(this);

            return base.GetWorldPacketFor(state);
        }

        public sealed class GMItemPacket : Packet
        {
            public GMItemPacket(Item item)
                : base(0x1A)
            {
                this.EnsureCapacity(20);

                // 14 base length
                // +2 - Amount
                // +2 - Hue
                // +1 - Flags

                uint serial = (uint)item.Serial.Value;
                int itemID = 0x1313;
                int amount = item.Amount;
                Point3D loc = item.Location;
                int x = loc.X;
                int y = loc.Y;
                int hue = item.Hue;
                int flags = item.GetPacketFlags();
                int direction = (int)item.Direction;

                if (amount != 0)
                    serial |= 0x80000000;
                else
                    serial &= 0x7FFFFFFF;

                m_Stream.Write((uint)serial);
                m_Stream.Write((short)(itemID & 0x7FFF));

                if (amount != 0)
                    m_Stream.Write((short)amount);

                x &= 0x7FFF;

                if (direction != 0)
                    x |= 0x8000;

                m_Stream.Write((short)x);

                y &= 0x3FFF;

                if (hue != 0)
                    y |= 0x8000;

                if (flags != 0)
                    y |= 0x4000;

                m_Stream.Write((short)y);

                if (direction != 0)
                    m_Stream.Write((byte)direction);

                m_Stream.Write((sbyte)loc.Z);

                if (hue != 0)
                    m_Stream.Write((ushort)hue);

                if (flags != 0)
                    m_Stream.Write((byte)flags);
            }
        }
    }

}

[Kaivan]

While it is possible to solve this issue with such a layering, it's an over the top type of solution for this kind of problem.

[the bazookas]

While it is possible to solve this issue with such a layering, it's an over the top type of solution for this kind of problem.

I declare a pun war!

[Robbbb]

While it is possible to solve this issue with such a layering, it's an over the top type of solution for this kind of problem.

Era accuracy is era accuracy...where there's a will, there's a way!

[Kaivan]

While it is possible to solve this issue with such a layering, it's an over the top type of solution for this kind of problem.

Era accuracy is era accuracy...where there's a will, there's a way!

To clarify what I mean, I am saying that placing a nodraw tile on top of a table will produce the desired results, but its not likely that we can actually make this work properly in-game. There are numerous problems associated with this approach, not the least of which is the fact that there will be a very sizable number of extra items added to the world just to replicate this effect. In addition to that, we would have to contend with every action that might take place with a table in-game, with many of them causing problems for other mechanics, just for the purposes of being able to walk across the top of a table. The result is a nightmarish amount of coding and testing, with very little return on the results. It is for this reason, this is not a feasible solution, although a very clever one.

While it is possible to solve this issue with such a layering, it's an over the top type of solution for this kind of problem.

I declare a pun war!

Accidental puns are the best kind, are they not?

As a final note, one thing to consider regarding the rubber-banding effect on foot stools is the height of the foot stool itself. In the demo client, there happens to be a bug with the way that the client handles walking on to certain tiles, preventing players from stepping into certain houses. This bug is related to the fact that certain houses have a slightly higher "step" when stepping from the outside steps into the house, resulting in a house that cannot be entered. Largely, this is probably why the client will attempt to step up on an item which is 2 z or less from the position of the player, which was probably a fix for this problem. This is meaningful because we can be sure that tables cannot be passed through, due to their height of 6, which would make an edit to the tile data relatively ideal.

[the bazookas]

I agree that putting nodraw surface tiles on every table is a bad idea . However, after considering how to consolidate this solution into something that might in fact be workable, I think there might be at least one way:

So instead of placing a nodraw surface on every table (which would present serious issues when it comes to moving the tables, etc.), you could override the Movable setter function such that when the table is set to Movable = false, then a nodraw tile is placed on top of it. When Movable is set to true, then delete the nodraw tile. The amount of code / corner cases that require testing in this case suddenly becomes quite minimal (at least in my estimation), since I am guessing that even when a house decays, it simply uses that Movable setter function, which ought to clean up the nodraw tiles handily . I suppose the only other thing that would need to be added would be cleaning up the nodraw tile (assuming Movable is false) if the table were deleted, or (and this is the only other corner case I can think of right now) if a GM were to use the [move command on it (which can move a Movable=false object).

Obviously the other thing that would need to be handled correctly would be the Serialization of the nodraw tile. However, one (potentially) easy solution would be to override the serialize function in the nodraw object such that it actually doesn't save itself. I would guess (haven't tested it) that on server-up, when all the Movable=false tables in the world are re-created from the serialized save file, that the Movable setter function would be called appropriately, which would create the nodraw tiles at that time. Increased load time? Very slightly. Increased save time? Shouldn't be.

Hmm.. I wonder how many locked down tables there are in the world?

[Kaivan]

I don't know how many tables exist in the world, but it's sure to be an extremely large number, strictly based on its use as a barrier in houses. Also, we still need to determine when tables were rendered impassable.

[the bazookas]

Tis true; I don't currently have any other clients... does anybody already have some of the old T2A clients that they could test this with?

[Light Shade]

Tis true; I don't currently have any other clients... does anybody already have some of the old T2A clients that they could test this with?

UO Clients

[the bazookas]

Cool, I'll check out the MUL files when I get a chance.

Kaivan mentioned a re-release of the T2A client in August 1999 (?) or something like that. Do you know which client you have there? Anybody have any ideas about the other one (earlier or later release?)

[Loathed]

any update on this yet? (bump)

[Kaivan]

There's nothing to really update. The client won't allow you to walk onto a table anymore, and without some serious addition of items into the game, there's no way to reproduce that without a custom client. What's more is even if we assume that it was possible to walk on tables at one point, they became impassable at some point which we have yet to determine. If that point was some time before our cutoff date, then it would be irrelevant anyway.

[Bicchus Dicchus]

I support table dancing, and single moms in general.