View Issue Details

IDProjectCategoryView StatusLast Update
0000930FSSCPgameplaypublic2023-11-01 04:05
ReporterGoober5000 Assigned ToMageKing17  
Status resolvedResolutionfixed 
Target Version3.8Fixed in Version3.8 
Summary0000930: Weird event bug in the FS2 demo campaign
DescriptionThis assert happens in the first mission immediately after the first wave of Libra is destroyed. Reproducible on every playthrough.

The event referred to in the array is Destroy Libra.

Assert: Mission_events[*e2 & 0xffff].born_on_date != 0
File: E:\Languages\Visual Studio Projects\Visual C++\fs2_open\code\Mission\MissionTraining.cpp
Line: 697
[This filename points to the location of a file on the computer that built this executable]

Call stack:
    insertion_sort() sort_training_objectives() training_check_objectives() game_simulation_frame() game_frame() game_do_frame() game_do_state() gameseq_process_events() game_main() WinMain() WinMainCRTStartup() KERNEL32.DLL bff8b560()
    KERNEL32.DLL bff8b412()
    KERNEL32.DLL bff89dd5()
Steps To ReproduceDemo campaign can be downloaded from this thread.,36960.0.html
TagsNo tags attached.



2006-06-01 08:36

administrator   ~0005684

Libra being destroyed is considered a special event. Special events don't appear to get a timestamp() for born_on_date (in missiongoals.cpp, mission_get_event_status()).

I'm not really into the mission design aspect of this thing, but from the mission it looks like Virgo wing has an arrival que with is-destroyed-delay for only 3 of the 4 ships from Libra wing. This would give it a partial true (I think) and then be considered a special event. You know that stuff a lot better than I do though so I'll leave the rest to you to figure out. ;)


2006-07-16 00:17

administrator   ~0006194

* BUMP *

... umm, just because it should be bumped, I guess ...


2006-07-16 00:36

administrator   ~0006195

LOL. :)

Yeah, not really sure what to do here. Also, it's low on the priority list.


2009-06-07 15:29

reporter   ~0010958

1) Very old (almost 3 years now!)
2) Demo???
3) There are |<---->| <- that many changes since then


2017-01-23 04:48

administrator   ~0016852

Reopening since MageKing17 has independently discovered, and made progress on, the same issue.


2017-01-23 04:56

developer   ~0016853

It's also not limited to the demo; any similarly-constructed event would have the same issue (of course, it's such a strange way to make an event that I'm not surprised nobody's complained about this assertion outside the demo). Since it works just fine in Release builds, and I can see no inherent reason to prohibit sorting just because born_on_date is 0, just removing the assertions would seem to be the simplest solution; that's what will be in the PR I'll be submitting soonish to fix this and other demo-related issues.


2017-01-24 20:53

developer   ~0016855

And here's the PR:


2017-02-03 22:47

developer   ~0016858

The PR was merged; this assertion is a thing of the past.


2020-04-14 00:46

administrator   ~0016976

I finally discovered that the *actual* cause of this bug is that born_on_date is never initialized when the event is parsed. An upcoming PR will fix this.


2020-04-14 03:11

administrator   ~0016977

Actually, I take that back. It is initialized, just not in the place I thought it would be. Carry on.


2023-11-01 04:05

administrator   ~0017151

And finally, I think I've nailed the actual *actual* cause of this bug. See Github 5747:

Issue History

Date Modified Username Field Change
2006-06-01 06:05 Goober5000 New Issue
2006-06-01 06:06 Goober5000 Description Updated
2006-06-01 08:36 taylor Note Added: 0005684
2006-07-16 00:17 taylor Note Added: 0006194
2006-07-16 00:36 Goober5000 Note Added: 0006195
2009-06-07 15:29 portej05 Status new => closed
2009-06-07 15:29 portej05 Note Added: 0010958
2009-06-07 15:29 portej05 Resolution open => no change required
2017-01-23 04:48 Goober5000 Assigned To => MageKing17
2017-01-23 04:48 Goober5000 Status closed => assigned
2017-01-23 04:48 Goober5000 Note Added: 0016852
2017-01-23 04:56 MageKing17 Note Added: 0016853
2017-01-24 20:53 MageKing17 Status assigned => code review
2017-01-24 20:53 MageKing17 Note Added: 0016855
2017-02-03 22:47 MageKing17 Status code review => resolved
2017-02-03 22:47 MageKing17 Resolution no change required => fixed
2017-02-03 22:47 MageKing17 Fixed in Version => 3.8
2017-02-03 22:47 MageKing17 Target Version => 3.8
2017-02-03 22:47 MageKing17 Note Added: 0016858
2020-04-14 00:46 Goober5000 Status resolved => assigned
2020-04-14 00:46 Goober5000 Resolution fixed => reopened
2020-04-14 00:46 Goober5000 Note Added: 0016976
2020-04-14 03:11 Goober5000 Status assigned => resolved
2020-04-14 03:11 Goober5000 Resolution reopened => fixed
2020-04-14 03:11 Goober5000 Note Added: 0016977
2023-11-01 04:05 Goober5000 Note Added: 0017151