Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ SMAUG
➜ SMAUG coding
➜ Writing Buffer Q?
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Tux
(8 posts) Bio
|
| Date
| Sat 12 Aug 2006 11:33 PM (UTC) |
| Message
| | Is there a way to remove the spam check? I would like to be able to paste lots of data into a writing buffer without being disconnected. Is this possible? I know that it could lead to abuse, but my server is so small that this is not a problem. | | Top |
|
| Posted by
| Zeno
USA (2,871 posts) Bio
|
| Date
| Reply #1 on Sun 13 Aug 2006 12:05 AM (UTC) |
| Message
| | I'd assume you can just search the code for the bug message and remove the ifcheck. But it's probably there for a very good reason. |
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org | | Top |
|
| Posted by
| Tux
(8 posts) Bio
|
| Date
| Reply #2 on Sun 13 Aug 2006 11:33 AM (UTC) |
| Message
| | That's what I have been trying to do. I haven't seen any type of bug message being sent out when this happens. It just shows a client being disconnected like a peer/ping timeout does, EOF bug() call. I understand that it is there for a reason, but sometimes I want to paste a large amount of data into a writing buffer, usually an ingame change, or a new ascii art for the motds and it disconnects me. I was hoping that someone had a fix or patch for this to disable this in a writing buffer or all together. | | Top |
|
| Posted by
| Conner
USA (381 posts) Bio
|
| Date
| Reply #3 on Sun 13 Aug 2006 07:32 PM (UTC) |
| Message
| | Are you talking about the spam filter that logs you off if you exectute the same command more than 20 times (look in comm.c for 'PUT A LID ON IT') or the buffer overflow thing that occurs if too much data is sent to your descriptor at once causing to you to be disconnected (not sure where you'd go about that right off hand)? |
-=Conner=-
--
Come test your mettle in the Land of Legends at telnet://tcdbbs.zapto.org:4000
or, for a little family oriented medieval fun, come join us at The Castle's Dungeon BBS at telnet://tcdbbs.zapto.org
or, if you just want information about either, check our web page at http://tcdbbs.zapto.org | | Top |
|
| Posted by
| Zeno
USA (2,871 posts) Bio
|
| Date
| Reply #4 on Sun 13 Aug 2006 07:34 PM (UTC) |
| Message
| | The buffer overflow, I assume. |
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org | | Top |
|
| Posted by
| Conner
USA (381 posts) Bio
|
| Date
| Reply #5 on Mon 14 Aug 2006 03:27 AM (UTC) Amended on Mon 14 Aug 2006 03:29 AM (UTC) by Conner
|
| Message
| In that case, my best guess would be that Tux would need to make his buffers bigger (MAX_STRING_LENGTH and/or MAX_INPUT_LENGTH) if it's happening when he's trying to input a large chunk of data. Now if the problem is when someone is trying to view that large chunk of data I'd be interested myself in finding out how to adjust that buffer max so that I could make certain large data files have less restrictions because I get that one all the time and usually have to just restrict the individual commands to limit how much data can be displayed. (Have that issue currently in a number of places.)
On the other hand, it might be worth noting that you want to be careful and not go overboard on how much bigger you set those two buffer limits because otherwise you'll run into the 2nd problem when the mud echos that data block back to you too. |
-=Conner=-
--
Come test your mettle in the Land of Legends at telnet://tcdbbs.zapto.org:4000
or, for a little family oriented medieval fun, come join us at The Castle's Dungeon BBS at telnet://tcdbbs.zapto.org
or, if you just want information about either, check our web page at http://tcdbbs.zapto.org | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #6 on Mon 14 Aug 2006 03:25 PM (UTC) |
| Message
| Personally I would be very wary about changing the buffer sizes, because you'd be opening yourself up to abuse from malicious players, not to mention that a lot of code assumes many things about those buffer sizes (e.g. without using proper constants).
MUSHclient at least can help you with this by sending very large chunks one line at a time, with a line every 200 ms or so, which will give the MUD server enough time to process stuff before filling up the buffer.
To fix this properly on the MUD server side would require a fair amount of work, because you would have to have it recognize that a buffer is full, and stop filling it up further until it gets a chance to process some of it. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Gohan_TheDragonball
USA (183 posts) Bio
|
| Date
| Reply #7 on Wed 16 Aug 2006 06:22 AM (UTC) Amended on Wed 16 Aug 2006 07:31 AM (UTC) by Gohan_TheDragonball
|
| Message
| | yeah he is talking about the overflow, which i think can be annoying too, however i figured it was put in for a reason, but if you want to change it i believe changing the MAX_INBUF_SIZE inside mud.h is all you need to do, the default size from stock smaug is 1024. | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
22,251 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top