|
2005-08-28 07:19
|
enif-mannheim1.jpg (106,682 bytes) |
|
2005-08-28 07:20
|
enif-mannheim2.jpg (120,134 bytes) |
|
2005-08-28 07:20
|
enif-mannheim3.jpg (105,470 bytes) |
|
|
I always manage to leave something important out. This started happening after 7-22-05, Goober's build from that date being the newest build that doesn't cause this, (I don't have 7-28-05 here to check) but is present in everything I've tried from august. I suspect this has to do with the AI rollback that was done around that time, but I can't confirm that. edited on: 08-28-05 03:23 |
|
|
I'm assigning this to Goober, since he ought to know the docking code best. |
|
|
Ugh... crap. Okay, I really don't have that much time to spend on this so I'd appreciate as much help as possible. Could you try a bunch of builds from http://fs2source.warpcore.org/exes/latest/ and see if you can pinpoint exactly when this bug appeared? Also try to verify that the bug did not appear in earlier builds. |
|
|
The bug comes from aicode.cpp, in the if statement at line 11096, inside the ai_dock function. The aip->active_goal seems to be set at -1, forcing the execution of the ai_cleanup_dock_mode function. Quick fix: Change line 11096 from if ((aip->active_goal < 0) || (aip->goal_objnum == -1) || (Objects[aip->goal_objnum].signature != aip->goal_signature)) to if ((aip->goal_objnum == -1) || (Objects[aip->goal_objnum].signature != aip->goal_signature)) Goober, you may want to check that this change does not mess up anything in the docking code. FYI, the newest CVS image that does not have this bug is dated around 21 or 22 July 2005. Edit: Clarify location of the offending line a little bit more. edited on: 08-28-05 09:38 |
|
|
@#$^*&. That line is there based on a careful examination of the code to fix a few other bugs while still keeping in line with what the dock code is supposed to do. This means the bug is going to take at least an evening or two of concentrated debugging and I don't have the time right now. :( |
|
|
A little more information on what exactly happens during the first moments of "The Sixth Wonder", after running it using a debugger: 1) Mission begins. The Mannheim starts docked with Enif station. The program arrives at aicode.cpp, line 11096 and performs the check described in the if statement. 2) The value of aip->active_goal at the time (Missiontime equals 16384) is -1. Regarding the other key values of the aip structure, aip->mode has a value of 8 (AIM_DOCK) - fine - and aip->submode is 27 (AIS_DOCK_4A) - perfect. However, since aip->active_goal is -1, the call to ai_cleanup_dock_mode_subjective is executed. Program flow goes to line 10918 in aicode.cpp. 3) Because the submode is 27, the if statement becomes true and the two statements within it are executed. In doing so, the ai submode takes the value of 33 (AIS_UNDOCK_3). Now the Mannheim is actually trying to undock from Enif station, when in fact it should maintain its docked position until the event to undock is invoked. The ai submode remains at AIS_UNDOCK_3 from this point on. I am not entirely sure why exactly this results in Enif spinning like it does, but definitely the docking behavior of the Mannheim (and more specifically the change in its ai submode) is where it all starts, since if I comment out line 11098 of aicode.cpp (the call to ai_cleanup_dock_mode_subjective), all goes fine in the mission with no problem. Goober is right. It is a quite "deeper" issue than it originally looked. |
|
|
Could it be moving when the Mannheim has completed its undock behavior and the game can't resolve the conflict between the transport's position and the fact that it's still "docked" to the installation? (though that doesn't explain WHERE it ends up). And I would have used the "docking" (or even AI) category had I seen one when I submitted this bug :p EDIT: on closer inspection, this seems to be a common problem for ALL missions in which initial docking has been used and when neither ship has any orders to start out with (what they are assigned later is irrelivant). edited on: 08-30-05 16:41 |
|
|
Well, Alpha0, that was immensely helpful. :) Do you think you might want to join the SCP? ;) I now think I understand this bug. I'll have to make it uglier than I wanted, but it looks like taylor's commit of 2005/06/01 is what I'm shooting for. StratComm: I only added the "dock" category after you submitted the bug. ;) |
|
|
Fixed. Check the next CVS build and see if it works. |
|
|
Looks good. Initial docking seems to be working ok. If I don't post anything else about this in the next 24 hours (as I'll do a more thurough test of docking behavior after class), I'd say this one's ready to be closed. edited on: 08-31-05 09:03 |
|
|
Yep, looks ok here as well. The fix works. |
|
|
Great. :) |
|
|
Erinnerung gesendet an Goober5000 I could not write a comment, so I hope it's okay to send a reminder... I hate to say it, but the bug still exists here... The Mannheim KEEPS docked with the Enif-Station. I even tried to edit the mission... No luck.. It just won't undock... Build: Every CVS-Build in the past two months or so... |
|
|
Okay... can you look through the Recent Builds archive here: http://fs2source.warpcore.org/exes/latest/ and tell me which builds (within two weeks or so) work and which don't? |
|
|
Erinnerung gesendet an Goober5000 It happens since... Well... For me, it never stopped happening... I'm always using the newest CVS-Builds (Linux, self-compiled). |
|
|
This bug has been reopened, so please post your comments directly to Mantis. Can you try CVS checkouts by date during the month of September? The bug should have been fixed on August 30. |
|
|
Okay... Maybe I'll try it... As for now: CVS Build - 02 January 2006 MediaVP 3.6.8 Beta |
|
|
No luck with any CVS-Date/Build... Can it be a Linux-specific problem? I'll try it with Windows now and then edit this message... EDIT: Okay... It IS a Linux-only-bug! Everything went fine in Windows... EDIT 2: Okay... Taylor seems to know what it is :) bearbeitet am: 01-08-06 14:54 |
|
|
The fix has worked every time in my tests and in all of the other missions that I've played I haven't found any new problems as a result of the change. I'll commit the fix and then we'll just see if anyone using the CVS builds notice a problem with events. |
|
|
Did your changes already hit CVS? If yes: It's still happening :( If no: I'll wait ;) |
|
|
No. :) I have been trying to complete the FRED2 changes for the new dynamic starfield code before I commit that and just haven't yet. It will be done today though and I'll get both things in CVS (or at least this one bug fix). The reason I've held off is that I just wanted to give it a quick test under Windows to make sure it did't break (though it shouldn't have). |
|
|
Ok, in CVS now. :) Give it a try in both Linux and Windows please and let me know if it's totally fixed. |
|
|
Okay... Seems to work... You're really a SCP-Linux Guru ;) |
|
|
Ok, I guess we can consider this fixed now. If you see it show up again or notice any issues which look like it might be linked please just reopen this. Oh and that's *Super* SCP-Linux Guru! ;) |
|
|
Fixered. |
- Anonymous
