Jump to content

Somebody fix the Prisoner Bug for god sake.


Recommended Posts

I know BTS is working hard on CM2, but take 10 minutes out of your time to fix the stupid "prisoner captured/ annoying Windows "ding"/ game locks up bug".

It ALWAYS happens during TCP/IP play. Everyone has had it happen to them, and I e-mailed the screwed up file to BTS many months ago.

It can be worked around by continuing via E-mail, but when I'm good and liquored up, and have just over-run that german position, with the blood lust boiling in my veins, dead bodies lying all around my position, and one last pathetic bastard left standing decides to throws down his arms, I pray to the gods of war that I had a 16inch battery landing on his ass before the 60 second timer is up.

This burns my ass.

Link to comment
Share on other sites

Check out Maxx's possible fix for the bug. He's played 15 hours tcp/ip using it with no problem. I just finished one with a prisoner taken without doing the manual "save" step he utilized for security purposes, and with ambient sound on (which was an unknown variable in his testing of the fix): no problem.

Yeah, it needs a patch, but this fix looks good so far.

Link to comment
Share on other sites

Just finished a second game (3000 pts). Did not do manual save, ambient sound both players was on. Took 84 prisoners (he he he ). No "ding-freeze". LOOKING VERY VERY GOOD MAXX!!! :D

[ 06-02-2001: Message edited by: Agua ]

Link to comment
Share on other sites

<BLOCKQUOTE>quote:</font><HR>Originally posted by Mr. Johnson-<THC>-:

Does ambient sound have any effect on the bug?

<HR></BLOCKQUOTE>

Unknown. While Maxx was playing immediately after discovering this potential fix, both he and his opponent had ambient sound turned off. So it is unknown what, if any, involvement the presence of ambient sound has in contributing to the "ding-freeze". I have since played two games (2,000 & 3,000 pts), and both my opponent and I purposely had ambient sound "on" to see if this had anything to do with causing the crash. So far, it hasn't.

[ 06-03-2001: Message edited by: Agua ]

Link to comment
Share on other sites

I have a wild stab of a guess about a possible cause for this bug, based merely on the reports about it.

This is not based on testing and I haven't seen it myself, so take it with salt. It is meant as a suggestion to the BTS people for something to look at. It is based more on bug-hunting instincts past, than any direct knowledge here.

Some report prisoners associated with the bug, some prisoners on both sides. MM's workaround that seems to be working, relies on both players having given all orders before hitting "go". The bug doesn't seem to always happen - if it did it would have been found a while ago. Putting them together I get the following guess.

Prisoners change the ownership assignment of units. Meaning -which- player gives them orders. Suppose one part of the code "thinks" unit assignments are -fixed-, while most of it properly accounts for unit assignments varying. I imagine the units, internally, are like data structures, and are probably accessed by pointers. Change the scheme of assignment in one part of the code, when a prisoner is taken. A pointer elsewhere is trying to change a data item on a unit, and it points outside of the new range of the data array for that side's units after the reassignment. A stray pointer can point at anything. It flips something where it wasn't supposed to, and down she goes.

Why the fix? Because the assignment of units is probably easy enough and correct when all units are "accounted for", is a guess. Maybe there is a bit of code assuring the assignments of units are right, that does not get called yet if both sets of orders aren't in?

Just a place to look. The guys that programmed it may be able to tell right away if it is at all sensible, or possible.

Link to comment
Share on other sites

×
×
  • Create New...