Colebrook Posted January 14, 2015 Share Posted January 14, 2015 Today we were playing a MP mission and something very strange happened,TC was watching a tank ,and gunner was not able to see it(one using GPSE and other GPS ).On the after action report apperars:**** Network clocks corrected by - 2917.917238 seconds ****On the log: [01:17:00,717] ERROR: Scenario has duplicate combatant IDs!We had no errors or ping warnings during the session.I have both AAR if needed. 0 Quote Link to comment Share on other sites More sharing options...
Colebrook Posted January 14, 2015 Author Share Posted January 14, 2015 http://www.filedropper.com/aar The AARs 0 Quote Link to comment Share on other sites More sharing options...
Moderators Volcano Posted January 14, 2015 Moderators Share Posted January 14, 2015 It sounds like a scenario problem to me. Can someone upload it? 0 Quote Link to comment Share on other sites More sharing options...
haukka81 Posted January 14, 2015 Share Posted January 14, 2015 Me and my friends have seen lots of mp desynchronization problems when in same tank. T-72M1 = ammo count shows difrent numbers for guner and tc :c:Leo 2A4 same thing :confused:Is this old bug really back ? 0 Quote Link to comment Share on other sites More sharing options...
Moderators Volcano Posted January 14, 2015 Moderators Share Posted January 14, 2015 Well, we aren't going to chase rabbits here. Let's stay on topic with the original post -- we need to see the scenario to know what the problem is, or at least to assist us in narrowing it down.As for ammo counts showing different numbers, we would need more information on that in a new thread, along with details about your network quality (ping times, was there any network overload? If so, for how much of the session? A debug log from host and client would be nice too). We can't really do anyting with a drive-by post of a couple of sentences. 0 Quote Link to comment Share on other sites More sharing options...
Moderators Volcano Posted January 14, 2015 Moderators Share Posted January 14, 2015 (edited) As for ammo counts showing different numbers, we would need more information on that in a new thread, along with details about your network quality (ping times, was there any network overload? If so, for how much of the session? A debug log from host and client would be nice too). We can't really do anyting with a drive-by post of a couple of sentences.Actually, for the sake of clarity...A voice in my ear says that this is an old issue that is known, and has been there since v1.0 (no changes have been made there). Basically, in cases of bad network/network overload, rapid fire of the gun may cause the maingun ammo count to differ by 1 or 2 rounds. When this does happen, the effects are usually minimal and that is why it has rarely been noticed in the past, and when you assumed it was "fixed" was likely due to periods of no heavy network overload. By "minimal" effects, I mean that one client has a few more rounds.The only way around something like this would be an occasional pause and synchronization to get everything back in order, but arguably this is much worse than an occasional ammo count discrepancy between human gunner and human commander, and it would carry its own complaints as the game pauses and stutters to synchronize at random points; just imagine the other games that do this and how annoying this is. So, the design decision has always been to let some things (like ammo count) differ in cases where there is heavy network overload, just to keep the action going. The other alternative is to fundamentally change the way the host and client interacts in this regard, which is not going to happen anytime soon.A somewhat similar situation is when the repair timers count down to 0:00 on a CLIENT, but then it remains damaged -- because on the HOST machine (which keeps track of all damages and repairs), his timer is still non-zero and is still ticking down. The CLIENT will get repaired when the HOST timer is at 0:00, and all will be good with the exception of the inaccurate timer. These kind of minimal effect desyncs are inevitable and unavoidable, since they depend on overall quality of the network. The emphasis is placed on updating the most important data instead, like the positions of all the vehicles, rounds in flight, etc.But yes, more information there would be nice, and preferably in another thread so we can confirm that it is indeed caused by network overload (which is known and expected in severe cases).But let's go back to the original topic about duplicate combatant IDs... Edited January 14, 2015 by Volcano clarification 0 Quote Link to comment Share on other sites More sharing options...
Tacbat Posted January 14, 2015 Share Posted January 14, 2015 A reminder on how to report bugs: http://www.steelbeasts.com/sbforums/showthread.php?t=15831 0 Quote Link to comment Share on other sites More sharing options...
Moderators Volcano Posted January 15, 2015 Moderators Share Posted January 15, 2015 OK thanks, I will give it a look. 0 Quote Link to comment Share on other sites More sharing options...
Moderators Volcano Posted January 15, 2015 Moderators Share Posted January 15, 2015 OK thanks, I will give it a look.I looked it over, nothing in it seems obviously wrong with the scenario -- it is pretty straightforward. I suppose I could of missed something of course, but I just recommend playing it again and it shouldn't happen. It makes me wonder if you guys went back to pick someone else up, or someone joined in progress and maybe some rare set of conditions caused something to get mixed up in that process. 0 Quote Link to comment Share on other sites More sharing options...
Moderators Volcano Posted January 15, 2015 Moderators Share Posted January 15, 2015 (edited) Also we forgot to mention: The host which was Asid paused for myself and bob to join.we choose our vehicles which is in observers view. We then decided to just restart the mission. So instead of bringing us into the mission Asid just quit the mission and everyone was allowed to select a vehicle position. We didn't exit completely out. Not sure if this helps but might have something to do with it.Aha, yes, I see how this happens, and apparently it is not specific to the Host quitting and going back during the join-in-progress process either. It seems that if anyone joins in progress, then they will continue to have that scenario loaded if they ever go back to the Assembly Area (they will see the join-in-progress temporary filename like "SB_9A74". That is the name of the temporary join in progress scenario state, and is essentially a scenario file saved at the point at which it was paused.The issue here is that when everyone goes back to the Assembly Area, then the HOST/CLIENT machines should make sure they have to same scenario selected.-------------------It is amazing how this was not noticed before, but it has to be because join-in-progress games rarely result in re-playing the same scenario again immediately after.SOLUTION:In the mean time, if everyone ends up back at the Assembly Area, then those that see the temporary join-in-progress save file listed (which is everyone that joined in progress) should exit the session and return again.We will look into closing this loophole in the future. Edited January 15, 2015 by Volcano 0 Quote Link to comment Share on other sites More sharing options...
Moderators Volcano Posted January 17, 2015 Moderators Share Posted January 17, 2015 Should be fixed in update. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.