2021-04-17 14:35 EDT

View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0001863FSSCPmultiplayerpublic2013-05-31 04:11
Assigned Tokarajorma 
Product Version3.6.9 
Target VersionFixed in Version 
Summary0001863: Ships with arrival cue true and delay don't arrive on standalone
DescriptionAnother one of those retail bugs. If you play RI (M-04b.fs2) on a standalone the caps do not show up. The first one's arrival is set to true with a delay of 34 seconds. I've never seen this in any other mission but then again how many multiplayer missions use arrival true with a delay for the cue?
Additional Information3.6.10 r5032 but it's been there since retail. Screenshot shows the log of the second wave of fighters arriving well past the arrival time of the caps but no caps.
TagsNo tags attached.
Attached Files
  • jpg file icon screen0035.jpg (33,494 bytes) 2009-01-05 19:14 -
    jpg file icon screen0035.jpg (33,494 bytes) 2009-01-05 19:14 +
  • patch file icon Mantis_1863.patch (474 bytes) 2013-04-30 01:22 -
    Index: code/freespace2/freespace.cpp
    --- code/freespace2/freespace.cpp	(revision 9660)
    +++ code/freespace2/freespace.cpp	(working copy)
    @@ -982,9 +982,7 @@
     	// Initialize the game subsystems
    -	if(!Is_standalone){
    -		game_reset_time();			// resets time, and resets saved time too
    -	}
    +	game_reset_time();			// resets time, and resets saved time too
     	Multi_ping_timestamp = -1;
    patch file icon Mantis_1863.patch (474 bytes) 2013-04-30 01:22 +

related to 0001815resolvedFSCyborg Player AI ships do not initally attack on standalone 



Galemp (reporter)

This happens in FSPort, too. Mission stmm-04, On the Run, has the same problems. This was verified in testing.


karajorma (administrator)

In tests I found that a ship set to arrive with a 10 second delay was arriving somewhere around 33 seconds after the mission started. It could be that the ships in the other missions would eventually arrive too but by that time everyone has already jumped out.

I can't see any immediate reason why this is occurring. The delay does appear to be parsed correctly but by the time it is used it has been changed. Trying to breakpoint the change left me stuck in disassembly so I suspect that it isn't a deliberate change.


karajorma (administrator)

This patch fixes the issue for me. Turns out that the issue was simply that the timer wasn't being reset for the standalone on mission init.

What's bugging me is that I can't figure out why Volition didn't want the server timer reset (Especially since they reset it a little later when starting the mission anyway).


FUBAR-BDHR (developer)

Wonder if that could be the cause of 1815 as well?


karajorma (administrator)

Hmmmmm. If the initial order involves any kind of timestamp, yes it's quite probably the cause. The ship wouldn't do anything until the timestamp expires.


karajorma (administrator)

Fix committed to trunk@9683.

+Related Changesets

-Issue History
Date Modified Username Field Change
2009-01-05 19:14 FUBAR-BDHR New Issue
2009-01-05 19:14 FUBAR-BDHR File Added: screen0035.jpg
2009-03-07 04:00 Galemp Note Added: 0010718
2009-03-07 19:33 chief1983 Summary Capital ships don't arrive in RI on a standalone => Ships with arrival cue true and delay don't arrive on standalone
2009-03-10 08:10 karajorma Note Added: 0010727
2012-12-30 10:49 karajorma Assigned To => karajorma
2012-12-30 10:49 karajorma Status new => assigned
2013-04-30 01:22 karajorma File Added: Mantis_1863.patch
2013-04-30 01:25 karajorma Note Added: 0014988
2013-04-30 06:46 Echelon9 Status assigned => code review
2013-04-30 11:11 FUBAR-BDHR Note Added: 0015001
2013-05-01 14:22 karajorma Note Added: 0015015
2013-05-02 02:01 karajorma Relationship added related to 0001815
2013-05-31 04:11 karajorma Changeset attached => fs2open trunk r9683
2013-05-31 04:11 karajorma Note Added: 0015100
2013-05-31 04:11 karajorma Status code review => resolved
2013-05-31 04:11 karajorma Resolution open => fixed
+Issue History