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? _________________
OmegaBolt wrote:
TS is abysmal to play, unless you're just casually city building in it.
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
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
