View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000721 | FSSCP | gameplay | public | 2006-01-17 12:16 | 2006-06-27 04:45 |
| Reporter | thesource2 | Assigned To | Goober5000 | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000721: Undocking problem | ||||
| Description | In Iceny capture mission if Azrael is destroyed before the undocking operation is complete, Iceny suddenly appears in inother place crashing everything that was there before. | ||||
| Tags | No tags attached. | ||||
|
|
This sounds like it may be a mission bug, but since it involves docking, assigning to Goober. |
|
|
I can add that if two or more objects are docked two one structure and one of the objects undocks, it causes massive destruction or even crash. Neither first nor second problem are mission problems - in original fs2 all works fine. |
|
|
I tried the Iceni mission but other than the standard physics whack I didn't see anything terribly wrong. The same thing will happen to Enif station in "The Sixth Wonder" if you destroy the initially docked ship. Of course it may be unralated to that and actually some undocking problem. There is the chance that this is related to the qsort() bug fix I made recently so someone needs to test the last build redmenance released to compare if there is an obvious difference. |
|
|
Well, still it is bug, because like I said there is no such problem in original fs2. |
|
|
I agree that there is a bug, never said otherwise. The physics whack is worse if you just shoot at the docked object rather than destroy it outright. The movement either shouldn't happen, or should be considerably less that what it is at the least. Object mass doesn't seem to be taken into account properly. |
|
|
Example: SD Lucifer is inside two docking rings. Two GTT Argo are docked to rings, one to each. If one transport undocks, fs2_open crashes. But if one of the transports is not docked and the other undocks, no crash happens. |
|
|
Errr.... hello? Does anybody still remember about this? Bug still present. |
|
|
The Iceni seems to move to the position it would be in if it were docked to the transport at the moment the transport was destroyed. This looks like it might be related to TP's Chronos bug, although I could be wrong. |
|
|
Reminder sent to redmenace When you have a chance, could you run a bunch of CVS builds and find out when this bug was introduced? |
|
2006-06-25 21:35
|
|
|
|
I uploaded a video that shows what happens. If you destroy the Azrael before it undocks, the Iceni jumps to the Azrael's last position. If you destroy the Azrael after it finishes undocking, everything is fine. |
|
|
It seems to have something to do with how it undocks. I'm trying to narrow down the exact commit now, but the builds that have the problem show the Azrael as docked even when it's moving away. The builds that work fine have the Azrael listed as undocked right when it actually undocks. It appears to have broken at some point between Dec 28th and Jan 1st. There was a LOT of code changes during that time though so it's going to take me a little longer to narrow it down more. EDIT: Grrr, it didn't break during that time. I started with a checkout of the 1st but I must have screwed up the date or something. Going back over it now. EDIT2: Up to the 20th now and am sick and tired of continually fixing WMC's code breaks, so I'm stopping at this point. But, since I got to the 19th without it messing up I wonder if this might not be a side effect of the goal sorting issue (qsort())? It would have been an issue for Windows starting on the 11-12th, but it works fine under Linux for those dates. It seems to be an issue for Linux sometime in early Feb, after Goober changed out qsort() for the insertion sort. The date descrepency points a serious looking finger at that being the cause. As a quick test I went back to using qsort() for aigoals sorting under Linux, with a current checkout, and it worked fine. So, works with qsort(), breaks with insertion_sort(), no other changes. edited on: 06-25-06 20:06 |
|
|
Well I just tried it with qsort, to no avail. EDIT: I commented back out that "else if ( ga->time < gb->time )" in the comparison function, though, and now it works. EDIT2: Scratch that - it works most of the time, but sometimes it doesn't. Doesn't matter whether insertion sort or qsort is used, but insertion sort seems to be more reliable. edited on: 06-25-06 21:59 |
|
|
Oh, FUDGE! My insertion sort algorithm had a bug in it. :p EDIT: Nevermind. I misunderstood the algorithm on Wikipedia. edited on: 06-25-06 22:31 |
|
|
Crap! Just had it happen with qsort() when I was debugging. So, it's not that simple I guess. The same case holds true though, the Azrael never fully processes the order to undock. EDIT: It's staying in AIS_UNDOCK_2 until it eventually gets too far away from the Iceni. edited on: 06-25-06 23:10 |
|
|
Okay, I think we might be chasing a wild red herring. The reason is that the Azrael isn't given two goals, undock and warp out, with the same priority; it's told to warp out as soon as the undocking as finished. So it probably has something to do with the undock goal either not completing or not being cleared properly. That ought to narrow the bug down to either aigoals or aicode. So it looks like the current goal sorting code (with insertion sort and with the -1, 0, 1 comparison) is correct. EDIT: Simultaneous posting again. :p AIS_UNDOCK_2 sounds promising. edited on: 06-25-06 23:16 |
|
|
Well, I replaced dock_orient_and_approach, dock_move_towards_point, and set_goal_dock_orient with their retail versions, and the bug still happened. :( |
|
|
I'll spend some real time with this later tomorrow if you don't figure it out first. I have some ideas of what I want to trace in working and non-working builds to help track this down, but I'm far too tired to do that tonight. |
|
|
Only had a few minutes to look at it before I have to do other things today, but my suspicions were confirmed. The build that works does exactly the same thing for the undocking stuff, but one value is off on the build that doesn't work. If you look in ai_dock(), the AIS_UNDOCK_2 case, you see the if() of what it has to do to move the mode 3. Everything is the same between the two builds except the speed. In the builds that work the speed is just above 2.0f, in the builds that don't it's just below 2.0f (and continues to drop each frame). Here's the strange part, I fired up the icculus.org version to test it under retail, and it messed up the same way. Tried it again and that time it worked. The exact same results though, it will undock properly if its speed is over 2.0f, and if it's not then the speed will continually drop each frame until it bottoms out (which doesn't take long). So I'm not really sure that this is even an FSO bug, it may have been there already but just due to float precision (it's above or below 2.0f by about 0.002-0.004 at most) it wasn't an issue previously. I'll work on this some more tonight. |
|
|
Hmm. Well then there are two separate bugs here: the speed thing, and the move thing. The ships shouldn't move together if they're physically disconnected. I'll have a look at the move bug. I'm assuming it's something in the death roll that I didn't handle when I added the new docking code. What we need to do now is find out at what date the Iceni started changing position ***when the transport fails to undock properly***. That should make interesting hunting. :p edited on: 06-26-06 12:29 |
|
|
That's what I'm saying though, I got it to happen in *retail code*. The *exact* same thing. The Azrael didn't undock properly, when it was destroyed the Iceni jumped positions. The jumping thing is from retail, the undocking thing looks to be little more than floating point error and also appears to exist in retail code. Simply changing the test to ((goal_objp->phys_info.speed + 0.005f) > MAX_UNDOCK_ABORT_SPEED) makes it (the undocking issue) not happen anymore in any of the code that I've tested, even current CVS. |
|
|
Okay, I'm pretty sure that my new code is the problem; this bug merely caused it to manifest. The old code has a "dock_objnum_when_dead" field, and the new code doesn't. EDIT: Simultaneous again. The jumping thing happened in retail too? edited on: 06-26-06 12:56 |
|
|
Ugh, now it won't do it. Retail's still doing the undock thing, but I can't get it to jump again. A fluke perhaps? Maybe it was something that I managed to trigger with my debugging code somehow. Not sure, I already removed the debugging code, but assume that I'm just stupid there. :p The undocking issue I quadruple checked (again) though, so that's deffinitely a retail thing. If you've got a reason for the jumping then go for it. |
|
|
Yup, I was right about the cause of the spinning bug. Good thing, too, because it took a significant amount of code to fix. :p I'll commit this as soon as I have a diff ready for the main branch. You can go ahead and commit your floating point fix, and I'll mark this as resolved once both are in. :) |
|
|
Ok, fp fix should be in both branches now. |
|
|
Yay. :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-01-17 12:16 | thesource2 | New Issue | |
| 2006-01-17 17:22 | WMCoolmon | Note Added: 0004352 | |
| 2006-01-17 17:22 | WMCoolmon | Assigned To | => Goober5000 |
| 2006-01-17 17:22 | WMCoolmon | Status | new => assigned |
| 2006-01-17 21:06 | thesource2 | Note Added: 0004355 | |
| 2006-01-17 22:28 | taylor | Note Added: 0004358 | |
| 2006-01-18 07:55 | thesource2 | Note Added: 0004368 | |
| 2006-01-18 11:40 | taylor | Note Added: 0004372 | |
| 2006-01-20 09:03 | thesource2 | Note Added: 0004417 | |
| 2006-05-13 14:58 | thesource2 | Note Added: 0005509 | |
| 2006-06-03 05:46 | Goober5000 | Note Added: 0005725 | |
| 2006-06-22 20:02 | Goober5000 | Note Added: 0005921 | |
| 2006-06-25 21:35 | Goober5000 | File Added: SM3-03.fs2 | |
| 2006-06-25 22:02 | Goober5000 | Note Added: 0005945 | |
| 2006-06-25 22:02 | Goober5000 | Additional Information Updated | |
| 2006-06-25 23:27 | taylor | Note Added: 0005946 | |
| 2006-06-25 23:34 | taylor | Note Edited: 0005946 | |
| 2006-06-26 00:06 | taylor | Note Edited: 0005946 | |
| 2006-06-26 01:41 | Goober5000 | Note Added: 0005947 | |
| 2006-06-26 01:47 | Goober5000 | Note Edited: 0005947 | |
| 2006-06-26 01:50 | Goober5000 | Note Edited: 0005947 | |
| 2006-06-26 01:51 | Goober5000 | Note Edited: 0005947 | |
| 2006-06-26 01:52 | Goober5000 | Note Edited: 0005947 | |
| 2006-06-26 01:53 | Goober5000 | Note Edited: 0005947 | |
| 2006-06-26 01:59 | Goober5000 | Note Edited: 0005947 | |
| 2006-06-26 02:08 | Goober5000 | Note Added: 0005948 | |
| 2006-06-26 02:20 | Goober5000 | Note Edited: 0005948 | |
| 2006-06-26 02:31 | Goober5000 | Note Edited: 0005948 | |
| 2006-06-26 03:02 | taylor | Note Added: 0005949 | |
| 2006-06-26 03:10 | taylor | Note Edited: 0005949 | |
| 2006-06-26 03:14 | Goober5000 | Note Added: 0005950 | |
| 2006-06-26 03:15 | Goober5000 | Note Edited: 0005950 | |
| 2006-06-26 03:16 | Goober5000 | Note Edited: 0005950 | |
| 2006-06-26 03:49 | Goober5000 | Note Added: 0005952 | |
| 2006-06-26 04:21 | taylor | Note Added: 0005954 | |
| 2006-06-26 14:27 | taylor | Note Added: 0005959 | |
| 2006-06-26 16:23 | Goober5000 | Note Added: 0005960 | |
| 2006-06-26 16:27 | Goober5000 | Note Edited: 0005960 | |
| 2006-06-26 16:29 | Goober5000 | Note Edited: 0005960 | |
| 2006-06-26 16:47 | taylor | Note Added: 0005961 | |
| 2006-06-26 16:50 | Goober5000 | Note Added: 0005962 | |
| 2006-06-26 16:56 | Goober5000 | Note Edited: 0005962 | |
| 2006-06-26 17:59 | taylor | Note Added: 0005964 | |
| 2006-06-27 03:15 | Goober5000 | Note Added: 0005965 | |
| 2006-06-27 03:37 | Goober5000 | Additional Information Updated | |
| 2006-06-27 04:33 | taylor | Note Added: 0005966 | |
| 2006-06-27 04:45 | Goober5000 | Status | assigned => resolved |
| 2006-06-27 04:45 | Goober5000 | Resolution | open => fixed |
| 2006-06-27 04:45 | Goober5000 | Note Added: 0005967 |
