View Issue Details

IDProjectCategoryView StatusLast Update
0001934FSSCPgameplaypublic2010-01-07 04:18
Reporterchief1983 Assigned Tochief1983  
PrioritynormalSeverityblockReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.6.11 
Target Version3.6.12 RC1Fixed in Version3.6.11 
Summary0001934: When using ships without secondaries, switching to a ship with secondaries leaves them blocked
DescriptionYes, I know, I could just be using a NULL weapon, but it really shouldn't be necessary to have secondaries equipped I don't think. I've already coded in a way around needing them equipped to play in multiplayer, but I can't figure out why switching from a secondary-less to a secondary-equipped fighter seems to leave the secondaries locked in the game. They're equipped, but just won't fire. I'm guessing there's some flag getting set when the fighter has no secondaries that's locking them and then it's not being unlocked when the ship is switched. If someone could even help point me at the code that might do this it would help.
Additional InformationAdditionally, FRED complains about these fighters on save/open of a mission containing them. Would be great if it did not when a mesh has no secondary slots.
TagsNo tags attached.

Activities

chief1983

2009-11-10 03:27

administrator   ~0011230

It would be great if this could get fixed this month, it's one of FotG's only real release blockers. Not sure how close we are but it's being a hindrance on development too. Can't effectively balance anything.

2010-01-07 02:42

 

bug1934.7z (121,462 bytes)

chief1983

2010-01-07 02:43

administrator   ~0011499

Added a mod folder for retail data to reproduce this bug. Load the mission, change to regular Herc Mk 2, and note that secondaries are showing but not selectable nor fireable.

2010-01-07 04:02

 

1934.diff (1,598 bytes)   
Index: code/fred2/fredview.cpp
===================================================================
--- code/fred2/fredview.cpp	(revision 5786)
+++ code/fred2/fredview.cpp	(working copy)
@@ -2446,7 +2446,7 @@
 					}
 				}
 
-				if (!count){
+				if (!count && Ships[i].weapons.num_secondary_banks > 0){
 					if (error("Player \"%s\" has no secondary weapons.  Should have at least 1", Ships[i].ship_name)){
 						return 1;
 					}
Index: code/ship/ship.cpp
===================================================================
--- code/ship/ship.cpp	(revision 5786)
+++ code/ship/ship.cpp	(working copy)
@@ -8082,6 +8082,7 @@
 	ship_info	*sip;
 	ship_info	*sip_orig;
 	ship			*sp;
+	ship_weapon *swp;
 	object		*objp;
 	p_object	*p_objp;
 	float hull_pct, shield_pct;
@@ -8090,6 +8091,7 @@
 	Assert( n >= 0 && n < MAX_SHIPS );
 	sp = &Ships[n];
 	sip = &(Ship_info[ship_type]);
+	swp = &sp->weapons;
 	sip_orig = &Ship_info[sp->ship_info_index];
 	objp = &Objects[sp->objnum];
 
@@ -8291,6 +8293,12 @@
 		}
 	}//end AB trails -Bobboau
 
+	// Chief1983: Make sure that when changing to a new ship with secondaries, you switch to bank 0.  They still won't 
+	// fire if the SF2_SECONDARIES_LOCKED flag is on as this should have carried over.
+	if ( swp->num_secondary_banks > 0 && swp->current_secondary_bank == -1 ){
+		swp->current_secondary_bank = 0;
+	}
+
 /*
 	Goober5000 (4/17/2005) - I'm commenting this out for the time being; it looks like a whole bunch of unneeded
 	code.  It should be (and probably is) handled elsewhere, like ship_set or ship_create or something.  Contact
1934.diff (1,598 bytes)   

chief1983

2010-01-07 04:03

administrator   ~0011500

Got it. Tested that it doesn't affect locking secondaries via SEXPs, got rid of FRED bitching when there are no secondary banks on the ship. Patch attached.

chief1983

2010-01-07 04:18

administrator   ~0011501

Committed in r5788.

Issue History

Date Modified Username Field Change
2009-06-05 15:37 chief1983 New Issue
2009-11-10 03:27 chief1983 Note Added: 0011230
2009-11-10 03:27 chief1983 Status new => confirmed
2009-11-10 03:27 chief1983 Target Version => 3.6.12 RC1
2010-01-07 02:33 chief1983 Additional Information Updated
2010-01-07 02:42 chief1983 File Added: bug1934.7z
2010-01-07 02:43 chief1983 Note Added: 0011499
2010-01-07 04:02 chief1983 File Added: 1934.diff
2010-01-07 04:03 chief1983 Note Added: 0011500
2010-01-07 04:03 chief1983 Assigned To => chief1983
2010-01-07 04:03 chief1983 Status confirmed => feedback
2010-01-07 04:18 chief1983 Note Added: 0011501
2010-01-07 04:18 chief1983 Status feedback => resolved
2010-01-07 04:18 chief1983 Resolution open => fixed
2010-01-07 04:18 chief1983 Fixed in Version => 3.6.11