The Truth Behind Wimpy and Trip

This blog post has two parts.  The first part is a rant, and the other part is a little more relevant.  If you're interested in just reading the detailed technical info, just scroll down past the rant.

Rant / Background Info

Back in April of this year, a small bugfix went in to address a problem with wimpy.  For some reason, a number of players read this change and assumed that the fact that wimpy can kick in when tripped was something new that we had added as a part of that change.  The truth of the matter was that trip always triggered wimpy, and the only thing that we had changed was the need to type "stand" after having wimpy-fled from being tripped.  The lag on both the tripper and the person being tripped remained the same, the damages were the same, and the fact that wimpy could be activated by the trip skill itself remained the same.

Despite this fact that we did not change anything, a number of players insisted that this wimpying on trip was something new and made a big stink about it.  Again, I emphasized that it was not new, but some people refused to believe it, either claiming that (a) they knew more about what I changed in the code than I did, or (b) I was purposely lying to them for some nefarious reason.  Both accusations were leveled at me directly (that is, at least one player literally called me a liar on OOC).

This bothered me more than usual because it's a gross mischaracterization of the admin staff, and it reeks of a total lack of understanding of how the admin staff runs Dark Risings.  We don't typically change major aspects of PK on a whim, try to sneak it into a bug fix, then lie about it.  In fact, literally every significant (and even almost every minor) change to PK we have made has been vetted by players, either by inviting select PKers to participate in closed testing or by hosting an open Hell Night.  That's just not how we operate, and I've written about our approach to implementation before.

In the next section, I'll walk through the code and explain exactly what is going on when someone wimpys out due to being tripped, and exactly what I changed in April that got everyone so convinced that we screwed up wimpy+trip.

Detailed Technical Info

I think a large reason people don't understand/believe what I did and did not change in April is that they don't fully understand how trip works.  To the casual player, the trip command does these things:

1. sends messages saying "So-and-so trips you and you go down!"
2. does a little damage ("So-and-so's trip scratches you.")
3. sets you to the sprawled position so you have to stand up before you can do other stuff

and they all happen at once.  You successfully trip someone, and they're on the ground instantaneously.  This isn't an unreasonable assessment, but the truth is that they don't all happen at once.  In fact, computers really can't do two things at once**; they take an instruction to do something, then they do it, then they take the next instruction, do it, and so on.  The reason it seems to happen all at once is because computers do this VERY quickly--our server's 3.2GHz processors can carry out 3.2 billion instructions per second**, or over three instructions every nanosecond.  To put that into perspective, in the time it takes you to blink your eye (~300ms), Dark Risings knocks out a billion instructions...so it's all effectively instantaneous to the player.

However, let's look at the code for the trip command from August 26, 2006, which predates the changes I made in April 2011 by a good many years:

1. act("$n trips you and you go down!",ch,NULL,victim,TO_VICT);
2. act("You trip $N and $N goes down!",ch,NULL,victim,TO_CHAR);
3. act("$n trips $N, sending $M to the ground.",ch,NULL,victim,TO_NOTVICT);
4. check_improve(ch, gsn_trip, TRUE, 1);
5.  
6. WAIT_STATE(victim, PULSE_VIOLENCE*2);
7. WAIT_STATE(ch, PULSE_VIOLENCE*2+4);
8. damage(ch, victim, number_range(2, 2 + 2 * victim->size), gsn_trip,
9.    DAM_BASH, TRUE);
10.  
11. if ( victim->position != POS_DEAD && victim->position != POS_UNCONCIOUS )
12.     victim->position = POS_SPRAWLED;

To translate a little, here's what's going on:

• Lines 1-3 are the messages that get sent to the person getting tripped (called victim), the person doing the tripping (called ch), and the rest of the room
• Line 4 is the check to see if your trip skill% should go up
• Line 6 is what puts the trip lag on the person getting tripped (victim).  It says PULSE_VIOLENCE*2, which means two rounds of combat, or six seconds.
• Line 7 is what puts the trip lag on the person using trip (ch).  PULSE_VIOLENCE*2+4 means six seconds (PULSE_VIOLENCE*2) plus another full second, so a total of seven seconds of lag, or one more second of lag than the victim.
• Line 8-9 is what does the damage from trip.  The messages ("Your trip scratches so-and-so.") is generated within this damage() routine, which is why they don't appear here.
• the first parameter, ch, indicates who is dealing the damage
• the second parameter, victim, indicates who should receive it
• the third parameter, number_range(2, 2+2*victim->size), is the amount of damage that should be done before sanc/ward/resists/etc.  In this case, it's doing a random amount of damage between 2 and 2+2*(the size of your race)..it's not much.
• the fourth parameter, gsn_trip, indicates the damnoun for the damage (in this case, it'll show up as "Your trip scratches ...")
• the fifth parameter, DAM_BASH, indicates the damage type of the damage.  Since it's DAM_BASH here, it'll do bash-type damage.  If it were DAM_HOLY, it'd do holy damage; DAM_ACID would do acid damage, and so on.
• the sixth parameter, TRUE, just indicates if the damage message ("Your trip scratches ...") should be sent out at all.  If this were set to FALSE, you'd take damage but it would be silent (like how dirt kick is).
• Line 11 is a bugfix that was added back in 2000.  More on this below.
• Line 12 is what puts the victim on the ground instead of in the regular fighting position

The next question is, where does wimpy factor into this?

As it turns out, a lot of functionality is wrapped up in the damage() routine (Line 8), and wimpy is a part of this.  When you trip someone and the game gets to executing Line 8 in the code, lines 11 and 12 don't get executed until the damage() routine is fully complete.  Here's what's going on in damage(), in no particular order:

• the effects of sanctuary are applied
• a check is made to see if the damage should hit a mirror image
• hp is subtracted from the victim
• if the victim's resulting hp falls below 1, either knock them out or kill them (depending on whether ch is a player or a mob)
• if the victim's resulting hp falls below their wimpy, make them flee

That last bullet point is the killer here.  Keeping in mind that computers can only do one thing at a time, here's what's happening with the trip command:

1. Everyone gets sent the appropriate "trips you and you go down!" message (lines 1-3)
2. ch's trip skill might improve (line 4)
3. both parties get lagged (lines 6-7)
4. damage is dealt to victim (line 8-9)
• if this damage drops victim's hp below his wimpy, he flees at this point 
• if this damage drops victim's hp below 1, he is knocked out at this point
5. victim is tossed on the ground AFTER the damage() routine completes

So what's happening is that, since the instruction to actually knock the victim to the ground comes after the damage is dealt, the victim will have already fled (due to damage()) before the trip code ever gets to the point where the victim gets sprawled.  Thus, this old code from 2006 was making people sprawled out even though they had already wimpy-fled from the room.

Line 11 above is a special check that was added in 2000 to prevent a similar problem.  Before it was added, some PKers had found out that if you manage to KO someone using a knockdown, they would get set to the unconscious position by damage(), but then immediately get woken back up when the rest of the trip code finished and set the person to the sprawled position.  Thus, they didn't have to wait the 45 seconds before they recovered from the KO; they could immediately stand up (after their PULSE_VIOLENCE*2 lag from trip) and run away before anyone could loot them.  What Line 11 does is only set the person's sprawled position if they weren't rendered (!= means "not equal") dead or unconscious as a result of the damage() routine immediately preceding it.

So, there you have it.  Code from 2006 showing that, due to the order in which damage is dealt relative to the instruction to sprawl out the victim, it is possible to wimpy out due to the damage from trip.  Sort of.

As Sintar pointed out (and much to my embarrassment), you can wimpy out of a fight even if you're sprawled.  Initially I said this was impossible because wimpy just issues the "flee" command automatically for the player, and the "flee" command can only be used by the player if his character is fighting, not sprawled.  Go get bashed by a mob and type "flee."  You'll see what I mean.

So how can Sintar get bashed by Heimdall, stay on the ground, and still wimpy out?  Well, let's look at the wimpy code in the damage() routine, which happens to be at the very end of it:

1. if ( !IS_NPC(victim)
2. &&   victim->hit > 0
3. &&   victim->hit <= victim->wimpy
4. &&   victim->wait < PULSE_VIOLENCE / 2 )
5.    do_flee( victim, "" );

with a brief translation:

• if the victim is not an NPC (that is, they are a PC, or a player character)... (line 1)
• AND the victim's hp is above zero (they aren't KO'ed or dead yet)... (line 2)
• AND the victim's hp is less than or equal to their wimpy setting... (line 3)
• AND their current lag is less than PULSE_VIOLENCE/2... (line 4)
• then execute the "flee" command directly, bypassing all the regular checks to make sure the person is standing, of the appropriate level to use the command, etc. (line 5)

The reason Sintar's wimpy lets him use the flee command is a bit hard to explain; in essence, the part of the code that takes whatever command you type (e.g., "flee") and translates that into a command that the game understands (e.g., do_flee()) is what imposes the restrictions on whether or not you have to be standing to use a command.  Wimpy bypasses that command interpreter entirely, so there's no position check.

So does this mean that you will always wimpy flee if sprawled out in PK?

Not quite.

Line 4 is the key here; although wimpy can make you flee regardless of if you're sprawled, Line 4 says that wimpy won't work unless you've got less than PULSE_VIOLENCE/2, or 1.5 seconds, worth of lag left.  Since trip gives the victim 6 seconds of lag, this guarantees that, as long as the trip damage itself doesn't cause wimpy

CRAP

The trip damage shouldn't ever cause wimpy to fire, because the lag is applied before the damage() (and therefore the wimpy code) gets run.  So, by the time the trip damage is dealt, the victim already has the 6 seconds of lag.  Line 4 will always cause wimpy to fail both when damage() is called by the trip command and for the first 4.5 seconds of lag caused by trip, which translates to a guaranteed minimum of one round of combat before the victim has a chance to flee-while-sprawled.

So why does the damage caused by trip cause the victim to wimpy out?

Because in the change I made back in April, I moved the WAIT_STATE lines in trip (and bash, entangle, armthrow, et cetera) below the damage() line:

1. act("$n trips you and you go down!",ch,NULL,victim,TO_VICT);
2. act("You trip $N and $N goes down!",ch,NULL,victim,TO_CHAR);
3. act("$n trips $N, sending $M to the ground.",ch,NULL,victim,TO_NOTVICT);
4. check_improve(ch,gsn_trip,TRUE,1);
5.  
6. damage(ch,victim,number_range(2, 2 +  2 * victim->size),gsn_trip,
7.     DAM_BASH,TRUE);
8.  
9. WAIT_STATE(victim,PULSE_VIOLENCE*2);
10. WAIT_STATE(ch,PULSE_VIOLENCE*2+4);
11.  
12. /* damage() can cause wimpy which changes victim->in_room */
13. if (victim->position > POS_FLATFOOTED && victim->in_room == ch->in_room)
14.     victim->position = POS_SPRAWLED;

Remembering that computers execute commands in-order**, this means that when the damage from trip is dealt, the victim hasn't been lagged by trip yet.  So, wimpy will kick in as long as the victim doesn't have more than 1.5 seconds of lagged already queued up from some other source.

Thus, contrary to the big long tirades I've gone on explaining how we never changed anything, we (that is, I) inadvertently did change (and break) wimpying from trip.  While it was true that it was always possible to wimpy out from being tripped, trip used to guarantee you 4.5 seconds of combat (at least one round) before your opponent could wimpy out.

Now there is a question of what we should do about this; the majority of players seem to agree that wimpy is fine as-is, but its as-is state is really the result of a bug.  If I'm lucky, I will have put everyone to sleep before they read this far down the post, and nobody will ever become aware of my serious folly here.  Realistically though, my inadvertent breakage of wimpy/trip (and subsequent ardent denial of doing such a thing) was not fair to the players, so it should be "fixed" and functionally restored to the way it used to be.  It was a reasonably fair way of doing it, too; people could still wimpy out of being tripped, but tagging with trip guaranteed you a round of combat to dish out damage before that happened.  The subsequent lag was still in the wimp's favor (6 seconds vs. 7 seconds) which is how it remains; the tripper just had a chance at knocking his enemy out with that one round before the wimp could take off again.

Blearg, I hate being wrong, and I hate more when I've been a jerk in the process of being wrong.  Maybe I should take a page from Nixon's book and just destroy all the evidence before word gets out.

** Note: these statements aren't really true, but they are close enough to the truth to illustrate my point.