"Bash and trip lag both the victim and the attacker exactly 2 rounds, it's not "1.9". Why am I so sure?

It's easy to prove: get tripped, and enter a command that isn't flee. Your command goes through EXACTLY at the same moment as the other guy's next one; they are, by the internal timing resolution of the game, simultaneous. It's just guaranteed that your command is processed before the tripper's, by some voodoo that I can't be bothered to research from the implementation of WAIT_STATEs in the ROM code.

There are of course other situations that lag you for a non-integer number of rounds, like a missed trip... this is why it sometimes looks like 1, sometimes 2, depending on which pulse you entered it.

Lagging moves in general OVERWRITE existing lag if it's smaller (so if you got tripped, a round passed, and another guy tripped you, your lag would be set from 1 to 2), but cheap shot just tags on a few extra pulses. This is why trip + cheapshot is guaranteed (harmonious or other lag-reducing special conditions notwithstanding) to permalag if both land; bash and cheap shot are NOT, because bash can still be 1 round and the extra pulses don't really help much there."

How much of this is correct? From a discussion on Dio's.

Since you brought it up and adamantly disagreed I have actually been researching the ROM code and its wait_states (I've absolutely nothing to do at work today) and I still can't pinpoint the voodoo, though the lag count for trip etc. are exactly the same for both attacker and victim. I'm not saying this means it's the case on CF, but since the output of combat on CF and on this POSmud looks identical, I'd rather assume the basic mechanics are the same too.

On a side note, I really, really pity Zulg and Nep now, having tried to figure out those parts of the code... sweet Jesus, it could be written in brain#### and make more sense sometimes.

It's quite simple really.

1) Characters are always parsed in the same order each pulse

2) Lag is decremented first, then commands are read (if lag = 0)

This post doesn't directly address trip, but it contains a bit of explanation that can be extrapolated.

http://www.qhcf.net/phorum/read.php?3,823074,823668#msg-823668

There must be something else going on, or else the tripper would sometimes get next command if his character happened to come first in the parse order.

If I remember correctly (and it's been a looooong time since I've mucked around in the guts of any of this), essentially, characters get their wait decremented when they come up in the parse order.

So even if you're first and you trip me, I still get my wait reduced on that pass through and you don't, so I'll still get a command just before you do.

Yeah, I spent my entire workday analyzing the mess and with the standard CF != POS disclaimer, it goes like this:
for each descriptor (for the uninitiated: descriptor is the connection point between you, the player, and your character) the wait state is checked. If it's higher than 0, it's decremented and nothing else happens. If it's 0, commands are parsed. The only thing that keeps warping my mind is this situation...

Let's say the descriptor list goes
1) Marcus
2) Mort
3 to N) other guys

On his input pulse, Marcus trips Mort, getting 24 pulses of lag. Mort also gets 24 pulses. Now, this particular pulse isn't over, so Mort's wait state gets processed and drops to 23, and then other guys are handled. This happens over and over until Marcus is at 1, and Mort is at 0. This means Mort gets to go first: then how come the commands still appear to go through at the same moment if it doesn't break combat, without a visible "pulse boundary" in between them? I sure haven't ever noticed one, and I refuse to believe I've always been the one first on the desc. list. Maybe I'm just thinking too hard about this.

Also the end result of the above combat, regardless of player order, is most likely Mort typing sta;n;w;w;s;s;s;get all corpse.

Maybe it's not possible to tell from a player's POV the difference between "commands processed in the same pulse" and "A processed at pulse N and B processed at pulse N+1".

Alternately: some of the time (i.e. when the tripper is "last" in the parse order) the next commands really WILL go through on the same pulse (assuming neither command lags on the other character):

Order is:

1) Mort
2) Marcus

Marcus trips Mort. Both now have 24 pulses of lag. Both characters input another command. 24 pulses go by, and both have 0 pulses lag on them. Mort's command goes through first since he's ahead of Marcus in the parse order, then Marcus's command goes through as well on the same pulse.

>> Maybe it's not possible to tell from a player's POV the difference between "commands processed in the same pulse" and "A processed at pulse N and B processed at pulse N+1".

You can tell this. If there is a prompt between the commands they were processed at different pulses, otherwise not.

I.e.

Mort has fled!
They aren't here.
<prompt>

Means they were processed on the same pulse, i.e. Mort is before Marcus on the descriptor list.

Mort has fled!
<prompt>
They aren't here.

Means the commands were proecssed on different pulses.

Which of the two scenarios above that will happen can be predicted by looking at the who list. (edit: disclaimer: this might have changed recently with the reversal of the who list order)

>Mort has fled!
>They aren't here.
><prompt>
>
>Means they were processed on the same pulse, i.e. Mort is
>before Marcus on the descriptor list.

Since Mort is first in the descriptor list, his attacks are processed first. The combat round would be like

Mort's pierce MANGLES you.
Mort's pierce MANGLES you.
Your bludgeoning MANGLES Mort.
Your bludgeoning MANGLES Mort.


>Mort has fled!
><prompt>
>They aren't here.
>
>Means the commands were proecssed on different pulses.

Now you are first on descriptor list. The combat round becomes

Your bludgeoning MANGLES Mort.
Your bludgeoning MANGLES Mort.
Mort's pierce MANGLES you.
Mort's pierce MANGLES you.

>Which of the two scenarios above that will happen can be
>predicted by looking at the who list. (edit: disclaimer: this
>might have changed recently with the reversal of the who list
>order)

The only difference is that the chars that logged in first stay on top of the descriptor list instead of bottom. The system should work like it used to do otherwise, meaning that the guy on top of the who list still gets his commands and attacks in first.

The order of attacks are not determined by the descriptor list, but rather another pointer list that includes mobs as well.. (char list)

The order of the char list is defined by who logged in first (or in the case of mobs, when the mob was created). The order of the descriptor list is depeonds on when you connected to the mud (so reconnecting will reset your descriptorlist position)

NT

,

I concede this battlefield!