Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ Suggestions
➜ Priority for commands and triggers in queue
|
Priority for commands and triggers in queue
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Welcomb
(14 posts) Bio
|
| Date
| Sat 28 Dec 2002 03:58 PM (UTC) |
| Message
| It would be good if we could specify the priority that commands have when they are inserted in the queue. Commands like msg or tells be set to have lower priority than immediate ones like attack, heal or flee.
For example one might have queued a few commands during battle but when he wants to flee or retreat, he should be able to set the flee command as highest priority to be executed before all commands in the queue. To jump the queue in other words.
User should be able to set which priority command line commands. triggered commands should have their own priority settings too. maybe a special syntax like /1 <command> to set command priority from the command line. | | Top |
|
| Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
| Date
| Reply #1 on Sat 28 Dec 2002 10:01 PM (UTC) |
| Message
| If you are talking about the command window, then this is impossible. All commands are sent 'as you enter them'. Even if the mud has not sent any return text, any command you type is sent right when you hit enter. The reason for this is because both the client and the mud keep a buffer containing all text they recieve. This is why sending a long series of commands to a mud will either get you kicked off (in order to prevent an overflow) or causes an internal error. Put simply, a few milliseconds after you hit enter, the command has already arrived at the mud and will be executed in the order it did so.
This can be a bad thing or a good thing. It can be a good thing, because if you know that you need to run away after 3 round of combat you can send the command at just the right time to do that. If telnet did use a transaction method that would allow what you suggest, then the amount of delay for each command to be reacted to would be about 1/2 the time it would take for the monster to execute another series of attacks on you. Best advice is don't send a mess of commands you can't stop when you know you may need to run away.
As for the using world.queue command as and option.. That won't do it either. You could concievably use a script to rearrange things in its queue and prioritize the contents, but doing so would be quite complicated and probably add additional delay to the execution.
However, it might be a useful thing to add to the queue command, since it would allow you to drop a command into the 'next command to execute' spot or the like. Since the queue command waits for a newline to send the next command, according to the docs, it might be possible to jump ahead of the commands you haven't yet sent, but only if you expect to recieve only a single line of response per command.
The problem though, is still that if a round of combat, for instance, generated 8 lines of text and you didn't send the run command until the end of that, you will have already sent 8 possible commands before you ever requested to insert a higher priority command, thus leaving in the same situation you are now. Using the speedwalk delay with it would imho be worse, since while Nick insists that a few milliseconds don't matter, the reality is that sending a command at the right time could be a matter a few hundred milliseconds, especially since you often have to send it a few moments 'before' you see the last bit of text from the world that you expect when your command needs to execute. With queued commands, the delay is of course always the same, so you can't send it at 'just the right time'.
Note to Nick: A good example of the timing issue is the following>
You miss giant.
You miss giant.
You hit giant with a great blow.
You miss giant.
Giant hits you.
--<command sent to run>
Giant hits you.
Giant hits you.
Giant hits you.
Giant hits you.
You finish concentrating on your spell.
The giant shudders as ....
--<command actually executes>
Sending the command to move just two lines earlier means the spell gets interrupted, while a few lines later means the giant gets several more hits in before you retreat. The difference is maybe 1/4 of a second. This is why a lot of people griped about timers and doafter being in seconds instead of milliseconds. Nor would all combat with all mobs, or the same mob under different circumstances generate a predictable enough pattern of events to use that as an accurate way to use timers or doafter with a 1 second minimum delay. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #2 on Mon 30 Dec 2002 03:54 AM (UTC) |
| Message
| | I agree with most of what Shadowfyr has said, however I still think that MUDs do fighting responses on an internal heartbeat that is probably in the order of a second, plus the internet latency time, so whilst it might be nice to have timers fire in a 1/100th of a second interval, it might not actually achieve much. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Meerclar
USA (733 posts) Bio
|
| Date
| Reply #3 on Mon 30 Dec 2002 05:02 AM (UTC) |
| Message
| | As a coder on multiple muds and codebases past and present, I can confirm Nick's suspicions of the internal heartbeat for combat functions. I can also confirm his statement that having triggers fire at 1/100 second intervals wont accomplish anything unless you can convince your muds coders to rewrite the entire combat structure from the ground up. Good luck on that one btw :) |
Meerclar - Lord of Cats
Coder, Builder, and Tormenter of Mortals
Stormbringer: Rebirth
storm-bringer.org:4500
www.storm-bringer.org | | Top |
|
| Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
| Date
| Reply #4 on Mon 30 Dec 2002 08:30 PM (UTC) |
| Message
| Hmm. Well my mud doesn't (and probably due to the way things execute on it can't) delay a command to the next combat round intentionally. They happen when they get pulled from the execution queue. This means that at least on LP muds, you can have command executing at the start, middle or end or a combat round. So here is the question..
1. You know that a command takes about 3.5 seconds (more or less).
2. You know that each round of combat is roughly 1 second.
3. You can't safely stay in the fight for more than 4 rounds.
4. The room you are in uses a hidden exit that can't be left using the auto-retreat.
How exactly do you make 100% certain that you leave within 3 seconds, 'but' after the spell actually goes off?
Answer: Unless you can adjust for the delay in sending commands you can't, since a timer at 3 second will end up sending it in 3.15 seconds (assuming a 300ms ping) or in more that 4 seconds (thus the start of round 5) and you will thus always either die or run before the spell is going to fire. But even if commands did only happen at specific pounts in a round, a 0.05-0.2 second delay in getting then there (if they execute at the 'start' of a round) would still fail to work right.
For me this is not an issue, since I don't believe in botting and the mud I play on prohibits it anyway, but it does seem like it would be a serious problem for some people. | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
16,624 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top