:: Home :: Get Hosted :: PPM FAQ :: Forum FAQ :: Privacy Policy :: Search :: Memberlist :: Usergroups :: Register :: Profile :: Log in to check your private messages :: Log in ::

Do you want to advertise at Project Perfect Mod. Find out how to do it HERE.

The time now is Mon Jul 04, 2022 4:12 pm
All times are UTC + 0
 Forum index » Modding Central » C&C: Remastered Collection Editing Forums
The LOL WW WTF OMG Series
Moderators: Global Moderators
Post new topic   Reply to topic Page 1 of 1 [6 Posts] Mark the topic unread ::  View previous topic :: View next topic
Author Message
Reaperrr
Commander


Joined: 26 Apr 2003
Location: Somewhere in Germany

PostPosted: Fri Jul 03, 2020 10:04 pm    Post subject:  The LOL WW WTF OMG Series
Subject description: Quest for finding stupid bugs
Reply with quote  Mark this post and the followings unread

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.
Code:
IsInaccurate = ini.Get_Bool(Name(), "Inaccuate", IsInaccurate);

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'... Laughing

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'll update this if/when I find more.

Back to top
View user's profile Send private message Send e-mail
Crimsonum
Seth


Joined: 14 Jul 2005
Location: Fineland

PostPosted: Sat Jul 04, 2020 7:26 am    Post subject: Reply with quote  Mark this post and the followings unread

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 Smile

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.

Back to top
View user's profile Send private message
SMIFFGIG
General


Joined: 03 Mar 2003
Location: Great Britain

PostPosted: Thu Jan 07, 2021 11:26 am    Post subject: Reply with quote  Mark this post and the followings unread

Interesting post Reaperr , only just came across this

Especially the 'inaccuate' part  Razz
_________________

Back to top
View user's profile Send private message Send e-mail Skype Account
Nyerguds
General


Joined: 24 May 2004
Location: Flanders (Be) Posts:300000001

PostPosted: Sat Jan 23, 2021 5:16 pm    Post subject: Reply with quote  Mark this post and the followings unread

Someone seems to have done a very in-depth analysis of weirdness in the code, from a coding point of view: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.
_________________

Back to top
View user's profile Send private message Visit poster's website Skype Account
Nyerguds
General


Joined: 24 May 2004
Location: Flanders (Be) Posts:300000001

PostPosted: Tue Jun 21, 2022 12:36 pm    Post subject: Reply with quote  Mark this post and the followings unread

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.

https://github.com/electronicarts/CnC_Remastered_Collection/blob/master/TIBERIANDAWN/TRIGGER.CPP#L486
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? #Cussing out
_________________

Back to top
View user's profile Send private message Visit poster's website Skype Account
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Wed Jun 22, 2022 11:45 am    Post subject: Reply with quote  Mark this post and the followings unread

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

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant, 1 Scrin unit, 1 GDI building

Tools
Image Shaper______TMP Shop______C&C Executable Modifier

Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Page 1 of 1 [6 Posts] Mark the topic unread ::  View previous topic :: View next topic
 Forum index » Modding Central » C&C: Remastered Collection Editing Forums
Jump to:  
Share on TwitterShare on FacebookShare on Google+Share on DiggShare on RedditShare on PInterestShare on Del.icio.usShare on Stumble Upon
Quick Reply
Username:


If you are visually impaired or cannot otherwise answer the challenges below please contact the Administrator for help.


Write only two of the following words separated by a sharp: Brotherhood, unity, peace! 

 
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


Powered by phpBB © phpBB Group

[ Time: 0.1538s ][ Queries: 11 (0.0095s) ][ Debug on ]