Describe the feature you'd like
At the bottom of loadResearch, after research.json and pre-reqs are loaded + processed, it would be nice to have a pass that detects cyclic research dependencies (i.e. in RESEARCH.pPRList).

Describe why do you think it is needed
It's currently possible to accidentally create research dependency cycles. This is obviously no good.

Detecting this,

Operating System: Any

Commit/build: None

Original game source: Any

*Reproducible in the original Generals Zero Hour?
Multiplayer affected?
Are you using any mods? (like Gentool, Rise of the Reds or Contra)

Issue explanation

Plain string files cannot reliably be read from .big files as they rely on line ending conversions of text mode file IO and .big file contents c

Our current map looks like this:

It has to look this way right now because of a pathing quirk:

To fix the pathing issue, we'll need to entirely rethink the algorithm that chooses where the creeps wants to go. Currently it goes towards the closest ene

Good first issue because no Unity-specific programming is involved.

Our unit config files allow a c-style #include directive, which lets us break them up into small reusable pieces. Example:

{
    #include "DefaultMobility",
    #include "DefaultHeloArmor",
    "LabelIcon": "D",
    "CategoryKey": "HEL",
    "Name": "AH64D Apache",
    "Price": 20,
}

ConfigReader.cs has s

The game has two unused video deinterlacing modes. They do need to be fixed in terms of graphical glitches.

3 modes. If set to 2 videos are deinterlaced, if set to 0 they're horizontally interlaced and when set to 1 they're supposed to be vertically interlaced (though the vertical interlacing doesn't seem to work).

I suggest using the VideoInterlaceMode= keyword in REDALERT.INI under the [O

As it turns out, it's actually pretty common for the queue pop times to display incorrectly because of weirdly configured system time on the client side. Since knowing the exact pop to the millisecond isn't crucial, we should add a time delta to the matchmaker_info message as well. I suggest we leave the timestamp in so that the client implementation can choose which one to use.

I'd say call it