Source Code Project Mantis - FSSCP
View Issue Details
0002107FSSCPFREDpublic2010-01-28 19:162021-01-09 05:19
ReporterFUBAR-BDHR 
Assigned Tokarajorma 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionsuspended 
PlatformOSOS Version
Product Version3.6.11 
Target VersionFixed in Version 
Summary0002107: Dogfight loadout screen crashes with default (non-dogfight) weapons
DescriptionFiling this under FRED as it's something it should catch. If you just toss a couple of ships in a mission and make it a dogfight the weapons are non-dogfight variants. This results in a not all ships have primaries message in loadout. If you click on the weapons screen to assign them is crashes trying to draw the default non-dogfight weapon.
Additional Information3.6.11 latest but pretty sure any build will do this. To reproduce just toss a Ulysses in FRED and make the mission a dogfight. You will see that the weapons are still the regular non-dogfight versions. Run it and it will crash. Change to -D variants and it works.
TagsNo tags attached.
Attached Files

Notes
(0011879)
karajorma   
2010-04-13 07:25   
Why do the weapons in a dogfight mission have to be the dogfight versions anyway? I thought the point of the dogfight versions was simply to balance the weapons a bit more so that the player could play with whichever ship they liked without being penalised by their weapon selection.
(0011880)
FUBAR-BDHR   
2010-04-13 16:41   
They don't have to be dogfight versions but they do have to be in the dogfight list. FRED isn't checking to see if they are in the valid dogfight weapon list.

I really think the dogfight primary and secondary lists in the tables are overkill. It should be up to the FREDder to set the right versions for the mission. If he wants to make a non dogfight variant mission it should be possible without table changes. TvT loadout list would have actually made sense for squadwar.
(0017062)
MjnMixael   
2021-01-09 05:19   
Migrated issue to Github.

Note: In the 20.0.0 builds the crash on weapon select no longer occurs. This is now just an issue that FRED should warn about.


Issue History
2010-01-28 19:16FUBAR-BDHRNew Issue
2010-04-13 07:25karajormaNote Added: 0011879
2010-04-13 16:41FUBAR-BDHRNote Added: 0011880
2012-12-30 10:41karajormaAssigned To => karajorma
2012-12-30 10:41karajormaStatusnew => assigned
2021-01-09 05:19MjnMixaelStatusassigned => closed
2021-01-09 05:19MjnMixaelResolutionopen => suspended
2021-01-09 05:19MjnMixaelNote Added: 0017062
2021-01-09 05:19MjnMixaelNote Edited: 0017062bug_revision_view_page.php?bugnote_id=17062#r1104