Best Mod!

Does this mod effect the ai in campaign like is it harder?

New Mod is fixing the direction in which the flag of the Soviet barracks is flying. Maybe you can integrate his files in your mod.
https://steamcommunity.com/sharedfiles/filedetails/?id=3391426735

@Vidya.Dave: Found and fixed your bug; it will be fixed in the next release. If you put the rally point very far away, it generates more little dots than the GlyphX engine could handle, so it crashed. I changed it to space the dots out more in the middle of very long lines.

I have Bug:
When a Player's Engineer / Thief entering enemy Raffenery / Silo, the users mod setting "max. amount of money per Raffenery / Silo", will added to his account.

Also, does it crash when you do that in legacy rendering mode?

@Vidya.Dave: How far are we talking about? Are you getting any kind of error message box? If so, what's it say?

I tested CFEPatchReduxRA_v1.9TestBuild3.zip.and the ore-growing-under-trees problem seems to be gone.
CTDs described below still soccurs though. Spuspect connection to zoom level. Tested with shipyards.

No, I mean the test build on the github page.

Just had another CTD when placing the shipyard collection point. The zoom level seems to be an issue.

The ore over-growth issue does not exist in vanilla

1. If by latest test build you mean most recent release then yes.
2. Unfortunate

@Vidya.Dave:
1. Are you getting the crash to desktop on the latest test build from github?
2. Ore growing where it shouldn't is a vanilla bug. At one point I did fix it growing over mine heads, but I guess that's not in the current release.

This is the only mod that I run for RA.
I experienced multiple CTDs when setting the collection point of a shipyard far away. Tested in skirmish mode.
Secondly, ore somehow manages to grow under trees and over the mine tile. It often leads to pathing issues with ore collectors that want to access a tile blocked off by the trees. (I usually set my ore growth speed to 9 or 10)

@JerK.
1. Use the latest test build from github.
2. "It crashes" is totally useless for purposes of finding and fixing the bug. Under what circumstances does it crash?

It crashes!

Thats such a shame... So I guess ill never have ultrawide support... Thank you for answering at least.

@Cheesy Bear: Nope. The GlyphX frontend is not moddable.

Would it be possible to implement true Ultrawide monitor support into this mod? Since you can't play with others unless in LAN mode anyways.

Wow, thanks for analysis! If there are any bugs, I'm sure I'll find them...

So UI toggle seems to override rules.ini while the toggle is only 1 slider but we have 2 settings for ore growth behaviour, spread & speed. This doesn't make much sense.

"Can you make an argument why ini files should have precedence?"

This is the gameplay of Red Alert. There's no logical arguement for a setting in singleplayer or multiplayer UI to overwrite parts of rules.ini. They should just delete the slider or deprecate ore spread behaviour in rules.

To your last questions:
I already made a game with "no growth" setting from UI slider, but with my maps (if that's OK). Result is that ore sources will generate some ore but I cannot tell if this will spread because it grows really slow if it does (waiting an hour and nothing happens). Also, it seems that the ore does not increase dense over time. This also affects mods like this.

Also, it would be helpful if you could test this for me:
1. Start a skirmish on an official map with no modified ini files and the UI toggle set to no growth.
2. Verify that there's no growth.
3. Save. Quit to menu. Load.
4. Is there now growth?

[continued]

So...
Does setting OreSpreads=no in the [GENERAL] section of an ini stop ore from spreading in single player missions? Because it looks like it should.
The design intent appears to be that ONLY the lobby UI toggle can control ore spread/growth in multiplayer.
Loading saved games is definitely bugged in that it applies the ini files and lobby UI toggle in reverse order as when starting the game.
Loading saved games sure looks like it's also bugged in that the saved lobby UI toggle value may be getting read, but not applied.
There might also be issues with GlyphX finding custom map ini's when loading saved games.

The multiplayer design intent -- control only via the UI toggle -- seems reasonable to me. Can you make an argument why ini files should have precedence?

OK, after reading some code:

When starting a game:
First, grow and spread are initialized as true.
Second, rules.ini is checked and applied.
Third, aftrmath.ini is checked and applied.
Fourth, the map's ini file is checked and applied.
Fifth, if it's a multiplayer game, the toggle from the lobby UI is checked and applied.

When loading a game:
First, grow and spread are initialized as true.
Second, the value of the toggle from the lobby UI is read out from the save file, but I cannot find a point where it is actually applied. I will need to check this.
Third, rules.ini is checked and applied.
Fourth, aftrmath.ini is checked and applied.
Fifth, the map's ini file is checked and applied. (There may be issues with GlyphX being able to find custom map ini's when loading saved games. I'll need to look into this.)

[continues]

Yes, it's "OreSpreads" with "s", just took a look into original & my rules.ini. I managed once to stop Ore from spreading: saved a skirmish game, changed rules.ini, loaded the saved game -- no more spreading ore. So I assume that this setting is overwritten each time a new game is started. Even putting this rule into the map doesn't work.

Regarding the service depot not sending units, there was enough space so I don't know why it doesn't work sometimes, but I will continue to watch it.

@ van Grunz

I think I figured out your ore problem. It's "OreSpreads=no" -- with an 'S' -- not "OreSpread=no"

I believe the service depot ejection is working insofar as the depot always tells the unit to get off, but sometimes the unit fails to find a path if the area is crowded.

Sometimes, when sending a single unit or a bunch, all damaged, to a service depot they will stay instead of leaving. Can someone confirm this behaviour?

Ah, and a word to rules.ini:
Yes, it is loaded & it does work (needs to be located into CnCRemastered's root directory, together with aftrmath.ini). Several changes I've done work like a charm -- besides ore spreading behaviour. So I assume a possible vanilla bug.

Many thanks for your answers, I appreciate them.

I've made some experiments, first, of course, with settings from rules.ini and from this mod. The slider in game lobby under section "Rules" I wasn't aware until today.

No matter if I use mods like this or none which alter Ore growth, and no matter if in rules.ini OreSpreads=no is written, it always spreads, tested with new skirmish games. So I don't think that it's due to this mod but rather vanilla CnC Remastered behaviour, which seems to be dependend on ore growth speed set in Rules tab.

If there were a way where I could always convert Ore into Gems then I could stop spreading this way but I haven't figured out yet which value I should take, tried 0.1 & 1.

Sorry, my original response was wrong.

"What exactly does the setting "ORE_GROWTH_SCALE" and how is this interconnected with Rules.Ini's "GrowthRate"?"


ORE_GROWTH_SCALE is a mutliplier applied to ore growth. It's linear, so 3 means you get 3 times as much ore per second.

It does not interfere with the growth rate set in rules.ini at all. Both operate independently and the result is basically multiplication. (Well, actually division because the value in rules.ini is a delay period in minutes.)

(ORE_GROWTH_SCALE does interact with the growth scale set in the multiplayer game formation lobby. How depends on whether BETTER_ORE_GROWTH is enabled. If BETTER_ORE_GROWTH is enabled, then only the bigger of the two is used. If BETTER_ORE_GROWTH is disabled, both are multiplied together.)

My guess is that you may not be introducing the rules.ini file to where it needs to be to get Remastered to recognize and apply it.

[continued]

GEM_OVERLOAD_FIX fixes a bug with harvesters scooping gems that they don't have enough space for. In the vanilla game, these gems just go poof. This bugfix makes the harvester dump some ore back into the cell to make room for the gems.

In general, you'd be well served to look at the wiki on the github page. All of this is documented.

[continued]

As for those other settings:
BETTER_ORE_GROWTH enables a better ore growth algorithm. You get (nearly) the same amount of ore per second, but it's a slow constant spread instead of a huge burst every two minutes. It also fixes bugs with the growth being biased towards certain spots and the delay between a cell being checked if it can grow and doing so (during which it might get harvested or shot), and other bugs.

ORE_INDEX_BUGFIX fixes bugs inherited from TD in which the programmers working on some parts thought level 0 meant "the smallest level of tiberium/ore" while others thought it meant "no tiberium/ore." This leads to bugs like a harvester scooping in a level 0 cell, but getting nothing. This bugfix makes everything consistent, with 0 as "the smallest level of tiberium/ore."

Some solutions:
We can edit any INI file and reload/start a new game for changes to take effect without quitting completely.

But I cannot stop Ore from spreading by setting "OreSpread=no" in rules.ini; that's odd, because too fast regrow rates would occupy building space without the possibility to harvest it free in time.

Is this a cause of this mod, or am I doing something wrong?

I even changed the following options:

BETTER_ORE_GROWTH=0
ORE_INDEX_BUGFIX=0
GEM_OVERLOAD_FIX=0

to no avail

That makes sense. Since (some?) mods need an extra activation in options menu and the fact that the other CFE Patch did not work for me because of this reason I didn't have Savegames that require a special mod (I don't know if the single Wall Building Mod I've used before writes anything into the saves). Thanks for the explanation.

I have another question: What exactly does the setting "ORE_GROWTH_SCALE" and how is this interconnected with Rules.Ini's "GrowthRate"? The original value in Rules.Ini is 2, with a value of 1.25 it spreads like hell on my map with a lot of ore sources, so much that the AI bases cannot develop any more -- no matter if I set ORE_GROWTH_SCALE to 0.5 or 2. Only solution I've found so far is to set Rules.Ini's value >10. Is it possible that this mod boosts Ore Growth alot?

And do changes to Rules.Ini or CFEPatchRedux_RA.Ini apply to loaded savegames?

Yes, mod details are stored in saves. When a mod is active, the frontend is supposed to refuse to load any save files other than those made with that mod. And for VERY GOOD REASON: Mods can change the size and internal structure of the data objects that are getting saved.

Why not? Are mod details stored in saves? What happens if I load such a save after uninstalling this mod?

It should not be permitting you to load a saved game that was created without the mod...

Interestingly, the Wall Building system does not work if you load a Skirmish Savegame that was played without the mod.

It was my fault: Mod needed to be activated in-game. Working well even with my own Rules.ini, thank you!

I might add that I use my own rules.ini, don't know if that has something to do with it (if that's true, maps with special rules wouldn't work, either).

Hello,

I've subscribed, but the mod doesn't seem to work. Also, a manual download with putting either mod archive or depacked mod files into document's mod/red_alert directory, doesn't work/crash my game. Am I doing something wrong? I'm testing by starting a skirmish game and build walls, but the TS/RA2 wall style building doesn't kick in. Subscribing a single mod with that feature works. The mod is active (says Steam) & downloaded in SteamApps\workshop\content\1213210\2268301299\CFEPatchReduxRA

I didn't specify, I meant for RA. NoFog is must have imo.

@Preston: It's already in the latest *test build* for TD, and on the list of things to add to RA.

Can you also add Map Reveal as a feature?

@Sally: Walls can be built off buildings up to the standard building gap (1 by default) or built off other walls (TibSun-style) up to the wall length setting (5 by default). Check that your CFEPATCHREDUX_RA.INI file includes BUILDING_GAP_OFFSET=0 and WALL_BUILD_LENGTH=5 in the [SETTINGS] block. Another possibility is that you're trying to run multiple DLL mods at once, so CFE Patch Redux isn't even running.

I downloaded this mod but I can't place walls more than 2 cells from my buildings - anyone know if this is a bug? Tried on multiple maps. On TD I can place walls 8 cells away (I adjusted the settings) but for some reason the walls don't follow this rule in RA. The other buildings can be placed further, but not the wall sections.

Thanks for replying, I just rebooted my PC, will install mod soon and test

I think it was fixed in 1.9 test build 3. Are you able to reproduce the crashes using that test build?

Yo dude, any update on air plane attack waypoints? Have you every encountered the crashes I talked about on the 2nd page of comments here?

I distinctly recall playing RA with timequakes a long, long time ago.

And, yes, it looks like a bug to me. I think they intended to keep the global timequake. They didn't remove the code for chronospheres rolling a timequake [github.com]. And the procedure for doing damage [github.com] branches on whether there's an epicenter, with the "else" clause doing a global timequake. And the bug itself is a pretty understandable mistake -- they tried to get away with reusing a global variable but the proper logic requires two variables.

Just looking at the github list of Chrono Disaster fixes... it mentions fixing "the vanilla Aftermath bug that prevented timequakes from working". Was that really a bug? As far as I know, the whole time quake mechanism was simply removed and recycled to become the MAD Tank effect.