SMACX Thinker Mod

[Induktio]

I pushed some more refactoring changes to the repo. There's even more fixes coming to pathfinding but it's still in the testing phase. By the way, try not to paste code that is from obsolete version of Thinker. Variable naming in source code is subject to any changes at any time. It's not part of the user interface, so to say.

> I would suggest to revert to my type of fix which doesn't introduce any brand new logic but hijack the existing psi combat logic instead.

Can you be more specific here, which patch locations are strictly necessary to make your implementation work? I recall you had a lot more binary patching that involved writing new code segments on the binary, not just changing a couple of pointers. I would try to avoid that kind of patching because in the future some functions might get totally rewritten. Patching new code segments is just the worst option for maintainability.

Did you find any other bugs than those mentioned? If so, the healing could possibly be fixed from repair_phase function. That's one of the functions that could be rewritten in source code format. For example, see mod_bonus_at/mod_goody_at. In that case we can have both the original results or new features based on the config flags applied.

> Does it limit number of computer player bases? If so, 25 seems like a small number for normal map.

New version will have expansion_autoscale feature for this reason. It's already part of the pushed changes.

[Alpha Centauri Bear]

By the way, try not to paste code that is from obsolete version of Thinker. Variable naming in source code is subject to any changes at any time. It's not part of the user interface, so to say.

I am trying to get them from your master branch on GitHub. Is it up to date?

> I would suggest to revert to my type of fix which doesn't introduce any brand new logic but hijack the existing psi combat logic instead.

Can you be more specific here, which patch locations are strictly necessary to make your implementation work? I recall you had a lot more binary patching that involved writing new code segments on the binary, not just changing a couple of pointers. I would try to avoid that kind of patching because in the future some functions might get totally rewritten. Patching new code segments is just the worst option for maintainability.

In my latest code check patch_ignore_reactor_power_in_combat_processing() function. Currently it patches 2 byte jumps in 4 places. Seems to be a minimal change possible. Don't remember if it was bigger than that before.

I agree with your view on patching and try to minimize impact on original code. Doesn't work every time, though. Let me know if you see some fragments in my code those can be rewritten more nicely.

Did you find any other bugs than those mentioned? If so, the healing could possibly be fixed from repair_phase function. That's one of the functions that could be rewritten in source code format. For example, see mod_bonus_at/mod_goody_at. In that case we can have both the original results or new features based on the config flags applied.

I am posting issues in your repo whenever I find anything like that.

Healing is not broken per se. It works as before. I just pointed out that if you want to actually reduce all unit HP to 10 you need to fix it everywhere else (like display and healing) and this is hell of a lot of places some of which we don't even know about. Would be a complete nightmare and a challenge to finish this work in lifetime.

> Does it limit number of computer player bases? If so, 25 seems like a small number for normal map.

New version will have expansion_autoscale feature for this reason. It's already part of the pushed changes.

Yea. I saw that. Still think this is very artificial and strange way to do things. Should be, at least off, by default.
Are you trying to satisfy some players in helping them to cripple AI? Beside of being a pretty strange way to do that it is absolutely contrary to your mod purpose. Is it not?

[Induktio]

I don't have any other branches than master there, so yes, it's most recent public version.

> In my latest code check patch_ignore_reactor_power_in_combat_processing() function. Currently it patches 2 byte jumps in 4 places. Seems to be a minimal change possible. Don't remember if it was bigger than that before.

Yeah I have not had the time to look through all of those changes. Almost thought it required something more complicated than that. That's certainly a really simple implementation and could be imported. However, how do the odds look like in the confirmation dialog? Do they reflect the real odds as it is calculated by the vanilla formula? Are there any other side effects with this patch?

> Beside of being a pretty strange way to do that it is absolutely contrary to your mod purpose. Is it not?

Hmm. I don't think on the default settings it cripples the AI at all. If you set expansion_factor way below 100 then the AI expansion would become very limited but that is not case by default.

[Alpha Centauri Bear]

> In my latest code check patch_ignore_reactor_power_in_combat_processing() function. Currently it patches 2 byte jumps in 4 places. Seems to be a minimal change possible. Don't remember if it was bigger than that before.

Yeah I have not had the time to look through all of those changes. Almost thought it required something more complicated than that. That's certainly a really simple implementation and could be imported. However, how do the odds look like in the confirmation dialog? Do they reflect the real odds as it is calculated by the vanilla formula? Are there any other side effects with this patch?

Odds display is a different story. Currently it patches a huge piece of code with custom computation added. This is because they are drastically different than in vanilla, though. First it computes winning odds, not round odds. Second, it converts ratio odds to percentage. You can settle for simple change if you feel it is too much for your mod. In any case vanilla odds are computed incorrectly. So they have to be fixed one way or another.

> Beside of being a pretty strange way to do that it is absolutely contrary to your mod purpose. Is it not?

Hmm. I don't think on the default settings it cripples the AI at all. If you set expansion_factor way below 100 then the AI expansion would become very limited but that is not case by default.

True. That is why I think you should make it optional. Many people don't bother reading through each and every configuration option. Your mod should not cripple AI by default. Even a little. Even potentially. This is pretty not intuitive/expected limit.

[Induktio]

> Odds display is a different story. Currently it patches a huge piece of code with custom computation added.

Well, uhh. That's a problem. I would consider incorrect odds display huge breaking change for the UI. It would result in many frustrating outcomes and many weird dialog boxes. But we can post more on that stuff on the github issues.

Anyway, I just uploaded develop build 20210404 and the rest of pathfinding tweaks. These changes allow the AI to spread the units to more tiles to avoid collateral damage, understand how to use or avoid chokepoint tiles that are occupied by a base, e.g. canals between two areas. Also AI satellite production is now automatically adjusted based on population counts and new config option player_free_units is added.

I was doing some 1vs1 test games on Veterans map and it really looks like Thinker AI now pounds the default AI into sand. It's as if there's some kind of natural flow into how the AI allocates troops to the front line and coordinates invasions. Remember on this map Thinker can launch a coordinated naval invasion into another continent over 40 tiles away.

[Alpha Centauri Bear]

Combat changes sound amazing. I like to check them out. I am currently working on production tuning. Hope to get synergy on this

[Induktio]

This could be better coordinated if you offered some kind of code to merge and then we could review the changes but you have not done so. There's still many ways that the coding style in WTP could be improved. I wouldn't want to merge redundant looking code if there's no clear reason for doing it. Just look at the code in smac-cpu-fix compared to the actual changes that were required to implement it in Thinker to get an idea of how much less code it was.

Actually I'm going to flat out say I don't recommend you to work on AI production planning if you don't want to merge the changes. That's one of the areas that is really core functionality of Thinker and I might implement some changes there anyway. Not really decided though. It's maybe best to open dissussions on github if you have changes in mind for some areas of this AI functionality.

> ; Remove AQUATIC faction bonus minerals from sea mining platforms.
> This actually disables AQUATIC +1 minerals bonus to each tile regardless of improvements.

Good catch, so in that case it sounds even more OP. Have to change that description.

[Alpha Centauri Bear]

This could be better coordinated if you offered some kind of code to merge and then we could review the changes but you have not done so. There's still many ways that the coding style in WTP could be improved. I wouldn't want to merge redundant looking code if there's no clear reason for doing it. Just look at the code in smac-cpu-fix compared to the actual changes that were required to implement it in Thinker to get an idea of how much less code it was.

Actually I'm going to flat out say I don't recommend you to work on AI production planning if you don't want to merge the changes. That's one of the areas that is really core functionality of Thinker and I might implement some changes there anyway. Not really decided though. It's maybe best to open dissussions on github if you have changes in mind for some areas of this AI functionality.

I meant it is good that you are doing this so less stuff for me after merge. The backward merge is up to you, of course. Not insisting on that.

[Alpha Centauri Bear]

Did you teach transports to move combat units across the water to where they are needed most?

[dino]

Recent exchange with AC Bear in the other thread about feasibility of disabling native stacks wipes after killing a single unit made me think about late game Eco Damage fungal popups armageddon.
Preventing late game suicide by Planet, should be a worthy goal, since reaching the end game before dominating the Planet and huge mineral output of AIs are now possible with thinker AI.

OK then, lets think what we should equip AI with to deal with eco damage:

(20 bases) * 3 (TF + HF + CP ) + 16 + 20 ( First pops are pretty mild ) = ~70 minerals before it become really problematic spiral of destruction.
There are two things that can rapidly shoot mineral output way above this treshold: satellites and +50% minerals facilities.

The second question is how many popups AI can manage: few super formers can rebuild any tile improvements in few turns and units can be repaired and reinforced also in few turns.
I'd say 10-20% Eco Damage should be manageable in the early game, since rapidly growing clean minerals will solve the issue by itself.
Late game 5-10% should be manageable if each base will be equipped with few Super Formers.

1) Check before building +50% facility, if building it would shoot Eco Damage above this treshold.
2) Sell +50% facility if Eco Damage is above 25%, or 15% late game.
3) Check if any of the 10 biggest bases is above the treshold before building a mining satellite.
4) Late game build Hybrid Forests and Centauri Preserves when available.
5) Keep at least one Super Former, or two Formers + 1 SF, or 2 F for each 5% of Eco damage.
6) Check if forces in a base are suffcient to deal with an estimated popup spawn size, if not move nearby forces there, or sell 50% facility.

Add thinker.ini adjustable multiplier for whatever late game ecodamage tresholds you hardcode.
So the player can adjust AIs balance between mineral output and probability of suicide by Planet / Global Warming speed.
Early game Eco Damage should be kept at 10-20% until certain amount of clean minerals is generated and popup spawns become dangerous.

If it's too much work, a simple cheat solution could be implemented: an adjustable Eco damage cap for AIs bases.

[Induktio]

Version 2.5 is out now, some new GUI improvements this time.



> OK then, lets think what we should equip AI with to deal with eco damage

Also as a general rule, I'm not really keen on introducing mechanics that complicate the game further for the AI. Remember we also have eco_damage_fix which enables Tree Farms to start decreasing eco damage earlier than before.

I'd say the only thing that really interests me on those changes is to add additional checks before building mineral multiplier facilities. Base production code should get still some more changes.

Other thing that could be implemented as an option is to eliminate most of the prototyping costs. Maybe only keep significant costs for planet buster prototypes because they're like a secret project, but for other units, I don't see how it adds much to the game. We already have steep cost increases with revised_tech_cost so you can't just rush to some particular weapon techs before developing the economy a little bit. Maybe you can test those kind of changes with WTP first because it mods the other mechanics so much also..

[Alpha Centauri Bear]

1) Check before building +50% facility, if building it would shoot Eco Damage above this treshold.
2) Sell +50% facility if Eco Damage is above 25%, or 15% late game.
3) Check if any of the 10 biggest bases is above the treshold before building a mining satellite.
4) Late game build Hybrid Forests and Centauri Preserves when available.
5) Keep at least one Super Former, or two Formers + 1 SF, or 2 F for each 5% of Eco damage.
6) Check if forces in a base are suffcient to deal with an estimated popup spawn size, if not move nearby forces there, or sell 50% facility.

Good suggestions. Worth embedding into production selection routine.

[Alpha Centauri Bear]

Version 2.5 is out now, some new GUI improvements this time.

How do you invoke this dialog???

Other thing that could be implemented as an option is to eliminate most of the prototyping costs. Maybe only keep significant costs for planet buster prototypes because they're like a secret project, but for other units, I don't see how it adds much to the game. We already have steep cost increases with revised_tech_cost so you can't just rush to some particular weapon techs before developing the economy a little bit. Maybe you can test those kind of changes with WTP first because it mods the other mechanics so much also..

Not sure how prototyping cost relates to eco damage. Is it just a separate topic?

Anyway, prototyping cost is a new thing introduced in SMAC that wasn't in previous Civ versions. The idea is to put both research power and production power check on producing new unit component. Technology is pretty easy to steal but prototyping cost will still be there unless one also steals the advanced unit. It seems pretty logical entry barrier that does not let military to be upgraded very quickly. Even upgrading units to not prototyped design cost enormous amount of money. There are special facilities removing prototyping cost. There are special faction traits nullifying prototyping cost. This all seems to be a very integral part of the game and is pretty well tied together by game designers. I don't see major flaws in it.
 
Talking about prototyping cost it does not feel that excessive either. 50% for a single first unit in exchange to extra morale supposing player will produce at least 10-20 of them especially in late game? Come on. It is not that big of investment. If anything, I'd say it is too low for entry barrier. That's why WTP raises it to 100%. Which is noticeable but not that much either.

Removing it would also hurt Spartans those don't have anything else besides rolling out modern units slightly earlier than others.
😢

[Induktio]

> How do you invoke this dialog???

Literally the first line in changelog, ALT+T shortcut.

> Not sure how prototyping cost relates to eco damage. Is it just a separate topic?

It's a separate topic but it ties to the same idea which is implementing complex mechanics that require micromanagement around some specific penalties. Prototyping cost is not broken but it's not terribly important for the game either.

The default value that was intended for it was just 50%. At those levels it doesn't matter much if the AI builds Skunkworks or not, but anywhere way over 100% it becomes an artificial handicap unless someone specifically codes the AI to work around those limitations. People can just make the prototyping cost really high in alphax.txt for whatever balance reasons but what ends up happening it handicaps the AI production choices. And there's many more of these kind of mechanics.

[Alpha Centauri Bear]

It's a separate topic but it ties to the same idea which is implementing complex mechanics that require micromanagement around some specific penalties. Prototyping cost is not broken but it's not terribly important for the game either.

This is a stretch. The game is a game. There is nothing terribly important in it by definition. At the same time micromanagement is the bread and butter of 4X games. Those despising it in general play single person games like race cars. People usually complain not about micromanagement but about excessive mouse clicks. The difference is that (micro or any other kind of management) is decision making. One make a decision that affect their future game progress in some way. The more layers in a game the more these decisions interlink and the more difficult to see them through. That is an essence of fun for those seeking intellectual challenge like I assume most of the SMACX players are. The mouse clicks are just extra actions need to be done not carrying any strategical decision making which is boring.
From that perspective, prototyping cost is a perfect strategical layer to the game. It calls some non trivial choices - whether produce old units or prototype new or build prototype free facility or play prototype free faction, etc. Plenty of interesting choices. And it does not require any excessive mouse clicks besides actually designing units as usual and building them as usual. All costs are automatically computed.

The default value that was intended for it was just 50%. At those levels it doesn't matter much if the AI builds Skunkworks or not, but anywhere way over 100% it becomes an artificial handicap unless someone specifically codes the AI to work around those limitations. People can just make the prototyping cost really high in alphax.txt for whatever balance reasons but what ends up happening it handicaps the AI production choices. And there's many more of these kind of mechanics.

I don't agree with that either. In WTP it is 100% just to not scare players used to 50%. However, nothing wrong with setting it to 200%, for example. Making it more pronounces and interesting aspect of the game to pay attention to.