2019-10-21 17:25 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001661FSSCPmultiplayerpublic2009-03-17 16:26
ReporterFUBAR-BDHR 
Assigned Tokarajorma 
PriorityhighSeveritymajorReproducibilityrandom
StatusresolvedResolutionfixed 
Product Version3.6.9 
Target VersionFixed in Version3.6.10 
Summary0001661: Transports departing via docking bay do not disappear from client side
DescriptionThis is another old retail bug. Transports ordered to depart using a docking bay leave on the host side but still show up on client side for some players. It does not happen to all clients just some of them.
Additional InformationExisted since retail. Last tried in 3/14 XT. Attaching mission that I know it happens in, screenshot of a departed transport inside of the hull of a Lucifer and the debug log from that game.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0009217

FUBAR-BDHR (developer)

Forgot to mention that game ended in an F4 freeze which might be in the log file. I added it to the F4 freeze report as well.

~0009231

Goober5000 (administrator)

Bleh. I fixed the single-player version of this bug some time ago, but I forget the circumstances.

~0009274

Goober5000 (administrator)

Ugh, now I can't even reproduce this in retail. What are the exact steps needed to trigger this bug?

~0009277

FUBAR-BDHR (developer)

Well you need to be on the client side of multi even for it to happen it retail. It's random even then. The test run we did with the attached mission even resulted in different results for each client. The mission in the file I attached has it happen quite a bit even in retail. I even went as far as adding an additional warpout for the clients which helped but didn't fully work around the problem.

~0009278

Goober5000 (administrator)

I am trying to reproduce this in singleplayer, in retail, because this is the classic case of something being fixed in singleplayer and the fix not being applied to multi. Karajorma has fixed many sexps along these lines; this is another example of the same thing.

So I need to know exactly how to reproduce this bug. Cut the mission down into the bare essentials which trigger the bug, or write down the exact in-game steps that the player needs to do.

~0009281

FUBAR-BDHR (developer)

In that mission here are the steps that result in the behavior. One Lucifer class ship hostile iff. Several friendly Satis and Bes transports with both arrival and departure set to true. Arrival is just set using delay, departure set to docking bay of the Lucifer. So basically they warp in and head straight for the docking bay. When they depart they don't disappear.

That's pretty much it. The only other thing that has to do with those ships is a few events that count the number of transports that docked but nothing that should effect departure.

I'll try to strip everything out of that mission tonight.

~0009879

chief1983 (administrator)

FUBAR, catch me sometime and we'll test for this bug. I grabbed the mission already. Going to high priority for now.

~0009964

FUBAR-BDHR (developer)

Confirmed that it still exists tonight. Played the actual mission no the test one and 2 Bes and a Sertis were still there on the client side.

~0009967

Goober5000 (administrator)

That's not going to help much, unless you can provide an extremely detailed debug log (and possibly not even then). The bug is already fixed in singleplayer; looking for it in multiplayer is going to be a lot tricker.

I need a way to reproduce the bug in singleplayer retail, so I can track down the original bugfix.

~0009968

FUBAR-BDHR (developer)

Hate to ask this but might there be a change log or something that might help. I never did any single player stuff so I don't remember this ever existing in single so it's hard to make a single player mission where it happens.

All I can try to do is see if it only happens with certain types of ships and if there is any pattern.

~0009969

FUBAR-BDHR (developer)

Shot in the dark here but check out the code around line 2740 of aigoals.cpp and 5492 of multimsgs.cpp There are some comments that seem like the fixes were a best guess and might need some fixes later. Granted I haven't programmed since the DOS days but after searching all night... Well it's just a feeling that this might be it and someone that knows what they are doing might make sense of it. Of course it's more likely the beer.

~0009982

FUBAR-BDHR (developer)

I ran some more tests. It's not just some clients or some ships but all ships. The client side event log shows the arrival and departure of the ships. The ships just do not leave the game.

Looks like the client side is receiving the departure info and placing it in the log but not doing the removal from the game.

It's not ship dependent. I tried several types of transports as well as a Typoon instead of a Luci with the same results.

Screenshots from 2 both runs including F4 event log from the client side
(which for some reason is working today) as well as the usual logs in the new attachment. Hopefully it will narrow it down a bit.

~0009983

Goober5000 (administrator)

Ah. *That* is much more useful. :) Thanks.

I will try to take a look at this sometime this week.

~0010703

karajorma (administrator)

If there's not been any progress on this I can take a look. I've got a fair idea where to start at least :)

~0010704

Goober5000 (administrator)

Sure, have at it. I won't have time to take a look for the rest of this week at least... :sigh:

~0010708

karajorma (administrator)

As far as I can see there's no way for any ship to depart via the bay on a client machine. This shouldn't just affect transports it should affect everything. (I couldn't get Beta wing to depart in the test I made).

~0010709

karajorma (administrator)

Fixed this one in my branch.

~0010751

karajorma (administrator)

Fixed in trunk
+Notes

-Issue History
Date Modified Username Field Change
2008-04-13 00:32 FUBAR-BDHR New Issue
2008-04-13 00:32 FUBAR-BDHR File Added: 04-12-08a.rar
2008-04-13 01:11 FUBAR-BDHR Note Added: 0009217
2008-04-17 22:05 Goober5000 Note Added: 0009231
2008-04-30 02:09 Goober5000 Status new => assigned
2008-04-30 02:09 Goober5000 Assigned To => Goober5000
2008-04-30 03:35 Goober5000 Note Added: 0009274
2008-04-30 07:17 FUBAR-BDHR Note Added: 0009277
2008-04-30 07:37 Goober5000 Note Added: 0009278
2008-04-30 20:03 FUBAR-BDHR Note Added: 0009281
2008-05-01 02:35 FUBAR-BDHR File Added: 1661.fs2
2008-10-09 00:40 chief1983 Note Added: 0009879
2008-10-09 00:40 chief1983 Priority normal => high
2008-10-14 00:22 FUBAR-BDHR Note Added: 0009964
2008-10-14 00:36 Goober5000 Note Added: 0009967
2008-10-14 01:14 FUBAR-BDHR Note Added: 0009968
2008-10-14 02:15 FUBAR-BDHR Note Added: 0009969
2008-10-14 17:58 FUBAR-BDHR File Added: 1661tests.rar
2008-10-14 18:03 FUBAR-BDHR Note Added: 0009982
2008-10-14 18:44 Goober5000 Note Added: 0009983
2009-03-02 18:10 karajorma Note Added: 0010703
2009-03-02 18:38 Goober5000 Note Added: 0010704
2009-03-03 12:57 karajorma Assigned To Goober5000 => karajorma
2009-03-03 12:59 karajorma Note Added: 0010708
2009-03-05 17:21 karajorma Note Added: 0010709
2009-03-17 16:26 karajorma Status assigned => resolved
2009-03-17 16:26 karajorma Fixed in Version => 3.6.10
2009-03-17 16:26 karajorma Resolution open => fixed
2009-03-17 16:26 karajorma Note Added: 0010751
+Issue History