Minor Race Advancement Project (old)

[Flocke]

Check the structures tab, it looks like two versions of farms might be built. If they are - it's a known occasional botf bug.

EDIT: if it's caused by this maybe we could find a fix for the old bug as well

Have begun testing again. This time I wanted to have a look at the upgrading function 452460 cause, regarding side affects, it might be easier to disable upgrading within that function instead of just not calling it.
First thing I've figured is replacing the "je short 452504" at 4524B6 by a jmp to skip some portion, causes old buildings of old type to keep in, while new ones still get added.
I don't have a savegame with that "occasional bug" to test with, but it's most likely caused in this place.

Additionally I've seen that in beginning of the function there's a race check again, preventing upgrades when owner is a major race. Could have some interesting effect, allowing minor to upgrade it's facilities when already membered. hehe
I alreaady wondered why removing the check for the evolution didn't cause them to upgrade their buildings as well. ^^

Continuing tests, I figured that first all buildings (at least the ones that shall be upgraded) get scrapped, then, at 452537, with calling 445DF0 in a loop (0 to current population number), the new buildings get build. Skipping this part or replacing the call by nops, causes zero buildings to be there after upgrading and only type 1 being buildable.
445DF0 is a function being called by many places. We already encountered it for building orbitals!
It is reading the RaceStateTable (or how to call it) at 445E21 and 445E2C and 445F74.

For the orbitals we already figured that it's for building one single structure. This time, in function 452460 that I've now labeled "_upgradeMinorBuildingType", it is called within a loop again.
It either reads out the tech level from RaceStateTable or takes it by parameter, can't tell yet but I believe it's been set somewhere before this function call. If we can set the old tech level here or stop setting the new one, we should achieve what we want without of the currently strange upgrading issues. (But they would also scrap if population gets lost)

I've now labled function 445DF0 "_buildSomething" and maybe we can find the place where the farms previously got build endless within DCER's changes and change it to become a future, so it's instead limited by population number and prevents starvation issues.
I've encountered same issues when completely skipping the upgrade part, so I think DCER's changes are fine but there's just another call to build more farms under some conditions, and somehow the real upgrade part just didn't take place anymore.

So far enough, I think we are on a good way.

[Flocke]

...and maybe we can find the place where the farms previously got build endless within DCER's changes...
I've encountered same issues when completely skipping the upgrade part, so I think DCER's changes are fine but there's just another call to build more farms under some conditions, and somehow the real upgrade part just didn't take place anymore.

Well, the call (E8 3D 3C FF FF) to _buildSomething (445DF0) at asm4521AE / hex515AE in original code is responsible for adding farms.
Replacing it by nops within DCER's last changes (at asm: 4520CB, hex: 514CB) stops building additional farms, at least for my talarians, but they still don't upgrade structures when reaching next EL.

The last, and as far I've seen the only remaining, call to _buildSomething in _evolveMinorSystem at 4523A7 I dunno what it's for, but replacing it by nops causes turn process to crash.

I'm not sure if I'll keep on analysing this. I'm currently in work with my other project.

[Nucky9]

Hi,

I just signed up here and first of all I want to thank everyone here for their hard work. A lot of untapped potential for this game has been opened up, and my friends and I have become addicted again, so much so that all night lan parties are becoming far too frequent.

The biggest issue we are having with the game is that the minor races can become very unbalancing (especially when you start at the lower techs). Using a HxD, I have successfully implemented many of the changes presented on these forums. However, I have been trying to slow down the rate of minor advancement (in both 1.03 and UDM III) by fooling with the [speed 1] and [speed 2] values as outlined in the initial post of this thread. Unfortunately, no changes I make seem to impact minor tech advancement in any way. In particular I have made [speed2] = 0, which is supposed to prevent all advancement, and this had no effect. Nor have changes to [speed 1] (either a positive or negative change) seemed to change the rate of advancement.

Just to be sure I am editing the right area of race.rst - in UDM III, for the minor races, [speed 1] = 7C FF, and [speed 2] = 0B 00, is this correct? If so, I'm not sure what I could be doing wrong - any insight would be greatly appreciated.

[Flocke]

Just to be sure I am editing the right area of race.rst - in UDM III, for the minor races, [speed 1] = 7C FF, and [speed 2] = 0B 00, is this correct?

As far I can see that's the right offset, but I currently don't have the time to proove your observations. To reduce minor advancement, you can also edit racetech.tec or use UE to change the techlevels that are reached after an evolutionary jump as well as reducing the growthrate in race.rst.

For computing the growth rates you might use http://babbage.cs.qc.edu/IEEE-754/

[Nucky9]

As far I can see that's the right offset, but I currently don't have the time to proove your observations. To reduce minor advancement, you can also edit racetech.tec or use UE to change the techlevels that are reached after an evolutionary jump as well as reducing the growthrate in race.rst.

For computing the growth rates you might use http://babbage.cs.qc.edu/IEEE-754/

Thanks for your help . You mention growth rate - as far as I can see based on the initial post, this only influences population growth, not tech growth. Is this correct? I suppose slowing population growth could also be beneficial, since even if the minors were at very high tech, if they only have a few of each building it would still take a long time to get them up and running once they joined.

Anyway, I'd rather not adjust the tech levels of the minor races, because 1) it's a bit of a pain in the ass (especially if I need to tweak it a few times), and 2) it means minors won't be nearly as useful at the higher starting techs.


Ideally, I'd like them to advance in tech at approximately the same rate as the human empires - that way no matter what tech you start at, they won't be way ahead or behind (on average).

Still, if this method won't work, I'll do that, since we usually play at the middle techs.

Thanks again!

[redhat1968]

I have been doing some testing based on Flocke's Orbital Battery sub routine analysis from a year or so back. If you place nops at both the regular sub routine call and the loop call, AI minors still build OBs up to the population requirements. Instead of 84 OBs on turn 22, it has 2 and on turn 222, a resonable 8 OBs. To compensate, I adjusted the strength of the OBs upward so an invasion is still going to take out a few ships, but not wipe out your entire task force.

Here are the asm offsets:

ASM 4522F0, 9 nops
ASM 45216C, 5 nops