Ok so question, do display this. You'll have to put something where the wait state is skiping past you yes? Now the only problem with this, is you'll need to clear the incoming buffer on the person. Or if they type one thing 4 times every second (standard stock rom pulse) they will get a message saying that.
Now if you clear there message they have to retype what ever it was they typed. Sounds like a good idea, but to me that would personaly drive me nutz. ----- Original Message ----- From: "Jed Yang" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Sunday, November 02, 2003 8:55 AM Subject: Re: ROM and WAIT_STATEs > 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 > > > -- > ROM mailing list > [email protected] > http://www.rom.org/cgi-bin/mailman/listinfo/rom >
