February 5th, 2009, 18:42
(This post was last modified: February 14th, 2009, 20:03 by kyrub.)
Posts: 901
Threads: 28
Joined: Oct 2008
sargon0 Wrote:Firstly in the file I downloaded x898D was x16 (decimal 22) which affects results. Oops.
The equations are:
(SUM of ship number x cost) / {0x88a9} = ship maintenance
(SUM of mbase number x cost / {0x898D} = mbase maintenance
Thus 0x16 = 22 produces about 225 % of initial maintenance. I was unaware of the changing mbase cost, it confused me.
- ship maintenance is indeed used in 5-6 other processes in the game. I'll look it up.
- mbase maintenance is very unaffecting, only one other place (scrapping comes to mind).
- note: the test games are meant to be unbalancing and over the top to reveal the influence on the game flow.
February 5th, 2009, 20:14
Posts: 218
Threads: 21
Joined: Jun 2007
The game manual and guide say you pay 2% cost for maint on ships or MB's and the division by a value of 50 you have found obviously achieves this (nice catch!).
Missile Base component costs miniaturize just like ship components by tech level (no worry about size with MB components!) but the (changing) cost of a missile base is not stored in the savefile like the cost of each ship. According to the OSG the cost of most MB components is about 60% of the cost of the same component on a large hull ship. MB missiles however cost roughly 5.4 times more than on a large ship because they are unlimited in number and +1 speed plus double range. Battle Scanner & Subspace Interdictor are free but you must pay for a base slab. CPs pay full cost on Simple, 90% on Easy, 80% on Average, 70% on Hard and 50% on Impossible subject to a minimum cost of at least 50 BCs. I have confirmed that at game start you pay 255 BC for a MB and an Impossible AI pays 127 BC with maint at 2% of cost rounded down.
I take your point about the idea of the tests. I was just spouting about possible side-effects, good and bad.
February 28th, 2009, 21:55
Posts: 901
Threads: 28
Joined: Oct 2008
Quote:The equations are:
(SUM of ship number x cost) / {0x88a9} = ship maintenance
(SUM of mbase number x cost / {0x898D} = mbase maintenance
The ship maintenance is protected against an overflow into negative numbers. Your ship maintenance will never exceed the magical number of 32.000- there is a controlled cap called just after the counting.
However, just after using the capped maximum, the program inexplicably ADDS the starbases' maintenance (100/starbase).
This poor implementation means that when any player reaches the 32.000 ship maintenance, he only needs to build 8 stargates to overflow into negative ship maintenance (-32.736 BC in this case).
the effects observed:
- this can happen to both AI or human player, but the AI tends to get much easier to the 32.000 cap.
- you can see a "0 -319%" message on the planet screen.
- the main economical_turnaround procedure gets around the bug and counts correctly the actual_production
demonstration
I post hereby a modified save file, that I kidnapped from civfanatics, which demonstrates the bug. (Your klackons have 6 starbases and two on the way. Just push the 'next turn' twice and look at the 'planet screen'.) I did not find any other negative/positive consequences for the human player beyond the bad displayed maintenance, but I am far from sure.
the source of 32.000 fleet bug?
Anyway, the count_maintenance function gets called several times in connection with the AI player only. Most notably, it gets called during the AI_ship_design. And, if you look closely at the game attached, you'll notice the runaway Meklars having 2 32.000 fleets over an inhabited world, you'll see a lot of Meklar starbases as well - and a quick view in the savefile reveals overflown maintenance...
Maybe, if anybody has a copy of an old savegame with 32.000 fleets, we could gather more evidence pro/contra this hypothesis?
Posts: 901
Threads: 28
Joined: Oct 2008
The fact that AI can stream its troops over (seemingly) unlimited range is generally well-known. That is only, as it seems, the most visible part of an "action radius" bug that clouds the bigger part of the AI judgement.
The AI reconsiders its main decisions based on the speed of its vessels. So, before it makes a decision, let us say, on attacking a nearby planet or invading it with troops, it calls a subfonction finding its quickest engine and after it is multiplied by the constant suitable for the type of its action (invasion or for attacking a planet or defending its own planet or supporting its own new planet with POP etc. etc.), an action radius is determined.
Only those targets, or only those friendly planets who are in the radius are activated/targeted.
There is a small bug in the called subfunction that severely cripples the AI thinking: the engine techs are found as multiples of 6 in the propulsion tech tree, but the program forgets to divide them afterwards. So, instead of a 0,1,2,3,... * constant the AI gets 0,6,12,18,... * constant. It usually starts considering every own planet (every enemy planet) once it reaches the sublight drive (warp 3).
Consequences:
(known)
- it cripples AI colony development and AI economy, because every AI planet in action radius sends 1/3 of its POP to a newly founded colony
- it cripples the defence, because the ship coming to rescue an endangered planet will arrive 10 years later
- it cripples the AI fleet gathering and distribution (unsure)
- it cripples the borders threat consideration (but that seems to be so screwed up anyway, that it does not matter? does it show in games at all?)
It does NOT cripple the invasion itself, because only the closest planet is selected a feeder of troops.
Posts: 901
Threads: 28
Joined: Oct 2008
Quote:- it cripples the AI fleet gathering and distribution (unsure)
Confirmed. The AI creates n major fleets to face n opponents. But it reconsiders the fleet distribution based on the action radius, and merges those fleets that are close to themselves. The fleets are put near the borders, preferably on planets with Mbases.
This part of the code is nicely done. There is another twist: when all the fleet focus points are merged in one (e.g. when the AI empire becomes too small to defend on borders), the fleet is merged into a single one, deep sitting fleet at the "gravity center" of the AI empire.
Now, the horrible thing is, that this sublime code is turned into its contrary by the action_radius bug. As soon as the AI gets warp 5 or 6 tech, it will most probably merge all its fleet focus points into one, and move its single, massive fleet into the depth of its empire, making its borders vulnerable and its weapon threat ineffective in the process.
Quote:- it cripples the borders threat consideration (but that seems to be so screwed up anyway, that it does not matter? does it show in games at all?)
Negative. It's handled somewhere else.
Posts: 31
Threads: 5
Joined: Aug 2005
Hmm interesting. Would it be possible to fix this multiplier so the AI behaves more sensibly?
Posts: 901
Threads: 28
Joined: Oct 2008
Actually, it is (3 + best_engine)* constant (multiplier)
so changing only the multiplier will result in a strange behaviour at the retros_level (now it is the opposite: only at retros level AI behaves as intended).
But don't worry, the fix is ready, under testing now.
I already have some kind of fix for majority of described or hidden Moo bugs (8th stargate, spy production, messed AI personnality/objectif focus, diplomacy bugs, beams_stronger_than_bombs bug, inter_AI diplomacy bug and some other, smaller ones). I am just waiting for a complete scan of the exe to post an unofficial Moo patch.
May 4th, 2009, 18:40
(This post was last modified: May 5th, 2009, 06:50 by kyrub.)
Posts: 901
Threads: 28
Joined: Oct 2008
1) There is a sub-function that makes AI consider to make a positive diplomacy move towards another AI player. The higher the game difficulty, the more frequently this sub-function is called; it is called every 7th year for the highest difficulty.
2) Only one positive move is allowed each time for each two AI players.
3) There is a complete mess regarding treaties in there. As a result, the AIs will:
- prefer to skip the NAP and to go directly for an Alliance, the first time they sign a treaty
- but the next time they hit the positive RNG, the AIs will be forced to drop their Alliance into a NAP (and the better their relations, + trade, alliance bonuses, the stronger the probability to degrade the treaty)
- next time they'll sign a new Aliiance. And so forth, oscillating between those two. This makes long-term AI alliances almost an impossibility.
4) This mess also, because of 2), leads to AI making almost no other positive diplo_moves. It delays the trade_deal creation and, more importantly, it all but cancels the AI trading of techs as well.
Note that the instability of AI alliances should occur more with the higher game difficulty, ironically.
Posts: 5,304
Threads: 115
Joined: Nov 2007
Still following with interest, though I've been quiet lately; the unofficial patch you propose sounds quite intriguing. It would be interesting to see just how much the AI would improve with a few bugs like these repaired....
Posts: 106
Threads: 6
Joined: Jun 2008
I'm also interested.  Question: what do you mean by the "beams_stronger_than_bombs bug"?
|
