17 Jul, 2012, Markov_AU wrote in the 1st comment:
Votes: 0
I am looking to separate channel/chat input from the main stack of commands players can put in, to make interaction easier, I am somewhat at a loss as to where to start
17 Jul, 2012, Runter wrote in the 2nd comment:
Votes: 0
Start by finding where the commands are processed

The logic looks something like this likely:

loop do
unless ch.lagged == 0
cmd = ch.command_queue.pop
cmd.execute
ch.lagged = cmd.amt_of_lag
end
ch.lagged -= 1
sleep for_timing
end


Now that you've found that it should be more obvious what you need to do.
You could implement a separate queue pretty straight forward. If the command is a lagless command, put it in the lagless queue.
Personally, I would just implement a priority queue. This would ensure the next cmd to clear the queue is always a lagless command. This is almost what you want, more dry, and more flexible in the long run as you can prioritize commands in the queue for other purposes.
18 Jul, 2012, Rarva.Riendf wrote in the 3rd comment:
Votes: 0
I had the same approach, parsing the general queue and if I found a lagless command just execute it and remove it from the queue, iterating till I had no lagless command in it.
(I think I uploaded the snippet (merc/rom) for that.
Implementing lagless command has some consequences though:your mprpog may not behave the same as before it you had a mob
cast armor
cast bless
say something

if say is now lagless what you may see
cast armor
say something
cast bless

(I am not sure about stock ROM though..I know I did some change so that mob use the same methods than player, so they use the same queue etc..)
19 Jul, 2012, Markov_AU wrote in the 4th comment:
Votes: 0
I found the snippet:
http://www.mudbytes.net/file-2822

Thanks, I'll review it and see how it works and decide if this is the way I want to go (w/ the rest of my coding team as well)
22 Jul, 2012, Rarva.Riendf wrote in the 5th comment:
Votes: 0
If you find any bugs or whatever, please report it :)
23 Jul, 2012, Hades_Kane wrote in the 6th comment:
Votes: 0
The approach we took was to take out "lag" time all together in favor of a "wait state". An additional entry into the command table for whether a command is restricted by the wait state was added as a means to exempt commands like who, look, say, chat, etc. When you 'bash' for example, you are put into a 'wait state' which then just restricts usage of the specified commands. There is no command queue, stack, or lag where the next command will automatically execute, you simply get a "You are not ready to do that." type of message and the command is otherwise ignored.

Most everyone seems to much prefer this system as opposed to the lag/stack/queue, so if you are in the process of addressing it, this might be another approach to consider.
23 Jul, 2012, Rarva.Riendf wrote in the 7th comment:
Votes: 0
Quote
There is no command queue, stack, or lag where the next command will automatically execute, you simply get a "You are not ready to do that." type of message and the command is otherwise ignored.

And what is exactly the difference except you show a message when you add a command that will not be executed right away ? (other than you removed a functionality in the process)
23 Jul, 2012, Runter wrote in the 8th comment:
Votes: 0
Rarva.Riendf said:
Quote
There is no command queue, stack, or lag where the next command will automatically execute, you simply get a "You are not ready to do that." type of message and the command is otherwise ignored.

And what is exactly the difference except you show a message when you add a command that will not be executed right away ? (other than you removed a functionality in the process)


I sort of agree. I find it really annoying to be 0.1 seconds off the cooldown of a skill and being told "You can't cast heal yet!" and dying. Much rather it queue it for the remaining 0.1 seconds and then cast it. I think it's a design problem if as a player I have to start spamming a command before it goes off cooldown so that I can hit the moment it's available.
23 Jul, 2012, Hades_Kane wrote in the 9th comment:
Votes: 0
Rarva.Riendf said:
Quote
There is no command queue, stack, or lag where the next command will automatically execute, you simply get a "You are not ready to do that." type of message and the command is otherwise ignored.

And what is exactly the difference except you show a message when you add a command that will not be executed right away ? (other than you removed a functionality in the process)


I think you misunderstand, you aren't adding a command, you attempt to use the command and you can't because you are already in your "wait state" for a previously executed command. Generally other than combat actions, a character is otherwise able to act as "normal" as though they weren't being limited by something they did in combat. There is no "lag".


Runter said:
I sort of agree. I find it really annoying to be 0.1 seconds off the cooldown of a skill and being told "You can't cast heal yet!" and dying. Much rather it queue it for the remaining 0.1 seconds and then cast it. I think it's a design problem if as a player I have to start spamming a command before it goes off cooldown so that I can hit the moment it's available.


It's also really annoying to lose track of how many times you've typed bash or a similar skill or command that carries with it a high lag timer and then being basically stuck in what you are doing until all the commands have executed, and being killed because something you typed 30 seconds ago is still waiting to be executed and you can't heal, flee, use a potion etc.

From a design point, I find the notion of using lag to enforce limits on actions to be sloppy and conducive toward lazy combat, and probably something that is largely used because "that's how it's always been." Since we made the change, it tends to cause players to pay more attention to what is going on in combat, has encouraged more active playing throughout an entire combat, and otherwise has made combat more engaging. On a stock ROM game, it's simple enough to type "bash bash bash 'cast heal' bash bash 'cast heal' bash" at the beginning of battle and switch to another window because you've effectively queued up an entire battle's worth of commands.

But aside from my own feelings about how it has improved the experience of combat on the game, it's been a very popular change among the players and one I would list as a selling point for the game overall.
23 Jul, 2012, Rarva.Riendf wrote in the 10th comment:
Votes: 0
Quote
It's also really annoying to lose track of how many times you've typed bash or a similar skill or command that carries with it a high lag timer and then being basically stuck in what you are doing until all the commands have executed, and being killed because something you typed 30 seconds ago is still waiting to be executed and you can't heal, flee, use a potion etc.

And the simplest solution is implemented: a command that can suspend the queue 'and even one to resume it !)
23 Jul, 2012, Runter wrote in the 11th comment:
Votes: 0
Quote
It's also really annoying to lose track of how many times you've typed bash or a similar skill or command that carries with it a high lag timer and then being basically stuck in what you are doing until all the commands have executed, and being killed because something you typed 30 seconds ago is still waiting to be executed and you can't heal, flee, use a potion etc.


You could have a sophisticated system that lets you have 1 item in the skill queue at a time. That addresses my concern, and lets you continue to force players to be attentive without actually having an interesting combat system that requires thought and tactics. It's a win win.
23 Jul, 2012, Kline wrote in the 12th comment:
Votes: 0
In one of my games I moved all combat-related skills onto cooldowns, offensive and defense. So you can do one offensive move and one defensive move at any given time, and each will set your cooldown depending on how strong/useful the skill is. Other skills in that category return the "not ready yet" type message. Spells are the exception to this.

Spells are "channeled" rather than the instant-fire spam with a lag/wait behind them. You "cast" which starts your casting timer and getting hit will cause spell knockback (to a maximum % of the original cast time, you can't knockback-lock a Mage forever). You can also get gear/abilities that increase casting speed. Once the casting time is up, the spell fires. Now, if this was a fireball directed at someone who has since left the room…Oops! Guess it missed. You can also interrupt your own cast to begin casting a new spell as needed, and casting also interrupts if you move rooms (although I may add skills/abilities to remove this temporarily as a buff). The fun part of this is since target checking is done when the casting completes, you can setup a preemptive cast against someone not even in the room yet, if you expect them relatively soon, and have it execute as well as a trap would. I don't remember if I made casting suspend your auto-attacks, I may have, but I can't remember. I'd have to go look.
24 Jul, 2012, Hades_Kane wrote in the 13th comment:
Votes: 0
Runter said:
Quote
It's also really annoying to lose track of how many times you've typed bash or a similar skill or command that carries with it a high lag timer and then being basically stuck in what you are doing until all the commands have executed, and being killed because something you typed 30 seconds ago is still waiting to be executed and you can't heal, flee, use a potion etc.


You could have a sophisticated system that lets you have 1 item in the skill queue at a time. That addresses my concern, and lets you continue to force players to be attentive without actually having an interesting combat system that requires thought and tactics. It's a win win.


There are plenty other things in our combat system that makes it interesting, engaging, and requiring thought and tactics, but when you can just queue up an entire combat's worth of commands and then go make a sandwich while your character does everything automatically, no amount of other interesting or engaging features is going to make that system any more appealing. Don't make assumptions about my game or our combat system.

As far as "a sophisticated system blah blah", more complicated doesn't always equal better. Why spend the time picking a lock when you can just use the key? I don't think having a combat command queue adds anything to the game, other than promoting a bit of laziness in combat as people don't have to rely on awareness, timing, or skill but can just rather -always- be one move ahead of where they currently are.

As I said before, I'm happy with the solution and it has been very highly regarded among our players… where is the problem here?




Kline said:
In one of my games I moved all combat-related skills onto cooldowns, offensive and defense. So you can do one offensive move and one defensive move at any given time, and each will set your cooldown depending on how strong/useful the skill is. Other skills in that category return the "not ready yet" type message. Spells are the exception to this.


Uh-oh! You don't have a command queue and attempts at using other skills are blocked? Someone else did it wrong too! :p


Kline said:
Spells are "channeled" rather than the instant-fire spam with a lag/wait behind them. You "cast" which starts your casting timer and getting hit will cause spell knockback (to a maximum % of the original cast time, you can't knockback-lock a Mage forever). You can also get gear/abilities that increase casting speed. Once the casting time is up, the spell fires. Now, if this was a fireball directed at someone who has since left the room…Oops! Guess it missed. You can also interrupt your own cast to begin casting a new spell as needed, and casting also interrupts if you move rooms (although I may add skills/abilities to remove this temporarily as a buff). The fun part of this is since target checking is done when the casting completes, you can setup a preemptive cast against someone not even in the room yet, if you expect them relatively soon, and have it execute as well as a trap would. I don't remember if I made casting suspend your auto-attacks, I may have, but I can't remember. I'd have to go look.


We've done a similar rewrite of the magic system. You type to cast a spell and your character then enters into a "casting" state, the length of time determined by the spell. During this casting state, your automated combat actions stop as your entire concentration is on casting. While in the casting state, there are numerous casting modification commands, such as brighten (which pumps more mana into the spell to increase the spell level), fade (which does the opposite), expand which speeds up the spell, truncate (which cancels the spell), target (which changes the target of the spell), among others. Casting a new spell while already in casting time will do one of a few things, including pausing the original to cast the new one, or even overlaying over the original spell to create a new one entirely. At the end of the casting time, the spell goes off and the character is then free to act immediately. Other actions (basically things not restricted by wait state) are fair game while casting, too.

This has been another change in the way we handle combat in the game that has been highly popular among the game (and there are several other ways the magic system has as much depth as a player is willing to put into it, from intricate levels of counterspelling, elemental affinities for everything in the game [including rooms], combination spells, hidden spells, etc).


A good bit of the mentality of the way we have built the game and combat is there is as much depth as the player may want to experience. If someone wants a simple, near stock like battle experience, there is nothing forcing them to use systems like magic (some classes don't even have access to any magic), nor are they forced to things like the limit breaks (customizeable skills that are usable when their limit meter is full [which has options as to what conditions cause this]), combination group technique skills that are executed by players in groups combining their individual skills into team attacks, more interactive and timed based skills like the blitzes, combat techniques such as defending, using tension or assault. If someone wants to just battle standing there hitting bash, more power to them, it's a valid play style and not everyone is looking for something complicated. In a PVP setting, they'd likely be very outmatched by someone who has taken the time to learn to combat system and all of the different ways it can be utilized, and the players who have chosen to do are definitely engaged and interactive throughout the battle. Likewise, someone can just 'cast fireball troll' and let the spell cast 6 seconds later, but those who really exercise the magic system for what it's built for can do so much more than that.

And a lot of that stuff was made possible by breaking away from the stock mentality of an all encompassing lag enforcing cooldowns on commands.
24 Jul, 2012, Runter wrote in the 14th comment:
Votes: 0
Quote
There are plenty other things in our combat system that makes it interesting, engaging, and requiring thought and tactics, but when you can just queue up an entire combat's worth of commands and then go make a sandwich while your character does everything automatically, no amount of other interesting or engaging features is going to make that system any more appealing. Don't make assumptions about my game or our combat system.


Well, I didn't really mean your combat system in specific. I'm referring to the proverbial "kick kick kick c heal kick kick kick" spam line to coffee. So if we're making the assumption that it's a problem and the change alleviates that, then there's other ways to do it without removing the feature and replacing a queue with no queue.

But as you just said, you think people could queue up an entire combat's worth of commands and go make a sandwich without the system. Why is that if you have a system that requires thought and tactics? No assumptions here. The only thing we know about your system is what you tell us.
24 Jul, 2012, quixadhal wrote in the 15th comment:
Votes: 0
Removing command queuing is silly, because just about everyone nowadays uses a client which can provide the same functionality.

/def usual = {
/repeat 3 kick%;%pause 1.5
c heal
/repeat 3 kick%;%pause 1.5
}

So now, you have the annoyance of wait states AND you don't have any protection from abuse.

It's not hard to just divide your command abilities up into various exclusive activities and put them in multiple queues.

cast 'fireball' fred
kick
kick
punch
inv
drink potion
kick
cast 'lightning bolt'
cast 'cure light;
kick

Perhaps melee attacks are one kind of activity, spell-casting a second which can be done while fighting, and eating/drinking a third which can't be done while casting.

So, you'd get a set of queues like:

melee: kick (1.0) kick (2.0) punch (3.0) kick (4.0) kick (5.0)
spells: fireball (0.0) lightning bolt (4.5) cure light (8.5)
consumption: quaff potion (3.0)
ooc: inventory (0.0)

In the above, I assume kick and punch both take 1 second to do, fireball takes 4.5 seconds to cast, lightning bolt takes 4 seconds, and that there's a global in-game action delay of 1 second. Further, OOC commands should have no delay, since they dont' affect the game mechanics.

So, at 0.0, "inventory" and "cast" are both up for grabs, do inventory first (ooc queue gets priority), then cast.
Nothing else is up until kick, then another kick, then you can quaff and punch at the same time, but not cast since you have to finish swallowing to speak… so lightning bolt gets pushed back for 1.5 seconds (assuming drinking takes 2 seconds).

You get the idea.

In any case, if your combat system is predictable enough to be able to queue more than a few commands ahead… you have bigger problems. :)
24 Jul, 2012, KaVir wrote in the 16th comment:
Votes: 0
quixadhal said:
Removing command queuing is silly, because just about everyone nowadays uses a client which can provide the same functionality.

If you shift the burden to the client then you end up with a situation like the IRE muds - technically "manual" combat, but in practice you need a client script in order to be competitive. End result: Automated combat with a high entry barrier for newbies.
24 Jul, 2012, Hades_Kane wrote in the 17th comment:
Votes: 0
Runter said:
But as you just said, you think people could queue up an entire combat's worth of commands and go make a sandwich without the system. Why is that if you have a system that requires thought and tactics? No assumptions here. The only thing we know about your system is what you tell us.


It was buried in my earlier rant, but combat is really as deep as the player chooses to have it. Someone can choose to just sit there and watch if they want, but compared to other players, it puts them at a disadvantage. I wouldn't say it requires it, but it certainly does highly encourage people taking advantage of the features available to them.


quixadhal said:
Removing command queuing is silly, because just about everyone nowadays uses a client which can provide the same functionality.


By this logic, it could be argued that you may as well have MUD-side triggers, mapping, or support for botting. Just because someone can use external programs to make the game play different doesn't convince me that a game should make design decisions based around what the player's clients can do (not counting the graphical protocols and stuff like that).

Quote
So now, you have the annoyance of wait states AND you don't have any protection from abuse.


Again, I repeat, this has been a change highly regarded among the players. So, where is the annoyance?

Quote
In any case, if your combat system is predictable enough to be able to queue more than a few commands ahead… you have bigger problems. :)


That's probably 90% or more DIKU based games out there, unfortunately, but I wouldn't count mine among those.


KaVir said:
quixadhal said:
Removing command queuing is silly, because just about everyone nowadays uses a client which can provide the same functionality.

If you shift the burden to the client then you end up with a situation like the IRE muds - technically "manual" combat, but in practice you need a client script in order to be competitive. End result: Automated combat with a high entry barrier for newbies.


The concern over high entry barrier is one reason, too, that the way our combat is setup to allow as simple or as deep as a player may want. Someone used to regular diku style combat will find notable differences, but it won't be so alien of an experience they will feel lost or immediately chased away (of course, some people are sticklers to what they want, and we are different enough where some purists will probably leave mid-way through their first battle). As a person progresses through the game, gains access to more skills, and overall just gets more familiar with what the combat system offers, the vast majority chooses to take advantage of what is there. Using defend, tension, assault, the magic system, blitzes, limit breaks, etc. are not at all mandatory or required, especially in the beginning, so players do have that opportunity to learn and experience at their own pace. Not alienating those used to typical Diku style combat, but providing enough depth and options in combat to make for an (optionally) much deeper and engaging system of combat for those who want more, this was all by design.

Also on the note of entry barrier for newbies… I can't count the number of times on games I was unfamiliar with, I did lose track of what commands I had going and ending up dying because I couldn't heal, recall, or flee because I still had like 20 seconds left of other commands to finish going off. Or how many times I was in combat with a single tough mob and another group of aggro mobs or even other players would come into the room and attack, and rather than being able to flee or take whatever other necessary actions, I'm locked into other command(s). Incidences of newbie deaths have also seemed to have been eased with the change to wait state.

As far as scripting with the removal of a command queue, I really think the "advantage" of that, as far as earlier examples of typing 'c heal' a second too late, would really be negligible. People tend to be pretty quick about hitting those commands they need when they are ready to act. People take to being a bit more careful about some choices in combat, too, holding off from entering a wait state until certain circumstances as well. Sure, it could be programmed to trigger off of coming out of the wait state, but I don't think that's anymore likely or useful than on other games were people will use timers to execute commands or whatnot based off of the lag of those skills.



Honestly, other than the fact that "this is how it's always been done" I don't see what the big hang-up on command queuing is. It works really well within the context of how our game systems work and has been received as a positive change for the game overall, so what's the issue?
24 Jul, 2012, KaVir wrote in the 18th comment:
Votes: 0
Hades_Kane said:
KaVir said:
quixadhal said:
Removing command queuing is silly, because just about everyone nowadays uses a client which can provide the same functionality.

If you shift the burden to the client then you end up with a situation like the IRE muds - technically "manual" combat, but in practice you need a client script in order to be competitive. End result: Automated combat with a high entry barrier for newbies.


The concern over high entry barrier is one reason, too, that the way our combat is setup to allow as simple or as deep as a player may want.

I meant that by not supporting command queuing, they effectively make client-side scripts a requirement for competitive play - and because the script needs to know which commands to execute, the player ends up with a de facto automated combat system, just one with a higher entry barrier.

This is less of an issue for a non-PK mud. It's also less of an issue if the combat system is already primarily automated, as is the case with most muds.

Hades_Kane said:
Also on the note of entry barrier for newbies… I can't count the number of times on games I was unfamiliar with, I did lose track of what commands I had going and ending up dying because I couldn't heal, recall, or flee because I still had like 20 seconds left of other commands to finish going off. Or how many times I was in combat with a single tough mob and another group of aggro mobs or even other players would come into the room and attack, and rather than being able to flee or take whatever other necessary actions, I'm locked into other command(s).

That isn't a problem of queuing, but of WAIT_STATE. I allow combat commands to be queued - but players can clear their queues at will, or push high-priority commands to the front of their queues. They can also independently perform other actions, including fleeing, while continuing to execute queued attacks.
24 Jul, 2012, Runter wrote in the 19th comment:
Votes: 0
Quote
As far as scripting with the removal of a command queue, I really think the "advantage" of that, as far as earlier examples of typing 'c heal' a second too late, would really be negligible.


Actually, the point was that accidentally entering slightly too soon is the problem. Because for a player like myself that may not use a fancy client or scripts, that means having to retype the command completely if it was slightly too soon. And dying, cursing the system, and leaving the game. Anecdotes about what your current players like isn't really saying much.

In this situation, someone smart would build basically a client side interface all on their own that would circumvent your system completely. For example, I might queue up attacks and send them one at a time when I get stimuli from the server. Assuming it has a message like "You can attack again." or some such, it would be more effective than human players. If you don't have such a message then I'd rely on timers to do it, which would give me even a bigger edge over real players since they have to guess and often times cast too late or too soon. Both of which are bad, too soon being even worse. In any event, it starts becoming too advantageous to automate stuff your server should be doing for everyone.
25 Jul, 2012, Rarva.Riendf wrote in the 20th comment:
Votes: 0
Quote
By this logic, it could be argued that you may as well have MUD-side triggers, mapping, or support for botting.

Triggers is to repeat uninteresting thing to be done.
I thought at one time to include trigger in the engine..finally I had a better idea…remove the REASON to have triggers in the first place.
mapping:yes I added it cause it is a pain in the ass to configure your client to do it.
botting:same than for trigger, if people bot is to avoid to keep doing uninteresting and repeatitive actions. (ie:genrally, leveling)

But removing the queue because you did not add a way to kill it (basic rom as a ! command that repeat the last command, in mine !! will just kill the queue, and resume will allow to well obviously resume it) is pretty much WTF
Example of why it is useful: when you speewalk, if you are interrupted because you needed a boat or fly spell wore off while in the middle of the sea, or an aggressive mob engage fight, you can kill the mob, then type resume and keep going.. (actually I kill the queue by code in those case)
or you launched a spellup with many spells, but want to sto pit for whatever reason: kill the queue, tada, do your thing, and get back to it !
The fact that your players well received it pretty much say they are too dumb to use a client.
0.0/46