Joined: 26 Apr 2003 Location: Somewhere in Germany
Posted: Fri Jul 03, 2020 10:04 pm Post subject:
The LOL WW WTF OMG Series
Subject description: Quest for finding stupid bugs
I believe nearly everybody who has ever remotely intensively played, let alone modded the old C&C games is probably aware of this, but just in case:
There have been some incredibly stupid bugs in each of them.
Thanks to the open-sourced DLLs of the remaster, we're now able to look for and fix some of them ourselves.
This is what I found so far.
No. 1:The 'wrong muzzle offset on TwoShooters/Burst=2+' bug
Not everyone might notice, but on any double-shooter with a muzzle flash animation and lateral offsets (most notable on the Mammoth tank), the muzzle flash is always displayed on the barrel opposite of the bullet exit.
This is at least the case in TD, RA and TS, not sure about RA2.
Anyway, I found the reason: The piece of code responsible for displaying the muzzle flash runs after the bullet has already 'unlimboed', which changes the coordinate returned by the
Code:
Fire_Coord(which)
method.
Just using the
Code:
fire_coord
that was cached before the bullet unlimboed is enough to make the muzzle anim use the same offset as the bullet itself. A bug that lived through at least 3 games, fixed by something as simple as using an already-cached value...
-----------------------------------
No. 2:A code change not thought through
I only stumbled over this while investigating No. 3.
Basically, The 'true' - as in TD artillery-style - inaccuracy was originally meant to apply to missiles (when Inaccurate) and Arcing projectiles, like in TD.
However, the 'ROT != 0' part of the 'if' check was commented out, so it ultimately only applied to Arcing projectiles.
The funny part? The assigned max inaccuracy is still HomingScatter.
And all non-Arcing projectiles use BallisticScatter, including inaccurate missiles...
At least in theory, because now we come to the true 'highlight'.
----------------------------------
No. 3:The weird 'inaccuracy' in RA
I always though that RA's inaccuracy system was silly, and a regression versus TD. Projectiles would only overshoot, but apart from that, there was no visible inaccuracy at all. That made things more predictable and controllable, but it also was less fun, both visually and in terms of gameplay.
Investigating the code, however, the difference to TD inaccuracy shouldn't have been that significant. Yes, RA toned down values a lot, but not to zero, so I was a little puzzled as to why the in-game difference was so huge: even when I tuned up the theoretical inaccuracy by orders of magnitude, there was no visible difference.
But suddenly, when removing the 'if' checks, it miraculously started to work. So I investigated where the 'IsInaccurate' flags were set in RA.
And then I found it.
Look closely. Veeery closely. At the spelling between the "", that is.
And almost fall off your chair in disbelief (or of laughter), like I almost did.
Westwood at its 'best'...
And yes, this means that spelling it as "Inaccuate" would enable proper inaccuracy in original RA.
Do keep in mind that inaccuracy scaling in RA is much more mellow, though (max inaccuracy for Cruisers at max distance is just 1.375 cells, and anything up to 4 cells will show zero inaccuracy).
I was looking at RA's inaccuracy code the other day, and was wondering why it was the way it was. Guess it makes more sense now
I hope the fix to no. 1 can somehow be ported to TS. I've always wanted to have a TD-style accuracy system as well, but unfortunatelly TS has the most regressed inaccuracy system of them all: HomingScatter doesn't work at all, and all arcing, inaccurate projectiles do is pick a random value between BallisticScatter and BallisticScatter/2. Who the hell thought forcing the shots to land in a ring is a good idea? _________________ QUICK_EDIT
Do note, when looking through part 2 of their analysis, I noticed a lot of the mentioned things were actually non-destructive methods the Remaster programmers had used to disable code without removing it. Some of the code shown there specifically uses variables with "Glyphx" in the name; a clear indication that it is remaster code. _________________ QUICK_EDIT
Joined: 24 May 2004 Location: Flanders (Be) Posts:300000001
Posted: Tue Jun 21, 2022 12:36 pm Post subject:
I just dug into the trigger code; specifically, I wondered how exactly it uses the "House" configured in the trigger. This has long been a subject of debate. It was mostly assumed that this restricted the house that could activate the trigger, but no one was really sure.
Well. This is another one worthy of this thread.
Take one building, with a trigger attached to it that activates when it is destroyed. Take two very similar actions; "Production" makes a House start (re)building buildings and producing units, "Autocreate" makes a House starts the automatic and randomised creation of attack teams. You'd expect those to be 100% equivalent, right?
Now, let's look at the code. Do note, this code exists three times: once for triggers activated from non-map events like "time", one for events linked to map cells, and one for events linked to objects on the map. This is the "objects" one, and the object is "obj" in the code.
case ACTION_BEGIN_PRODUCTION:
HouseClass::As_Pointer(House)->Begin_Production();
break;
case ACTION_AUTOCREATE:
if (obj && obj->Is_Techno())
((TechnoClass *)obj)->House->IsAlerted = true;
break;
So, the Production trigger will activate the House set in the trigger itself. So far, so bad. Not what I expected. I thought this enabled Production on all AI Houses.
And now, for the Autocreate trigger. Exactly the same type of action, except it... takes the House of the actual object that was destroyed? Wait, what? Why? _________________ QUICK_EDIT
Isn't it logical? (or am I missing the point?)
Production: to make a certain house actually start building (units, buildings etc)
I think in several of my TD maps with multiple AI bases I used this to make first one then the other AI start building.
AutoCreate: uses the house of the destroyed object, so if you have 2 AI players, they don't try to replace/produce units of the other house.
e.g. if a GDIAI loses a M1A1, you don't want another GDI or Nod to build this and thus fill the required team numbers again.
Same with a passive AI (Production=enabled, Autocreate=disabled) starting the autocreate production when one of its units/buildings is attacked.
You only want that house to start building and not all AI houses. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 24 May 2004 Location: Flanders (Be) Posts:300000001
Posted: Tue Jul 26, 2022 10:16 pm Post subject:
No, the problem is that it's ridiculously ambiguous in TD what the "House" in a trigger is actually used for. Sometimes it's part of the cause (for celltriggers, the House is a restriction on which House can activate it), sometimes it's part of the effect, and in some combinations, it's both.
Case in point on the ambiguity part, the Westwood mission SCB13EA contains a trigger of the type "when this Guard Tower is discovered, start production". And because the trigger has no House set, the game crashes on it. Because the map maker apparently expected the game to take that House from the discovered object, like it would do if the effect was "Autocreate" instead of "Production".
In fact, on an "Attacked" trigger to link to something, the House should specifically be left empty, or, on top of acting as an "Object Attacked" trigger, it will act as a "House Attacked" trigger too, which triggers immediately when any structure of the House is attacked the first time.
So an "attacked -> Production" trigger linked to a unit will never work correctly; if you add the House, it will also trigger when any building of that House is attacked, and without House added, it'll crash. If it was linked to a building, a valid way around this would be to set the trigger to semipersistent (loop status 1) so it'll only trigger after both are done, which would happen immediately when that building is attacked, but it can't reliably work on units. And you'd need to make multiple identical triggers if you wanted to link this to multiple possible buildings.
In another similarly confusing case, the "Allow Win" trigger must always be set to the player's House, or it won't work, since this is actually an amount of "win blockers" put on a house. This excludes a ton of possible triggers from being able to cause the Allow Win effect. For example, you can't even do "everything from GDI and Neutral needs to be destroyed to win". Because "All destroyed" needs a House as argument, and if you combine that with "Allow Win", the win blockers will be put on that House, not on the player's.
AutoCreate: uses the house of the destroyed object, so if you have 2 AI players, they don't try to replace/produce units of the other house.
e.g. if a GDIAI loses a M1A1, you don't want another GDI or Nod to build this and thus fill the required team numbers again.
That's not at all what Autocreate does. Autocreate makes a House start producing and sending out random teams from the Teamtypes list that have a special flag set that includes them in the autocreation pool. This is unrelated to replacing destroyed objects, and teamtypes contain a House, so each House can only produce their own teams from that pool anyway. _________________ QUICK_EDIT
Joined: 24 May 2004 Location: Flanders (Be) Posts:300000001
Posted: Sat Jan 07, 2023 4:42 pm Post subject:
Found another weird bug, in the harvesting mechanic.
When a patch of resources is being harvested, and is not completely harvested away, everything is fine, and it works as expected.
However, at the moment the patch is harvested to the point where it needs to be removed from the map, rather than returning how much was harvested from it, it returns the icon number that the resource patch had at the moment the harvesting operation began. Now, this icon number is indeed how the game stores the value... but the issue is, the icon number is a zero-based index.
This means that if tiberium (or ore; same bug is in RA) is at growth state 5, you get 5 from it. But in reality, "5" is the sixth icon in the resource graphics, so 6 levels were removed before the resource is actually gone.
This also means that a cell with the lowest growth stage, stage 0, will give your harvester 0 bails of resource when harvesting it.
I discovered this bug when fixing the Remaster Map Editor's resources estimate. Most of the inaccuracy for RA resources just came from the fact it used RA's internal defaults for the income values, rather than the ones actually set in rules.ini, but after that was fixed, another smaller inaccuracy appeared, and at the end of that rabbit hole was this code:
OverlayData is the shown icon of the resource overlay. The code on RA is slightly different (has a bugfix on something else), but both have the bug that they set reducer = OverlayData instead of reducer = OverlayData + 1, to compensate for the 0-based index.
I tested this out in-game; placed down 8 spread-apart tiberium cells, so they'd be growth stage 0 in-game, harvested them all before they could grow further, and unloaded in the refinery. And indeed, it got me zero credits.
Also note that this is definitely a bug; the game contains another resource calculation system, namely CellClass::Tiberium_Adjust, which both sets the initial growth stage for preplaced tiberium on a map depending on density, and calculates the value to make a global estimate of the amount of resources on the map. And those do use OverlayData+1 as value for the resource.
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
The LOL WW WTF OMG Series
