I think he was refering not to a real lag. Normally, when we cast a spell, we cannot type anything for the next few seconds because of `wait' in effect. It will look like the mud is not responding at all and looks like a lag. He wants to make it so even when we can not legally do more actions during the wait time, the mud will respond with ``You still need to wait xxx seconds.'' I think that was what he meant.
Htam ----- Original Message ----- From: "Chris "Winston" Litchfield" <[EMAIL PROTECTED]> To: <[email protected]> Sent: 2003.11.02 07:17 Subject: Re: ROM and WAIT_STATEs > Exactly what lag are you refering to here? by preventing input for a round? > A round is mighty fast and not really noticable. > > Lesse.. most I had on simultanously was 65 and no lag due to wait. Now.. > lag I have I trace per command.. COMMANDS have way more lag than the battle > system. > > Chris "Winston" Litchfield > ----- Original Message ----- > From: "George Whiteside" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Saturday, November 01, 2003 1:26 PM > Subject: ROM and WAIT_STATEs > > > > As much as I like the ROM codebase, there are naturally goods and bads > > associated with it. One of those bad things, to me, is the implementation > of > > the ch->wait feature. It basically causes a game client's input to lag by > X > > amount of game pulses. On my MUD, everything is very round-orientated. The > > old combat system is long dead, (good riddance), and most complex actions > > incur a round time, usually a few seconds, depending. The point is, it's > > irritating to just use WAIT_STATE and have a player lagging until the > round > > time passes, wondering whether the problem is his connection or not. > There's > > a very simple fix. You can move the ch->wait check to after the command > > interpreter, and in the actual interpreter, add a few lines telling the > > character something to the effect of "Wait X more seconds." Like so: > > > > In comm.c - void game_loop_unix: > > > > + if (d->character != NULL && d->character->daze > 0) > > + --d->character->daze; > > + > > - if ( d->character != NULL && d->character->wait > 0 ) > > - { > > - --d->character->wait; > > - continue; > > - } > > + > > + read_from_buffer( d ); > > + if ( d->incomm[0] != '\0' ) > > + { > > + d->fcommand = TRUE; > > + stop_idling( d->character ); > > > > Cut out the character->wait if statement, and paste it approximately 20 > > lines down: > > > > + d->incomm[0] = '\0'; > > + } > > + > > & if ( d->character != NULL && d->character->wait > 0 ) > > & { > > & --d->character->wait; > > & continue; > > & } > > + } // Make sure it's BEFORE this bracket. > > + > > + /* > > + * Autonomous game motion. > > + */ > > + update_handler( ); > > > > Now the command interpreter gets a pass before waiting. > > > > Okay, in interp.c - void interpret: > > > > Put a 'char buf[MAX_STRING_LENGTH];' in the variables at the top right > away > > if you're going to use sprintf. > > > > Add the following near the bottom of the function: > > > > + return; > > + } > > + > > & if( ch->wait > 0 ) > > & { > > & if( ch->wait > PULSE_PER_SECOND ) > > & { > > & sprintf( buf, "Wait %d more seconds.\n\r", (ch->wait / > > PULSE_PER_SECOND)+1 ); > > & send_to_char( buf, ch ); > > & } > > & else > > & { > > & send_to_char( "Wait 1 more second.\n\r", ch ); > > & } > > & return; > > & } > > + > > + /* > > + * Dispatch the command. > > + */ > > + (*cmd_table[cmd].do_fun) ( ch, argument ); > > > > That should just about do it, I hope. I've never tested my MUD large > scale, > > (read: more than 3 simultaneous players) and I'm not sure I havn't > forgotten > > more of the code, so your mileage may vary. I think those were the only > > pertinent changes, however. Enjoy! > > > > decaheximal ([EMAIL PROTECTED]) > > > > --- > > [This E-mail scanned for viruses by Declude Virus] > > > > > > -- > > ROM mailing list > > [email protected] > > http://www.rom.org/cgi-bin/mailman/listinfo/rom > > > > > > > > -- > ROM mailing list > [email protected] > http://www.rom.org/cgi-bin/mailman/listinfo/rom
