2018-09-26 05:55 EDT


View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0002783FSSCPmultiplayerpublic2013-01-30 02:39
ReporterGoober5000 
Assigned ToGoober5000 
PrioritynormalSeveritycrashReproducibilityalways
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0002783: Multiplayer respawn code can't keep its ship classes straight
DescriptionCopied from 0002326...

For some reason, client parse objects already have the correct ship class of the ship they're respawning into. That seems to be causing trouble with change_ship_type, although upon reflection it really shouldn't. Nevertheless, skipping the ship class change seems to fix it. (Strangely, server parse objects retain their parsed ship class as expected.)

EDIT: For posterity, the problem in change_ship_type is most likely due to the parse object's ship_class being assigned to the new class, while its ship_max_hull_strength (and ship_max_shield_strength, and who knows what else) stayed at the original, parsed values.
TagsNo tags attached.
Attached Files

-Relationships
related to 0002326resolvedThe_E Assert: hull_pct > 0.0f && hull_pct <= 1.0f in ship.cpp line 8298 
+Relationships

-Notes

~0014672

Goober5000 (administrator)

Last edited: 2013-01-30 02:20

View 2 revisions

And thanks to a variable breakpoint, the culprit appears to be line 714 in multiutil.cpp. Guessing this is an old bug from way back when multiplayer was first being developed.

EDIT:
     Net_players[net_player].p_info.p_objp->ship_class = ship_class; // be sure this gets set so respawns work

~0014673

Goober5000 (administrator)

Fix committed to trunk@9516.

~0014674

Goober5000 (administrator)

For reference, I confirmed this fix by locally reverting the fix for 0002326 and then confirming that the crash no longer occurred.
+Notes

+Related Changesets

-Issue History
Date Modified Username Field Change
2013-01-30 02:19 Goober5000 New Issue
2013-01-30 02:19 Goober5000 Status new => assigned
2013-01-30 02:19 Goober5000 Assigned To => Goober5000
2013-01-30 02:19 Goober5000 Relationship added related to 0002326
2013-01-30 02:20 Goober5000 Note Added: 0014672
2013-01-30 02:20 Goober5000 Note Edited: 0014672 View Revisions
2013-01-30 02:23 Goober5000 Changeset attached => fs2open trunk r9515
2013-01-30 02:32 Goober5000 Changeset attached => fs2open trunk r9516
2013-01-30 02:32 Goober5000 Note Added: 0014673
2013-01-30 02:32 Goober5000 Status assigned => resolved
2013-01-30 02:32 Goober5000 Resolution open => fixed
2013-01-30 02:39 Goober5000 Note Added: 0014674
+Issue History