Why is my speedwalk going backwards.

Posted by Robert Powell on Sun 10 Feb 2008 05:21 AM — 7 posts, 24,590 views.

Robert Powell Australia Sun 10 Feb 2008 05:21 AM #0

I have this code which is for an ingame speedwalk, trouble is i now noticed that it goes backwards through the string and not forwards, is this due to changes in gcc4x. Anyways im not sure why its going backwards now when it used to go forwards, anyone see anything obvious thats wrong.


void do_speedwalk( CHAR_DATA * ch, char *argument )
{
   char buf[MSL];
   char arg[MIL];
   char *direction;
   bool found = FALSE;


   if( !ch->desc || NULLSTR( argument ) )
   {
      send_to_char( "You must include directions.  Read help speedwalk for more information.", ch );
      return;
   }

   buf[0] = '\0';

   while( *argument != '\0' )
   {
      argument = one_argument( argument, arg );
      strcat( buf, arg );
   }

   send_to_char( "You start to walk...", ch );


   for( direction = buf + strlen( buf ) - 1; direction >= buf; direction-- )
   {
      if( !isdigit( *direction ) )
      {

         switch ( *direction )
         {
            case 'N':
            case 'n':
               //removed for clarity sake.
            default:
               send_to_char( "Invalid direction!", ch );
               return;
         }
      }

   }
   return;
}

David Haley USA Sun 10 Feb 2008 05:31 AM #1

Umm...

for( direction = buf + strlen( buf ) - 1; direction >= buf; direction-- )

Doesn't this for loop mean it's counting from the end, instead of from the beginning? :-)

By the way, doesn't this have potential for abuse? If you treat the speedwalk as an instant series of commands, a player can't get "caught" in a room by another player, because the MUD is busily zooming that player around. It also seems like a great way to basically instantly traverse the world if only you have directions to do so. :) And if rooms have movement delays, then you also wouldn't be able to take those into account unless you're doing something fancy you're not showing here.

Nick Gammon Australia Forum Administrator Sun 10 Feb 2008 05:31 AM #2

I would be very surprised if you told me it is going forwards.

In the for loop you start at the end of the string, and then do "direction--" (which is subtracting one each time) until you reach the start of the string.

Nick Gammon Australia Forum Administrator Sun 10 Feb 2008 05:32 AM #3

Hello David, I see we replied in the exact same minute. :)

David Haley USA Sun 10 Feb 2008 05:37 AM #4

Indeed! But it appears that I beat you by just a few seconds. :-) Looks like you posted as I was editing my post.

Robert Powell Australia Mon 11 Feb 2008 08:09 PM #5

Quote:

By the way, doesn't this have potential for abuse? If you treat the speedwalk as an instant series of commands, a player can't get "caught" in a room by another player, because the MUD is busily zooming that player around. It also seems like a great way to basically instantly traverse the world if only you have directions to do so. :) And if rooms have movement delays, then you also wouldn't be able to take those into account unless you're doing something fancy you're not showing here.

Is it really any different to say Mushclients or Zmuds abilities to make speedwalks? My game is not Pk orientated so being caught by Pc's is not an issue, and the way the game plays, its not much of a bother with agro Nps's either.

With movement delays, why wouldnt those be processed, when you type north into your client, it calls move_char which is where the delay processing takes place. Not that i have tested it on my overland where there is some delays on sector types, but give me a min and i will test it now and see.

David Haley USA Mon 11 Feb 2008 10:07 PM #6

Quote:
Is it really any different to say Mushclients or Zmuds abilities to make speedwalks? My game is not Pk orientated so being caught by Pc's is not an issue, and the way the game plays, its not much of a bother with agro Nps's either.

The difference is that a client's speedwalk will be treated as a series of commands, each processed by the interpreter loop one at a time (and therefore with potential for MUD-enforced delay) whereas a single command that does it all will do it all instantly unless you introduce delay... but see below.

Aggressive NPCs would probably stop the player since I believe those are triggered on room entry, so it would happen during a move_char call. Of course, then you'd have a whole bunch of move_char calls that would fail.

Quote:
With movement delays, why wouldnt those be processed, when you type north into your client, it calls move_char which is where the delay processing takes place. Not that i have tested it on my overland where there is some delays on sector types, but give me a min and i will test it now and see.

Yes, but the delay is introduced on a per-character basis and prevents the incoming data from being treated until some amount of time has gone by. However, in this scenario, the delay will be accumulated over the whole speedwalk, and will not intervene in between each step. So, the end result will be an "instant" travel across the world, followed by the accumulated lag for that whole travel.

If however you delay in between each step, you will be pausing the whole MUD at once unless you have some kind of scheduling going on, which you probably don't unless you're using a rather modified codebase.