Hard Light Productions Forums

General FreeSpace => FreeSpace & FreeSpace Open Support => Topic started by: CT27 on November 14, 2017, 07:46:48 pm

Title: Luyten Civil War technical problem
Post by: CT27 on November 14, 2017, 07:46:48 pm
In the "Luyten Civil War" campaign (mission "From My Cold Dead Hands") I ran into a technical problem I haven't encountered before.

I'm supposed to scan certain parts of the Arcadia station in the mission.  In the directives list I'm supposed to scan four [4] parts of the station.  The parts are represented by items in the escort list.  However, when I scan a part, the directives list stays at [4] and doesn't go down.  I scan all four points but the directive stays at [4].  After I've scanned all four nothing happens and I can't progress in the mission.

I tried a debug build and got this when I hit play on the launcher:
Assert: "first_frame != -1"
File: missionshipchoice.cpp
Line: 2807
Failed to load icon iconINFFighter02


ntdll.dll! ZwWaitForSingleObject + 10 bytes
KERNELBASE.dll! WaitForSingleObjectEx + 156 bytes
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
kernel32.dll! BaseThreadInitThunk + 13 bytes
ntdll.dll! RtlUserThreadStart + 33 bytes
[...]
[ This info is in the clipboard so you can paste it somewhere now ]


Use Debug to break into Debugger, Exit will close the application.

ntdll.dll! ZwWaitForSingleObject + 10 bytes
KERNELBASE.dll! WaitForSingleObjectEx + 156 bytes
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
fs2_open_3_8_1_20171022_4e7f8fa_x64_SSE2-FASTDBG.exe! <no symbol>
kernel32.dll! BaseThreadInitThunk + 13 bytes
ntdll.dll! RtlUserThreadStart + 33 bytes

I was playing on a post 3.8.0 nightly.  A log is also attached.


[attachment stolen by Russian hackers]
Title: Re: Luyten Civil War technical problem
Post by: TopAce on November 15, 2017, 12:33:49 pm
I tested it with a 22 October nightly and it didn't work for me either. Weird. It surely worked when the mod was released. I don't know what's going on here, but I'll investigate it tomorrow.
Title: Re: Luyten Civil War technical problem
Post by: Novachen on November 15, 2017, 01:32:22 pm
Mhh.. i have changed the ship-vanish SEXP for the investigation points with the destroy-instantly SEXP and it worked.

Maybe ship-vanish works different now and the game forgot everything what the player have done with the object. Especially if the object has a arrival cue, maybe the game still thinks, that the object is still there. I don't know.

Put that into data\missions.



[attachment stolen by Russian hackers]
Title: Re: Luyten Civil War technical problem
Post by: CT27 on November 15, 2017, 05:49:14 pm
Thanks Novachen.

 I played the mission through the techroom and it worked.
Title: Re: Luyten Civil War technical problem
Post by: Goober5000 on November 21, 2017, 05:24:49 pm
Mhh.. i have changed the ship-vanish SEXP for the investigation points with the destroy-instantly SEXP and it worked.

Maybe ship-vanish works different now and the game forgot everything what the player have done with the object.

This is the correct problem and solution.  I just looked at the code.  For ships that are no longer in the mission, the code checks the status which is saved when a ship departs or is destroyed.  This status is not saved when a ship is vanished.

I am not sure why the sexp worked previously.  It was rewritten at one point, but the rewrite did not affect that aspect.
Title: Re: Luyten Civil War technical problem
Post by: TopAce on November 22, 2017, 04:43:04 am
So if I understand you correctly, all missions with ship-vanish must be fixed?
Title: Re: Luyten Civil War technical problem
Post by: Goober5000 on November 22, 2017, 08:37:17 am
It depends on how ship-vanish is used.  The sexp is designed to make the ship disappear without a trace.  So sexps should not really refer to ships after they have vanished, due to unpredictable effects.

In this case, the sexp that broke was cargo-known-delay.  I don't know if any other sexps would break.
Title: Re: Luyten Civil War technical problem
Post by: Novachen on November 22, 2017, 01:33:26 pm
I am not sure why the sexp worked previously.  It was rewritten at one point, but the rewrite did not affect that aspect.

In the original mission it is visible, that the objectives goes down to [3] for a brief moment, before the Investigation point vanishes and the number goes up to [4] again. But actually... because if one Point vanish it should be the same as this point was never in the mission in the first place for the game. And so there should not be never 4 ships to scan. I think that another sexp was also rewritten so that this one does not work anymore.

Actually i still think, that this one have to do more with the warpless Arrival Cue the four ships have. Because with it there is a evidence (aka Log) for the game, that the ships have arrived in the mission and so there are still in the mission as long there is no log about their departure or destruction.

Would be intesting if this would work, if you use ship-create instead.
Title: Re: Luyten Civil War technical problem
Post by: AdmiralRalwood on November 22, 2017, 07:13:48 pm
Actually i still think, that this one have to do more with the warpless Arrival Cue the four ships have. Because with it there is a evidence (aka Log) for the game, that the ships have arrived in the mission and so there are still in the mission as long there is no log about their departure or destruction.
Not quite; the way a SEXP like is-cargo-known-delay determines if a ship is present is by iterating through every single ship in the mission and comparing their names; it only checks the mission log to see if it's already departed. In other words, it doesn't check for the ship having arrived at all; it just assumes that anything that hasn't departed/been destroyed and isn't currently in the mission must not have arrived yet.