RunUO Community

This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

Faster Razor?

I Cheat

Wanderer
St George said:
Why should Razor respect the uo client's timeouts? I think they are either too strict or the client itself is slow. Razor should bypass this and be more loose about waiting for an aknowledgement. Isnt that what PlayUO did?
What acknowledgement is Razor waiting for? Razor simply blocks the use packet being sent from the client and enqueues the use reuest. Whenever the use queue has something in it Razor will send a use packet to the server based on the info. in the first queue object. it then waits however long to set the delay to and send another use request if there are any. PlayUO didn't queue use request expect when you did things like ". makeregs" or ". regdrop" as far as I know.

You can disable the UseQueue in Razor if you don't like it, or you can just not use Razor if you think it makes UO slow.
 

St George

Wanderer
I am not arguing that Razor is slow but that the client is and Razor should be doing something about it. For example when waiting for a target or gump razor could ignore the fact and send the gump responce. If razor had prenegotiated this feature with the server the client would pressumably show the next gump.

In playuo for example if you looped the Dclick of a dye tub and had 100 leather vests to dye you could start a chaotic clicking till you got your result. And this sounds very good to me since an auto-paint macro cannot be currently created since the target by type feature would target 1 random vest out of 100 at a time (which now reminds me of another big isue that ned to be adressed)
 

Ilutzio

Sorceror
St George said:
an auto-paint macro cannot be currently created since the target by type feature would target 1 random vest out of 100 at a time
Razor is buildt like that; with some deliberatly restrictions when it comes to macro making.

Edit: Yeha, Zippy beat me to it, so what he said.
 

Zippy

Razor Creator
Also it's worth noting that Razor cannot send a gump response before it receives the gump... because how can it ever know if the gump was really sent? The response could arrive at the server before it sends the gump.
 

mordero

Knight
If you dont want razor to actually wait for the gump, just add a wait for 1 second or .5 seconds or whatever before you make it send the response.
 

St George

Wanderer
Zippy said:
Also it's worth noting that Razor cannot send a gump response before it receives the gump... because how can it ever know if the gump was really sent? The response could arrive at the server before it sends the gump.

It sounds logical but as i said before i have playuo in mind. i am not sure what it did it obviously but i remember it sending gump responces that at least seemed not to come after a gump return from the server. It may have been some short of negotiation between the client and the server that allowed the client achieve this, the server would know it was playuo on the other side and would return the gumps at 0 delay. So you were actually going at the max speed for your latency. It rather felt that way i must say... oh krrios... :rolleyes: hehehe
 

Zippy

Razor Creator
St George said:
It sounds logical but as i said before i have playuo in mind. i am not sure what it did it obviously but i remember it sending gump responces that at least seemed not to come after a gump return from the server. It may have been some short of negotiation between the client and the server that allowed the client achieve this, the server would know it was playuo on the other side and would return the gumps at 0 delay. So you were actually going at the max speed for your latency. It rather felt that way i must say... oh krrios... :rolleyes: hehehe
You obviously have no knowledge of the UO protocol. What you are talking about just isn't true. KUOC was one single solution so of course it is going to do things more seamlessly than Razor can because Razor has to interface with the client, and the client isn't even designed to do that.
 

Vash1986

Wanderer
Zippy said:
You'll have to explain what exactly you think Razor slows down.

As far as I know the only thing possible for Razor to slow down is general client communications between the client and the server....

yep! it does indeed!

With 100 average ping, sometimes players hit me from 2-3 tiles away. And to hit players, i have to anticipate their moves to get some tile in front of them.
This happens when running on a rail obviously, and on a horse. You notice the slow down much less when running by foot.
 
Top