View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0003118 | AI War 1 / Classic | Crash/Exception | Mar 26, 2011 5:55 pm | Mar 29, 2011 8:54 am | |
| Reporter | Fleet | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 5.008 | ||||
| Fixed in Version | 5.009 | ||||
| Summary | 0003118: Desync | ||||
| Description | Desyncs on save loading. I'm at a loss for words. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | |||||
|
|
|
|
|
|
|
|
|
|
|
Once again, the devs' reaction: http://www.youtube.com/watch?v=WWaLxFIVX1s |
|
|
I find the video extremely appropriate, and quite funny in this context. |
|
|
Sigh. On the bright side, I CAN duplicate it. You guys have all the luck, I swear -- I can't remember the last time I had a desync from anyone else, and I never get them, but you just hit them all. I... don't understand how this works. At any rate, once again thanks for your patience. Hopefully this will be quicker to track down than the last one, but I won't be able to do any hardcore tracking of it until Monday, I'm afraid. But since I can duplicate it, that's a definite thing that it can be fixed, at least. And in terms of being at a loss for words. I can think of *several* words, but I'd have to report myself for moderation. ;) |
|
|
Haha. I was a bit depressed when I typed that. I'm halfway though my 2 week spring break, so I am trying to fit in as much AI as I can. |
|
|
Sorry about that -- man I hate desyncs, and especially that you guys keep running into them. You've had more than your fair share! At least this one isn't a "ghost" one, is the only good thing I can say about it! |
|
|
Well, I've verified two things: 1. It's not related to gravitational slowing. 2. It's not related to that counter that was the problem in the last desync. So, first guess is that this is a completely unrelated desync of some sort. I also found that a ton of ships are slightly off again, AND the random number generator result at the end of the affected turn is off, so this is a case where an extra RNG call is occurring for some reason. Since the desync happens so quickly in this save, that does give me one unusually brief vector for tracking these (through the RNG calls), but I'm not sure that will yield anything too fast since it could be a downstream effect rather than the direct cause. Anyway... I'll see what I can do. I suggest trying to resume playing from one of the saves after the desync occurs, as it might not be something that persists beyond this one event. You never know. Anyway, I may have some time to look into this one tonight after all, but I don't know if I'll have enough time to actually find it if it's as tricksy as the last hobbit to come through here. I'll let you know! |
|
|
Well, I can also confirm that the position of units is being set just fine at game load, and that the saves don't diverge until somewhere around a second or two after the simulation starts. My guess is that it's actually loading the save fine this time, but having an issue during the simulation itself, rather than having a simulation issue that was just a downstream effect of a save-loading issue like last time. So that's some progress. Fortunately all my tracing stuff is in there from last time anyway, and just commented out, so that's quicker to re-enable and find stuff. Now I need to run to dinner for a while, but I'll be back on in an hour or two. |
|
|
Alright, thanks for your extra commitment here. If it looks like it will be best solved on Monday, you have my patience. |
|
|
My pleasure. Well, I've narrowed it down to either target selection or the "protection" logic for force fields, etc. It's possible it might be in he throttling code, or at least that's what I am going to try looking at tonight if I get a chance. It's still possible it is actually something else, rather than that directly. I also think I figured out why you and Tss are getting at least these last two desyncs when no one else is: very few people save right in the midst of a big battle, and both of these saves are smack dab in the middle. That means that if there is any slight initialization stuff that might self-correct for most people's saves before the next battle happens, for you two it is not having a chance to and instead is resulting immediately. That obviously doesn't answer why a desync would happenfoe you guys after playing for a long time, not right after a save load, but that was mostly in the pre-5.0 times I think. These last two saves are particularly notable for being in media res. Not that I'm suggesting you change your save habits -- there shouldn't be any such issues, and we'll fix whatever is there (hopefully his is the last one for the moment!) -- but I've been trying to puzzle out what factors are leading to your more frequent desync finds lately, and that's all I could come up with. As with movies, people tend to stop at a lull for the night. Or with books, at a chapter break. Between battles, when it comes to ai war. It's interesting that you guys don't, at the very least. :) |
|
|
Hahaha, interesting observation. I used to play this for hours at a time. I now limit myself to about half hour chunks. There is simply no other way for me to not end up pouring half my day into a game. Also, I find the middle of a large battle(s) is a great time to stop, because when we come back, I take a few moments to reassess the situation, and input any new commands or orders. |
|
|
Makes sense to me! Just a note, I haven't completely found this one, but I do have a strong lead on it at the moment after some various semi-successful logging attempts. It appears that on the client, whether or not the destination of a minor faction ship has checked its destination or not (to decide if it should do course corrections to avoid a collision at the destination) differs from the host. I'm not sure yet why that is, but I suspect it might be something funky with minor factions being loaded from saves, which would explain the rarity of this particular desync. Anyway, that's a pretty strong lead, but I'm a few hours into this particular rabbit hole so far today, and that's all I've got so far. These bleeding desyncs are so horrendously time consuming to find. Hopefully later tonight I'll be able to finish running this one to ground. |
|
|
Just a note, I can now confirm that the destination point is getting set incorrectly on savegame load. I'll definitely be able to finish running this one to ground tonight, now that I know that. |
|
|
Got it. It was an issue with how it was initializing the "ship to kill." So, this would only happen in certain circumstances, when ships were actively fighting during a save. Go figure -- I guessed right on why only you guys are seeing this one, for sure! Fix will be out briefly. |
|
|
Thank you. |
|
|
You bet! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Mar 26, 2011 5:55 pm | Fleet | New Issue | |
| Mar 26, 2011 5:55 pm | Fleet | File Added: Fleet Before Desync.sav | |
| Mar 26, 2011 5:55 pm | Fleet | File Added: Fleet After Desync.sav | |
| Mar 26, 2011 5:55 pm | Tssbackus | File Added: Tss After DESYNC.sav | |
| Mar 26, 2011 6:06 pm | TechSY730 | Note Added: 0011498 | |
| Mar 26, 2011 6:18 pm | Fleet | Note Added: 0011501 | |
| Mar 26, 2011 7:59 pm | Chris_McElligottPark | Note Added: 0011505 | |
| Mar 26, 2011 7:59 pm | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| Mar 26, 2011 7:59 pm | Chris_McElligottPark | Status | new => confirmed |
| Mar 26, 2011 8:06 pm | Fleet | Note Added: 0011506 | |
| Mar 26, 2011 8:11 pm | Chris_McElligottPark | Note Added: 0011507 | |
| Mar 26, 2011 8:20 pm | Chris_McElligottPark | Note Added: 0011508 | |
| Mar 26, 2011 8:31 pm | Chris_McElligottPark | Note Added: 0011509 | |
| Mar 26, 2011 8:34 pm | Fleet | Note Added: 0011510 | |
| Mar 27, 2011 11:04 am | Chris_McElligottPark | Note Added: 0011517 | |
| Mar 27, 2011 12:29 pm | Fleet | Note Added: 0011518 | |
| Mar 28, 2011 6:52 pm | Chris_McElligottPark | Note Added: 0011553 | |
| Mar 28, 2011 8:26 pm | Chris_McElligottPark | Note Added: 0011557 | |
| Mar 28, 2011 10:46 pm | Chris_McElligottPark | Note Added: 0011562 | |
| Mar 28, 2011 10:46 pm | Chris_McElligottPark | Status | confirmed => resolved |
| Mar 28, 2011 10:46 pm | Chris_McElligottPark | Fixed in Version | => 5.009 |
| Mar 28, 2011 10:46 pm | Chris_McElligottPark | Resolution | open => fixed |
| Mar 29, 2011 1:40 am | Fleet | Note Added: 0011563 | |
| Mar 29, 2011 8:54 am | Chris_McElligottPark | Note Added: 0011567 | |
| Apr 14, 2014 9:27 am | Chris_McElligottPark | Category | Bug - Crash or Exception => Crash/Exception |
