2021-03-09 04:35 EST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002715FSSCPgameplaypublic2020-04-13 16:36
Assigned ToGoober5000 
PlatformOSWindows 7OS Version
Product Version3.6.13 
Target Version3.8Fixed in Version 
Summary0002715: Weapons are always loaded on top banks when some banks are empty
DescriptionIf some banks are left empty on the loadout screen, whatever weapons were selected in the other banks will be shifted toward the top banks.
For example if on the loadout screen you have :
Bank 1: empty
Bank 2: weapon 1
Bank 3: weapon 2

In mission you will have
Bank 1: weapon 1
Bank 2: weapon 2
Bank 3: empty

This is potentially heavily balance-breaking as it can alow a player to entirely bypass per-bank weapon restrictions, like for example loading an Archer on the hexa bank of an Uriel instead of the single underslung bank.

Confirmed with both primary and secondary banks.
Steps To ReproduceLoad a mission with ships that have at least two banks.

Put weapons only in bottom bank(s).

Load mission.

Watch in external mode what bank is actually firing when you fire.
TagsNo tags attached.
Attached Files

parent of 0002355closed Primary and secondary banks with no default weapons cannot be set 



MatthTheGeek (reporter)

Also confirmed with both 2-bank and 3-bank configurations. Tested on latest trunk, but it very much sounds like it is a retail-era bug.


niffiwan (developer)

Last edited: 2012-11-16 03:47

View 2 revisions

This is going to be... interesting. The observed behaviour is "as designed". i.e. the loadout code removes any missing weapon entries & moves the weapons in the banks 2+ towards bank 1. This is done because there's an assumption in many places (e.g. firing primaries, switching secondaries, drawing the HUD, probably other places as well) that the ship weapon array starts at zero, there are no gaps/empty banks, and the number of full banks is the number of banks on the ship.

Since this will need a fair bit of refactoring to fix, I think it should be deferred until 3.7.2. It might be an opportunity to refactor all the loadout code at the same time.

edit: also discussed on the IRC whether a possible fix could be preventing the loadout screen from exiting if there were any gaps in the banks. However, this would prevent FREDers from deliberately leaving banks empty if they wished to in their missions.


MjnMixael (manager)

Perhaps a decent work around until then is to create a 'dummy' weapon called Empty and doesn't fire?

Of course the player would have to know to specifically choose to place it where needed...


FUBAR-BDHR (developer)

I was thinking about this last night for some strange reason. What about adding a int primary_bank_flags[MAX_SHIP_PRIMARY_BANKS] and secondary_bank_flags[MAX_SHIP_SECONDARY_BANKS] to the ship_weapon struct. Then a flag such as "unloaded" could be added and checked to leave that weapon there but make it not usable. Additional flags could be added such as "no-rearm" that would prevent reloading of a particular weapon by support and "no-hud" that would work with "unloaded" to not display the weapon on the hud.

These could be set in ships table and altered in FRED. This would also provide a way to fix 0002355 as well as allow for other future features.


MjnMixael (manager)

I could see myself even using a system like that. It's basically a feature request then, though.. so perhaps this (already is) and 2355 should be re-targeted for 3.7.2.


niffiwan (developer)

Thanks for the suggestion, that's more flexible than what I had been thinking of which would have only dealt with the equivalent of the "unloaded" flag.


MageKing17 (developer)

Bumping target.


Goober5000 (administrator)

I took a look at this recently while dealing with one of the Weapon_info vectorization issues. Yes, the behavior is as-designed. I think the best fix will be to prevent the player from exiting the loadout screen with incomplete banks. Scramble missions can bypass this check because presumably FREDders will know what they are doing.


Goober5000 (administrator)

PR opened:


Goober5000 (administrator)

PR merged.

-Issue History
Date Modified Username Field Change
2012-09-22 15:35 MatthTheGeek New Issue
2012-09-22 15:55 MatthTheGeek Note Added: 0013969
2012-10-25 04:54 niffiwan Assigned To => niffiwan
2012-10-25 04:54 niffiwan Status new => assigned
2012-11-16 03:38 niffiwan Note Added: 0014042
2012-11-16 03:39 niffiwan Target Version => 3.7.2
2012-11-16 03:47 niffiwan Note Edited: 0014042 View Revisions
2012-11-16 09:03 MjnMixael Note Added: 0014043
2012-12-12 14:45 FUBAR-BDHR Note Added: 0014429
2012-12-12 14:52 MjnMixael Note Added: 0014430
2012-12-12 16:17 niffiwan Note Added: 0014431
2012-12-12 22:19 Goober5000 Relationship added parent of 0002355
2014-08-20 06:04 niffiwan Target Version 3.7.2 => 3.7.4
2016-03-23 06:02 MageKing17 Note Added: 0016814
2016-03-23 06:02 MageKing17 Target Version 3.7.4 => 3.8
2020-04-12 22:37 Goober5000 Assigned To niffiwan => Goober5000
2020-04-12 22:38 Goober5000 Note Added: 0016963
2020-04-12 23:17 Goober5000 Note Added: 0016964
2020-04-13 16:36 Goober5000 Status assigned => resolved
2020-04-13 16:36 Goober5000 Resolution open => fixed
2020-04-13 16:36 Goober5000 Note Added: 0016974
+Issue History