Object delay

[Loathed]

I've searched high and low- and cannot find info on this but memory and basically common sense tells me that object delays current trigger is somewhat off.

On osi when you were to far to use something say, a back pack/door/dagger/anything!
you would get the I can't reach that message over your head, upon going to the island (quickly moving to the use item range of this said item) you could hit last object and it would use it. Ofcoarse this makes perfect sense since no object action was performed when you were to far away. I recall being able to dbl click someone's pack from far away and run by them and hit my last object macro- at this point my character would attempt to snoop. However- here if you try to use an item or object of any sort that is too far away you get the same message but must wait for the entire 1 second to pass before you could try and use the object, even if you're next to it or not. There should be no 1 second timer on ebject delay if the object isn't used (I.E- too far away) using an item that is out of reach should not trigger this 1 second delay.

The above only makes sense, as I stated above I was unable to find any info on this anywhere. Any feedback would be helpful. I didn't have a open door macro during t2a era, But i know some did have it on their space bar as this was very useful. So if anyone can find screenshots of a journal or sumfin when they typed lots and see if there was a "you must wait to perform another action" spam while you were typing (assuming no door was close by to open) I am sure if no item is actually used no matter what the item, the trigger shouldn't be activated for 1 second cooldown

Ty for your time

[nightshark]

Agreed, it's bizarre that performing failing to perform an action (out of reach) uses up your action delay.

Also, is it era accurate that you can only use objects within 1 tile of you? I thought it was supposed to be two tiles.

[MatronDeWinter]

It seems like you are right, but with the lag I had in t2a it is hard to be certain. I certainly agree that item use is off. You cannot use items that you should be able to use, and when dropping items, sometimes the direction you are dropping them effects the range. I also believe that ALL locked down items in a home should be usable by anyone. I should be able to eat food, use dye tubs, re-dye tubs, use your house key, whatever basically.

I do not believe that OSI has any special code to determine whether or not a player was able to use an item locked down. It seems most logical (and accurate from my memory) that the use object function was the same for all objects.

[Derrick]

I just tested this under pre-T2A OSI code via the UO Demo. This is a simple test to do if you have access to this software.

I bound a open door macro to my spacebar, and while standing inside the building and rapidly double clicking the sign outside, i tapped my spacebar at a rate less than once per second.

useDelay.gif (259.76 KiB) Viewed 1424 times

As you can see, the packet was sent, as the client responds "opening door..." but the door does not open. This demonstrates that these packets are throttled before they are processed, as was I believe found in the core decompilation as well; Batlin should be able to confirm this.

[Loathed]

I just tested this under pre-T2A OSI code via the UO Demo. This is a simple test to do if you have access to this software.

I bound a open door macro to my spacebar, and while standing inside the building and rapidly double clicking the sign outside, i tapped my spacebar at a rate less than once per second.

useDelay.gif

As you can see, the packet was sent, as the client responds "opening door..." but the door does not open. This demonstrates that these packets are throttled before they are processed, as was I believe found in the core decompilation as well; Batlin should be able to confirm this.

i see.

[Kaivan]

Another test that you can run to see this in action on the demo is by setting a last object key. Set the key, and put an object on last target. Then attempt to use a container from 3 tiles away and quickly move in one tile an use it again. You will find that you must wait out the object delay, despite having actually done nothing.

There is one noteworthy exception that is not properly reflected on UOSA though. Using the same method, you can attempt to open a door using the last object macro and produce the same result. However, if you set another macro to OpenDoor and stand next to the door (not facing towards the door) and use your OpenDoor macro and then quickly use last object, the door will be opened (or closed) with no delay. Essentially, this means that the client doesn't (or shouldn't) create an action delay. This is currently not reflected correctly on UOSA. As of now, if a player stands next to a door and issues and hits an OpenDoor macro and then attempts to interact with any other object, including the door, they will receive the full 1 second action delay before they can successfully interact with something again.

[nightshark]

Interesting! This knowledge may come in handy when dungeon PvPing in the future!

[Loathed]

Another test that you can run to see this in action on the demo is by setting a last object key. Set the key, and put an object on last target. Then attempt to use a container from 3 tiles away and quickly move in one tile an use it again. You will find that you must wait out the object delay, despite having actually done nothing.

There is one noteworthy exception that is not properly reflected on UOSA though. Using the same method, you can attempt to open a door using the last object macro and produce the same result. However, if you set another macro to OpenDoor and stand next to the door (not facing towards the door) and use your OpenDoor macro and then quickly use last object, the door will be opened (or closed) with no delay. Essentially, this means that the client doesn't (or shouldn't) create an action delay. This is currently not reflected correctly on UOSA. As of now, if a player stands next to a door and issues and hits an OpenDoor macro and then attempts to interact with any other object, including the door, they will receive the full 1 second action delay before they can successfully interact with something again.

So hypothetically speaking, If i put opendoor macro on my space bar, i shouldn't be spammed with you must wait to perform another action when i'm doing sex roleplay (typing lots of words quickly) while i'm not facing a door, correct?
if that is the case, then correct one what u say, this currently not the way it is on uosa, makes me want to test out many other things with this, i'll run some test in the morning and see what the demo can't reveal for us, if that damn wisp could just set my str and dex up to 100 i'd be set now >_<

[Derrick]

It sounds like Open Door checks the action throttle, but does not set it. i'll test this.

Thanks guys