TCP/IP crashes

[Ricochet]

Well I tried going to PBEM after getting the ding and then back to TCP play but to no avail.

No matter what turn after the “bing” it still locked up every time we went from PBEM to TCP.

[Schrullenhaft]

The autosave from the 'sending' computer (the one that didn't get the 'bing) is the file that needs to be used. Start a PBEM session from that and exchange at least a turn. After that I believe you should be able to go back to a TCP/IP game.

This from another post on this thread:

When machine A locked up, we let machine B continue to the end of the turn, and player B ended the turn and started the next turn. Player A exited the game, which was auto saved, and when he reentered, it took him to the start of the NEXT turn (i.e. the same one that player B had just started) so that they were then in sync. We were then able to continue the game normally to the end of the scenario

The only "penalty" for using this work-around was that player A was unable to view the playback for the corrupted turn, but he could figure out what happened by looking at the next-turn starting locations and status of the various units.

The advice here seems to suggest using the autosave from the 'client/receiving' computer (the one that experiences the 'ding').

[ 01-06-2002: Message edited by: Schrullenhaft ]</p>

[LeBlaque]

The autosave from the 'sending' computer (the one that didn't get the 'bing) is the file that needs to be used.

This from another post on this thread:

The advice here seems to suggest using the autosave from the 'client/receiving' computer (the one that experiences the 'ding').

*********

So bottom line, what is the advice, this appears conflicting.

[Schrullenhaft]

Doing a quick test on my LAN with a scenario that will almost consistently produce the 'captured crew bug', I was able to restart the game using the autosave file from the 'sending/generating' computer (no intermediary PBEM turn was used). However my test scenario ended on the very next turn with an Axis surrender (it was setup for a quick surrender of units to generate the bug quickly). The receiving player never did see the turn of action that it was receving when it crashed ('bing' sound). It just picked up on the orders phase of the next turn (as if it had already seen the movie like the 'sending/generating' computer did).

I will have to look at it further to determine if performing a PBEM of the autosave file from the 'sending/generating' computer would help the 'receiving' computer to see the missing movie. I'm guessing that it won't (since the autosave most likely has been saved after the movie has been viewed). If the autosave from the 'receiving' computer is used I assume that the previous movie would be invalid and the turn would be recomputed/generated (with possibly slightly different results).

[ 01-11-2002: Message edited by: Schrullenhaft ]</p>

[aka_tom_w]

bump

[007 Commander]

OK, time for me to join this problem..

I have had the problem happen on an internet game AND LAN game with both the same PC's.

It happened in the demo which i cracked to enable TCP/IP, on Valley of Trouble. AND it happend after we purchased the game the full 112 version. We were playing Son map, over the internet and the very turn befor last it also occured.

Everytime this error has occured it has been with the client PC, not the host. Also we both have WinXP, client has 512 meg i think, and the host (mine) has 1 gig of RAM. Both have Gforce2 64 meg, with the latest 27.20 det drivers.

Also, ALL of these complaints above and NO one post their system specs. Can we please start posting system specs when your reporting a problem.

007

[007 Commander]

I have an idea....

Has anyone been able to have this issue recreated with a custom map? If so what units were included?

Then take out some units and try it again...

I wonder if this bug could be cause of certain units present in the battle.

I may work on this, i have 2 pcs on a LAN at home.

007

[Schrullenhaft]

If you read through the posts here you'll find that one of the common elements to the TCP/IP crashes is captured crews (sometimes it may be other captured units, but crews are the most common) or reininforcements. There have been postings before mentioning system specs and it doesn't look like the problem is attributable to OS, video card, network card or ISP.

I don't know if there will be a patch to CMBO to fix this problem. CMBB DOESN'T have this problem, but the TCP/IP code was extensively re-written from what I've heard and I don't know what kind of effort it would take to move that into CMBO.

So right now the issue is somewhat dead. If you read above there are work-arounds. Though they're annoying and can affect your enjoyment of the game, they still let you finish the game. Until CMBB is out and has been (possibly) patched, I wouldn't expect anything from BTS on this. They have stated in the past that CMBO is a finished product and that it won't receive any more patches/tweaks. They might make an exception for the TCP/IP bug, but there is no guarantee on that (and statements have already been made to the contrary regarding any patches).

[007 Commander]

I hope this issue isnt too dead yet.

I just bought my copy for TCP/IP. I only play multiplayer games.

However if my resolution is to wait for the next game, i had better receive that for free or obtain a refund from BTS.

So, i hope they are still working on this issue, and not just blowing it off cause of the next game.

007

[aka_tom_w]

Originally posted by Ricochet:

Well I tried going to PBEM after getting the ding and then back to TCP play but to no avail.

No matter what turn after the “bing” it still locked up every time we went from PBEM to TCP.

I've had this too

In my case there was duplication of reinforcements (I got twice as many) and they were appaernately not seen by my opponent.

THe game could continue in PBEM but NEVER in tcp/ip

the strange thing is the game allowed us to continue in PBEM EVEN after I had received duplicate reinforments.

For me that MUST be a bug :confused:

-tom w

[Madmatt]

Okay, here is the very latest from us on this matter.

1. We do know there is a problem with TCP/IP and captured crews which can sometimes cause the game to become corrupted. There are work arounds

for this, although admittedly not optimal ones (See below).

2. We have not specifically identified where the problem lies, but we do know (generally) what is causing the problem. Unfortunately, knowing where the problem might be does not necessarily mean it can be fixed or at least fixed easily.

3. Currently, the only known fix is not simple nor is it a viable one. It would require an entire rewrite of the game file format which would make every single scenario ever made over the last 1.5 years incompatible with the patched version. Obviously such a fix is out of the question because it would be like killing a fly inside your house with an 8" Howitzer. The TCP/IP problem, while very real and very annoying, is not serious enough to kill compatibility with the thousands of hours of

scenario work which has been done since CMBO's initial release in June of 2000. Anybody who thinks that the problem is worth sacrificing this

amount of work is, plainly stated, nuts

4. The file format has already been completely rewritten for CMBB so this TCP/IP problem has been incidentally fixed. CMBO can not benefit

from this work directly since the two code bases are no longer similar enough to transfer fundamental changes from one to the other.

5. We have not written off the possibility of finding a different fix for the problem, or what we call in programming terms a "bloody hack".

Such hacks can be highly problematic in their own right, but can sometimes work if the God of Code is smiling upon the programmer. However, a possible fix of this nature will have to wait until CMBB is released. It could take a significant length of time to address this

issue and it is simply not in the best interests of the CM community as a whole to enter into a CMBO related coding Black Hole at this point in

CMBB's development. There are work arounds for this problem now, but there are no work arounds to Charles stopping work on CMBB and futzing

around with CMBO for an undetermined length of time.

6. Charles has already spent enough time looking into this issue to be sure that there is no quick fix possible and therefore feels comfortable stating that only viable option is to deal with this issue in a couple of

months.

7. As stated above, the proscribed workaround when this issue occurs is to have the host player reload the resulting autosave file that is created when the lockup occurs and load the game as a PBEM (Play By Email). Proceed with the game like a normal PBEM turn and send the resulting file to your opponent. Once one full PBEM turn has been carried out ( in effect passing the event which triggered the crash) you should be able to resume the next turn as a TCP/IP game per normal.

Madmatt

[MeatEtr]

the madman has spoken, gotta love that analogy, "killing a fly inside your house with an 8" Howitzer". lol

[NightGaunt]

Madmatt:

can you detail what you believe causes the problem so that we can try tob avoid it?

is it just captured?

captured brits?

the more detail you can give the better.

[Schrullenhaft]

It's captured crews that will most often duplicate the problem (regardless of nationality). There seems to be some problems with reinforcements too, but I haven't seen it myself. So with most QB's you should be OK except when your units get in close proximity to a suppressed crew. The reinforcement problem will only happen in pre-made scenarios (and I'm not sure what factor affects that problem).

[Toad]

Any new news on this?

My friend is having this exact problem.

Thanks.

[Schrullenhaft]

There is no fix other than the PBEM workaround mentioned in this thread or elsewhere.

CMBO is considered a 'finished' product and no further updates are being considered, to my knowledge.

[Toad]

Even while playing networked via LAN in the same room, my friend's machine consistantly had this problem after 10 turns of a 20 turn game. Even trying the suggested autosave recoveries and playing a few rounds via e-mail before switching back to networked play had no success.

Here's looking forward to the re-creation of CM:BO that will fix this bug, bring the new CM:BB commands and AI intelligence to CM:BO and work in Mac OS X. (Battlefront.com: Hint, hint ...)

[Toad]

Originally posted by Madmatt:

6. Charles has already spent enough time looking into this issue to be sure that there is no quick fix possible and therefore feels comfortable stating that only viable option is to deal with this issue in a couple of

months.

My friend and I once again had a TCP/IP match grind to a halt after this problem again resulted in a crash on his machine.

All the symptoms that others have mentioned on this topic were present. Pre-made scenario. Recently captured troops. (In this case, a captured US gun crew.) Playing via TCP/IP. I still have the "autosave" file, if it's of any value for troubleshooting.

I'd like to know what Battlefront's next plan is. Matt's quoted words, above, suggest that work on solving the problem was going to be attempted "... in a couple of months." That was written in February of last year.

If the plan is to re-make CM:BO with the newer CM:BB innards - which already includes a fix to this TCP/IP problem - I would find such an answer acceptable. Even better would be to learn that a re-make is planned that will also work in Mac OSX. I recognize that a re-write of the CM graphics engine is no quick task, however.

Whatever the answer, I would greatly appreciate learning what it is and what the planned schedule is. I'm not expecting the fix to happen "tomorrow." But I would like to know what the plan is.

[Madmatt]

As said above, CMBO is a finished product, no further updates or patches for it will be made.

We will at some point return to the Western Front (WWII) era, the same which is covered in CMBO, but it is not certain at what point that will be.

Madmatt

[Mies]

Are there going to be any updates in future CMBB patches regarding tcp/ip? I don't know if this makes any sence, but would it be usefull to set the time-out time to a higher value so that tcp/ip packets have more time to reach the other side?

Mies