typing loads of characters in chat will cause a buffer overflow and crash the game -.-' this is in wormnet lobby... has this been resolved? has a max. limit been set?

I was unable to reproduce this issue. The edit box is limited to 450 characters - the game doesn't let you type or paste more than that.

o_O was gonna take a screenie with fraps -.-' this has been fixed somehow.... maybe something was just screwie on my pc -.-' cause now it works fine here since i reinstalled windows... so it was either a) a bug found deep within my prehistoric windows install or b) a server upgrade solved it.

Certainly wasn't b), that's for sure.

It's still in the 3.6.27.2c alpha (haven't tried the 2d yet). It happens in the Host/Join lobby, *not* the WormNET lobby.

heres a pic of the area i meant... yes its where m3ntal said it was -.-' and it still happens to me... so yea i just forgot where it occurred xD.

Well, this bug was confirmed by other players, but I'm still not able to reproduce it on my machine (nor on a virtual PC). From the minidump submitted by Liam, I was only able to figure out the crash was set off by a routine in the VC++ CRT, but I couldn't determine what originally causes it without being able to reproduce it.

Does anyone know if the line you enter is actually sent to the other players before you crash?

havnt really bothered checking if it does get sent or not -.-' this is because the game will usually have started by the time i get back into the lobby.

Yes Cyber, it is sent. I'm not sure if all of it is or just the first 255 chars, but i've had KRD telling me what i typed when i've returned to a game i've crashed from before.

Bizarrely, there were two ways in which entering long lines caused a crash. One of them, I fixed in v3.6.23.0; it crashed with lines that were nearly 500 chars long.

The remaining bug causes a crash with lines at least 256 chars long and didn't happen when I tested the previous fix. I don't know why exactly, but it has to do with W:A's use of MFC, which is hybridized with DirectDraw in a way that's incomplete. The crash happened when an attempt was made to erase the entered line from the text entry box.

I've implemented a workaround fix which will be in the next release.

It's still in the 3.6.27.2c alpha (haven't tried the 2d yet). It happens in the Host/Join lobby, *not* the WormNET lobby.

There are alphas?

I guess this is some sort of "Selected People" alpha.

what is the workaround? o_O did you just limit how much a user can type in the box thus preventing the crashes?

it occurs in the main lobby of anything goes aswell -.-

I wondered why the hell one wanted to type in more than 50 chars.
Spam somewhere else.

no, it should cap the max character possible to enter to prevent the crash...
profesional products shouldnt crash.

profesional products shouldnt crash.
A crash test dummy is a professional product... :rolleyes:

lol .

A crash test dummy is a professional product... :rolleyes:

lol . ,

no, it should cap the max character possible to enter to prevent the crash...
profesional products shouldnt crash.

For once I agree with Franpa. If it crashes for this reason it is unacceptible. Maybe programmers are so busy with the hard stuff that they overlook the obvious and super easy.

The testers should not have missed this either, but looks like deadcode has got alot of work to be getting on with.:p

It's not as simple as it seems. W:A does cap the maximum number of characters allowed in the input to the amount it can store/process, however there seems to be a different issue at the core of this. In other words, there is a bug which is only revealed when you enter more than a certain number of characters in the input line, and it isn't even always reproducible (I couldn't reproduce the original issue on my machine).

We believe that it's caused by W:A's somewhat buggy DXMFC framework (see Deadcode's post). At the moment, this issue is of too little importance to be dealt with since DXMFC will be replaced in W:A 4.0 anyway.

The testers should not have missed this eitherWe didn't.

It's not as simple as it seems. W:A does cap the maximum number of characters allowed in the input to the amount it can store/process, however there seems to be a different issue at the core of this. In other words, there is a bug which is only revealed when you enter more than a certain number of characters in the input line, and it isn't even always reproducible (I couldn't reproduce the original issue on my machine).

We believe that it's caused by W:A's somewhat buggy DXMFC framework (see Deadcode's post). At the moment, this issue is of too little importance to be dealt with since DXMFC will be replaced in W:A 4.0 anyway.

There you go, you just fixed the problem there, cap the letters further.

Just find out from testers what the number of chars is, then cap it at 10 below there. Easy :D

*poofs back into the shadows to do some PHP*

There you go, you just fixed the problem there, cap the letters further.

Just find out from testers what the number of chars is, then cap it at 10 below there. Easy :D

It's a work-around more than a fix, though.

Hey, I have an even simpler "fix": Don't enter any characters at all! :rolleyes:

ah well, this won't affect me anyway so it is hardly major:) I usually geta good stable game of worms via the net and that is the main thing isn't it:cool:

The remaining bug causes a crash with lines at least 256 chars long and didn't happen when I tested the previous fix. I don't know why exactly, but it has to do with W:A's use of MFC, which is hybridized with DirectDraw in a way that's incomplete. The crash happened when an attempt was made to erase the entered line from the text entry box.

I've implemented a workaround fix which will be in the next release.what is the workaround? o_O did you just limit how much a user can type in the box thus preventing the crashes?
Maybe I should be more specific. I reproduced the bug, and then made a change that stopped the bug from from being reproducable. I only called it a workaround because I have high standards... what I did was bypass the MFC call that clears an entered line of text, because that's where the crash happened (and it would take some deep delving to figure out why); and instead, I manually clear the line in a way that keeps MFC and the API out of the loop.

ok, thanks for the reply.

I avoid using the chat panel where necessary. If I can get everyone using a ChatApp like TeamSpeak or Ventrilo, that's what I do. I personally think it restores some of the social aspect that is lost when you play Worms online.

Failing that I just keep my messages short and sweet.

Failing that I just keep my messages short and sweet.
Or multiple and provoking. ;)

Well, yes. But in my defense Dude broke my heart. Also he was not the sharpest crayon in the deck of cards.

my internet sux for "speaking" on the internet to tho's who are not in my country (australia) with out it getting garbled... but this is with teamspeak and not msn... with msn its fine but the lag id make in the game would be horrendous i would imagine.

256/64 kbps

256/64 kbps

Ooh ! Now that's what I call slow connection.


(Says the 14kbps guy)

14kbps is approx 1 kilobyte.

14kbps is approx 1 kilobyte.

And a mile is approximately two thirds of a kilogram

And a mile is approximately two thirds of a kilogram

Er, actually, he's right, he just has a funny way of putting it. :p

Er, actually, he's right, he just has a funny way of putting it. :p

I had a feeling he might be, so i decided to omit my rolleyes smiley :)

Well. 14Kbit/s is actually more of approximatively 2KB/s, than 1KB/s... unless you round 1.75 down to 1...