Source Code Project Mantis - FSSCP
View Issue Details
0001098FSSCPmultiplayerpublic2006-10-08 22:042008-10-23 00:46
Assigned Totaylor 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version3.6.10 
Summary0001098: Assert: (Weapon_info[Weapons[homing_object->instance].weapon_info_index].wi_flags & WIF_BOMB) || (Weapon_info[Weapons[homing_obj
DescriptionWell that was cut off. Full message is: Assert: (Weapon_info[Weapons[homing_object->instance].weapon_info_index].wi_flags & WIF_BOMB) || (Weapon_info[Weapons[homing_object->instance].weapon_info_index].wi_flags & WIF_CMEASURE)
Second time I've got this error. Might be related to error report 773 that is marked fixed. Received while client during a RI
TagsNo tags attached.
Attached Filesrar Media-10-08-06b.rar (26,996) 2006-10-08 22:04
rar Media-10-08-06c.rar (26,382) 2006-10-08 22:19
rar Media-10-08-06d.rar (29,140) 2006-10-08 22:37
rar Media-10-13-06a.rar (45,518) 2006-10-13 18:29
rar Core2Quad-06-30-08a.rar (20,866) 2008-06-30 21:14
rar Media-06-30-08a.rar (13,625) 2008-06-30 21:14
log fs2_open.log (66,102) 2008-09-12 15:07
diff 1098.diff (5,183) 2008-10-19 10:46

2006-10-08 22:20   
Second time tonight this time in ravana rescue.
2007-09-29 13:47   
I've just seen this one while playing Rebels & Renegades in multiplayer. At first glance it seems to me like someone marked bombs and countermeasures as homing weapons but missed out that missiles can home too.

2007-10-01 03:11   
It's been so long since I've played FS2 or any game for that matter I can't remember what the circumstances behind this were.
2007-10-04 17:39   
weapon_home() seems to have a similar assertion

Assert(Weapon_info[Weapons[hobjp->instance].weapon_info_index].wi_flags & WIF_BOMB);
2007-12-02 20:52   
Hmmmmm. Strange. If I add that assertion to the packet building function it won't assert. Looks like the packet is leaving the server fine but is being built up again incorrectly.

I'll have to look into this further.
2008-06-30 21:13   
Was doing some testing with the Scoring-Changes build and received this a couple of times. Saved the logs from both the server and client side.
2008-09-12 15:08   
Uploaded a new log file from Kara's TeamChatBuild.7z. Looks like some more debug stuff was added so I hope this helps. Was hosting on a standalone. Standalone did not crash.
2008-10-09 12:40   
Hopefully this can be sorted out when Kara or someone can take a look at it, or else bump it back down in priority.
2008-10-09 15:44   
This one is causing me real problems because the packet seems to be leaving the server fine but by the time it reaches the client the net_signature is invalid.

I will try to take another look at it soon.
2008-10-18 14:56   
The net_signature isn't really invalid, it is just assigned to a different object. Every time this Assert() gets hit it's when it's trying to home in on a cmeasure. This really goes back to the fact that counter measures were never valid network objects in the first place. When they were converted to be weapons they started getting valid signatures, but that opens it up to all sorts of problems.

I haven't confirmed it yet, but I think it is due specifically to lifetime of the cmeasure being so short. You can end up with the weapon net signatures getting out of sync. I'm going to attempt to test that out later tonight, but it's going to be difficult to say whether it will be 100% fixed or not. The fact that the cmeasures don't always cause this indicates that it's not lifetime that's the problem, but there is still some situation that causes the signatures to get out of sync, so we just have to start ruling things out.

The Assert() just needs to be followed up with a check to make sure that the game doesn't further pass an invalid object through. This is to prevent badness in weapon_home() (as noted by the Assert() it tends to hit there).
2008-10-18 15:25   
I remember back in retail there was a bug with dual fired Cycs and Helios. If one of the pair was shot down both would disappear from the client side. Been meaning to see if this still exists. Anyway would something like that cause this? Basically a bomb that still exists on the host side but the client doesn't register it as there anymore? He may be able to see it (can't remember the details) but can't shoot it or anything. I did noticed the missions where this happened the most would tend to have a lot of bombs to shoot down. Of course they have a lot of everything else too.

Again I don't even know if that bug still exists in FS2_Open. Just that WIF_BOMB makes me think of it every time I see it.
2008-10-18 17:33   
It shouldn't be related. This bug is caused specifically by the new cmeasure code.

I gave the lifetime thing a check, and ruled it out. But I did figure out that indeed the signatures get out of sync, and it appears to be specifically because of the cmeasures. It appears that when a weapon is typically triggered through the network, the server adds the signature to the packet, then the clients will sync that signature before creating the weapon on their end. This makes sure that the weapon should have the same signature on the client that the host has for it. The old cmeasure code didn't give valid signatures to their objects since there wasn't any need to ever send it over the network (there was just a fired/fire packet, very basic). The new code treats it as a real weapon however, which means that it needs to keep track of the signatures now.

The only way that I see if fix this properly is to bump the server/client version for multi and fix the packet to send the signature to sync with. The alternative fix is to create a new packet for cmeasures, but this will still ultimately break older clients since it still won't sync weapon signatures properly (as both client and host must have this fix in order for it to work). The alternative really isn't a fix in other words, it just addresses the cause while ignoring the result.

Do you see another way to deal with this karajorma?
2008-10-18 19:40   
I think that I might have figured out a way to fix this without breaking anything, without needing a version bump, and without requiring a new packet. You would still need updated builds for client and host in order for the fix to work, but the fix wouldn't break older builds, and older builds wouldn't hurt newer builds.

It might be tomorrow before I can actually code it up and test it out, but if it works then I think that it should effectively solve our problem. :)
2008-10-18 23:45   
Ok, my initial tests show that it is fixed, but not 100%. The cmeasure signatures do stay in sync across host and client, but there are rare instances of duplicate signatures which can cause the same Assert() due to it getting the wrong object. This duplicate signature issue seems to be due to the fact that primary weapons also don't have signature syncing. Secondary weapons do sync however, and now that cmeasures do as well, the various objects are kept in sync overall if not entirely.

I believe that the duplicate signature problem was there in retail as well, but since secondary weapons don't typically target other weapons, it is something that rarely becomes an issue. So, I guess we should just accept it as-is for now and maybe have another look at fixing the duplicate sig problem when we really decided to break the netcode compatibility. For now I think that we should just go with this fix, remove the Assert(), and handle the case with an early return instead for the rare instances that still require it.

These changes will be in my next multi_test build, so if the testers sign off on it, and no devs disagree, then I'll commit at some point next week.
2008-10-19 03:50   
If you can post a diff of the change then I can take a look to see if I can see another way past the problem.
2008-10-19 10:53   
Diff attached.

The fix is to use the rand_val int that it sends over with the cmeasure packet to store the net_signature. The actual value of rand_val doesn't matter since it's use as a random value for velocity and lifetime values that can be identical between client and host. The value is just an objnum, which means that it is always lower than MAX_OBJECTS. This allows us to get away with setting it to a larger number (the signature, which is a minimum of 32768) to indicate the fix to new clients, and older clients don't really care what the value is so long as it's >= -1.

The changes to multiutil.cpp are just to fix some bad checks that V made for the signature values and isn't directly related to the fix for this bug.
2008-10-20 15:18   
Looks good to me.
2008-10-23 00:46   

Issue History
2006-10-08 22:04FUBAR-BDHRNew Issue
2006-10-08 22:04FUBAR-BDHRFile Added: Media-10-08-06b.rar
2006-10-08 22:19FUBAR-BDHRFile Added: Media-10-08-06c.rar
2006-10-08 22:20FUBAR-BDHRNote Added: 0006832
2006-10-08 22:37FUBAR-BDHRFile Added: Media-10-08-06d.rar
2006-10-13 18:29FUBAR-BDHRFile Added: Media-10-13-06a.rar
2007-09-29 13:47karajormaNote Added: 0008547
2007-10-01 03:11FUBAR-BDHRNote Added: 0008549
2007-10-04 17:39karajormaNote Added: 0008554
2007-12-02 20:48karajormaAssigned Totaylor => karajorma
2007-12-02 20:52karajormaNote Added: 0008722
2008-06-30 21:13FUBAR-BDHRNote Added: 0009428
2008-06-30 21:14FUBAR-BDHRFile Added: Core2Quad-06-30-08a.rar
2008-06-30 21:14FUBAR-BDHRFile Added: Media-06-30-08a.rar
2008-09-12 15:07FUBAR-BDHRFile Added: fs2_open.log
2008-09-12 15:08FUBAR-BDHRNote Added: 0009662
2008-10-09 12:40chief1983Note Added: 0009896
2008-10-09 12:40chief1983Prioritynormal => high
2008-10-09 15:44karajormaNote Added: 0009905
2008-10-18 14:56taylorNote Added: 0010035
2008-10-18 15:25FUBAR-BDHRNote Added: 0010038
2008-10-18 17:33taylorNote Added: 0010039
2008-10-18 19:40taylorNote Added: 0010041
2008-10-18 23:45taylorNote Added: 0010042
2008-10-19 03:50karajormaNote Added: 0010045
2008-10-19 10:46taylorFile Added: 1098.diff
2008-10-19 10:53taylorNote Added: 0010047
2008-10-20 03:40taylorAssigned Tokarajorma => taylor
2008-10-20 15:18karajormaNote Added: 0010067
2008-10-23 00:46taylorStatusassigned => resolved
2008-10-23 00:46taylorFixed in Version => 3.6.10
2008-10-23 00:46taylorResolutionopen => fixed
2008-10-23 00:46taylorNote Added: 0010100