Main Menu

MOO3 Information

Started by solops, July 07, 2013, 01:46:57 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

solops

I am starting a new MOO3 thread. I have a lot of mods and articles from the early 2000's, some of which may not be available on the web. I'll post some of it here and give credit where the author is known. Links:

http://members.chello.nl/gbrinkers/codemods.html
http://www.moo3.at/
http://www.mediafire.com/?bab6i5ezwj6u1
http://bhruic.dyndns.org/patcher/  (his server is down at the time of this writing)
http://www.orionsector.com/pages/moo3/  (old, low activity level)


Some helpful notes:


Technology Modifying:

The speed of tech advances is determined by the file, TechTables.txt.

The part to adjust is Row I, lines 32-37. Raising those numbers will slow down research. I recommend you not exceed 1.35 for Economics, Biology & Social, and do not exceed 1.4 for Mathematics, Energy and Physics, until you have play-tested it with those settings.

and

Bhruic - Über Modder - Reg: Dec 2002 
There are two different numbers that you can modify (both are in the "TechFields" table).

The first is "Research_Cost_Exponent_Base". This number is the amount of RPs that you have to put in at level 1 to get to the next tech level. Obviously, the higher the number, the slower your tech research will be.

The second number is "Research_Cost_Multiplier". This number acts on the first number to determine how many RPs are needed for subsequent research levels. I won't go into the formula, I'll just explain how it works. Basically, modifying this number alone will have very little effect on the speed of early tech, but a large impact on the speed of late tech. The previous number is somewhat the reverse, although its effect at higher levels remains.

So, if you want to slow down your early tech speed, increase the first number. If you want to keep early tech fast, but slow down later tech, then increase the second (keep your increases very small, the second number is exponential, meaning that small increases have large effects). If you want to do both, increase both numbers.


OTHER
To increase the number of ships in the picket and escort rings:
1: Unzip TaskForceRules.txt and open it.
2: Look at the first table in that spreadsheet. The upper row of column headers should have two entries titled "Escorts" and "Pickets" (IIRC).
3: Change the value for these columns to whatever you want.

To remove planet destroying weapons:
1: Unzip and open up TechTables.txt.
2: Look in the section with all the weapons for any weapon with the modifier PntDstWp=1. Remove all instances of this. You can also look at the weapons mounts and remove any instances of PntDstMt=1 you see.

"I could have conquered Europe, all of it, but I had women in my life." - King Henry II of England
I may be drunk, Miss, but in the morning I will be sober and you will still be ugly. - Winston Churchill
Wine is sure proof that God loves us and wants us to be happy. - Benjamin Franklin

solops

#1
TASK FORCE STUFF

I do not know if the Strawberry mod plays with this.

TASK FORCE RULES NOTES
By Awsric Armitage 3/21/2004

First off in TFrules.txt here is what I have changed the values to increase the numbers of escorts for each size of TF. Note this 'escort' can be defined later as any ship type allowed into that particular TF ring.
Code:
TableStart   ShipNumbers                                 
ColumnHeadingsStart   Unicode   MinShip   MaxShip   Pickets   Escorts   Mission                  
RowHeadingsStart                                    
Detachment   TSKSIZE0   1   1   0   0   1                  
Squadron   TSKSIZE1   2   8   0   0   1                  
Flotilla   TSKSIZE2   8   16   2   3   3                  
Wave   TSKSIZE3   16   32   4   8   4                  
Pack   TSKSIZE4   32   48   8   12   8                  
Armada   TSKSIZE5   48   64   12   16   12                  
TableEnd

The Columns for MinShip and MaxShip are the upper and lower bounding limits of that particular sized TF. These numbers can overlap so if you wanted detachments of sizes say 1 to 4 and squadrons of sizes 2 to 8 then you could do this and TFs of 2, 3, and 4 ships could be classified as either detachments following the detachment rules or the squadron and following the squadron rules. Note that overlaping these numbers does not cause a hang or crash but gives the human player probably a tactical advantage of using the detachments with out the escort rules applied rather than the larger sized squadrons with the escort rules applied if you do not have the required forced escort ships if any are required and if those settings are indeed differently set below in the TF rules tables to force escorts. Generally speaking though it is a good idea to have little overlap as the AI might not know very well which size to use optimally but this is of little consequence as generally speaking again the AIs tend to go with the largest TFs it can effectively muster at any given time from my experience. I have however seen the AIs field 5 or 6 smaller TFs of LR and SR ships only because it did not have enough Recon ships in its reserves to make the larger TF sizes so later when adjusting the MilitaryAI.txt and the build ratios bear this in mind when limiting the Recon numbers as generally the number of recons required for making larger TFs adds up very quickly and can cripple the AI disallowing it to field the larger TFs by not having enough escorts to fill the picket slots. This also can be solved by allowing the LR, SR, and PD or Flotsam Defense as not only escort ring ships but also as picket ring ships. Additionally keep in mind allowing the detatchment sizes larger than 1 ship might cause the colonization AI to use escorts to round out the auto-colonization routines sent colony TFs with ships that you have allowed into the core ring of the detatchments. I once saw the AI pull a modern CV out of my reserves and use this larger core ship as an escort for a colony TF so be carefull as the rules apply globally once set.

Pickets are generally Recon classed ships only by default unless you also change the ships allowed into the Recon ring of the TFs below which I think you will want to do as most believe the Recon Ships the AI builds are somewhat broken as it builds on the assumption that ecm/eccm works, more on changing this later also. Escorts are generally Flotsam defense or PD ships and the name difference here means the same but its larger implications are that ships getting blown up on the battle screen not only cause the light show we all love but those larger chunks can actually hurt your ships if not fired on by your pd ships. For this reason alone it is a good idea to include some pd guns on your SR ships if indeed this occurs at all. By changing the ships allowed below we can also allow LR, SR, Recon, and PD ships into any TF ring but bear in mind the warnings of what this does to the AIs selection criteria when creating TFs. As allowing the use of Recons only as pickets can be used as a very simple controlling mechanism for how many larger TFs the AIs can effectively field by controlling this number both here and in the MilitaryAI.txt. Simply put limiting the number of Recons the AIs can build in the build ratios in MilitaryAI.txt and you limit the AIs ability to field larger TFs because of lack of Recon classed ships to fill the required picket slots here in TaskForceRules.txt. Both need to be adjusted accordingly if using the Recon's as a controlling variable.


These are the current settings I am using for the next table that governs what classes of ships are allowed into what rings of the TFs. The TF rings are numbered as follows: 0 Not Allowed, 1 Mission Ships, 2 Core Ring, 3 Escort Ring, 4 Picket Ring.
Code:
TableStart   MissionShips                                 
ColumnHeadingsStart   Unicode   EscortRulesApply   LRSS   SRSS   PlanetDestroyer   IndirectFire   Carrier   FlotsamDefense   Recon   Transport   Colony   Outpost
RowHeadingsStart                                    
LongRange   TASKLRSS   0   1   3   1   0   0   3   4   0   0   0
ShortRange   TASKSRSS   0   0   1   0   0   0   3   4   0   0   0
IndirectFire   TASKIFSS   1   3   3   0   1   2   3   4   0   0   0
Carrier      TASKCASS   1   3   3   0   2   1   3   4   0   0   0
Reconnaissance   TSKRCNSC   1   3   3   0   0   0   3   1   0   0   0
Transport   TSKTRNSP   1   3   3   0   0   0   3   4   1   0   0
Colony      TASKCLNY   1   2   2   0   0   0   3   4   0   1   0
Outpost      TASKOUTP   1   2   2   0   0   0   3   4   0   0   1
TableEnd


The columns list the various types of ships as they are typed at creation in the design screen. The rows are the various TFs and the ships allowed into the various rings. Change the numbers accordingly to allow for different ships to be allowed into the different rings of the TFs thus acting as escorts in ring 3 or pickets in ring 4. Generally speaking though you will want the FlotsamDefense in the escort ring but also some outer perimeter picket ring PD ships is not a bad idea either but these rules must combine with the above tables as well as the build ratios in MilitaryAI.txt.

And the last table governs how the AI selects weapons and systems on the different builds.

TableStart MissionShipRules
ColumnHeadingsStart Unicode Core Escort Picket Mandatory Recommended Maximize Defense Speed
RowHeadingsStart
LRSS       SHPMLRSS 1 1 1    InfoWeap InfoWeap    AccDisEn    3 100
SRSS       SHPMSRSS 1 1 1    InfoWeap InfoWeap    NearDamg    3 100
PlanetDestroyer SHPMPLDS 1 0 0    InfoWeap InfoWeap    PntDstWp    3 100
IndirectFire    SHPMINDF 1 0 0    InfoMisl   UniSpace    FarDamag    2 80
Carrier    SHPMCARR 1 0 0    InfoFWpn InfoFWpn UniSpace    2 80
FlotsamDefense SHPMPDEF 0 1 1    InfoWeap InfoWeap    FireDlay    3 80
Recon       SHPMRCON 1 1 1    OffTgtRg DefTgtRg    AccDisEn    3 100
Transport    SHPMTRNS 1 0 0    TrpCap     UniSpace    FireDlay    3 60
Colony    SHPMCLNY 1 0 0    Colony     UniSpace    UniSpace    1 50
Outpost    SHPMOUTP 1 0 0    Outpost    UniSpace    UniSpace    1 50
TableEnd

"Defense key 0-none, 1-light, 2-medium, 3 heavy"
"Speed key 100=do 100% max speed, 50=do 50% max speed"

Note that this table also has the listings of Core, Escort, and Picket but that only the CV, IF, TR, and CO, are allowed as Core only. The Flotsam Defense you could allow as a Core ship if you wanted to but then this leaves less of those ships for creating other larger TFs. So when adjusting these also remeber to adjust the MilitaryAI.txt for the build ratios.

Many people have cut and pasted the LR ships build criteria above and replaced the Recon ships with the same builds. You can do this but yours and the AIs recon default builds will match the LR build type exactly with no difference in between the two classes. A better fix I think is to allow both ship types into the Picket ring so if the AIs are running short on Recon ships then they can have the option of filling out the TF with LR, SR, or whatever else happens to be on hand adding inherently more flexibility to the AIs TFs builds.

The MilitaryAI.txt is straight ratios of number to number comparisons before the code modifies those numbers for build ratios. What and how the code modifies those numbers is beyond me at the moment. You do not necessarily have to change the build ratios to get better beam strengths just the rings the LR, SR, and Flotsam Defense are allowed to enter.

TaskForceRules.txt will change immediately in your current game. At least for the first table in it IIRC. Remember you have to have enough escorts and pickets to fill those rings before you can field a larger sized TF if the escort rules applies column has a 1 included in it. If it is 0 as for SR and LR then the escort rules do not apply as those LR and SR do not need escorts like the other types do.
Actually if you have done those then the Taskforcerules.txt would be the one to change some values in. It is the second table I believe that is the one that lists the mission ships, escort rules applies, and then values from 1 to 4 for the other slots. IIRC the values represent:[list=1]
  • Mission ship
  • Core Ring
  • Escort Ring
  • Picket Ring[/list=1]

    That way you can change the values to your TF rules to allow/disallow certain ships into certain rings to act as escorts or pickets or even mission ships for other currently limited mission ships. Optionally you can change the number of ships you want for each size in the table above that one mentioned above or the first in the file to modify the actual sizes of the TFs and then require a certain number of ships per ring. Adding ships to the picket and escort rings is what you will want to do here. Just be careful that if you add ships to the required lists for forming TFs for the picket ring that you also allow more ship types to act as pickets or you are actually handicaping the AIs by only allowing recon pickets. As mentioned previously these Recon pickets are of limited use as electronic surveliance and jamming platforms for the AIs so adding the LR, SR, and PD to pickets acts to increase beam strengths of the overall collective TFs of the AIs better.

    It is much easier to mod these spreadsheets by opening the .txt file and selecting edit then select all and cut and paste the contents into a blank spreadsheet. This enables you to see the values in the individual cells of the spreadsheet program to better ensure the correct numbers are being changed. Then just highlight the spreadsheets cells and cut and paste again back into the now empty original .txt file. Viola, better TF rules.
    -
    Table: ShipNumbers
    (col#) Column : Description

    (1)Unicode    :  Code Assigned to the Task force
    (2)MinShip    :  Minimum # of Ships needed to create the Task force
    (3)MaxShip    :  Maximum # of Ships needed to create the Task force
    (4)Pickets    :  Number of Ships needed in the Picket ring
    (5)Escorts    :  Number of Ships needed in teh Escort Ring
    (6)Mission    :  Number of ships of the Mission type needed to create the task force.


    Table: MissionShips
    (col#) Column : Description

    (1)Unicode        :  Code Assigned to Task Force Mission Type
    (2)EscortRulesApply  :  1 for yes ; 0 for No
    (3)LRSS                :  Number of Ships needed for that Mission type
    (4)SRSS                :  Number of Ships needed for that Mission type
    (5)PlanetDestroyer   :  Number of Ships needed for that Mission type
    (6)IndirectFire        :  Number of Ships needed for that Mission type
    (7)Carrier        :  Number of Ships needed for that Mission type
    (8)FlotsamDefense    :  Number of Ships needed for that Mission type
    (9)Recon        :  Number of Ships needed for that Mission type
    (10)Transport        :  Number of Ships needed for that Mission type
    (11)Colony        :  Number of Ships needed for that Mission type
    (12)Outpost        :  Number of Ships needed for that Mission type


    Table: MissionShipRules
    (col#) Column : Description
       
    (1)Unicode      :  Code Assigned to Mission Rules
    (2)Core         :  ?
    (3)Escort       :  ?
    (4)Picket       :  ?
    (5)Mandatory    :  Type of Weapon on Ship*
    (6)Recommended  :  Picks Best from those values*
    (7)Maximize     :  Picks highest Value for for those areas*
    (8)Defense      :  0-none, 1-light,  2-medium, 3 heavy
    (9)Speed        :  100=do 100% max speed, 50=do 50% max speed and so on

    **Note
    - Mandatory - The Values are: InfoWeap, InfoMisl, InfoFWpn, OffTgRg, TrpCap, Colony, Outpost. These codes are found in the Tag column in the TechTables.txt file
    - Recomended - The Values are: UniSpace, InfoMisl, InfoFWpn; These Are used to decide the best ship to put in the task force(UniSpace picks largest hull)
    - Maximise - the Values are: AccDisEN, NearDamg, PntDstWp, FarDamag, UniSpace, FireDelay. The Autobuild, tries to get the Best for these values when making the Task force.
    - ? - Have not Figure out yet.
"I could have conquered Europe, all of it, but I had women in my life." - King Henry II of England
I may be drunk, Miss, but in the morning I will be sober and you will still be ugly. - Winston Churchill
Wine is sure proof that God loves us and wants us to be happy. - Benjamin Franklin

Kushan

Thanks for sharing solops. As someone who is just starting to get into the game I can use all the help I can get.
PanzersEast: Have to think to myself.... will I play the first one by the Winter Sale?  Probably not, then I should remove Dragonfall
PanzersEast: but that is thinking too logically.... and Steam Sales are about ignoring Logic

---
Twitch Channel
YouTube Channel
Twitter - @KushanGaming
Discord Chat
Command Northern Inferno Let's Play

solops

#3
The next several posts are about combat, mostly from one article by Visage. Not all of it takes into account the fixes by Bhruic and Guerra or some of the Strawberry mod. I did note write any of the next several posts.

SPACE COMBAT IN MOO3  as of 3/1/06
Forum Query:
Would someone please explain "advanced" versions of fighter weapons to me? For instance, a fighter equipped with the dual phaser pod costs more and takes up more space but does the same damage as a fighter equipped with a regular phaser. There is no mention of any additional benefit in having the dual phaser pod. Almost all of the "advanced" fighter weapons have the same lack of description.

Can anyone shed some light on this?

If you open up techtables.txt, the dual phasor/ion pulse/plasma pods give x2 multifire.

As for fighter shields and armour, this is from the Space combat mechanics guide:
armour:
Code:
Armor Weight   Armor*=   Defl*=   Cost*=   TechLvl
Missile/Fighter   0.5   0.25   0   5
shields:
Code:
Generat. Size   ShStr*=   Rech*=   Cost*=   % HullSpace   TechLvl
Missile/Fight   0.33   1   0   0      16

IIRC (and I probably do not), fighter armor adds half it's normal armor value, independent of current armor tech. Same goes for shield...

Base HP is the amount of unmodified space the fighter takes up (so it depends on type of weapon) IIRC...

There was a very good guide on this stuff in the strategy and gameplay forum once... (see below!). Note that the patches by Bhruic fix many things, especially point defense, ECM, ECCM.


SPACE COMBAT MECHANICS

By Visage

<edit- Updated to accommodate changes in 1.2b

9/06/2004 edit: Visibility finally figured out and included>

I'm writing this document as an attempt to consolidate what is known about space combat in MoOIII into a single coherent whole.

This post will explain how combat works in some detail. The post that follows it will contain charts (or links to charts) of the various ingame values that are relevant to space combat. The third post will touch upon various implications brought out by the information in the first two.

I will be assuming that you the reader have a minimum of familiarity with MoOIII. 

If you find errors, let me know. I care more about factual errors than typos, of course. 

If you want to snarf the information here, go right ahead. If you're going to snarf the actual text, it'd be nice if you actually attributed it.



Starships versus System Ships versus Orbitals

Starships are the default for ship stats. Hull size for hull size, orbitals cost 60% of the AUs and get 150% of the space, System ships cost 75% of the AUs and get 133% of the space.


Armor, Shields, and Hit Points

Things that get shot at by default have Hit Points equal to their space. For some reason, ships have space available equal to one less than their listed space; the amount of damage to distroy a hull with a listed space of 200 is 200 points, but you can only put 199 space of stuff in the hull (and Orbitals and System ships have more HP than starships). Fighters have HP equal to their base space (modified by weapon mods), which is 66% of the space the interceptor form takes up and 33% of the space that the SCF form takes up; this is entirely dependent upon the weapon type of the fighter. Missiles have HP equal to the space a single missile takes up (without counting in the +1 per-rack surcharge; missile mods do modify missile HP, though).

The number of armor points a ship, fighter, or missile has is based on its armor type and armor thickness. Armor for fighters and missile always has the same "thickness." Armor also has a deflection value, established by armor type and modified by thickness. Armor never takes up space, regardless of its thickness.

Shields have three combat-relevant stats, apart from their size and cost. Each shield technology has a stopping percentage (StpPow), a number of shield points (ShdStr), and a recharge rate (Recharge), and except for the Damper Field they all default to consuming 5% of the hull space of the ship they're on (so shielding an Orbital takes up more space than shielding a Starship). Shield generator sizes modify the shield points, the recharge rate, and the space, but don't change the stopping percentage. Missile and fighter shields have their own shield generator "size."

Note: Shields and armor for fighters and missiles don't take up space.

How damage is applied to a target:

1) Take a particular weapon hit (so, a volley from 2 LFG's that fire 5 times each time they fire would go through this 10 times).
2) First, apply the effects of shields.[list=a]
  • The shield absorbs a fraction of the damage equal to its stopping percentage.
  • Subtract that fraction from the shield points remaining on the shield.
  • The remainder, plus any absorbed damage that was in excess of the remaining shield points, is passed on to the next step.[/list=a]3) Now, apply the effects of armor.[list=a]
  • Pick a random number between 0 and 1. If the random number is greater than the ArmrPier value of the weapon, skip to step 4.
  • If the amount of damage remaining is less than the deflection value, the remaining damage is wasted. If shields were damaged, display a blue number equal to the number of shield points lost.
  • Take a random number between 0 and 1. If the random number is less than the ratio of the remaining armor to max armor, the remaining damage hits the armor: subtract that many armor points. Display a yellow number equal to the amount of damage that hit armor. If all the armor is destroyed at this point, pass on to hit points all the damage that hit armor (not just that in excess of the amount needed to destroy the armor).
  • If the random number is not less than the ratio, go on to the last step.[/list=a]4) The damage falls on the hit points of the target. Subtract the remaining damage from the hit points. Display the lesser of that number and the number of HP that were present to take the damage. If hit points are reduced to or less than 0, the target blows up.
    In actuality, you only display damage per-volley, based on the furthest penetration achieved by that volley.

    Note: the shield recharge rate is misrepresented in game as the number of shield points regenerated per 5 seconds; the actual rate is per second.

    Note: When you wipe out a target's armor all the damage that hit the armor is passed on to the Hit Points of the target, not just that which is in excess of the armor that was remaining. This strongly suggests to me (though I haven't tested it) that wiping out all the shields points has similar behavior.
"I could have conquered Europe, all of it, but I had women in my life." - King Henry II of England
I may be drunk, Miss, but in the morning I will be sober and you will still be ugly. - Winston Churchill
Wine is sure proof that God loves us and wants us to be happy. - Benjamin Franklin

solops

#4
Direct Fire Weapons

Accuracy: The change to hit at or below the minimum range (AccDisSt) for a DF weapon is the listed maximum accuracy for that weapon. The chance to hit scales down linearly to 60% of the maximum value at the maximum range (AccDisEn); beyond this range the weapon will refuse to fire. So, a weapon with an accuracy of .7, or 70%, has a 42% chance of hitting at its maximum range. Some weapons (Stellar Converter, Mauler) have their minimum range set to just under their maximum range so as to produce an effect of no dropoff in accuracy. Having an accuracy of greater than one (once accounting for range dropoff) is treated like having an accuracy of 1. (Note: See the visibility section below for an unused mod to accuracy.)

Damage Dropoff: Most DF weapons don't do their maximum damage when they hit their target. There are two elements to this.

First, there's a range-based reduction. At or under a weapon's minimum range for damage purposes (DmgDisSt), this reduction is zero; the Base Damage is equal to the weapon's maximum damage (NearDamg). The Base Damage scales down linearly from there to the minimum damage (FarDamag) over the course of twice the weapon's listed maximum range for damage purposes (DmgDisEn). Thus, the Base Damage for a weapon is its minimum damage at 2*DmgDisEn + DmgDisSt; the default weapons set always has the maximum range for accuracy and damage the same, so the actual minimum Base Damage for a weapon is close to the average of the minimum and maximum damage, shifted towards the maximum damage based on the relationship between the minimum range and the maximum range.

The actual damage done is the Base Damage reduced by a random factor. To determine the random factor, take the smaller of the Base Damage and the damage delta (DmgDelta) stat. Multiply this by a random number from between 0 and 1. Subtract the result from the Base Damage to determine how much damage is actually dealt.

By default, the damage delta stat is equal to the difference between the maximum and minimum damage stats.

Mass-classsed weapons (Mass drivers, Rail guns, and the like), have their minimum range for damage set to be just under the maximum range for damage, so they have no dropoff due to range. Furthermore, they have their damage delta set to 0, so there is no randomized reduction.

Mounts change all of the stats mentioned above except for the damage delta stat. Thus, mounts with larger multiples on the damage stats (e.g. the Spinal series) suffer much smaller proportional reduction in damage dealt from the random factor. (Obviously, mass-classed weapons don't benefit from this effect.)

Note: The code is capable of handling cases with stat configurations that are far from the defaults. DmgDelta can be much larger than the NearDamg; FarDamag can be larger than NearDamg; AccDisEn does not have to be the same as DmgDisEn; etc. These cases all behave as described above.




Weapon Stats: Range and damage weapon stats, as well as DmgDelta, are discussed above. Other weapon stats:
•   FireDlay: Seconds between weapon fires. There seems to be a floor on this stat; reports suggest it is around 0.5 or 1 second.
•   Multfire: How many times the weapon fires when FireDlay has elapsed. All Multfire shots hit the same target.
•   ShldPen: When hitting shields, the shield's stopping percentage is multipiled by this value; lower is better. If StpPow * ShldPen is greater than one, it is treated as if it is one.
•   ArmrPier: Is a multiplier against the chance to hit armor; the lower the ArmrPier, the greater the chance that a particular shot ignores armor and hits Hit Points directly.
Mounts: Weapon mounts can change the four range stats, the two damage stats, Dmgdelta, size, cost, ShldPen, MacxAccry, but not MultFire.

Mods: Weapon mods are capable of altering: MultFire, the four range stats, FireDlay, the two damage stats, size, DmgDelta, and ShldPen.

IF Weapons

All default missiles have 95% accuracy at all ranges, regardless of what you change about their range stats; they always do max admage, similarly regardless of what you change about their range stats.

The rate of fire displayed in the ship design screen is not the actual rate of fire, but the multiplicative modifier to the warhead's rate of fire, which are all 45 seconds by default. The number of racks you have is the number of missiles you fire in a volley; the number of missiles per rack is the total number of volleys you can fire. The space a missile rack takes up is proportional to 1 plus the number of missiles in it.

Once you have the tech for missile armor and shields, they are installed by default on all missiles in new designs, but the checkboxes aren't selected. To turn them off, you have to select then deselect the checkboxes.

Missiles have Hit Points equal to the space they take up per missile (including chassis and weapon mod effects).

MultFire for missiles just generates more missiles; it doesn't require all the missiles to hit the same ship (or missile or fighter).

Fighters

As far as I know, the following fighter stats have no in-game effect: ShieldDmg, MaxShrnk, MinFactr, MinimSize, HullDMod, DamagCap.

Fighters have HP equal to the base space, the amount they take up before the *=1.5 multiplier for Interceptors or the *=3.0 multiplier for SCFs is applied (fighter weapon mods do add to HP, though). The only difference between SCFs and Interceptors is that SCFs take up twice as much space and get a 40% increase in max damage and a 20% increase in min damage. Damage calculations for fighter weapons are handled in the same fashion as for direct fire weapons. However, all fighter weapons are listed with 3000 minimum range, and almost all fighter combat happens under that distance.

Carriers wait 90 seconds between launching successive waves of fighters.

I have noticed no difference between SCF AI and Interceptor AI. It's conceivable that Interceptors will occasionally deign to shoot at missiles and fighters while SCFs won't.

It is commonly reported in these forums that Interceptors will not participate in planetary bombardment, but SCFs will.

Modding Note: I've found the following fighter weapon stats to be not modifiable by the fighter chassis: Armor points, DmgDelta, DmgDisSt, MultFire, ShldPen, MaxAccry. Weapon stats I've found the chassis to modify: UniSpace, SystCost, NearDamg, FarDamag, FireDlay.

ECM/ECCM/Sensors/Cloak

Thanks to Bhruic, we finally know what's going on in visual detection! There are several significan bugs, but it's there.

Sensors and ECCM multiplicatively reduce the OffTgtRg stat. ECM and Cloak multiplicatively increase the DefTgtRg stat. (Values in TechTables which increase OffTgtRg or decrease DefTgtRg are ignored.) Cloak also increases the Cloaking stat.

Major Bug: The space combat code ignores the first non-UniSpace non-SystCost tag in the ShipItem and ShpMItem objects. Thus, the default TechTables versions of Sensors/ECM/ECCM/Cloaks have no effect upon visibilty. A modder can trivially fix this by merely repeating their values, however.

Bug: While they're listed as ShpMItem objects, meaning that they can appear multiple times on a hull, you only get the effect of the single best modifier to each of OffTgtRg and DefTgtRg that appears in a given Task Force. A single ship in an Armada with a Sensors mk V is just as effective as an entire recon armada filled to the gills with 10 Sensors mk V each.

Periodically, every TF in a combat attempts to detect every enemy TF in that combat. Apparently, each wave of missiles and fighters counts as a TF in all ways for this. The period is approximately 10 seconds, but apparently with some element of randomness. If any of your TFs see an enemy TF, they all do.

The chance for a TF to see another TF is found by the following process (this isn't the precise programmatic sequence, but it is functionally identical):

EW_Mod = 0.75/(OffTgtRg*DefTgtRg)
If EW_Mod < 0, set it to the range between the TFs.
If EW_Mod > 1, set it to 1 (which means if it was < 0, it's now 1).
D is the distance between TFs.
Range_Mod = (D-8500)/50000
Chance to see the TF is EW_Mod - Range_mod.

In other words, assuming the appropriate bounds on OffTgtRg*DefTgtRg, your chance of seeing another TF with a given TF is:
0.75/(OffTgtRg*DefTgtRg) + 0.17 - D/50000

Written in terms of squares on the combat map rather than weapon range units (and assuming that a square is 3400), and looking at it from a different direction:

If there's no EW (OffTgtRg, DefTgtRg), you have a 0% chance of seeing an enemy TF at a range of 13.5 squares, and hit 100% chance of seeing it at -1 squares (which you of course can't reach). Each square of distance changes your chance of seeing the enemy TF by 6.8%. As 1/(OffTgtRg*DefTgtRg) grows, up to a maximum of 1.33, both of those distances increase, up to a maximum of 3.67 squares. As 1/(OffTgtRg*DefTgtRg) shrinks, those distances decrease.

Effects on Accuracy: For purposes of accuracy, range is multiplied by DefTgtRg. Note that modding TechTables to fix visibility will mean that ECM (which the AI empires don't use) will completely break game balance and will make ships nigh-impossible to hit with DF weapons at high TLs.

Shipbuilding AI

What the autobuild will pick for you, and thus what your AI opponents use.

Armor and Shields
Autobuild always uses the highest-tech class of armor and shields available. The generator size and armor weight used are as follows:
•   Class 0: No armor, no shields. Colony and Outpost ships are Class 0.
•   Class 1: Minimal armor, minimal shields. The AI will take use your smallest shield generator and uses a buggy algorithm (you have N armor weights available; if you have more than 2N hull sizes available, assign the heaviest available armor weight to everything; if you have fewer than 2N hull sizes available, assign the second-lightest (counting "none" as the lightest) armor weight to everything; if you have 2N hull sizes available, everything gets the second-lightest weight available except the two smallest hull sizes which get the heaviest) to select armor weight. IF, CV, Recon, and Transport are Class 1.
•   Class 2: Moderate armor, moderate shields. The AI will use the second-smallest shield generator. For armor weight, see below. Point Defense ships are Class 2.
•   Class 3: Maximum armor, maximum shields. It will use your third-largest shield generator, and will select armor as indicated below. LR, SR, and Planet Destroyer ships are Class 3.
For Class 3 ships, armor weight is selected as follows: Ignoring the "no armor" weight and the first two hull sizes (Lancer and Cutter) available, map your weights to hull sizes as evenly as possible, rounding such that the heavier weights get hulls allocated before lighter weights do. The first two hull sizes get the second-lightest armor (using the default game files, they'd get Very Light). So, if you had all size armor weights in addition to "no armor" and you had all the hull sizes except Behemoth and Leviathan, you'd have: Lancers, Cutters, Corvettes get Very Light; Frigates and Destroyers get Light; Light Cruisers get Medium; Cruisers and Battlecruisers get Heavy; Battleships and Dreadnoughts get Very Heavy; Superdreadnoughts and Titans get Ultra Heavy.

Orbitals are considered one hull larger than they are; Class 2 ships are considered one hull smaller than they are.

Note: "Highest Tech" above actually means "furthest down the listings in TechTables." Since the Damper Field is listed after all other shields, it will be chosen preferentially over all other shields. Changing its position in the sequence will change the preference. Similarly, larger shield generator sizes and heavier armor weights are actually "later listed" in the code; changing sequence will change preference. Nothing actually evaluates the stats of the various weights or techs. "No armor" is merely the first-listed armor weight.
"I could have conquered Europe, all of it, but I had women in my life." - King Henry II of England
I may be drunk, Miss, but in the morning I will be sober and you will still be ugly. - Winston Churchill
Wine is sure proof that God loves us and wants us to be happy. - Benjamin Franklin

solops

#5
ECM/ECCM/Cloak

If a ship is marked Stealth, it'll put in the best cloak/ECCM available; best in this case is the one with the best (largest) DefTgtRg.

LR, SR, and PD ships get one Sensor or ECCM, the one with the smallest OffTgtRg (i.e. the best) that fits within 25% of the space left for PD weapons.

Recon ships seem to get maxed out on last-listed ECCM in TechTables (last-listed object with OffTgtRg). Note that multiple copies of EW items do not increase effectiveness.


Weapon and Mount choices

I've not investigated anything about the decisionmaking process of picking which Planet Destroyer weapon to mount on a Planet Destroyer ship.  Each of SR, LR, and PD ship-types are listed in TaskForceRules as trying to optimize a particular characteristic (NearDamg, AccDisEn, and FireDlay, respectively). For simplicity, I'm going to talk about the decisions based on SR/LR/PD. I've not found another stat that you can plug in there that will work (including FarDamag, which is listed as what IF TF's are supposed to optimize) for DR autobuild choices.

The AI will add mods to weapons according to the following scheme:
•   Point Defense weapons: No mod that increases space or FireDlay gets used. Other mods that reduce either or both get used.
•   Short Range Weapons: No mod that decreases NearDamg gets used. Other mods that reduce space or increase NearDamg get used.
•   Long Range Weapons: No mod that decreases AccDisEn gets used. Other mods that reduce space or increase AccDisEn get used.
The Autobuild AI will consider the effects of the above mod choices when making decisions according to the following rules:

Point Defense ships: For the type of the primary weapon, it picks the weapon with the smallest FireDlay (in general, every weapon except the New Orion weapons has the same FireDlay of 2.5 seconds). From any ties there, it chooses the weapon with the highest base tech level. From any ties there, it picks the weapon lowest on the TechTables list. It uses the available mount highest on the list in TechTables. Once it has stuffed as many of those in as it can, it will try to fill in the remaining space by going down its list of "best PD weapons" and finding the best one that will fit at least one weapon in.

Long-Range ships: For the type of the primary weapon, it picks the weapon with the highest AccDisEn. From any ties there, it looks like it prefers the weapon with the smallest InfoWeap number (the order weapons are listed in the weapons table). For the mount, it selects the mount furthest down the TechTables listing (since TechTables lists the PD, then Light, then Standard, then the Heavy Series, then the Spinal series, it will only pick Heavy series mounts for LR ships if there are no Spinal mounts available). If the selected weapon/mount combo is too big to fit, it will try smaller weapons. 25% of space is reserved for filling with weapons chosen according to the PD criteria above; Sensors consume PD space.

Short-Range ships: For the type of the primary weapon, it picks the weapon with the largest NearDamg. I haven't been able to determine what governs choices between ties in this case. If the selected weapon/mount combo is too big to fit, it will try smaller mounts. It follows the same scheme for weapon mount choice and secondary weapons as it does for LR.

Indirect-Fire ships: It takes the last-listed warhead you've got and puts it on the chassis furthest down TechTables. It then fills in space with PD nukes. I haven't yet tested how it decides to use PD nukes; I assume the PD chassis is selected as the first listed in TechTables, nukes are probably chosen as the first warhead listed in TechTables (and if there were lower-listed warheads with smaller space, they'd presumably be used in any case where the PD nukes wouldn't fit). It builds 5-missile racks.

Carriers: It selects the fighter weapon listed last in TechTables, and fills the carrier with SCFs of this type. It then fills the rest of the space with Laser Interceptors. Predictably, the SCF/interceptor choice is made by position in TechTables, and it's also the case that the weapon used for "padding" is chosen by taking the first figther listed in TechTables. It looks like for the primary fighter, it'll add all available mods and for the "padding" it will ignore mods

Engine Speeds

Colony ships, Transport ships, and Outpost ships get autobuilt with 60% of their max speed. IF ships get autobuilt at 80% of max speed. Everything else gets full system engines.

PD bug

Before the 1.2 patch, there was a severe problem that ships usually failed to acquire the first inbound volley of missiles and/or fighters before they hit/start firing. The best workaround that was found is to make sure that every TF you want to have firing PD has a missile rack with missiles remaining.

The 1.2 patch has largely, but not entirely, alleviated this problem.

Presumably modding Sensors to work will improve the behavior of PD to some degree.

TF AI

This information is based on preliminary testing only. Others have done their own tests and found results that contradict my own, so take the following with a grain of salt:

TF AI is done by TF type, and does not care about the ship designations within the TF. (This assertion in particular is disputed by the tests performed by Blaze/Renaux.)

LR and SR AI: On Watch mode, fighters and missiles are prelaunched (fired before any targets are detected). On Control mode, it auto-launches and auto-fires (fires on targets as soon as detected and in range, without any orders from the player). In Watch mode or when directed to attack a target, it will attempt to maintain a particular target range. If its max AccDisEn is longer than than that of its target, it will attempt to maintain its target's max AccDisEn; if its max AccDisEn is shorter than that of its target, it will attempt to maintain approximately 40% of its max AccDisEn.

IF and CV AI: On Watch mode, it prelaunches fighters and missiles; on Control mode, it autolaunches and autofires at a range that seems based on its DF max range. When in Watch mode or when ordered to attack, it will compare its DF combat stats with the DF stats of the target as to whether it should charge or run away from the target.

Colony and Outpost AI: On Watch mode, it prelaunches fighters and missiles; I expect it autofires in Control mode. In Watch mode, I've observed well-armed TFs maintain a moderate distance between them and their target while firing; I expect that this is triggered by the DF stat comparison leading the AI to believe it was more powerful than the target. It seems likely that similar behavior will be seen in Control mode.

Recon AI: Seems to take the firing behavior of LR and SR and the movement behavior of IF and CV.

The DF stats comparison mentioned above seems to use the same calculations as are used to generate the TF stats that display in the lower right corner during combat, so it is possible to fool the AI into thinking that a TF is better or worse than it actually is. My only hard data point on this is reducing FireDlay to below the apparent effective cap. I currently expect that this is the reason behind the kludges used for Mass-classed weapons, which all have unused FarDamag stats. The same calculations are apparently also used in determining AI retreat behavior and which options the AI defaults to for the pre-combat options ("Blockade Planet", "Intercept Fleet", etc).

Data Appendix

<edit - While I updated the first post with the last code patch, I'd forgotten to update this, so for the past year it's been saying that AP doesn't work and similar. Oops.>

Included are the raw stats for various elements discussed in the header post. I'll probably add interpretive tables over time.


Hulls
Code:
Hull      Num   Space   Cost   TechLvl
-------------   ----   ------   -------   -------
Lancer      00   50   50   0
Cutter      01   70   71   0
Corvette   02   100   102   0
Frigate      03   140   149   0
Destroyer   04   200   219   0
Light Cruiser   05   285   325   0
Cruiser      06   405   487   6
Battle Cruiser   07   575   729   11
Battleship   08   815   1132   17
Dreadnought   09   1155   1756   23
SuperDN      10   1635   2736   29
Titan      11   2310   4323   34
Behemoth   12   3265   6853   40   
Leviathan   13   4615   11122   45

Armor
Code:
Armor      Num   Points   Defl   Cost   TechLvl
-----      ----   ------   ----   -----   -------
Zortrium   01   100   2   10   0
Duranium   02   200   6   30   10
Titanium   04   400   10   70   20
Neutronium   07   800   14   150   30
Adamantium   10   1600   18   310   40


Armor Weights
Code:
Armor Weight   Armor*=   Defl*=   Cost*=   TechLvl
------------   -------   ------   -------   -------
None      0   0   0   0
Very Light   0.5   0.5   0.75   0
Light      1   0.66   1   0
Medium      2   1   3   11
Heavy      4   1.5   7   21
Very Heavy   8   1.75   12   35
Ultra Heavy   16   2   18   45
Missile/Fighter   0.5   0.25   0   5









Shield Techs
Code:
Shield Class   StpPow   ShdStr   Rechrge   Cost   TechLvl
------------   ------   ------   -------   ----   -------
I          0.5   50   5   50   04
II          0.54   75   8   63   10
III          0.58   125   13   79   15
IV          0.62   200   21   100   20
V          0.66   325   34   126   25
VI          0.7   525   55   159   30
VII          0.74   850   89   200   35   
VIII          0.78   1375   144   251   40
IX          0.82   2225   233   317   45
X          0.86   3600   377   400   50
Damper Field   0.75   32000   32000   750*   45

       *: takes up 3* space of others


Shield Generator Sizes
Code:
Generat. Size   ShStr*=   Rech*=   Cost*=   % HullSpace   TechLvl
-------------   -------   ------   ------   -----------   -------
Small      0.66   0.5   0.7   2.5      0
Standard   1   1   1   5      0
Large      1.5   1.5   2   10      16
Missile/Fight   0.33   1   0   0      16

Note: Damper field takes up 3* as much space as normal

DF Weapon Mounts
Code:
Mount      Dam*=   Range*=   Dlay*=   Space*=   Cost*=   TechLvl
-------      -----   -------   ------   -------   ------   -------
Point Defense   (*)   0.75   0.75   0.8   1   9
Light      0.8   0.8   0.8   0.8   0.75   0
Standard   1   1   1   1   1   0   
Heavy      1.5   1.3   1.2   1.75   2   12
Very Heavy   2   1.7   1.4   2.75   3   28   
Ultra Heavy   2.5   2.1   1.6   4   4   39
Spinal      2   1.5   2.2   1.5   3   0
Improved Spin   3   2   3.5   2   5   27
Ultra Spinal   5   2.5   5   3   7   39

This above is listed in TechTables order.
Damage multipliers are to both NearDamg and Fardamag. 
Range multipliers are to all four range stats.
*: The Point Defense Mount has a NearDamg stat of 0.5 and a Fardamag stat of 0.33;
     it gives a MaxAccry bonus of *= 1.5








Direct-Fire weapons
Weapon   NearDam   FarDam   DmgDsEn   MaxAcc   Cost   Space   ShldPen   TechLvl   Number   Mods
------   -------   ------   -------   ------   ----   -----   -------   -------   ------   -------
Laser   7   1   7167   0.7   5   10   1   1   0   M1, M2, Imp, AP, AF, Cont
Mass Dr   14   3*   5733   0.5   9   22   1   1   9   M1, M2, Imp, AP, AF
Fusion   31   2   6167   0.8   21   15   1   5   1   M1, M2, Imp, Cont, Env
Quark   15   3   8017   0.7   10   12   0.9   5   14   M1, M2, Imp, AP, Cont
Hard Be   15   7   11333   0.7   10   7   1   10   15   M1, M2, Imp, AF, AP, Cont
Neutron   33   3   11628   0.7   22   15   0.9   15   2   M1, M2, Imp, AP, Cont
Rail Gu   30   7*   9067   0.5   20   13   1   10   16   M1, M2, Imp, AF, AP
Gravito   49   3   13433   0.7   33   18   0.9   20   3   M1, M2, Imp, AP, Cont
Hellfir   67   10   8944   0.8   45   19   1   15   17   M1, M2, Imp, Cont, Env
IonPul#   33   4   15500   0.7   22   10   1   20   11   M1, M2, Imp, AF
Parti$#   49   10   13433   0.9   33   18   0.1   20   12   
Phasor   48   5   17583   0.7   32   14   1   25   4   M1, M2, Imp, Cont, AF, AP
Plasma   213   6   13111   0.8   142   44   1   30   5   M1, M2, Imp, Cont, Env
Gauss   97   9*   14067   0.5   64   27   1   25   10   M1, M2, Imp, AP, AF
LFG#   2.5   36^   6364   0.9   24   10   0.7   25   23   
DEB   107   20   17044   0.7   70   25   1   35   19   M1, M2, Imp, AP, Cont
Disrupt   209   20*   17400   0.5   139   54   1   35   6   M1, M2, Imp, AP, AF
Death#$   157   50   18850   0.9   105   45   0.8   35   13
Disint   105   23   21750   0.7   70   25   1   35   19   M1, M2, Imp, AF, AP, Cont
Megabol   314   23   14500   0.8   209   59   1   35   22   M1, M2, Imp, Cont, Env
Tachyon   231   27   20656   0.7   154   61   0.9   40   20   M1, M2, Imp, AP, Cont
DarkMat   453   30*   20733   0.5   302   95   1   45   21   M1, M2, AF, AP
Mauler$   679   1!   15889   1@   453   113   0.5   45   7   M1
Stella$   1000   200!   28000   1@   666   495   1   50   8

The above is listed in TechTables order
Default stats:  FireDlay: 2.5; MultFire: 1; DmgDisSt: 4500; AccDisSt: 4500; AccDisEn = DmgDisEn.
DmgDelta is by default the difference of NearDam and FarDam.
*: DmgDelta is 0, and DmgDisSt is set to DmgDisEn-1, so damage is always NearDamg
!: DmgDelta is 0.
@: AccDisSt is set to AccDisEn-1 so accuracy is always MaxAcc.
$: Mauler's FireDlay is 4; Stellar Converter's FireDlay is 8; Particle and Death are 2.
^: MultFire = 5; FarDamag is equal to NearDmg, so DmgDelta is 0.
#: Innate armor piercing.  0.7 for LFG and Death Ray, 0.8 for Ion Pulse Cannon, 0.9 for Particle Beam.
DF Weapon Mods
Code:
Mod      TechJump   Effect
----------   ---------   -------
Autofire   +4      MultFire *= 3, Space *= 2
Continuous   +4      MaxAcc *= 1.5, Space *= 1.25
Armor Penetrat   +4      ArmrPen *= 0.75, Space *= 1.5
Enveloping   +4      ShldPen *= 0.5, Space *= 1.66
Improved   +13      NearDamg *= 1.5, FarDamag *=1.1
Miniturize 1   +4M      Space *= 0.8
Miniturize 2   +8M      Space *= 0.8

TechJump indicates how many tech levels above the weapon you find
  the mod.  'M' indicates that the mod is found in the Mathematics
  tech group.


Warheads
Code:
Warhead      Number   Damage   Cost   Space   TechLvl
---------   ------   ------   ------   -----   -------
Nuclear      01   56   14   6   0
Anionic Energy   02   82   15   6   7
Neutronium   03   121   17   7   15
Hercular   04   178   19   8   18
Merculite   05   262   21   8   19
H.E. X-Ray   06   386   23   9   26
Scatter Pack   07   568   25   10   31
Ionic Pulsar   08   836   28   11   35
Energy Pulsar   09   1231   31   12   41
Omega      10   1811   34   14   45

All warheads have FireDlay = 45, MaxAcc = 0.95.

Missile Chassis
Code:
Chassis      Dlay*=   Cost*=   Damag*=   Space*=   TechLvl
-------      ------   ------   -------   -------   -------
Point Defense   0.1   0.75   0.25   0.25   0
Rocket      0.5   1   1   1   0
Light Missile   1   2   2   1.25   18
Heavy Missile   1.33   3   4   1.75   28
Torpedo      1.66   5   5   2.5   37












Fighter Weapons
Code:
Weapon      NearDam   DmgDelt   MaxAcc   Cost   Space   ShldPen   TL   Mods
---------   -------   ------   ------   ----   -----   -------   ----   ----
Laser      4   3   0.7   4   6   1   1   AF
Mass Driver   7   0   0.5   7   13   1   1   AP
Fusion      15   4   0.8   15   14   1   5   Env
Neutron      17   8   0.7   17   7   1   15
Graviton   25   12   0.7   25   9   1   20
Phasor      24   15   0.7   24   7   1   25   DualPod
Ion Pulse Canno   16   16   0.7   16   5   0.5   20   DualPod
Particle Beam#   25   20   0.9   25   9   0.1   20
Gauss Cannon   48   0   0.5   48   17   1   25
Death Ray#*   78   50   0.9   78   22   0.7   35
Plasma      107   25   0.7   107   41   1   30   DualPod
Disruptor   105   0   0.5   105   32   1   35

The above are listed in TechTables order
Default stats are FireDlay 2.5 and Multire 1.
*: FireDlay of 2.
#: Innate Armor Piercing: 0.8 for Particle Beam and 0.7 for Death Ray.

Fighter Mods
Code:
Mod      TL   Size*=   Cost*=   Effect
---------   -----   -------   -------   -------
Auto Fire   +7   2   1   MultFire *= 3
Armor Penetrat   +3   1.5   1   ArmrPier *= 0.75
DualPod      +4..7M   1.8   2.25   MultFire *=2

Fighter Chassis
Code:
Chassis      Size*=   Cost*=   Effect
---------   ------   ------   ------
Interceptor   1.5   1   
Space Control F   3   2.5   NearDamg *= 1.4, FarDamag *= 1.2

The above is listed in TechTables order.


System Engines
Code:
Engine      Cost   Size*=   Speed   TL
--------------   ------   ------   ------   ---
Thrusters   25   0.25   1500   0
Improved Thrus   27   0.235   1800   5
Hydrogen Fuel   30   0.2325   2100   10
Impulse Engine   32   0.218   2400   15
Iridium Fuel C   35   0.2155   2700   20
Dotomite Cryst   37   0.201   3000   25
Uridium Fuel C   40   0.1995   3300   30
Reajax Fuel Ce   42   0.185   3600   35
Trilithium Cry   50   0.183   3900   40
Transwarp Driv   52   0.169   4200   45

Interstellar Drives
Code:
Drive      Cost   Size*=   Speed   TL
---------   -----   ------   ------   ---
Retro Engine   100   0.25   85   0
Nuclear Engine   126   0.235   105   5
Sub-Light Drive   158   0.2325   133   10
Fusion Drives   200   0.218   168   15
Impulse Drives   252   0.2155   211   20
Ion Drives   318   0.201   266   25
Anti-Matter Dri   400   0.1995   336   30
Inter-Phased Dr   502   0.185   422   35
Hyper Drives   634   0.183   532   40
Warp Factor X   800   0.169   672   45


Mandatory Ship Systems
Code:
System      Cost   Size*=
---------   -----   -------
Bridge      25   0.02
Crew Quarter   10   0.05
Life Support   40   0.02

Electronic Warfare
Code:
System          Size    Cost    OffTgtRg DefTgtRg Cloaking TL
-----------     -----   -----   -------- -------- -------- ---
Sensor I        15      30      0.85                       0
Sensor II       20      90      0.79                       13
Sensor III      35      150     0.63                       17
Sensor IV       55      210     0.46                       30
Sensor V        90      480     0.25                       41
-----------     -----   -----   -------- -------- -------- ---
ECM I           15      30               1.12              0
ECM II          20      60               1.17              12
ECM III         35      120              1.33              20
ECM IV          55      240              1.6               28
ECM V           90      480              2.2               37
-----------     -----   -----   -------- -------- -------- ---
ECCM I          15      30      0.87                       0
ECCM II         20      90      0.81                       12
ECCM III        35      150     0.67                       20
ECCM IV         55      210     0.5                        28
ECCM V          90      270     0.3                        37
-----------     -----   -----   -------- -------- -------- ---
Cloaking De     15      30               2.2      1.5      18
Phased Cloa     20      30               3.3      1.8      29
Reactive Cl     35      30               4.95     3        38
Ghost Devic     55      39               7.425    7.4      45
-----------     -----   -----   -------- -------- -------- ---


"I could have conquered Europe, all of it, but I had women in my life." - King Henry II of England
I may be drunk, Miss, but in the morning I will be sober and you will still be ugly. - Winston Churchill
Wine is sure proof that God loves us and wants us to be happy. - Benjamin Franklin

solops

#6
Interesting Implications

<edit - Note that this was all written pre-code-patch (1.2? something like that) and thus there are things that are now inaccurate. I may rewrite it someday, but don't hold your breath.  >

The following is conclusions I've drawn from the information above. If you think I've drawn an incorrect conclusion, point it out. I'll be glad to fix mistakes in my reasoning. I'll try to avoid wandering into speculation that isn't driven primarily by the specific mechanics discussed above (for example, I'll try to stick to things like "At range X and tech level Y, the following weapon/mount combos seem to offer the best damage efficiency once shields and deflection are counted in" instead of offering up the l33test TF I can design).

I'll be adding sections over the next week or so, I expect... which means I might be done in time to have it all be obsoleted by the code patch. 


Point Defense

First off, the fact that weapon mounts can't affect MultFire means that the PD mount is itself pretty worthless right now. Without that MultFire *= 2, it has no benefits over the Light mount.

For the rest of this, though, I'm going to be optimistic and talk as if QS is fixing the mount problem in the code patch (hey, QS, if you're listening: while you're enabling MultFire in mounts, could you make fighter chassis able to mod fighter weapon combat stats, and shield generators able to change StpPow? I'll be explaining why these would be useful in my upcoming post about making the AI better at combat through mods.). I'm also not going to be talking about the PD bug.

How do you kill an incoming missile or fighter? In general, a sequence of shots hit the target. Assuming that after getting past any shield's stopping percentage deflection doesn't stop the shot, each shot chews away at armor or hits internals. The first shot's going to hit armor; after that, each one has a chance of hitting internals equal to the fraction of the armor that's missing from previous hits. Generally, before the shields are depleted and long before the armor is run out, enough hits have gotten past armor to destroy all the internals and the target blows up.

I'm guessing that firing on a swarm of missiles/fighters leads to shots being randomly distributed between the targets. This guess is based on casually observing what happens in that case and when DF volleys fall on TFs. I haven't done the testing to try to distinguish between that case, shots being evenly distributed, and shots falling on single targets in sequence; the behavior I've seen seems to bear the most resemblance to the first, offhand.


The following elements are what's particularly relevant to a weapon/mount combo being good for point defense:

Getting Past Deflection: This is actually a significant concern. Most weapons (generally anything that's not mass-class) only average 35-45% of their maximum PD-mount damage when firing at max range; a PD-mount Ion Pulse Cannon only averages 3.366 damage per hit at max range. About half the shots that hit will do damage less than that. IPCs are TL20. At TL 20, shields have 0.62 StpPow and missile armor has a deflection value of 2 (or 2.5 if fractions are kept, or 3 if it's rounded up; I should test this more). Weapons with no damage dropoff (mass weapons and Lightning Field Generators) generally don't have to worry about this; plasma weapons with their high damage are better about it than beam weapons. In the lategame, when shields become very effective, particle weapons' shield piercing effects are actually fairly useful. Deflection is abig downside to using the PD mount (assuming, of course, that the code patch gets it working), since with most weapons a significant fraction of your shots are going to get stopped by it.

Efficient Packetization of Damage: Up to the threshold where a single shot getting past shields can kill all the internals (ignoring armor) in a single hit, what's important is efficiency in dealing out damage. Past that threshold, efficiency of producing independent shots is more important; the value of of damage output increases goes approximately with the square root. So, a weapon that does twice as much damage per hit as it takes to kill all the internals is only 40% more effective than a weapon that does precisely enough damage to kill all the internals. Now, most weapons do randomized damage, so the value of raising your expected value per hit a fair ways above the amount required to kill the internals in one shot is better than that (since you're increasing the probability that a given hit can kill in a single shot).

Shield Penetration: Since in general you're not going to run out the shields on a point defense target before you kill it, and since getting past deflection is actually an issue with PD mounts, weapons with shield penetration are fairly handy for point defense work.

Range: Long-ranged PD has two uses. Primarily, it allows your TFs to support each other. If your per-TF point defense effectiveness with weapon A is three times that with weapon B, but you've got ten TF's in the battle and they can all support each other with B but not A.... It can also have the effect of letting your PD get multiple volleys in before an incoming wave of missiles hits. Followup volleys have the advantage of firing at shorter range, reducing damage and accuracy dropoff; this means the followup volleys are generally far more effective.


If you go for single-TF-focused PD, nothing beats Lightning Field Generators. They don't have damage dropoff, they've got good shield penetration, their damage packetization is such that they never hit deflection (at least against AI designs) even with a PD mount, and they have MultFire *=5 to get an obscene damage output efficiency. Of course, their short range is such that you're not going to get much inter-TF PD support with LFGs.


It's often the case that your best PD is lower-tech weapons outfitted with useful mods like continuous and autofire, especially since right now you should be using the Light mount and thus aren't in nearly as much danger from deflection. (Once the PD mount is fixed, the benefit of keeping ahead of deflection while using its MultFire bonus might push more for using the highest tech available.)


I haven't done enough testing of missile velocities to determine what ranges and tech levels will lead to X number of volleys. If I do (or anyone else does) that testing, I'll expand this section to cover that.


Armor and Shields

Armor: Since QS halved all armor costs in the data patch, one really doesn't have to do any math on the subject of what kind of armor to put on a ship. Just pile it on. Sure, as the Armor/Internals ratio grows the per-armor-point value of the armor goes down, but unless you're building hulls far far below your technological limit, the cost of armor is a small fraction of the total cost of the ship and thus negligible compared to its benefit. Troop, outpost, and colony ships are often far far below your size limit, and they generally see less combat than the other ship types, so minimal armor on them makese sense. Every combat hull, though, should really max armor.

Shields: If you've got a starship that has the mandatory equipment and moves at top system speed, you've consumed between 59% and 42.8% of its space (depending on Tech Level). So, the difference between consuming another 2.5%, 5%, or 10% for shields is significant. At TL16, when you gain access to the Large shield generator, you're down to 47.4% of your space left before you add a shield or weapon. The large shield generator will consume 20% of your remaining space. Will it increase the ship's survivability by that much? The answer isn't straightforward, but here are some thoughts:
•   Deflection: One element of a shield's usefulness is that its stopping percentage can drop the damage dealt by an attack to below the deflection threshold. When it does that, the hit does no damage to armor or internals. This is most relevant if you're fighting at extreme range, if your opponent is using Light or Standard mounts, and particularly against fighters. Most of the point of the Spinal series is to be able to do damage at long range without dropping below deflection levels.
•   Combat Intensity: The faster ships are blowing up, the less time the shields have to recharge on something that's taking damage. It takes 10 seconds to recharge a shield from 0 to max, in general (small shield generators take about 13). If you've got two LR TF's sniping at each other at long range, shields are unquestionably worth it; the shields will generally be able to recharge in between salvos. If you've got 10 TFs versus 10 TFs, whatever's taking fire isn't going to get any noticeable recharging in. A shield's strength points alone are generally not going to justify its space, you need to benefit from its recharge rate.
•   Force/Tech Ratios: If you expect to be steamrollering an enemy, shields will help keep down the attrition you suffer in the process. If your tech is significantly superior to your opponent's, the value of shields goes way up, as you start forcing them beneath the deflection threshold and benefit more from recharging. If you're overwhelmed in tech or force, shields aren't going to do you much good.
•   System Ships / Orbitals / IF / CV: System ships and Orbitals don't have warp engines. All four of the listed frequently have system speed significantly reduced. Both of these significantly increase the space available, and thus reduce the effective space cost of shields for these types of ships.
Damper Fields: Damper fields merit their own section apart from normal shields. They take up enough space and their shield points and recharge rate are sufficiently close to infinite that you should probably never install anything but a small one (I really hope QS closes this loophole; I'd prefer they did it by making Damper Field the largest shield generator rather than by writing code to ban it from using the small generator; in any case, fixing this is necessary to prevent the AI from shooting itself in the foot by building Large Damper Fields all the time in the late game). Damper fields very clearly do increase the survivability of a ship by an amount that justifies the 7.5% of the hull (approx 13% of the space after essentials). Looking at the example of Ultra Heavy Disintegrators firing at 50% of their max range against a leviathan with Ultra Heavy Adamantium, a damper field increases the survivability of the ship by approximately a factor of 2 over using a Class X shield with a Large Generator (assuming minimal recharging time). Ships destined for low-intensity combat might benefit from using a non-damper shield, but that dramatically reduces their suitability for high-intensity combat.

I've done some more testing of weapon mods and the Autobuild AI's choices wrt to them; top post is updated to include the info. Basically:
PD: No mod that increases space or FireDlay gets used. Other mods that reduce either or both get used.
SR: No mod that decreases NearDamg gets used. Other mods that reduce space or increase NearDamg get used.
LR: No mod that decreases AccDisEn gets used. Other mods that reduce space or increase AccDisEn get used.




Quote:
Originally posted by clb
It is worth noting that what the player will optimize for should change in the game. Early in the game you have what I will call condition A:
•   Plenty of room in the taskforces, but limited production. For this situation the ships should be optimized for the most bang per buck.
Late in the game you have Condition B:
•   Full Armadas, but plenty of production. Optimising for space (while using the largest hulls) is paramount here.
Note that certain systems and planets can reach a condition B for their system ships (only 18 show up at a time) and orbitals (3 or 4 + 3 per moon?) well before the empire as a whole does for starships. Note that the AI selection of Armor/Shields not only does not distinguish between the situations, but often makes choices contrindicated in *both* situations.

My experience is that there are only really a few things where cost diverges sufficiently from space to really consider building cheap:

a) Armor. But since they halved armor costs, it's really only a big deal if you're building pretty small ships.
b) PD-chassis missiles. You can make an enormously expensive ship by trying to use PD missiles as your primary offensive weapons.
c) The Spinal series. But I never really used those... 'Course, I can shave off 1/3 of the cost of ships the AI autobuilds in various of my savefiles by changing the IS and US mounts to VH and UH.

Minor updates to the header post; fighters get hp bonuses from mods that increase their size is the big one. There are other small ones probably scattered.


I also regenerated the middammetric and fardammetric files. They now list the normalization factor, actually accounts for accuracy dropoff, and fixes a bug in how I was calculating weights. Now that I think about it, though, the 50% range one is going to be inaccurate in two ways: maulers and stellar converters are going to be boosted a bit because I listed their accuracy as 1.67 in the data so I didn't have to deal with flagging them and didn't cutoff accuracies at 100%; and the accuracy used in that table is a bit lower than it should be, since I fed it 50% of total range for accuracy dropoff calculation, not accounting for the min range effect. I'll fix these at some point....

<end of Combat Notes Post...and I repeat, I did not write the above....solops>
"I could have conquered Europe, all of it, but I had women in my life." - King Henry II of England
I may be drunk, Miss, but in the morning I will be sober and you will still be ugly. - Winston Churchill
Wine is sure proof that God loves us and wants us to be happy. - Benjamin Franklin

solops

#7
AI mod stuff I found - I think Bhruic did more work on ECCM/ECM after the below was published - solops
---------------------------

Note that the material below was written mostly before the many of the fixes provided by Bhruic and Guerra.

MAKING THE AI MORE COMPETITIVE – MAINLY ECONOMIC & MILITARY IDEAS
By Great Old One  (circa early 2005)

MOO3 offers more tools than any turn-based 4x game around to make its AI opponents more effective, notably with modifications to the AI bonuses for Heavy Foot of Government (HFOG) and population growth. These two factors allow players to give the AI delayed production and research bonuses. All other AI bonuses, including those in other turn-based 4x games (possibly excepting the more limited Galactic Civilizations) are effective at the inception of a given game such that really large bonuses tend to be most effective in the early turns. This forces players into a limited style of play to avoid being overrun early on by vastly more powerful AI opponents, which makes a game boring after a while, and it certainly limits the duration of the most enjoyable period when real players and AI opponents are roughly comparable in strength.

Giving AI's a major bonus in population growth (say 1.5x instead of the impossible level's 1.25x), though, produces only a small initial AI advantage but one which increases at a decent rate up to about the midpoint of a game. Player empires generally colonize faster than AI empires so this will give them a more comparable population in the early and middle games.

Heavy Foot of Government, though is what can give the AI's their biggest middle and end game advantages. The impossible level gives them only a 15% advantage (a multiplier of 0.85 – if an empire's HFOG would be 2.0, it is only 1.7 at impossible for an AI empire. I recommend setting the multiplier at 0.4 instead, so an AI's HFOG would be only 1.2 where a player empire's HFOG would be 3.0. A setting of 0.4 will pretty much eliminate HFOG for AI empires. This means that, right when player empires start to grow rapidly due to players invading and conquering developed AI worlds, the player empires will have their ship production costs soar while AI empire ship production costs remain the same.

I also recommend increasing the rate at which AI empires colonize empty worlds, at least during the early game. I don't recall the file and factor to modify at the moment. Hopefully someone else will tell us.

It might be appropriate to make outposts into an unobtainable tech (increase their tech level to 100, etc.). My experience is that the biggest player colonization advantage is that players use outposts while AI empires don't. It is much cheaper, and faster overall in the early game, to create colonies on yellow or red zone worlds by creating an outpost there and then have those grow into colonies through migration, than to use only colony ships. I personally create dozens of outpost ships before turns 40-50 – generally before turn 30. Players can also create system colony ships while AI empires don't.

These points are intended to give the AI's more productive capability, and therefore more ships to oppose players with, in the middle and end games. Increasing their productivity per population point, above that in the impossible level as designed, should be done with care as that runs the danger of making the AI's too strong in the early game. Giving the AI's a nastier attitude towards real players runs the risk of breaking MOO3's excellent diplomatic game.

The next issue is how to make the AI's use those ships it has more effectively. That entails having the AI's produce greater proportions of more effective ship designs. It will take me some time to write up my initial thoughts on that, so I'll get off this first post now.
__________________
Tom Holsinger

MAKING THE AI MORE COMPETITIVE – PART TWO

This opens the discussion on how to make the AI use its resources more effectively. That means less waste of resources, better ship and task force designs, more production of warships in more effective proportions to go with improved task force designs, and more effective use of AI task forces.

I'll start with less waste of resources, which includes less production of transports. The AI ground game is broken. Before Bhruic's code patch it was remarkable to ever see an AI empire do a ground invasion. I've played a lot of MOO3 in the past two years and can count the instances of known AI ground invasions, prior to Bhruic's patch, on one hand. Not AI invasions of my worlds. Any AI invasion of any world.

Since Bhruic's code patch I've noticed several AI invasions per game, of which two were against my colonies – both newly established with no defenses. I've also seen the AI attempt two obvious invasions of my new colonies which would have succeeded but for my small defending fleets either winning or getting a draw against the AI attacker. However all of those have occurred in the early game. I am certain that I have never seen successful AI invasions of anybody, or attempted invasions of my own worlds, after turn 100. My recollection is that all were before about turn 60-70. Furthermore all the invasions seemed to be of relatively new, and small, colonies. Some had defenses (a base or two, or a small defending fleet) but most didn't.

It appears that the code is broken for getting the AI to put transport task forces in the same fleets as combat vessel task forces. This results in the middle and end games, in AI combat fleets bombarding target worlds to glass on the turn they knock down the planetary defenses. They don't wait for transport TF's to arrive. In the early game the AI combat fleets tend less often to do any bombardments, while their bombardments are much less likely to immediately eliminate a colony so that there is time for follow-on transport TF's to arrive and do an invasion. Later though, AI combat fleets just nuk'em to glass because they can. If Bhruic were still working on code patches, I'd ask him to make fixing this a priority. But he seems to have given up on MOO3.

Additionally we've all seen constant parades of AI transport task forces through our territory as our allies, or AI empires we have non-aggression treaties with, send unescorted transports at faraway targets. And AI's disband those transport TF's when they arrive because they're defenseless against any opposition whatever. Every single one of those transport task forces was a waste of AI resources.

And AI empires are incapable of building more than one ground unit at a time so they waste the production of scads of heavily industrialized planets building three ground units per turn (the three spaces in a build que). So the ground game is almost a complete waste for the AI, especially after the early game when it ceases to perform invasions. After the early game AI transports are a complete waste of resources, and the only utility of AI ground units is to reinforce planetary militia garrisons and either make real players waste some time and resources taking a few heavily defended AI worlds slowly, or just nuke the smaller ones to glass.

Prior to Bhruic's patch I tried a mod which made all ground units and ground combat tech into unobtainable Antaran techs, and gave transports a build priority of zero in MilitaryAI.txt. This resulted in a noticeable improvement in AI space combat capability – I'd say AI empires had about 30% more warships. It also slowed game pacing down terribly after the early game, because AI worlds which had been nuked to glass had to be recolonized and slowly built up to create mobilization centers. Otherwise I had to send new task forces, created as replacements for those lost in combat, greater and greater distances from existing mobilization centers.

I also had major problems with AI empires that I had alliances or non-aggression treaties with trying to recolonize newly vacant worlds that I had just nuked.

Overall I prefer to keep ground combat, however much it sucks in play-balance terms.

My fall-back position, which I have not started playtesting yet, is to at least reduce the number of troop transports the AI builds. I recommend starting by reducing the number assigned to transport build priority in MilitarAI.txt by about half, and ditto for ground units. AI empires perform only a few invasions in the early game so halving the number of transports and ground units then won't much reduce AI invasions, if at all. But a 50% reduction should cause the AI to use the freed up production points to produce more AI warships in the middle and end games.

An additional thing to try, or use as an alternative, is to eliminate AI transport and ground unit production entirely by Turn 100 or so. Just create a version of MilitaryAI.txt which assigns a priority of zero to transport and ground unit building, exit a game in progress around Turn 100, install the no-ground game MilitaryAI.txt in the Spreadsheets folder, and reload the game. That way the AI empires will be able to do the small number of invasions they perform with Bhruic's patch, but not waste resources afterwards producing things which they never use. This option would have a side benefit of letting players swap in a new version of GovernModifiers.txt around Turn 100 with really big AI production and research bonuses. By Turn 100 such bonuses would not have the adverse effects they'd have in the early game.

This latter point would definitely require a major change in playing styles. Players much prefer mods that don't require exiting a game and moving game files around. Given MOO3's major problems, though, it might be required.

Next week, or perhaps this weekend, I'll put up a post on changing AI ship and task force designs as a vehicle to making the AI more competitive.

MAKING THE AI MORE COMPETITIVE – PART THREE

This continues the discussion on how to make the AI use its resources more effectively. That means less waste of resources, better ship and task force designs, more production of warships in more effective proportions to go with improved task force designs, and more effective use of AI task forces.

Here I go into how to have the AI make better use of its resources in ship design and task force organization. My approach to this is different than most – I look more at strategic outcomes and game pacing, and less at making space combat work the way we think QSI intended it to work (among other things, we have different opinions as to QSI's objectives).

I assume that any mods will end up being mini-maxed by the players to the point where the AI will still suffer significant disadvantages, which again leads to a change in perspective – always ask, how will the AI use the mod?

Beam combat is sexy. We all love beam combat battles because they look pretty and offer players the biggest chance to actually control battles and influence the outcome. Modders focus pretty much on helping the AI design more effective ships for beam combat. But relatively even beam combat engagements are rare. As in really, really rare. This is less a matter of beam combat being rare than that most engagements have such disproportionate force ratios that either result one side retreats before the range is close enough for beams to hit, or are plain one-sided and brutal – generally the attacker's first missile pulse and fighter wave annihilates all the defenders.

So I decided to make a virtue of necessity and concentrated my mod here on boosting the effective of the AI's really long-range weapons – missiles and fighters. We all know the player cheats of arming indirect fire ships with exclusively point defense chassis missiles rather than vastly smaller numbers of much more powerful missile chassis with far slower rates of fire, and arming carriers with huge numbers interceptors rather than much smaller numbers of space superiority fighters. So I gave those to the AI too. All missile chassis now have the same stats as point defense missiles, and space superiority fighters have the same stats as interceptors.

And surprise, surprise, that made AI indirect fire armadas absolutely deadly, and AI carrier armadas more powerful (though not that much more so if you have 6-8 point defense escorts per armada instead of only four). Use of exclusively point defense chassis missiles at least quadruples the number of missiles in a given pulse, which makes it far more difficult to destroy enough of them with point defense beams to save the targeted task force, and lets the AI task force launch at least four of its five total missile pulses before your own first missile pulse can reach them.

So fleet engagements hurt. We know how an AI missile base's first pulse can destroy any single task force when its point defense does not engage, which still happens somewhat. Consider that @ every 5-6 pulses from AI indirect fire armadas armed exclusively with point defense chassis missiles (and assuming that their core ships are generally two hull sizes smaller than yours) can generally do the same even if your point defense does engage. I.e., three AI indirect fire armadas can probably take down at least two of your armadas, with each getting off four of their five total pulses before your first missiles can reach them. That's with my AI armadas, which have only eight core ships instead of twelve, six point defense escorts instead of four, and four beam-armed recon picket ships instead of two. If the AI armadas have core ships of the same hull size as yours, make that one armada of yours lost for every 3-4 pulses launched. And the doubled number of fighters on AI carriers will probably cost you one or more armadas in a fleet engagement.

Suddenly the player losses in fleet engagements will soar when using tactical combat. That has a strategic effect. At present a player can advance up a chain of AI defended warp points, at the rate of roughly one planet every 1.5 turns, with pretty much two fleets - one to attack with and the other to defend newly conquered systems. Generally the only player losses come from the missile bases defending AI worlds when the point defense on the attacking player fleet does not engage the initial pulse from the missile base. But now every fleet engagement will result in at least some player losses, and thereby slow down player conquests of AI planets. This will buy the AI empires the time needed for their HFOG advantages to kick in big-time.

The results of fleet engagements with this mod are actually more in line with the results of engagements on full AI control, which at present tend to produce higher player losses than when a battle is on Watch or Player Control. Right now player fleets suffer less losses on Watch or Player Control, because Quicksilver seems to have ignored Lancaster's Rule in computing losses for AI controlled battles – the attacker's losses tend to be in proportion with the numeric value placed on the size of the defending fleet, rather than the square of the combat values of each side. Here is Lancaster's Rule for those unaware of it.

"I could have conquered Europe, all of it, but I had women in my life." - King Henry II of England
I may be drunk, Miss, but in the morning I will be sober and you will still be ugly. - Winston Churchill
Wine is sure proof that God loves us and wants us to be happy. - Benjamin Franklin

solops

#8
continued------------"Here is Lancaster's Rule for those unaware of it.

http://www.panpub.com/traveller/rules/sociology2.html
Quote:
Lancaster's Rule
"Rule of thumb regulating military casualties. According to this rule, the ratio of casualties suffered by opposing forces, assuming that all combatants have the ability to fire at the opposing side and are in the open and armed with weapons of like technology, is the factor of the ratio of forces engaged in battle between the two sides, squared. Hence if one force is twice the size of its opponent, under these circumstances they will inflict four times as many casualties on the smaller force than they suffer in return. The ratio can be modified by mitigating factors as terrain, fortifications, technological superiority, force or TO&E composition, dispersal and/or concentration, and intelligence. But the casualties remain the square of the force multiplied ratio. Named after an ancient British Solomani scholar."

Lancaster's Rule is what makes interceptors so superior to space control fighters – they have double the numbers (2x2 = 4 times the combat power) while giving up about a 60% firepower advantage (1.6 x 1.6 = 2.56 the combat power). And this does not include the results of the doubled number of interceptors, with the same hit points, armor and shields as space superiority fighters, making them far more surviveable against point defense. Overall I'd rate interceptors as having double the combat power of space superiority fighters. This point is so glaring that I am confident Quicksilver's designers were ignorant of Lancaster's Rule, which surprises me given Alan Emrich.

I don't disregard the need to change beam combat technology so the AI will produce more effective ships, but others have addressed that far better than I could. In particular see Visages' thread and mod here:
http://www.ataricommunity.com/forums...hreadid=292060

My space combat mod requires changing more than space superiority fighter and missile chassis tech. It is vital to turn Missile Armor, Missile Shield, armor-piercing missile warheads, fighter pods and fighter armor-piercing weapons into Antaran techs. This is because the key to my mod is having lots and lots of cheap missiles and fighters. Missile Armor and Missile Shield just aren't cost-effective for ships with lots of missiles. The point-defense only missile chassis concept relies on sheer numbers to get through point defense, not penetration aids. The cost of shields and armor for missiles will double or triple the cost of indirect fire ships armed only with point defense missiles, while adding little to their ability to penetrate point defense.

Likewise armor-piercing technology for missile warheads and fighter weapons jacks up their size too much, as does any type of fighter pods.

But keep Fighter Shields and Fighter Armor.

The doubled numbers of fighters requires more point defense. I recommend increasing the required number of point defense vessels per task force, up from 1 to 2 for flotillas, and up from 4 to either 8 for armadas or, if you've changed recon ship designs to the same stats as long-range space superiority ships, as I have, 6 point defense ships and 4 recon ships per armada. For those unfamiliar with that mod, here is a repost of something I said in Otsego's thread on his mod:
Quote:
Sensors don't work. Even with Bruhic's mod they still don't seem to work. My workaround for this was to mod Task Force Rules (plus maybe one other file – it was more than a year ago). I gave all Recon ships the same design as Long-Range Space Superiority Ships. And I eliminated all sensor techs from the game by making them either Tech Level 100, or Antaran techs. Recon ships now do spotting based on maximum beam range.

But I didn't stop with that – I also addressed the great temptation to abuse the utility of point defense missiles by making them the primary armament of Indirect Fire ships (this was before Bruhic's mod came out, and he added the missile mod to it at my request). I eliminated all missile chassis BUT point-defense by making those unobtainable techs, and ditto for warhead modifications (armor-piercing, etc.). I also reduced the damage done by point defense chassis from 25% of a standard warhead to 15%. So the indirect fire armadas of AI empires are as deadly as my own.

And I didn't stop there either. I made Interceptors the only form of fighter (Space Control Fighters are now an unobtainable tech) and changed the proportion of core/escort/screen vessels in armadas from 12/4/2 to 8/6/4 (similar mods for smaller task forces). The former mod made AI carrier TF's as deadly as my own, while the latter gives every IF and CV armada a potent secondary role in beam combat. The offensive power of individual IF/CV ships is much greater, but there are fewer of them so the overall punch of IF/CV TF's remains about the same.

OTOH, they have 50% more point defense ships, and effectively four LR ships per armada, so their staying power, beam combat values and anti-missile & especially anti-fighter firepower are much greater than in unmodded form. Point defense missiles on IF ships, and laser-armed interceptors on carriers, are actually used only for attack so they are useless for point defense

The vastly increased beam combat values of AI task forces mean their fleets cut and run a lot less often now after the initial missile/fighter exchange. Trust me, player indirect fire and carrier task forces on Watch, and AI IF/CV TF's using these mods, will close to beam combat range and slug it out if they think they can get away with it. Though my monitor almost whites out when several TF's light each other up with point defense Lightning Field Generators at point-blank range.

Inability to address the root causes of the broken sensor tech features, and the need to address other game design imbalances, led me to make several different, minor, mods which together have had a pretty far-reaching effect. Solitaire battles are now somewhat fun, though not as much as they would be if sensor techs worked, but the AI opponents are much more competitive. The key was making Recon ships use LR designs, and doubling the number per armada. This vastly increased the beam firepower values of AI armadas, especially the many recon armadas the AI fields starting about Turn 150. "
"I could have conquered Europe, all of it, but I had women in my life." - King Henry II of England
I may be drunk, Miss, but in the morning I will be sober and you will still be ugly. - Winston Churchill
Wine is sure proof that God loves us and wants us to be happy. - Benjamin Franklin

solops

#9
More------------

Tom Holsinger
spamtomh@yahoo.com

I've found some simple mods for Governmodifiers.txt which will make the AI empires competitive at impossible. These are best used with Bhruic's transport, ground troop and autobuild patches.

The solution lies in modding Governmodifiers.txt at line 176, column B. Reduce HFofGovt to .60 - .75 and add a new OverProd+=1 or +2 . I also suggest you consider eliminating outposts from the game as the AI's just won't use them. Change TechTable.txt at line 353, column H, to Const_99.

You'll need to playtest the changes to suit your style and level of play as each change has the major portions of its effects kick in at different points in a game. Eliminating outposts will significantly slow down early game expansion of real player empires (parking an outpost on a world and growing it into a colony through migration is cheap and easy), and so has its greatest effects appear towards the end of the early game – say about turns 50-75.

The Heavy Foot of Government bonus for AI's lets them produce more relative to real players starting in the middle game period when their empires grow larger in population and numbers of planets, i..e., around turns 100-120 and increases rapidly after that until about Turn 180-200 when AI empires cease to grow much. My experience was that reducing AI empires' HFOG alone wasn't enough to make them more competitive, even when I set it at .40 (40% of what happens to real players).

OverProd+=1 or OverProd+=2 lets AI empires overdrive their industry (get more production from the same number of industrial points by spending money on production) while suffering less penalties for doing so. This is important because AI empires have so few industrial DEA's relative to real players, especially in the middle and late games when players start converting mining and food DEA's into industrial DEA's.

The OverProd bonus for AI empires has an immediate effect – right from Turn 1, and so should be used with care. I find it essential to making the AI's competitive in the end game, but you should start your competitiveness modding with just HFofGovt. and add OverProd+=1 only after you're comfortable with the HFofGovt. bonus to AI empires.

One way to compensate for giving AI empires an OverProd+=2 advantage is to use Bhruic's saved game editor to improve your starting position – make all worlds in your home system ultra-rich paradises for your race. Or leave outposts in the game.

My major point here is that you have several tools to make AI empires more competitive with real players in solitaire games.

I have consistentely extended the period of AI competitiveness from Turn 100 to Turn 200 this way. I didn't start clearly winning my current game until about Turn 260. I wasn't even certain I'd survive to Turn 100.

Try these ideas out and you can have challenging (if not thrilling) games of MOO3 for years.
__________________
Tom Holsinger
spamtomh@yahoo.com

1st Over-Production Test Results

Would putting

OverProd+=2

into GovernModifiers.txt at Line 176, Column B, do the trick? That's the line for AI empire bonuses for the Impossible difficulty level.

Now that I'm home, I can see that OverProd+=1 is in TechTables.txt at Colulmn K, Lines 496-499 (Polyfabric Building Materials, etc.). Wrap-around effect not experienced at +5 OverProduction using technology only. I made the first OverProd tech (Holistic Planning at line 496 of TechTables.txt) into an EconomicsLevel 0 KEEPTHIS OverProd+=2 tech, made the next two at lines 497-498 into Economics Level 0 KEEPTHIS OverProd+=1 techs, and the final one at line 499 was turned from an Antaran tech (Secreted Resins) into an Economics Level 5 KEEPTHIS OverProd+=1 tech.

Then I played the first 13 turns of the game. I saved turns 10 & 11 when Secreted Resins was almost finished. And I saved Turns 13 & 14 when it was finished. Those did not exhibit any effects of a wrap-around industrial production bug.

In my next test, I will give the player race an OverProd+=3 as a racial modifier, and turn the OverProd techs into OverProd+=1 Economics techs at Levels 3, 4, 5 & 6. If no wrap-around effect appears for industrial production, I'd say it won't, and that will be one less thing for Bhruic to fix.
__________________
LATER: Still no wrap-around. It seems safe to give the AI empires a bonus of OverProd+=2 in GovernModifiers.txt at the impossible difficulty level, without changing TechTables.txt.

At this point it looks like the AI's ability to grow by conquest (perform invasions) is the only remaining big AI competitiveness issue.

I'll start a game tomorrow using Bhruic's transport selection patch. My informed guess right now is that this might about double the period during which AI empires can, sort of, successfully perform ground invasions.

That period right now seems to kick in about turns 25-35, starts to peter off around turns 50-60, and dies outright sometime between turns 75-100. This is due to AI inability to coordinate the simultaneous arrival of transport and combat task forces.

The transport selection patch makes the task force creation code choose the newer and faster transports first, instead of the older and slower ones, such that AI transport task forces are more likely to keep up with AI combat task forces.

This should extend the period of effective AI invasions from about turns 30-70 out to maybe turns 100-150.

This could be fun.
__________________
Tom Holsinger  aka Great Old One
spamtomh@yahoo.com
--------------------------------
I agree with the Great Old Ones ideas except for a few small points. The idea that the AI should be enchanced by changing only a few, very powerful modifiers is a good one, as its easier to change the AIs overall effectiveness and make changes based on play testing. What the idea fails to realize is that some of the other modifiers used are there for a reason, which is to patch very specific problems with the AI, problems that generally manifest in the late game. As an example, the AI can't alter any empire level controls like the Oppressometer or tax rates, and it is only allowed to adjust planetery taxes by a few percentage points. This gives the AI huge fundamental problems with dealing with unrest, affording fleet maintenance and esionage expenses, and keeping up with the player in the late game when the huge unrest reduction bonuses from recreation and military DEAs kick in. From my experience It also tries to build enough mining DEAs to fully support every industry DEA built on the same planet, clogging resource poor worlds and using up space better suited for other DEAs.

So, what seems to be needed are AI cheats that increase the AIs ability to manage resources, deal with unrest and simulate the benefits the player gets from being able to change empire level controls such as dev plans and governments that make the AI as competive as the player without making the it too powerful in the early game.

Heres what I'm using for impossible:
BioHaEff *= 1.5, MineEff *= 1.5:
To help with resource problems

SPortEff += 3, TFormCst *= 0.5, HFofGovt *= 0.5, AntarMod *=1.5:

These all provide mid to late game bonuses and help the AI with Antaran expeditions (if AntarMod actually works), while the HFoG bonus helps cover the AIs problem with taxe rates. Spaceport efficiency has been given an additive modifier because multiplicative ones have no effect.

SpInsert+=30, SpOff+=15, SpRepel+=30, SpDef+=15:
These cover the AIs inability to adjust the Oppressometer while increasing the stats of spies so that they are not rendered useless. This isn't one of my favorite changes as it essentailly gives the AI a bonus for spying on the player, but it doesn't give it a preference to do which makes it fairly "gray area" for me.

MdUnrest*=.5, MdUnrest+=-30, OSTradAU*=1.5,BoxDelay += -5, FltMaint *=0.5:
These help with the AIs problems with fleet maintenance, unrest, and fleet maintenace (if BoxDelay actually works).

Also, its worth noting that I increased the cost of ground troops and changed economic elements around a lot, as well as the scope of planets that the AI considers for colonization and changed some AI in military ai.txt.

Otsego19
-------------------------------------------------------------------------

Quote:
Originally posted by JosEPh
The table Does NOT allow for the manipulating of the Holy War settings.

As far as I've been able to tell it's hard coded, hopefully I'm wrong. I personally would like to see the Holy War setting removed from the Game. Or at the very least GREATLY REDUCE the AI's programming to use it. The AI goes into Holy War setting WAY too easy!
JosEPh, what you want to look at is MilitaryAI.txt. The table there which says:

TableStart BorderPolicyModificationPref
ColumnHeadingsStart KeepTheSame RaisePolicy LowerPolicy
RowHeadingsStart
preference 8 7 3

Despite being called "BorderPolicyModificationPref" is actually the determinant for Military Political economy. (I have tested this, so I know it to be the case) Anyway, I don't fully understand how it works, but as it stands, the table is biased towards raising the policy. If you set "Raise Policy" and "Lower Policy" both equal to 5, you will see a dramatic improvement in terms of the AI maintaining generally lower Military-Political Economy settings.
__________________
Strifeguard
------------------------------------------------------------------------------

Originally posted by jlab

try not to get too into detail, but i have dealt with several points you mentioned in my own way for my own mod:

increase the frequency of magnates. this is really the only solution barring eliminating them entirely. in many ways they are the game. more people on more planets building more ships. greater frequency makes it more likely that everyone will get at least one.

population.txt contains controls for migration. this relates to the outpost colonisation issue. i found the quantity of migrants to be too high in 1.2.5, so i changed it, particularly in regards to yellow and red planets. i got tired of masses of people showing up on planets where they really didn't belong, according to their hab and grav preferences. now it takes a lot longer for an outposted world to fill up, unless it's green. also, outposts really aren't that much cheaper than colonies.

i reduced the penalties for non-preferred gravity from .75 and .5 to .85 and .7. this helps game pacing and really benefits the ai - which plops down colonies on inappropriate worlds much more often than the player.

the baseemph value in modifiers.txt is what you're looking for to increase ai colonisation.

i changed the economic model in some significant ways. more cement (+66%) and test tubes (+100%) per pop. less pop required for all deas except industry. doubled base dea efficiency for gov, mil, rec, and spaceport deas. modded all deas to cost 200 pps to build. this helps the ais problem of over-building deas before they're needed, and eliminates the player cheat of starting a cheap dea then switching mid-construction to a more expensive one - you will notice that you don't actually pay for the upgrade. increased mineral efficiency for very poor, poor, and average worlds. similar treatment for bioharvest. hulls are cheaper and larger, troops are more expensive.

i added a +1 corrcap modifier to all ai difficulty levels in governmodifers.txt. this is the mod that determines the percentage of imperial grant money planets lose to corruption, so now the ai is much less likely to have a size 6 planet with 4 gov deas.

i for one enjoy the ground game, hokey as it is. and i have lost several worlds to ai invasion since Bhruic's patcher - to my eternal delight. i have also found evidence of ai vs ai invasions in autorun games opened with the mulitplayer option. this can be a large factor for the AI. i've added gndcombt+= mods to ai difficulty levels as well.

the advantageneeded table in militaryai.txt can be heavily tweaked to make the AI more likely to attack. this really needs to be done to fully enjoy the patch, because the ai will sometimes refuse to land troops even on a completely defenseless world.

i agree that striking a good balance between what the ai produces is important. militaryai.txt controls the ratios. i'm still thinking about disallowing system ships and orbitals. the ai really doesn't know what a chokepoint is.

one of the better things i've seen for the ai is loosening up task force restrictions, allowing LR and SR into the escort ring and PD and Recon into the pickets for all task forces.


SHIPBUILDING
Quote:
HIDETHIS -- Simply causes it to not appear in the tech tree. For example, the no armor(for ship armor) tech has this tag also.
Is that in the display portion of the tech tree? Obviously the computer AI is capable of building militia, just the players are not allowed to actively control this. Wonder if the AI can be given the ability to build other things that the player cannot?
Quote:
Const_99 -- to keep it from ever getting researched, since the tech tree ends at 50, not level 99.
Strange that it cannot get researched and yet it exists, unless it is a completely independent subroutine. Just wondering if any other attributes were attatched to that particular flag. Using a flag like 99 is good to make sure something stays at the end of a list, and stays grouped. Just an unusual paradox that's all.
Quote:
Regarding Hull_Bld -- I'm pretty sure what this controls is the maximum size of hull a planet can build(i.e. light cruiser for homeworld at the beginning of an unmodded game). I am not 100% positive on this, but I'd be surprised if I'm wrong.

confirmed on Hull_Bld. All of the capacity-enhancing buildings such as Basic Systems Module, Space Environment Module, etc, have the Hull_Bld += 1 modifier, meaning that one size larger hull can be built at a planet which installs these improvements.
In modifiers.txt the parameter is set a bit differently.
Hull_Bld + 20
How big of ships can this planet build?
Note: The developers put a question mark on this. The scale factor is set at 20.
Scale Factor is a number that gets multiplied with the modifier value to give us a number relative to 100 for the AI to know how much a modifier helps or hurts.

The likely usage is that the AI is prioritizing hull building improvements, in weighing when it should be put into the build que. Increasing it would just make the AI want to add better spacedocks sooner, I think.

What I had been hoping is that it was using the factor to choose which hull size to build, when building ships. Stubborn enough not to rule out the idea completely until it is tested, but I think that the build que thing is more likely. Just that question mark at the end of the comment, keeps me from being entirely sure.

======================

OTHER:
Any idea what the colonial decision lottery is? (BaseEmph) Is that to do with colonization routines or galaxy construction perhaps?

Box Delay: This one is used in some chart, as recall, a higher state of war readiness adjusts this. Wonder if it can be used to change the cycling speed of ground troops/ troop ships (if it can be applied that specifically) and what the ramifications of that are.

HullERM: Think this one is tied to space combat, think it had some effects on accuracy or something. This may have been the one I initially saw, that triggered this concept of being able to change what hull sizes could be built. (wish I could remember which one that did that. Might as well keep looking though.)

MiliQual and MiliQuan: This could be for a number of things, and is probably useful once it is determined how it works. Suggests military quality and quantity. Might have some bearing on the class of units versus cost in the AI routines. Whether this applies to ground troops, space ship building, or ground combat balance, it is probably important to look into.

MilitiaU: (Militia Units generated). A noted change in the invader spreadsheets. May have a few indirect effects. More militia might mean less troops are required to station, therefore more available for the reserves. May have the opposite effect of deterring transports due to strong defenses. Have to look at how this was used.

PlanDef: Presumably planetary defense. Is this used for prioritizing planet defense builds or possibly for the AI to build up ground defenses, or just the likelehood of roy using it in his development plans. Not sure of the implications, but it is interesting enough to note. (Has military flag as far as application, which may indicate more concrete usage than a development plan priority)

Miscellanious:
MaxRatio + 100
MinRatio + 100
NulSuprn - 100
tsoCtsyS + 0

These do not have a specific flag (such as terraform, military, etc.)
Ratios: Could be referring to almost anything, which is probably why they are undocumented. These two have high scale factors but no initial base priority. Interesting because they probably have a significant influence, but no idea what they do.
NulSuprn and tsoCtsyS: Nullify suppression (?) and ?... any guesses as to what these are or what they might stand for?

Just looked through all of those without an (!). So presumably these are usable variables in the right place. The ones above may or may not have relevance to current discussions.

Didn't see anything that relates directly to the hull/production issue, so the notion must have originated with hull_build and hull_ERM, either that or it was something in another table, or a modifier notation instead of an active modifier.

Just a few things to think about. Some of which may pertain to military behavior. Any comments? Might be fun to speculate about. Are any of these known in a more precise sense? Anyhow, kinda got sidetracked from where I started this post. But figured these things were at least worth taking note of.

Shaper
"I could have conquered Europe, all of it, but I had women in my life." - King Henry II of England
I may be drunk, Miss, but in the morning I will be sober and you will still be ugly. - Winston Churchill
Wine is sure proof that God loves us and wants us to be happy. - Benjamin Franklin

solops

Heavens...I have barely scratched my archives. The stuff above seemed the most interesting in the first quick glance. I will sift through and see if anything else is really intriguing. I have many of the old mods, too.
"I could have conquered Europe, all of it, but I had women in my life." - King Henry II of England
I may be drunk, Miss, but in the morning I will be sober and you will still be ugly. - Winston Churchill
Wine is sure proof that God loves us and wants us to be happy. - Benjamin Franklin

solops

#11
Posted by "Max"

some observations on tech slowdown
This thread is not intended for a debate over the pros and cons of slowing down tech advance. If you're itching for an argument, go someplace else. I'm simply providing data and looking for the same, not inane chatter over the 'best' way to play the game.

All testing was done on huge, three-arm galaxies. This is the only galaxy type I play in; I'm not interested in the others and won't test for them. If tech advancement isn't correlated to galaxy size through the reduction of RP requirements then I seriously doubt the smaller galaxy-type players will find this of interest.

My goal in this series of tests was to sufficiently slow down tech advancement in order to accomplish two things:

- make each and every tech advance a major milestone, a Big Deal(TM)

- provid for successive bouts of period warfare

The first point is rather obvious. In the unmodified game the techs fly by so fast it's like watching one of the newer commercials during your favorite television show - y'know, the ones where images successively flash by so fast that anyone over the age of 12 is in serious danger of having a seizure. You have to be a crack addict or a teenage boy to keep up with the pace of the game, or to even want to keep up with the pace of the game.

In any event, I wanted to dramatically slow tech advancement to the level where every single tech counts.

The second point may not be so obvious, but it's lack in the unmodified game is. Essentially, because of the hypersonic speed of tech your ships are essentially obsolete by the time they roll of the assembly line, certainly so after they crawl through the star lanes to the front. The result is that you're constantly building new ships, constantly striving for the Next Best Thing. I'm sure the kiddies find this flash-flash-flash rush-rush-rush sort of gaming right up their alley, but it ain't my style.

A 'period' game is one where a certain set of techs rule the battlefield for some length of time. A 'successive period' game is the same thing, only one 'period' follows another as the tech level advances. As I said, in the original game there is no period warfare because the tech advances so fast that something else better comes along by the time your current ships hit the front. I wanted to change this so that each set of techs remains 'queen of the battlefield' for some decent length of time, before being replaced by another set of techs.

Example: you start the game with lasers and nukes. Lasers and nukes should remain the primary weapons of battle for x number of turns before, say, the hard beam or quantum beam comes along to displace them. You should be able to field entire fleets of laser/nuke warships, fight with them, win with them or even die with them before a new set of techs results in a new kind of warship. *That* is period warfare.

To achieve these goals the only thing I modified was the constant value of tech advancement in TechTables.txt. I didn't touch the exponential value because doing so can easily lead to tech slowing down so much in the mid-game or end-game that you can't reach a new level in any reasonable amount of time (just as you might expect from an exponential modifier). Modifying the constant gives you a straight, across-the-board increase in the number of RPs it takes to reach a new tech level. E.g., if you modify the original 80-something number to 160, it takes twice as many RPs to get the next level.

I tried a number of games with the constant ranging from 400 to 1000. This is anywhere from 5 times to 12.5 times the original value, so tech is slowed down by this amount. For example, if you set the constant to 1000 and you were getting techs every five turns in the unmodified game, you'll now get them every 62.5 turns. It's actually less than this, because your expansion, and thus your investment in research, isn't slowed by a corresponding amount.

In any event, anything less than a value of 1000 still resulted in a lack of period warfare and tech overload on planet-building, with the AI frantically attaching buildings to DEAs in a never-ending construction frenzy because it simply couldn't keep up with tech advances. At a value of 1000 I hit tech level 25 before turn 400 - still too fast, still too many generations of ships mixing about.

After this I set the constant to 2000 and got a fairly decent game that lasted about 735 turns, where my highest tech was level 28. This game I liked quite a bit; with some of the other changes in the AI files there was a large amount of period warfare, often involving massive armadas blasting each other to smithereens because most fleets didn't have strongly superior weaponry. The AI managed to keep pace with me in the tech department, and several of the races were more advanced than I was, but only by one or two levels (three at most).

Even so it was still a wee bit too fast so I quit out of that test and tried another with the value set to 4000. Damn, now *that* was a period game; I was still sporting laser/nuke ships after turn 200. A little too slow, but here in this game I discovered an entirely new and rather exciting development: because the economic techs were few and far between, empire overexpansion became a very real, and very serious problem. I couldn't simply wait to zip up the tech tree to install new food or mineral-producing buildings, because 'zipping', in this case, meant waiting a couple hundred turns. By that time everyone would be dead or in revolt. For the first time playing this game I actually had to do something of a balancing act when it came to food and mineral production, and industry capacity. I actually had to *think* about the economic aspects of the game, something that just wasn't at all necessary before. By turn 650 or so I hit tech level 18 in most everything, and there I quit out for the next test.

Given the results above I set the magic number to 3000, and got what I think is the perfect game, one that requires some real thought not just in 'what Big New Shiny Thing am I sending to the front this turn' department. I had a tech of around 18 by turn 700 or so (expansion affects altering numbers here). All of the AI players who weren't eliminated at this point were either toe-to-toe with me or actually more advanced. In this game:

- lots of period warfare, and every tech counts - alot. Every tech is crucial.

- spying is worth far more than it is previously. So much so I adjusted the prices for buying spies.

- because unrest reduction is more difficult to accomplish, social spies can be incredibly damaging, especially in the early game.

- balancing the economy requires thought, especially if you colonize worlds that aren't green, which I often do since it seems like all the best mineral worlds are Red 1/2.

- magnate empires are both a boon and a curse. A boon because they effectively turn inhospitable worlds into hospitable ones, and a curse because their 'spontaneous' colonization efforts can quickly destabilize your economy. I got the Darloks in this game after kicking some Silicoid ass, and they went hog-wild and colonized everything in sight. I could almost hear my economy groaning from the lack of resources needed to support these new worlds during their growth phase.

- I never had a tech advantage over a major empire, and thus couldn't build vastly superior war fleets to take out the AI. With modifications to other files based on some of the discussions that've taken place on these boards, fights were usually between incredibly large groups of mostly evenly-matched ships. Lots of death, destruction, and frantic 'oh ****' building to replace the fleet after it once again pyrrhically defended the empire from another AI attack.

- with the lack of early game mobs the AI can and will assault worlds with ground troops. It seems to follow a pattern of 'invade - destroy enemy fleet - disband transports' followed by 'invade now defenseless system - land troops'. In other words, when it won the space battle it would follow up with a second fleet, complete with transports, and if it got to the system before my replacement fleet did it would conduct an invasion.

Just for some clarification: I can practically hear the incredulous gasps over games lasting 600 and 700 turns just to get to tech 18 or 20, with perhaps 20% of the galaxy conquered. One might wonder just how bloody long it takes to play a game like this. The answer is: not very long at all.

Why? Because tech is slow and new goodies come sparsely, there really isn't that much to do on most turns. If you're in the middle of a war and the best engine you can field is nuclear, it's going to take a good 20 or 30 turns for your brand new fleet to make it to the front, not to mention the time it takes to build it since you don't have any industry improvements, or very few. There are many turns in which you just take a gander at the sitrep, briefly glance at the galactic map to see if you're missing an invading armada, and then click on the 'Turn' button.

And I should note: I do not, ever, use the planetary AI. Most people seem satisfied with it - I am not. I find the planetary AI to be brainless most of the time when choosing for the military queue, and semi-brainless when building DEA's (does good for the world, lousy for the empire at large). When I colonize a new world I set up all the DEA's immediately and let the AI build 'em in whatever order it chooses, and then stack the same six improvements in the military queue - missile/beam/fighter, followed by three OWPs (orbital weapons platforms - frigate-sized satellites that any world can build, and are sufficient to lower unrest from piracy to 0). So for me colonizing is a breeze so long as I pay attention to what my empire needs; I only need to do extra work on the shipyard planets, and this is almost entirely through sitrep messages anyway.

So playing a game of 700 turns, even with all the AI turned off that I can turn off didn't take nearly as long as it sounded (less than a minute per turn). It took me much longer to process turns in the unmodified game since there was so much to do precisely because tech advancement was unbelievably fast.

In any event, I haven't seen a discussion where anyone else set the tech value to such high levels, so I thought to report the results here, and to emphasize that games this long don't correpond to equally long real-world playing times. If anyone else has messed about on the high end of things I'd surely like to hear about their experiences.

Max

---------------------------------

I found 3000 to be a little high for me though...
I settled on 2500. Almost the same but not quite. It's slow enough to allow you to earn what's given to you, but fast enough where I didn't lose interest. You could have written this in 12 hrs and it would have been old news. Dang it that smarts

--------------------------

Technology Modifying:

The speed of tech advances is determined by the file, TechTables.txt.

The part to adjust is Row I, lines 32-37. Raising those numbers will slow down research. I recommend you not exceed 1.35 for Economics, Biology & Social, and do not exceed 1.4 for Mathematics, Energy and Physics, until you have play-tested it with those settings.

and

Bhruic - Über Modder - Reg: Dec 2002 
There are two different numbers that you can modify (both are in the "TechFields" table).

The first is "Research_Cost_Exponent_Base". This number is the amount of RPs that you have to put in at level 1 to get to the next tech level. Obviously, the higher the number, the slower your tech research will be.

The second number is "Research_Cost_Multiplier". This number acts on the first number to determine how many RPs are needed for subsequent research levels. I won't go into the formula, I'll just explain how it works. Basically, modifying this number alone will have very little effect on the speed of early tech, but a large impact on the speed of late tech. The previous number is somewhat the reverse, although its effect at higher levels remains.

So, if you want to slow down your early tech speed, increase the first number. If you want to keep early tech fast, but slow down later tech, then increase the second (keep your increases very small, the second number is exponential, meaning that small increases have large effects). If you want to do both, increase both numbers.



"I could have conquered Europe, all of it, but I had women in my life." - King Henry II of England
I may be drunk, Miss, but in the morning I will be sober and you will still be ugly. - Winston Churchill
Wine is sure proof that God loves us and wants us to be happy. - Benjamin Franklin

mikeck

Whenever I see "Let's play" videos on Moo3, there are always a dozen comments about how this game sucks. Bugs at release aside, what is the problem? Seems very deep and complex to me.
"A government large enough to give you everything you want is strong enough to take everything you have."--Thomas Jefferson

Jarhead0331

The problem is it is not MOO or MOO2. This was a disappointment to those who were waiting for an update of the same game.  It was also bugged on release, so nobody gave it the chance it deserved.
Grogheads Uber Alles
Semper Grog
"No beast is more alpha than JH." Gusington, 10/23/18


republic

I guess I need to give Moo3 another try.