On Wed, 30 Oct 1996, Chi Hoai Tran wrote: > Okies, here is the continuing chapters of my cookbook. > > METHOD :- > 1/ Again, save the char with all the eq you want to dupe, then transfer > all that eq to a new char and save the new char. > Buy thousands of breads (I'm sure you can afford it since they are cheap) > and drop them on the ground. Type look, and if you get the warning :- > *** OVERFLOW ERROR *** then you are getting close to the mark. > Now buy MORE breads until you think you have enough *grin* > Alias the following :- > alias tt look; look; look; look; look; look > and now, using a mud client, have several chars in the same room and > type #all #100 tt > This should lag the mud tremendously, especially if you have more chars > in the same room, and if you lag it enough, it autokills. First of all, you'd have to have a really nice link to keep your client from dying from the overloaded input with all that looking. Doesn't matter if you try to make tintin or whatever 'ignore' the input, it's still gonna be sent by the mud and your client needs to handle it. The only time I've seen anyone keep their link when they get enough input from the mud to cause an overflow is when they are on the actual machine. Let's assume however that they have a speedy link like that. The mud is gonna run through the list of descriptors, read all the input and attempt to process it. Theoretically you could probably make it spend so much time processing this input that the 5 minutes or whatever the alarm is set at gets called and the mud dies. > SOLUTION :- > 1/ Code multiple objects so it will show [2000] breads - this will > prevent overflowing the buf. Dont ask me for a patch, I hate doing > patches (well, actually, I dont know much about the diff command), but > I heard there is a patch on the snippet, so find it there I guess. > Basically, The Dark Realms coders use original code. That'll help keep you from getting overflows, but the weakness is caused by a more fundamental problem. > > 2/ As previously suggested, prevent the same command going through, but > there is a weakness to that...what if the alias is actually > alias tt look;bounce;look;bounce;look > Then your checks for the same command doesnt really work?? > Anyways, I have my own system BUT please do not ask me how I did it > because I do not want anyone else to know about it just in case they > find out a way to circumvent it (which, fortunately, the crashers have > been unable to do). Don't think that's a good solution. The problem is that imps want the players to be happy, and a larger number of players out there are using clients like tintin and Zmud--at least much more than they used to. The real problem is that the mud will read in *all* the input and attempt to process it, and I'm not sure if it's only like this to keep tintin working or not. If you coded the mud to read in only one command at a time (ie, read from the input buffer until you hit the first '^M', then not only would you solve the above problem of lagging the mud out by input, but you'd make it a little more fair for those without tintin. However, if you code it like this, you will notice the difference if you try to do a bunch of actions in a row cause each action will only get called once per iteration through the descriptor list. The result of doing this also is that you can create an input overflow, but the result is just that their link gets cut. -cjd +-----------------------------------------------------------+ | Ensure that you have read the CircleMUD Mailing List FAQ: | | http://cspo.queensu.ca/~fletcher/Circle/list_faq.html | +-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/18/00 PST