I wasn't really thinking about macro's or scripts. I was thinking more along the lines of communication. Anyone here ever been fighting something and holding a conversation. Be a pain in the backside if the mud was just dropping most of your commands, cause of the wait states.
----- Original Message ----- From: "Matt Foltz" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Sunday, November 02, 2003 2:54 PM Subject: Re: ROM and WAIT_STATEs > 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/ > > -- > ROM mailing list > [email protected] > http://www.rom.org/cgi-bin/mailman/listinfo/rom >
