Incorrect virtual offsets for CBaseObject in TF2 on Windows

[nosoop]

As requested, here's the vtable dumper mismatch that was initially reported on Discord:

• CBaseObject::CanBeUpgraded(CTFPlayer*) is offset 375, dumper reports 374
• CBaseObject::StartUpgrading() is offset 376, dumper reports 375
• CBaseObject::GetMaxUpgradeLevel() is offset 380, dumper reports 379

[2:24 PM] nosoop: curious what's different between win/linux for the CBaseObject table, windows offsets are off by one there [...] [2:25 PM] nosoop: I mean the windows offset is off by one from actual (CBaseObject::CanBeUpgraded(CTFPlayer) is 375, not 376 as the webapp reports) [...] [3:21 PM] asherkin: ah, multiple inheritance [3:26 PM] asherkin: I suspect the problem is it thinking that FindObjectOnBuildPoint should be skipped on Windows [3:28 PM] asherkin: the confusion seems to be because that is both on the actual CBaseObject vtable and one of the MI classes [3:29 PM] asherkin: in fact I think that case is one of the main ones that led to the "This class uses C++ features which can not be accounted for by this tool." as there doesn't seem to be a way to tell them apart

edit: mixed up the dumper results because of a copy/paste error, my bad

[nosoop]

Confus. The dumper-reported values were actually off by -2. These should be correct now.

Same issue as #7; FindObjectOnBuildPoint is indeed skipped on Windows (the dumper is correct on this one), but CanBeUpgraded is overloaded, and there is a CBaseObject::CanBeUpgraded(void) inserted at offset 374 (all the other entries are shifted one to the right).

[nosoop]

Have to watch out for subclasses, though; CTFPlayer::ChangeTeam(int) exists as an override for CBaseEntity, but CTFPlayer also implements its own CTFPlayer::ChangeTeam(int, bool, bool, bool) exclusive to it and its subclasses. Can't make those contiguous.