Add CnCNet YR branch changes to mainline branch#68
Conversation
|
Nightly build for this pull request:
This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build. |
|
any reason to gate desync fixes behind CnCNet YR? I think they'll be useful for everyone, even if not optimal (better than desyncing) |
|
other than that lgtm |
Mainly as it's not been reviewed. Have made it available to all now. |
ZivDero
left a comment
ZivDero
left a comment
There was a problem hiding this comment.
Not a whole lot that's controversial here. The PR name could be adjusted though - it does a bit more than just move something :D
| // HouseClass::Flag_Remove: clears the flag home cell overlay without RecalcAttributes. | ||
| DEFINE_HOOK(0x4FBF3C, HouseClass_Flag_Remove_RecalcAttributes, 0x5) | ||
| { | ||
| GET(CellClass*, pCell, EAX); | ||
| pCell->RecalcAttributes(DWORD(-1)); | ||
| return 0; | ||
| } |
There was a problem hiding this comment.
Does this affect anything? It's not like CTF works
| DEFINE_HOOK(0x56F712, MapBridge_56F690_Damaged_EAX_F1, 0x7) | ||
| { | ||
| GET(CellClass*, pCell, EAX); | ||
| pCell->OverlayData = 0xF; |
There was a problem hiding this comment.
It would be nice to name the various magic numbers but if you can't, not a huuuge deal.
|
|
||
| // NOTE: Overrides incorrect Ares hook at the same address. | ||
| // Simplified: always apply the cloak check without configurable open-topped behavior. | ||
| DEFINE_HOOK(0x6FCA26, TechnoClass_CanFire_RevertAresOpenTopCloakFix, 0x6) |
There was a problem hiding this comment.
Does this apply after Ares reliably?
There was a problem hiding this comment.
Yes it has worked perfectly for a while now in YR build
There was a problem hiding this comment.
Unless it has been changed in SyringeEx (like does the DLL whitelist also make the DLL injection order fixed? I don't remember), the way this used to work was 'first come, first served' and the hooks execute in the order they are declared in syshk of DLL and the DLL order likewise follows the order they are injected in, which depends on what Win32 FindFile returns. So it is likely to be same on a lot of systems but there's no real guarantee.
EDIT: At quick glance I think the DLL load list also specifies the order so it probably behaves deterministically with that feature in use.
There was a problem hiding this comment.
I still think that if possible it should be placed earlier to exclude a possible fuckup of wrong order
Metadorius
changed the title
5 participants
Adds the current CnCNet YR spawner fixes behind the existing
IS_CNCNET_YR_VERso they are only included in CnCNet YR builds.Includes:
Can be deleted once this is merged:
https://github.com/CnCNet/yrpp-spawner/tree/current-cncnet-yr-build