So when I hit my macro to walk from area A to area B, it won't work? Sounds like it'll cause a lot of problems. :P
--- Sarix <[EMAIL PROTECTED]> wrote: > 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 > === message truncated === ===== -Matt Foltz [Neoterra MUD] telnet://neoterra.is-a-geek.com:4000 [Car Audio Resources homepage] http://www.car-audio.net __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
