2019-10-14 13:27 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001934FSSCPgameplaypublic2010-01-06 23:18
Reporterchief1983 
Assigned Tochief1983 
PrioritynormalSeverityblockReproducibilityalways
StatusresolvedResolutionfixed 
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.
Attached Files
  • 7z file icon bug1934.7z (121,462 bytes) 2010-01-06 21:42
  • diff file icon 1934.diff (1,598 bytes) 2010-01-06 23:02 -
    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
    
    diff file icon 1934.diff (1,598 bytes) 2010-01-06 23:02 +

-Relationships
+Relationships

-Notes

~0011230

chief1983 (administrator)

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.

~0011499

chief1983 (administrator)

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.

~0011500

chief1983 (administrator)

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.

~0011501

chief1983 (administrator)

Committed in r5788.
+Notes

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