fix(weapon): Align Aurora weapon behavior with the GO reference build - #3057
fix(weapon): Align Aurora weapon behavior with the GO reference build#3057Okladnoj wants to merge 1 commit into
Conversation
4714607 to
19408c4
Compare
|
Considering this is a data issue, I think the fix belongs in Patch2 @Stubbjax rather than a hack in the code. |
|
I agree with Skyaero. We do some hacks for UI, but not these kind of hacks for gameplay bugs. We will fix them in INI instead. |
|
The core issue is broader than just Patch2. Because the retail Aurora Alpha omitted MissileCallsOnDie = Yes, any custom mod weapon inspired by or copy-pasted from it over the last 20 years inherited the exact same bug once the deterministic math pr gets merged. |
|
I think key is
Need to understand why. |
|
I do not understand what the root problem is from the given description. My impression right now is if |
That from your's repo |
|
That is Generals Online Repo. |
After all, our ultimate goal is to unite GOD-Team and TSH. If we are talking about determinism in this broader context, shouldn’t we be targeting the GO services? We’ll have to take this Aurora implementation and do something with it anyway. It would be better to make everything a little more synchronized now, ahead of the future merge. This hack will also serve as a reminder of where the set of INI files still needs to be improved. |
|
Can you explain what the cross play bug with MissileCallsOnDie is, if anything? |
|
GO allows more hacks compared to TSH considering one has a live service to run and the other has 20 years of backwards compatibility to consider. (I actually have a test port of "TSH on GO" running locally right now that only includes the networking changes, zero gameplay changes). Instead of looking at this as a data/INI issue, I want to ask: is there a truly fundamental fix we could apply to this in-engine that doesn't involve hardcoding exceptions or altering how the data structure is read?" |
In branch branch, commit At the determinism-consolidation stage I'd advise against getting into whether the fix is "the correct one." GO did it this way, and GO is the only build I can guarantee the result on, so I suggest keeping this fix as-is. Once there's work aimed at fixing the content itself, everything will get sorted out within that scope anyway. screenshot
|
SupW_AuroraFuelBombWeapon does not specify MissileCallsOnDie in INI, so getDieOnDetonate() returns false and MissileAIUpdate::detonate() skips the attemptDamage() call that runs the die modules of the projectile. The second explosion then never happens when the target is a structure. The fix belongs in the game data, which does not live in this repository, so the flag is forced for that one weapon behind PRESERVE_MISSING_AURORA_SECOND_EXPLOSION. Retail builds are unaffected.
19408c4 to
851b1e3
Compare
|
Comment maked shorter |
Maybe you are onto something and there is a determinism bug behind the original Aurora weapon behaviour, but changing (not fixing) the Aurora weapon behavior only masks it. Try to find the root cause. We will change the Aurora weapon behavior in INI. |
Okladnoj
changed the title
There is most likely no determinism violation in the original weapon behavior. It's a matter of choosing the weapon's behavior — first by MrS-ibra (27146d0), then by x64-dev (e08d0ca) on the GOD-Team repo. If it's important to you not to carry this behavior into TSH, I can drop the fix from the mac repo (GOD-Team) and not take it into TSH for the paired mac↔windows network tests. But then I'd have to redo a whole series of manual test runs that could stretch across more than a week: all the easy, obvious desyncs are already fixed, and what's left is very well hidden — tracking down a single small thing can take several days. |
|
If this is just needed for testing, may I suggest to just put a local modified INI file with the fix for the Aurora weapon? |
Yes, we can do it that way—then the fix itself is unnecessary. But for the retail version, we currently have many different sources of INI patches, with no consolidation at all. Is it worth addressing this at this stage just for Aurora? Also, if I’m not mistaken, a single source of truth is maintained only in the GO project. |
I do not understand what this means. Can you explain in other words? |
|
@xezon Losing this fix would eventually cause a desync that is extremely difficult to trace back to the modified INI file. Finding it could require another week of investigation and bring all other work to a halt during that time. We also have no single source or mechanism where this patch can be fixed once and then applied to every player’s PC. These INI files and patches are scattered all over the internet. A manual local modification would solve the problem only on my current test machines. |
|
I don't know your test setup, but if you juggle with different Mods, just create separate installs for immutable Mods to test with. Leave the INI modifications in there and don't touch it for anything else other than your tests. Do your normal gaming on a separate install. Does that work? |
|
Hi @xezon ! You are suggesting a very inconvenient "topic" for me... o_0 I already have 2 separate installations, each with 7 mods: Contra 007..009, Contra X, Apocalyptic, Silent Death. I am already running out of disk space on my computer... Because if I change my own assets, I will get a desync with all community players right at the game start, since all game resources are hashed and participate in forming the reference CRC. So I would have to create a third separate game resource space just for one small unfortunate Aurora fix... I have already tested it — the configuration works. So I am closing the PR. Let's move directly to the math now: |
5 participants
The macOS port used for paired win↔mac testing is built from the GOD-Team (GeneralsOnline) repository, where
SupW_AuroraFuelBombWeaponforcesMissileCallsOnDie. This brings the same behavior here so the deterministicbuilds stay in lockstep.
Guarded by
#if !RETAIL_COMPATIBLE_CRC && !PRESERVE_MISSING_AURORA_SECOND_EXPLOSION— retail is not affected.P.S. If this force is removed from GO's code and not applied in TSH, there is no desync either: both builds fall back to retail behavior. The force is needed solely to match the current GO build.