GrogHeads Forum

Digital Gaming => Computer Gaming => Topic started by: solops on July 07, 2013, 01:46:57 PM

Title: MOO3 Information
Post by: solops on July 07, 2013, 01:46:57 PM
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.

Title: TASK FORCE SIZE RULES
Post by: solops on July 07, 2013, 01:48:45 PM
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]
Title: Re: MOO3 Information
Post by: Kushan on July 07, 2013, 01:49:07 PM
Thanks for sharing solops. As someone who is just starting to get into the game I can use all the help I can get.
Title: SPACE COMBAT - Part 1
Post by: solops on July 07, 2013, 02:01:28 PM
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]
Title: SPACE COMBAT - Part 2
Post by: solops on July 07, 2013, 02:02:07 PM
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.
Title: SPACE COMBAT - Part 3
Post by: solops on July 07, 2013, 02:03:03 PM
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
-----------     -----   -----   -------- -------- -------- ---


Title: SPACE COMBAT - Part 4
Post by: solops on July 07, 2013, 02:03:48 PM
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>
Title: AI MODDING
Post by: solops on July 07, 2013, 02:16:52 PM
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.

Title: AI MODDING - Part 2
Post by: solops on July 07, 2013, 02:17:40 PM
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. "
Title: AI MODDING - Part 3
Post by: solops on July 07, 2013, 02:19:29 PM
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
Title: Re: MOO3 Information
Post by: solops on July 07, 2013, 02:21:53 PM
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.
Title: Tech Slowdown
Post by: solops on July 07, 2013, 02:27:04 PM
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.



Title: Re: MOO3 Information
Post by: mikeck on July 07, 2013, 03:37:19 PM
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.
Title: Re: MOO3 Information
Post by: Jarhead0331 on July 07, 2013, 04:45:56 PM
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.
Title: Re: MOO3 Information
Post by: republic on July 07, 2013, 04:57:02 PM
I guess I need to give Moo3 another try.
Title: Re: MOO3 Information
Post by: Darkspire on July 07, 2013, 04:59:43 PM
Quote from: Jarhead0331 on July 07, 2013, 04:45:56 PM
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.

You forgot to mention the mountain you had to climb to learn it, I loved MOO2 and still have it installed, even with the bad vibes doing the rounds on M003 I gave it a fair chance but it was so awkward to learn, I did enjoy it though to an extent, and that was before all the mods were released to improve it.
One thing I would ask is has anyone got the Chocolate mod? I think someone else mentioned it and I had a look and can find Strawberry and Vanilla, If I can find Chocolate and find a recommended mod list that interests me I will dig the CD out.

Darkspire
Title: Re: MOO3 Information
Post by: Huw the Poo on July 07, 2013, 05:06:00 PM
Quote from: Darkspire on July 07, 2013, 04:59:43 PM
One thing I would ask is has anyone got the Chocolate mod?

Here! (http://www.mediafire.com/?bab6i5ezwj6u1)
Title: Unrest Notes
Post by: solops on July 07, 2013, 05:09:28 PM
Thanks, Poo.
This might be of interest - solops

Unrest Management 101 v1.01    
________________________________________
This a basic guide to explain how to deal with unrest, and all the various problems that come with it.

I'm aiming at giving new players a fighting chance at dealing with civil disorder in their growing stellar empires.

First point, Unrest is a property of a population that describes how unhappy they are, a high unrest will cause a planet to go into a higher Unrest State.
Unrest State refers to how unhappy they are acting.

Unrest State has 5 lvl's

Content (Good)
Unrest 1 ( irritating, 25% production penalty, but not serious YET)
Unrest 2 (Serious now - effecting production 50% production penalty)
Unrest 3 (You'll be getting the "close to revolt" SITREP Message 75% production penalty)
Revolt (Woo-Hoo lets all loot and pillage! production? what production?)

Revolts result in poor production and civilians destroying buildings - this is a Bad Thing and can lead to actually losing colonies.


Therefore, step one . . .

Assess the Problem . . . ("What the hell is going on?")

Normally you discovery you have unrest problems from the sitrep - in which case you can hit the link to go straight to the colony in question.

Another option is to use the Planets Screen. Tick the Unrest check box And sort the list by Unrest. Then start at the top and work your way down.

Ok, so your people are unhappy on this planet, first thing to check is what unrest state your planet is in, this can be found on the Planet Screen(planet screen, not planets screen).

In the top right hand corner of the planet screen is a summery of your colonies industry, directly underneath it the 'Unrest State:' is desplayed, this gives you an indication how serious the unrest is.


OK, we know how unhappy they are acting, the next question is . . . why?

Now open the Demographic Info Tab located at the bottom of the screen, just right of center.

Now select the Unrest Tab, (Hiding behind the Population Changes Tab at the bottom). This Tab tells you 2 things;
How much unrest you are dealing with e.g. 287.4 unrest over 6 regions.
Unrest Factors: e.g. High Taxes, Pirates, Leader Effect, Starvation

Importent to note not all factors show here - oppressometer and unrest from FLUs are among the 'invisible' unrest factors.

So, now we know why they are unhappy, what can you do about it?

Step 2

Take Action(What the hell am I going to do about it?)

My first step is to place troops on the planet.

Troops do not effect unrest on the planet

They effect unrest state

To do this, close the Demographic Info and open the Military Info Tab, on the bottom right hand side of this Tab is the Go To Ground Force Creation. Press the button and create some units - the number of units on the ground appears t be the only factor here. This is one case were Infantry seems to work just as well as battleoids - so building a few Infantryx10s occasionally may be a good idea.

Fleets in orbit also seem to effect this, i'm guessing it is hull size again as it is for piracy which makes the difference.

*** If anyone actually knows how this aspect works, could you let me know by posting? I'll update accordingly. ***

Having done that, we have now given the population a good reason to consider settling down.

FYI: Having unrest on the planets will drive up their Unrest State - removing the source of unrest will not automatically lower your Unrest State - Once you make someone angry they tend to stay angry.

By placing troops you have now placed a factor driving the Unrest State down. Even if the troops don't immeadiatly stop the revolt, they will at least reduce the damage done to your colony while in a state of revolt (you lose less buildings).

Ok, we've done about all we can here - i do not advocate manually placing DEA's - the viceroy is already on it and does a better job of it anyway.

Step 3

Minimise Unrest Factors(Well, get that the hell out of here)

There are several common factors I will cover here, and how to deal with them.

High Taxes:
Much thanks to all who've done research on this (DavidByron especially)

Your total tax is the sum of planet tax(seen in the planet screen) which pays money directly to the planet.
System tax(seen in the finance screen under Budgets Tab, Taxes heading) which is payed to the planet holding the system seat of government(and is not displayed in any report any where . . .).
Empire Tax (seen in the finance screen under Budgets Tab, Taxes heading) which is payed directly to the empirial treasury.

Each Government type has a tax tolerance ~ normally 35% total tax - Planet + System + Empire. Unrest penelties appear to be very heavy at high tax rates - and unrest reduction is huge for low tax rates.

So - to reduce unrest due to tax i would reccomend turning down the plantary tax(For unrest showing the High Tax factor, but effecting only a few systems) The viceroy will raise it again later.

I will add more detail here at a later date.


Oppressometer:
Causes global empire wide unrest - but makes it harder for enemy spies. Turning it down can be good for an Empire wide reduction in unrest in a hurry - but I wouldn't reccomend leaving it to low.

Forced Labour Units (FLUs):
FLUs are a family of viral infections . . .
Or in this case FLUs increase production of certain DEAs at the cost of unrest.

Your current FLU policy is found in the Empire Screen, FLU tab - you have a allowed/disallowed toggle and a slider - higher the sldier does, the more production you get from your FLUs, but the shorter their lives are and the more unrest you create.

For empire wide unrest problems i would reccomend turning forced labour off for at least 1 turn(this will free all current FLUs) and turn it back on next turn if you want to build them up again.

Leader Effect:
Fire the Leader, or do more to keep you population happy to make up for it.

Pirates:
Arrg!

Big common cause of frustration here . . .

To explain, each region on your planet attracts pirates - and if there is no fleet to stop them, they will prey on your new colony without mercy.

Ships will defend the same number of regions as thier hull size - a lancer will stop pirates in 1 region, a frigate will stop piracy in 4. If you have a Sytem Ship design availible the viceroy will produce them until piracy ceases all by himself. for a new colony this can take a while though.

You could try to force the planet to produce enough system ships to end piracy, i don't do it that way my self though.

Where possible i try to use my starship fleet to guard the system in the early stages until the local fleet is big enough to take care of itself, this has the advantage of defending the system from external threats as well - namely a blockade by one of your neighbors recon detachments . . .

Once the local defence fleet is up and running piracy will stop being an issue.


Ok, so now you've reduced the unrest factors as much as you can, and they're still revolting (or rebelling - we already knew they are revolting). . .


Managing Unrest (What the Hell do u mean, "put up with it"?)

There are several things you can do to reduce unrest at an Imperial level, you could lower the tax rate, but it's not recommended, lower the oppressometer (and get spies up to your eye balls) if your oppressometer is set over your governments reccomended range you will have revolts in no time, so be aware of where it is set if you decide to change government types.

The best way to manage unrest however is through the Finance Screen (F3). Open the Finance screen and select the ledger tab.

The left hand side of the screen has 4 Sliders, these are:

Additional Research Spending Money placed here will go to research.

Military Budget This money goes to items being built in the military build queue accessed through the Economics Tab on the Planet Screen

Unrest Money placed her goes to reducing Unrest . . .

Grants to Planets This money is divided into up to 10 grants which are then given to the 10 planets in most need, according to the AI.

If you are having significant unrest problems, empire wide this is one of your most powerful tools. The unrest slider has 3 arrows- red (revolt) yellow (unrest) and green (content) To guide how much money you need to spend to bring the empire to that state of unrest. I typically put at least 10%(each division in the sliders represents 10% of you availible funds) above the green arrow - helps to stop unrest sneaking up on you.

If your problem is piracy, place some money into Military spending as well to help speed up your police fleet production. And colony ships for that matter.

If you are having trouble with unrest in young colonies you will also want money in Grants to Planets, to speed the development of your smallest colonies.

I try to leave about 20% of my availible funds unallocated, to allow me to build a surplus for emergancies.

If you are having an empire wide revolt however, you need to get as much as possible done to reduce unrest NOW - in this case put all your funding into the unrest slider - revolts cripple your production and destroy buildings that you have already payed for. Basically in this situation your cheapest option is to spend everything on lowering unrest immeadiatly.


The final aspect of unrest management is to have an unrest DEV plan, these are found in the Empire Screen (F4), Development Plans Tab. My unrest plans normally look like,

Planet Classification - Prmary - Secondary - Tertiary

Unrest- Military - Military - Infrastructure
Unrest - Rec - Rec - Infrastructure

Both Planetary Defence and Morale scripts will build DEAs - but will not build improvements, this is a Bad Thing - so do not use these scripts for unrest managment.

I will note that more than morale effecting DEA on a planet appears to reduce the effect of other DEAs of the same type - so in this case quality is better than quantity - and a rec and a military DEA may indeed be better than 2 military, for instance.

This tends to get the viceroy building the right DEAs (dempending of my current government choice) for the best unrest reduction.

The VR will only adjust its tax so much to counter unrest, so if unrest problems really get nasty it wont help anymore, but loyalty picks only help a little too. As for opresso metre; this affects the HFoG rise, so playing max opressometer all the time will cause quite some unrest (which VR adjust with tax and extra DEAs, both of which are a waste), but above all will cause the HFoG to rise ridiculously.

Also, i think the security provided by the opressometer is in some exponantial/logarithmic in comparison the the "prefferred" opressometre range. So i think the opressometre 10 for a constitutional monarchy is lower then the opressometer on 10 for a unity government. But i don't have any data on this, so don't just take my word for it 

But in any case i think the opressometer on 10 is a waste, since the little damage that spies do is nothing compared to all drawbacks of high opressometer.

Unrest can also be caused by over-crowding, and is inherent on just-conquered worlds. If you just conquered the world, leave your troops on the planet, and see if it goes down in a few turns.

If the planet is over-crowded, your people will probably try to move away soon on their own. If they don't, give them a little help, colonize some new worlds, and set "migration" to your less-populated, lower-unrest worlds. This will encourage people to move out of your crowded colonies and into your less-crowded colonies.

Finally, if piracy isn't listed as a cause, building more ships will probably just cost your production and upkeep. On the other hand, lower taxation by a point or two on the planetary level will reduce local unrest. (High tax is sighted when its extreme, but any tax causes a small amount of unrest).

If none of this is working, and the problem exists on several planets, try dropping the oppressometer by a point of two, then cover the difference with defensive spies.

Finally, if all else fails, increase the unrest spending slider on the finance screen. This is my least favorite thing to do, because it takes away money that, IMHO could be put to better use speeding up military production or research.
Title: Bhruic's Work - 1
Post by: solops on July 07, 2013, 05:20:51 PM
Here is the detailed info on Bhruic's patches from his website, which is currently down. I think it is important to get this posted somewhere in case it never gets back up. Bhruic's work is absolutely vital to good MOO3.
--------------
THE "PATCHER" PROGRAM
The Patcher program is designed to scan the individual '.patch' files, and present them in a readable format. Each patch file can then be applied to the executable. Once applied, a patch takes effect immediately (unless it requires an additional spreadsheet modification).
Note: The Patcher, by itself, does nothing. It merely implements patches. Each patch needs to be downloaded before the Patcher can install it.

1) This is the main patch window. It lists the type of patch (either a Fix or a Mod), the version number of the patch, the name of the patch, a short description of the patch, whether the patch requires the dll to be present, the current status (whether the patch is installed, not installed, or if there is some discrepancy with the patch), and finally when the patch was last installed.
2) This is the main window for the dll. It lists the current dll version, the name of the dll, how many patches the dll supports, whether the code for the dll is installed, and what date and time the dll was last compiled at. Note: If the dll code is listed as "Uninstalled", no patch file the requires the dll (see the dll column from (1)) will install. If you remove dll support, make sure to remove any patches that require the dll.
3) This points to the executable that is currently being patched. By default, it uses the normal executable, Moo3.exe. However, if you want to keep that version 'clean', you can point the patcher at a copy of Moo3.exe and it will use that executable instead.
4) This window will display a longer description of the currently selected patch. In general, the documentation on this web page is superior to the description shown here, but if you are patching and unable to consult these pages, this window will provide you with enough info to proceed.
5) This button will either patch (if the patch is not installed), or unpatch (if the patch is installed) the currently selected patch. The text of the button will inform you of which behaviour it will perform.
6) This button is identical to (5), except that it installs the dll code, not a patch. As the warning from (2) states, make sure that this is installed before trying to install dll patches.
7) This button will allow you to browse for a different Moo3 executable, as described in (3).

MOO3 DLL
The dll file is a requirement for some of the patches. It contains extra code that could not fit within the main executable.
The dll file (Moo3DLL.dll) needs to go into your main MoO3 directory to function properly. By default, that directory is:
C:\Program Files\Infogrames Interactive\Master of Orion 3\

If you are unable to find that directory, the game may have been installed somewhere else. Use the Windows 'Search' function and look for 'Moo3.exe'.
Often, a great deal of confusion arises over which dll version to use. This is because as new patches are released, the code for them is added to the dll. Also, patches may be updated, which require changes to the code in the dll. The best rule of thumb is to always use the most recent dll file. If, for any reason a patch doesn't function properly with the latest dll, check to see if there is a newer patch.

FIXES
Fixes are designed to correct game bugs that exist in the default v1.25 MoO3 executable. To qualify as a 'fix', a patch must change the behavior of a game function back to the way it was designed to work (or as close as can be approximated).

Diplomacy - The diplomacy fix is a simple one. When designing the game, the programmers called the diplomacy spreadsheet 'Statements.txt'. However, the final version of the game ended up using a spreadsheet called 'Diplo.txt'. Unfortunately, the programmers didn't update the MoO3 executable to use that name. This patch corrects that oversight by changing the name in the executable.

Finance Wraparound - The way a number is represented on a computer is based on the number of 'bits' that it uses. The formula is a simple one, 2^x. That is, two to the power of x, where x is the number of bits. So a single bit can represent 2^1, or 2 numbers (those numbers being 0 and 1). With 8 bits, you can represent 2^8 numbers, or 256. With 16 bits, you can represent 2^16 numbers, or 65,536. And finally with 32 bits, you can represent 2^32 numbers, or 4,294,967,296 numbers. Those numbers can be divided up in one of two ways. They can be numbers from 0...4,294,967,295, or -2,147,483,648...2,147,483,647. Note, the amount of numbers is the same in both cases, but one allows negatives, and the other doesn't.
Now what happens if you are using the latter example (the one with negatives), and the number you are trying to represent is larger than 2,147,483,647? The best way to explain it is with some number translations. Computers don't use base10, or decimal, the number system that most people use. Instead, they use base16, or hexadecimal. So the number 2,147,483,647 looks like 7FFFFFFF. The number -2,147,483,648 looks like 80000000. I'm sure you can see where this is going. If you take 2,147,483,647 and add 1 to it, you'd get 80000000 as far as the computer is concerned. But it considers that number to be -2,147,483,648. So you've gone from having a really large positive number to a really large negative number.
That, in a nutshell, is what happens with the financial wraparound bug (which, obviously, is a 32 bit number). The money in your treasury goes over the 2,147,483,647 limit, and so becomes negative, causing your empire to go into bankruptcy.
What the patch does, is check to see if you've gone over that limit. If you have, it changes your account back to 2,147,483,647, so that you still have a positive balance. This means that you are losing some of your income, but you won't go bankrupt, which is preferable.

Ground Combat - In the RaceModifiers.txt spreadsheet, each playable race starts off with a GndCombt value of 3. The value is designed to be modified by the three ground combat race picks (Accuracy, Reflexes, and Toughness). The final value will then be a number from 0-9. That number is then checked against the RaceTrait table of the GroundCombat.txt spreadsheet to determine the bonuses in combat.
Unfortunately, the base game doesn't work properly. The race picks, instead of modifying the GndCombt value, do nothing. This patch adjusts the game so that the race picks work like they were intended to.

Sitrep - The sitrep that gets displayed at the beginning of each turn includes links that take you to the appropriate screen, depending on what the sitrep is referring to. For example, a sitrep report about a revolt taking place will link to the planet in question.
Unfortunately, a bug exists where clicking on a sitrep to a ground combat link will not function properly. It will either crash the game completely, or take one to a blank screen. There is no way to return to the game from that blank screen, requiring one to reload the game to continue.
This patch fixes the link for a ground combat sitrep so that it takes one to the proper planet. There is, however, another facet to the bug - ground combat sitreps are not stored in the savegame. That bug is not fixed by this patch (that bug has been deemed to be minor enough to not require fixing).

Stuck Tech - The label of 'Stuck Tech' is really a misnomer. The tech isn't actually stuck, it is simply being researched very, very slowly. The practical effect is the same, however, as the technology is unlikely to finish researching within the span of a normal game.
The problem only occurs when the amount of RPs needed to research a technology gets sufficiently high. An error in the mathematical calculations causes the game to set the research rate of the technology to a much lower value than it should be. This patch fixes the mathematical calculation, which eliminates the problem.

Turns Remaining - Once a particular technology level is researched for the various schools, all of the projects at that level start being researched (unless they have a secondary school requirement). For example, when you hit tech level (TL) 10 in Mathematics, any level 10 Mathematics technology will begin research. In the technology screen, there is a list of techs currently being researched. Included is a report of how many turns it will take for that tech to finish researching ('Turns Remaining').
Unfortunately, that number actually has nothing to do with how many turns it will take to research the tech. This patch fixes the system so that it displays the actual turns remaining. Note that if an overrun occurs it may change the amount of time to research a technology.

TFdisplay - Many players are not aware that when creating a new TF, it should be immediately be available for orders. Unfortunately, a bug causes it to not be displayed properly. A common work-around was to hit the 'B' key twice, which would cause the TF to be displayed.
Once this patch is installed, TFs will be displayed immediately, removing the need for that clumsy work-around.

Transport Disband - Perhaps the most serious bug in v1.25 of Master of Orion 3 is the fact that AI Transport TFs automatically disband the turn after they are created. This makes it impossible for the AI to invade any world unless it can reach that world within one turn. Obviously, that isn't the case most of the time. So the AI rarely has a chance to invade worlds, which is arguably the most effective way of expanding.
This patch corrects that problem.

Visibility - It is most likely no surprise to anyone who has engaged in numerous fleet combats that the visibility system doesn't work properly. The visibility patch does a number of things to try and fix this.

First, there was a bug where the first Tag_Values tag would get ignored in combat (the UniSpace and SystCost tags do not count towards the 'first tag ignored' rule). So, using ECM I as an example, it has the tags 'SystCost = 30, UniSpace = 15, DefTgtRg *= 1.12'. The first two are UniSpace and SystCost, so those are dropped. As far as the game is concerned, it only has one tag, 'DefTgtRg *= 1.12'. However, as was stated at the beginning of this paragraph, because of the bug, the first tag value is ignored. That means that ECM I does absolutely nothing in combat. In fact, none of the Sensor/ECM/ECCM/Cloak ship items do anything in combat.

Second, because of the way the formula for ship detection works, DefTgtRg (that is, decreasing he chance of being spotted by the enemy TF) was limited so that it could never provide more than a 1.33 benefit. In other words, if you used, say, ECM V, it should provide you with 'DefTgtRg *= 2.2'. However, the formula would reduce that to a benefit of only 1.33, or the equivalent of ECM III.

Third, the system was set up so that OffTgtRg and DefTgtRg had multiple functions. The TgtRg part of each of them stands for 'target range'. But not only did they affect targetting range, they also affected spotting range. Originally, there was another variable called SptRg (with OffSptRg and DefSptRg). Instead of keeping the two concepts separate, they were both merged into TgtRg. This made it difficult to design a system that worked for spotting, but didn't become overpowered for targetting (or vice versa).

Finally, there was the problem with OffTgtRg. In the previous paragraph it was stated that TgtRg affected targetting range. That isn't precisely true. While DefTgtRg functioned correctly, OffTgtRg did not, leading to severe problems with targetting.
The solution to all of these problems was multifacetted. TgtRg and SptRg were separated again. This means there are now four values to use instead of two:

OffTgtRg - Increases chance to hit.
DefTgtRg - Decreases chance of getting hit.
OffSptRg - Increases chance of spotting enemy TFs.
DefSptRg - Decreases chance of your TF being spotted.

There are two things to keep in mind about these tag values. For spotting range, the best value from the offensive (or the TF trying to spot) TF is compared against the worst value from the defensive (or the TF being spotted) TF. This means that only one ship needs to have a good OffSptRg (unless that one ship gets destroyed), but all ships need to have a good DefSptRg for cloaking to function properly.

Second, for targetting range, unlike spotting range, it works on a per ship basis, not a per TF basis (that is, the individual ship firing has its tag value used, as does the individual ship getting fired at). Targetting range also only affects beam weapons (this is unproven, but demonstrably likely), ships that aren't likely to engage in beam combat don't need offensive targetting, although they would still benefit from defensive targetting (as it will affect fighters and missiles that target your ship).

OffTgtRg was fixed so that it worked properly alongside DefTgtRg. The problem with ignoring the first tag value was also fixed. For this to have a proper effect on games, however, it is necessary that changes to TechTables.txt be done. Some modders have made the changes for you, however, if they have not, then you should use the TechTables.txt that is included with this patch (or, if comfortable modding, you can replace the required lines yourself).
Title: Bhruic's Work - 2
Post by: solops on July 07, 2013, 05:25:56 PM
MODIFICATIONS
Each modification to the MoO3 executable comes in a '.patch' file. These files are read by the Patcher program to determine their function. They include instructions on how to apply the patch, as well as how to revert back to the original code.

Because the patches are designed to work with the Patcher, it is necessary for them to be located in the same directory as the Patcher itself. The recommended location is in a subdirectory off your main MoO3 directory. So, assuming you used the default MoO3 directory to install, it would be:
C:\Program Files\Infogrames Interactive\Master of Orion 3\Patcher\

Allied Victory - A common complaint about vanilla MoO3 was that having to completely conquer the galaxy to win the game wasn't much fun. To remedy this problem, the Allied Victory patch was created.
Functionally speaking, the concept is quite simple. Any player that is allied with every other remaining empire in the game will be declared the winner (where 'allied' refers to either a 'Defensive Alliance' or a 'Full Alliance'). This condition is checked whenever a senate vote occurs, or a player is eliminated from the game. This means that merely having the alliance isn't sufficient, it has to last until one of those checks occurs.

Keep in mind that any empire may win this way, so it is vital that you keep an eye on which empires are allied with which other empires.
Allstars - This patch prevents the addition of Blackholes and Neutron Stars to the game during galaxy creation. Without either being available, all stars added to the game will be usable (although not guarunteed to contain planets).

Autobuild - The AutoBuild patch is the most complex patch that has been made. As the name implies, it completely replaces the in-game code that is used to design a ship by either the AI, or when the player selects the 'Auto-Build' button.
With just the patch installed, the ships built will be only marginally better than the defaults. However, the real advantage of the Autobuild patch comes from the Autobuild.txt spreadsheet. This spreadsheet (unlike the default MoO3 spreadsheets) needs to go in your main MoO3 directory, the same place that the Moo3dll.dll file is located.

If you have no interest in designing the autobuilt ships yourself, then you need read no further. All of the information past this point describes how the Autobuild.txt file is created.

The file itself is split up into three different sections. The first section, called the 'Alias' section, allows you to define rules to choose ship components. Each table deals with a different component type, of which there are a total of 8. Most of the tables have 3 columns. The first column is the 'Alias' column. The text you choose for the alias will be used later in the ship design section to identify which component, and which formula you wish to use. Each alias must be unique. The second column assigns the sign for the formula that you will use. And the third column contains the formula itself.
The formula is used to rank each component. For example, if you chose a formula of 'UniSpace * SystCost', then the UniSpace and SystCost values of each component would be checked. How it is checked is where the 'Sign' value comes in. The sign can either be > or <, that is, greater than or less than. If it were >, or greater than for the formula 'UniSpace * SystCost', then the component with the largest UniSpace times SystCost would be selected. If it was <, or less than, then the smallest would be selected.

For some component types, there are modifier components that affect the base. For example, for ship weapons, there are ship weapon modifiers and weapon mounts, both of which can change the value(s) of the original weapon. The formula system takes every combination into consideration. For example, if you've researched the Laser, Autofire Laser, Continuous Laser, Standard Mount and Spinal Mount, the following combinations would be used:

Standard Laser
Standard Continuous Laser
Standard Autofire Laser
Standard Continuous Autofire Laser
Spinal Laser
Spinal Continuous Laser
Spinal Autofire Laser
Spinal Continuous Autofire Laser

If we used the earlier formula of 'UniSpace * SystCost', the value for each combination would be calculated, and the largest or smallest (depending on the sign) would then be chosen.

Previously I mentioned that most of the Alias tables were the same. Two of them are slightly different. The 'Missiles' table contains an extra column called 'Reloads'. As one might expect, this sets the number of missile reloads that weapon will have. The second table that is different is the ShipItem table. Unlike all the other tables, it doesn't have a 'Formula' column, it has a 'Tag' column. The 'Tag' column is used to determine which 'Tag_Values' tag will be looked at to select that item. For example, by default the ECCM looks for the 'OffTgtRg' tag. So every ShipItem (or ShpMItem) type that you have researched will be scanned for that tag. The 'Sign' column then determines whether you want the largest or smallest value for that tag.

The next section of the Autobuild.txt file is devoted to the ship designs themselves. There is a table for each type of ship (LR, SR, etc). Each ship is already assumed to have selected the hull size, hull type, and had all of the ShReqSys (Ship Required Systems) placed on board.
There are 4 columns for each ship design. The first is the 'Alias' column. This is where the aliases from the previous section are put to use. Using an alias here tells the Autobuild routine to look up the sign and formula for that particular component.
The next column is for 'Percentages'. This can have two different functions, depending on the type of component. Specifically, for ship engines, it tells the ship how fast it should go. The percentage is multiplied against the top speed of the engine, to determine what speed (and how much space) it should use. For every other type of component, the percentage is used to determine how much of the currently available space (or space remaining) should be used by that component. For every component where space is not a factor, the '-' tag should be used to denote that it is 'unused'.
The third and fourth columns are for 'Min' and 'Max' values respectively. The Min and Max values can be used instead of, or in conjuction with the percentages column. They are prioritized in this order:

Min
Percentage
Max

An example will help clarify how this functions. Let's assume we want to put a component on a ship that takes up 20 space, and we have a total of 30 remaining space on the ship. The Percentage is set to 50, Min is set to 1, and Max is set to 2. When it gets time to add the component to the ship, it looks at the percentage (50%) of remaining space, which is 15. Normally, because that is less than the 20 space the component takes up, it would not add the component to the ship. But the Min is set to 1, so despite the fact it takes up more than 50% of the space, the component will be added.
Now, let's consider another example. Same component, but now we have 200 space remaining. The Percentage, Min and Max values are all the same. This time, when it looks at the percentage of remaining space it can use, the value is 100 units. That means it could fit 5 of the component onboard the ship. However, it then looks at the Max value. Because the Max is set to 2, it will only put that many on the ship instead of 5.
The order that items are placed aboard the ship is very important. The order of:

Warp Drive
System Engine
Armour
Shields

should not be changed (unless you don't wish shields on the ship design). After those four items, the order is no longer important, although it may become so depending on how you wish your ships designed.
Note: The ship designs are identical regardless of which hull type (Starship, Systemship or Orbital) is being designed. However, the routine will recognize the hull type, and modify accordingly. Warp Drives will not be added to Systemships or Orbitals, for example, regardless of what the design says.
The final section of the Autobuild.txt file is deals with ship names. There are four tables in this section. The first table contains the strings that assign the name itself. Any plain text is used as is, any tag that starts with % is set based on the particular tag. The current tags are:

%t - Hull Type (StarShip/Systemship/Orbital)
%h - Hull Size
%m - Ship Mission (LR/SR/etc)
%s - Ship System Speed
%w - Ship Warp Speed
%n - Ship Design Number
%# - Turn Number

The second table contains the 'codes' for the hull types, the third table contains the 'codes' for the hull sizes, and the fourth table contains the 'codes' for the ship missions.
Some examples:

The ship we have designed is a Battlecruiser Starship. It's a SR ship, with a system speed of 2100, and a warp speed of 105. It was the 25th ship designed, and we created it on turn number 70.
%t%h-%m%# - StrBcr-SR70
%m %w - %t%h - SR 105 - StrBcr
Royal Ship %m:%n - Royal Ship SR:25

In each case, the 'Str', 'Bcr', and 'SR' values came from the other three tables in this section. By changing those, you can also affect how the name will turn out.

As you can see, you can adjust the names as much as you'd like. However, it's important to note that not only will your ships have these names - so will all the AI ships. You don't often see the AI ships, so it won't matter in most cases, but it's something to bear in mind.

Autoconquer  -  The AutoConquer patch is designed to assist the AI in the later game stages when it comes to taking new planets. Investigation has revealed that as the game progresses, the AI has a harder and harder time fielding Transports properly, resulting in excess planet bombardment, which is an inefficient advancement system. The player, on the other hand, doesn't suffer from that problem, giving them an expansion advantage.
The way the patch functions is by changing the Planet Destroyer weapon class to Planet Conqueror. In the default game, if any AI ship that takes part in combat has a Planet Destroyer weapon, then it will automatically get used, completely destroying the planet (by default, only the Stellar Converter has Planet Destroying capablities). Once the patch is installed, the same system will occur, except instead of destroying the planet, the aggressive empire will take it over completely intact. The planet suffers no damage whatsoever.
As mentioned previously, only the Stellar Converter is considered a Planet Destroying weapon by default - and as a level 50 (roughly) tech, it is rarely researched. For this patch to be effective, other weapons will need to be designated as Planet Destroying. The tag for this is PntDisWp=1. Note, for a weapon to be considered Planet Destroying, both the weapon itself and the weapon mount must contain the tag. By default, all Spinal Mounts and Heavy Weapon Mounts have the tag.

Note: Although the original purpose of this patch was to help the AI in the later stages of the game, some players have chose to use it to complete replace ground combat by giving all beam weapons the PntDisWp=1 tag. This works, and can lead to a completely different strategical game. However, it should be mentioned that the AI is unaware that it can conquer planets in this fashion, so it will not be playing in that fashion. This gives the player the advantage in the early game.

Also worth noting is the fact that the Sitrep does not currently report that the planet was conquered. Hopefully a future version will rectify this.

Colony Display - Once a colony ship is put into a TF and launched, you no longer have the option of checking what race is onboard. This can make it difficult to determine which planet the colony ship should travel to.
By applying this patch, you will be able to see the race onboard any of your colony ships.

Contact Propagation - The way Master of Orion 3 determines if you should have contact with another Empire is by checking if you are both in the Orion Senate, or if you have a colony within 2 systems of the other Empire. This can be restrictive, making it difficult for you to meet other Empires, or take advantage of some diplomatic options. For example, you may have a Full Alliance with another Empire, but if they haven't met your enemies, you have no way to ask them to join you in fighting them.
The purpose of this patch is to allow for such options to take place. It does this by creating the following contact criteria:

Intelligence Treaty - grants contact with all contacts of the other Empire
Full Alliance - grants contact with all allies and enemies of your ally
Defensive Alliance - grants contact with all enemies of your ally

Worth noting is that contact obviously is a two-way street. So if you have an alliance with an Empire, and they grant you contact with an enemy of theirs, the enemy also has contact with you. That may seem obvious, but the reverse case is equally true. If you are the enemy of an Empire, you will have contact with any allies that empire has.

Another example of where this patch creates diplomatic opportunities is with the Orion Senate. One thing that often happens is you are the only one to have met another Empire that you'd like to get into the Orion Senate. But because no one else has met them, no one will vote for them. Now, if you form a Full Alliance with them, all your allies will meet them. Or better still, if you form an Intelligence Treaty with them, all of the Orion Senate members will meet them. This can make it much easier to get your sponsorship motion seconded.

Damage Display - When damage is displayed in combat, it uses the 'farthest penetrated' system to determine what number and colour to use. The order of penetration is 'shields', 'armour', 'hull'. So, if damage was applied to the hull (the 'farthest' in the penetration scale), then the number displayed in combat would be the hull damage, in red. If no damage was done to the hull, then it would drop back to the armour. If armour damage was done, that amount would be displayed in yellow. If no damage was done to the hull or armour, then it would drop to the shields, and display the damage in blue. What this system doesn't do, however, is tell you how much damage was done to the previous layers. That is, if damage was done to the hull, then it won't display the damage done (if any) to the armour or shields. And if damage was done to the armour, it won't display the damage (if any) done to the shields.
What this patch does is cause all the damage to be displayed in combat. If damage was done to the hull, armour and shields, all three will be displayed. If damage was done to the hull and shields, but none to the armour, then those two will be displayed (note, the appropriate colours are still used to differentiate). This will allow you to determine how effective your weapons/shields/armour are, even if damage is applied to the hull.

Empire Limit - When you start a game of MoO3, you are allowed to select between 1-16 AI players. The game actually supports up to 32 players. For a normal game, that would include the player, as well as the New Orions. That leaves a possible 30 other empires in the game. It is also possible to play without any other AI empires, leaving just the player and the NO.
This patch changes the empire selection limit to a range of 0-30.

FighterInterceptor - The default Fighter AI causes it to ignore all other Fighters and Missiles unless they are the only forces remaining. This patch adjusts the targeting AI so that Missiles and Fighters will have the same target priority as all other enemy ships. The Fighter AI normally selects the closest enemy target to attack. Since Missiles and Fighter waves travel faster than most TFs, this patch permits Fighters to act in the role of Interceptors.
This patch only affects Fighters when under AI control. If the player issues orders to the Fighters (for example, by ordering a Carrier TF to attack a specific enemy, the Fighters will ignore all distractions enroute. If the player issues no orders to the Fighters, however, they will automatically launch in a defensive role if Missiles/Fighters are converging. Therefore, this patch can have a dramatic affect on the way combat takes place.
Title: Bhruic's Work - 3
Post by: solops on July 07, 2013, 05:27:45 PM
Fighter Speed - With this patch you can change the speed of Fighter swarms in combat. Their default speed is 10,000 (following the same scale as ship speed, which ranges from 1500-4200).
The speed can be changed in two separate ways - either modifying the set speed, or creating Fighter Engine technologies. Fighter technologies supercede the set speed, or to put it another way, if a race has researched any Fighter Engine technologies, then the set speed is no longer used.
A sample tech entry (with each line being a separate column entry):

Fighter Engine I
TAFtrE01
TBFtrE01
None
Ship, KEEPTHIS
FtrEng01
Achieve
Energ_00
TFEngine
None
MaxSpeed = 5000

The most important cell there is the "FtrEng01" entry in the Type_ID column. This is what the dll will search for to determine if you have researched the technology. You can have up to 10 Fighter Engines from "FtrEng01" to "FtrEng10". The other important cell is the last containing the MaxSpeed entry (in the Tag_Values column). This tag must be present for a speed to be obtained. Finally, keeping the tech as "Achieve" in the Application_Class column is necessary. It should not be be changed to any of the ship techs, because the game does not know how to handle it as such. All of the rest of the columns can be changed based on your preference.

The way the techs are handled when combat is launched is they are each scanned. The MaxSpeed value is compared, and the highest (that you researched) will be what is used. If, however, you have not researched any, or none exist, it will fall back to the set value.
Galaxy Configuration - This patch increases the number of Galaxy Configurations available from seven to whatever number you choose. There are a few caveats that go with this.

First, the number chosen is the number of entries that is displayed, even if that many configurations don't actually exist. For example, if you set it to display 8 entries, but you only have the default GalaxyConfigurations.txt spreadsheet (which contains 7 entries), an eighth option will show up in the dropbox. You will be allowed to select that entry, and start the game. However, the game will end up stuck at the Creating Galaxy stage. Therefore, it is important to make sure that the number you choose is the number of configurations you have available.

The text that is displayed in the dropbox is read from the wsStartUpScreens.txt file (which is contained in the wStrings.mob file). The text needs to follow the '\!NGSIZ' tag. Each text entry should follow the same format that already exists in the file.

Finally, the data for the galaxy configuration needs to go in the GalaxyConfigurations.txt spreadsheet, as mentioned above. A full description of how to modify that file is outside the scope of this discussion, but the file provides some basic details on what each column does. More important, however, are two columns, the 'Key' column, and the 'String_Tag' column. The value is each respective column must be unique. Furthermore, the value in the String_Tag column needs to be sequentially increasing. That means that if you start with NGDD01bA, the next tag must be NGDD01bB, and so on. Should you reach the end of the alphabet, it continues using the ascii table. Note, there are two tables in the file, one labeled GalaxyConfigurationTestKeys, and one labeled GalaxyConfigurations. The first table is unused, the second one is the one that needs to be modified to work.
Included with the release is a sample GalaxyConfigurations.txt, as well as a wsStarUptScreens.txt. This is a collection of galaxy configurations assembled by rhyssana, and originally distributed as 4 separate galaxy configuration files. The 4 files have been merged into a single collection (the sample), and are ready to be used. There are 28 galaxy configurations, so that number should be used with the patch (and that is the default).

Hull Speed - The Hull Speed patch allows one to adjust the overall speed of a ship based on the size of the hull. By editing the TechTables.txt spreadsheet, you can add a 'MaxSpeed *= X' tag to the 'Tag_Values' of ship hulls (where the X value is the multiplier you wish to use). The multiplier will then be applied to the overall speed of the ship.

This can be useful in one of two ways. First, you can make smaller ships very fast, allowing them to close quickly with the enemy and attack. Second, you can decrease the amount of space taken up by engines on smaller ships, but have them still able to travel as fast as larger ships. This lets the pack more weapons on board.

Missile Speed - With this patch you can change the speed of Missile launches in combat. Their default speed is 15,000 (following the same scale as ship speed, which ranges from 1500-4200).
The speed can be changed in two separate ways - either modifying the set speed, or creating Missile Engine technologies. Missile technologies supercede the set speed, or to put it another way, if a race has researched any Missile Engine technologies, then the set speed is no longer used.
A sample tech entry (with each line being a separate column entry):

Missile Engine I
TAMisE01
TBMisE01
None
Ship, KEEPTHIS
MisEng01
Achieve
Energ_00
TFEngine
None
MaxSpeed = 7500

The most important cell there is the "MisEng01" entry in the Type_ID column. This is what the dll will search for to determine if you have researched the technology. You can have up to 10 Missile Engines from "MisEng01" to "MisEng10". The other important cell is the last containing the MaxSpeed entry (in the Tag_Values column). This tag must be present for a speed to be obtained. Finally, keeping the tech as "Achieve" in the Application_Class column is necessary. It should not be be changed to any of the ship techs, because the game does not know how to handle it as such. All of the rest of the columns can be changed based on your preference.

The way the techs are handled when combat is launched is they are each scanned. The MaxSpeed value is compared, and the highest (that you researched) will be what is used. If, however, you have not researched any, or none exist, it will fall back to the set value.

One Turn Tech - Once you have researched a technology level (TL) for a school, all of the techs that are at that level will begin researching. Each of them will take a random amount of time to finish researching. This randomness is abstracted from the rest of the research system - that is, it doesn't matter how many or how few research points (RPs) you are generating, the tech will research in the same amount of turns regardless.
Because of the complete abstraction, there is little justification for having the random turn system in place. By applying this patch, the randomness is removed, and all techs will automatically finish researching in one turn (the turn after you've researched the appropriate TL).

Race Selection - The Race Selection patch has three different functional modes. First, it allows for full randomization of races within the galaxy. The default race selection process often ended up with duplicates of races, even with a relatively small selection group. When using the full randomization mode, there will be no duplication of races until every race has been used at least once.
The second mode allows for specific race selection via a text file called RaceConfig.ini. The file format is simple - each line contains either a race string, or an alias. The same RaceAlias.ini that the RacialTech patch uses can also be used here. That means that you can either use RACEx00y, where x is the species, and y is the race, or you can use an alias from the file. For more specific details of the RaceAlias.ini file, see the RacialTech patch.

A sample RaceConfig.ini file is included with the patch. You can use this file by removing the .sample extension, and moving the file into your main MoO3 directory. As the previous paragraph mentioned, the format for this file is simply one entry per line. The order the file is in is the order the races will be selected for the game.

The final mode is a hybrid of the previous two modes. You can use the configuration file to select some of the races specifically, and then leave the randomization routine to select the rest. An example:
You wish to always have 5 Ithkul in your game, but you don't wish to select any other race. You play with 16 AI empires. You would create a RaceConfig.ini file that would look like:

Ithkul
Ithkul
Ithkul
Ithkul
Ithkul

What this would do is ensure that the first 5 races added in the game are Ithkuls. But because the file stops there, the final 11 races will be determined randomly. Because there are already Ithkul in the game, no Ithkul would be picked randomly. The rest of the races would be unduplicated, thanks to the randomization factor.

Racial Tech - The basic premise of the RacialTech patch is to limit the research of specific techs to specific races. This is accomplished by modifying the TechTables.txt spreadsheet. In the TechApplications table, there is a column labeled 'Sort_Tag'. This column will normally contain a label such as 'Ship', or 'Region', or 'Achieve'. It may contain a tag called 'KEEPTHIS' - this tag ensures that the particular technology will always be researchable by every empire in the game.

The 'Sort_Tag' column supports multiple tags, separated by commas. It is this column that racial tags may be added to. The RacialTech.patch file is accompanied by a RaceAlias.ini.sample file. This file is fully functional, and should you choose to use it, you may remove the '.sample' from the name, and move the file into your main MoO3 directory.

As the name suggests, it is a list of aliases. There are two columns. The first contains a tag that matches the internal MoO3 executable format. For the playable races, it goes by the format 'RACEx00y', where x is the species value, and y is the race value. The species and race numbers can be obtained by looking at the first table in the RaceModifiers.txt spreadsheet. Note, there are three column headings of note, 'UISpecies', 'Species', and 'Race'. Ignore the 'UISpecies' column, it's not relevant.

The second column of the RaceAlias.ini file is the actual alias. You can set this to any value you wish (although only the first 8 characters are actually used, so ensure there are no duplications). You may then use that alias in TechTables.txt instead of using the RACEx00y value.
The alias is then added to the 'Sort_Tag' column of the tech you wish to limit to a specific race. You may add more than one race to a tech, should you want it to be shared.

An example:
Let's assume you want to change the Point Defense mount so that only Humans could research it. Using the default RaceAlias.ini file, the alias for Humans is, appropriately, 'Human'. The default 'Sort_Tag' for the Point Defense mount is 'Ship, Military'. To make it only researchable by Humans, you would change that to 'Ship, Military, Human'.

Now perhaps you decide that that's too limiting, and you want an Humanoid (that is, the species Humanoid) to be able to research it. Again, using the default RaceAlias.ini values, the 'Sort_Tag' would now be 'Ship, Military, Human, Evon, Psilon'. Instead of using aliases, you can use the actual RACEx00y values themselves. If you choose this route, you don't need the RaceAlias.ini file. You could set the 'Sort_Tag' to 'Ship, Military, RACE0000, RACE0001, RACE0002'. They would both have the same effect, but the former is certainly easier to read than the latter.
It is worth noting that the word 'research' has been used throughout this document. That is because the RacialTech patch only applies to research. The tech may still be obtained by other races by trading, stealing, or military action.
Title: Bhruic's Work - 4
Post by: solops on July 07, 2013, 05:28:48 PM
Random Events - This patch adds new Random Events to the game that aren't possible with the current RandomEvents table. This patch includes, and supercedes the old StarlaneEvent patch. The patch currently adds three new Random Events to the game - the aforementioned Starlane Event, a new AntaranRevolt Event, and a new DiscoverSystem Event.

The Starlane Event adds the possibility of 'new' starlanes being created. 'New' is in quotations because they aren't properly new at all. During galaxy creation, a pool of starlanes for each system is created. From this pool, some are chosen to be starlanes, and some are not. But even the ones that are not are stored. This patch selects one of these unchosen lanes, and turns it into a normal starlane.

The AntaranRevolt Event does what it's name describes - causes an Antaran Revolt to take place in the New Orion empire. This causes the destruction of the New Orions (if they exist at that point), and the creation of a new empire formed by the citizens from the old empire. This new empire acts just like an AI empire - meaning they will expand, enter wars, etc. Depending on when this event takes place, it can dramatically alter the course of a game. Note: Combining this event with the Senate Victory Condition will mean that you will either win or lose the game after the next vote - and is therefore not recommended.

Finally, the DiscoverSystem event will cause a random empire to 'discover' (or, more accurately, explore) a random unexplored system, assuming such a system exists. This will cause them to become aware of both the planets in the system, and any starlanes.
The ExtraRandomEvents.txt file included with the patch controls the chance of each event taking place on any given turn. This file should be placed in your main MoO3 directory. The 'Chance' column is a value from 1-1000, where 1000 means the event will take place every turn, and 1 means there is a 0.1% chance of it taking place. For the mathematically inclined, setting the 'Chance' to 7 will mean that the event has a 50% of happening in the first 100 turns. If you don't want a particular event to take place, you can either remove that row from the file (not recommended), or simply set the chance to '0' (recommended).

Also included with the patch are sample Sitrep.txt and wsSitrep.txt files. These are necessary for the events to be reported properly. If you use custom Sitrep files, then you will need to copy the last 3 entries from each file into your own.

Relations By Race - The base relations in the game are set based on the species of the interacting empires. This patch allows the relations to be set by race, instead of species. It uses the same SpeciesBaseRel table (now inaccurately named) in BaseRelations.txt. Where the current columns/rows refer to species names, they now can be changed to race names (note, the actual name of the column/row is irrelevant to the game). The order is first by species, then by race (meaning, for example, the the first species, Humanoid, is first, so it starts off 'Human, Evon, Psilon', then hits the Etherian with 'Imsaeis, Eoladi', then hits Geodic, 'Silicoid', etc). The table is setup to handle 20 entries, but because the magnate civilizations seldom, if ever, form empires, the columns/rows for them are essentially wasted. As there are 16 primary races plus the New Orions (or Elder Civilization), changing to a race based table leaves 3 unused columns/rows. These will come after the 16 primary races, but before the Elder Civilization.
This mod is primarily designed for other modder's use - installing it without an accompanying change to the SpeciesBaseRel table is not recommended.

Retreat Timer - This simple patch allows the Retreat Timer to be modified from the default 15 seconds. It can be used, for example, to prevent the "shoot and scoot" combat tactic by increasing the "scoot" time so that TFs can be gotten to before they can get away.
Senate Victory - This alters the Senate Victory Condition to require an empire to get 2/3rds of the total vote. An empire that wins a simple majority, but does not acquire 2/3rds of the vote will become Senate President, but will not win the game.

Starlane Event - This patch adds the possibility of 'new' starlanes being created. 'New' is in quotations because they aren't properly new at all. During galaxy creation, a pool of starlanes for each system is created. From this pool, some are chosen to be starlanes, and some are not. But even the ones that are not are stored. This patch selects one of these unchosen lanes, and turns it into a normal starlane.
When patching, a window will appear asking you to determine the chance of a new starlane appearing. This is a straight percentage, between 1-100 (ie, setting it to 100 will ensure that a new starlane is chosen every turn). The recommended value of '5' means that, roughly speaking, you should have a new starlane appear once every twenty turns on average.
To have the starlane event properly appear in the Sitrep, the following changes need to be made to the specific textfiles:
Sitrep.txt - table ReportType (ensure that spaces are converted to tabs):
NewStarlane New Event Reg ICO_SitRep_ExplorationComplete STARLN01 STARLN01 STARLN01
wsSitrep.txt - end of file:
\*STARLN01 Astronomers have located a previously undiscovered Starlane connecting the %Value1% and %Value2% systems.
System Defense TF - By editing the TaskForceRules.txt file, you can adjust the number of ships that can be added to a TF. Should you wish, you can set it so you can have up to 255 ships in a single TF. Unfortunately, these changes are only applied to Starship TFs, not the System Defense TF.
Applying this patch will allow you to set the maximum number of ships that may be in the System Defense TF. This number doesn't have to correspond to the number(s) in TaskForceRules.txt, so you are free to increase or decrease it independently.

Tech Levels - The maximum Tech Level that can be set is level 50. Anything set above that in 'TechTables.txt' will be automatically lowered to that level. Additionally, the Tech Matrix is locked into only displaying up to Tech Level 50. Some modders have expressed an interest in using higher Tech Levels, which is what this patch enables. Tech Level 99 appears to be a special level, therefore the new cap is set at TL 98. The Matrix has been modified to show techs up to that level.

Tech Tags - Functionally, this patch is similar to the RacialTech patch. Where that patch allows for an alias file, for those who may have renamed the races, this patch doesn't require one. It introduces four hardcoded tags:
NoSteal: Prevents the tech from being stolen by spies.
NoTrade: This tech will not show up as a trade option (or for demand, or any other diplomatic avenue).
NoCap: Prevents the tech from being acquired by capturing a planet.
NoRandom: Prevents the tech from being granted via a random event or special.
This tags can be used separately or all together. Using all of them effectively bars a race from aquiring the technology unless it can research it.
The tags get applied to the 'Sort_Tag' column of TechTables.txt. For more precise details about how to add them, see the RacialTech patch.

TFs Per Combat - Each empire participating in combat is allowed to have up to 10 task forces (TFs) engaged in the fight. Any TFs present beyond the 10 will not be used. This can artificially inhibit the AI, because the AI isn't programmed to be aware of this limitation. By applying this patch, you may select an alternate maximum TF limit.
Please be aware that system performance will degrade the more TFs participate in combat. Tests performed suggested that approaching the limit of 50, the FPS (frames per second) of combat was less than 10, making it extremely difficult to either control or watch combat progress.
Also, the number of 'cards' the UI (user interface) will display is 12. Beyond that, you will have to select the TF on the battle screen itself.

SPREADSHEET MODDING
One of the really nice things about MoO3 is that many parts of it can be modded (short for 'modified') to fit your prefered playing style. This guide won't focus so much on what can be modded so much as how to do it.
Note: This guide will assume a Windows version of MoO3. The instructions are similar for the Mac version, but directories and program names would vary.
The first thing to do is find the right directory. By default, MoO3 gets installed to:
C:\Program Files\Infogrames Interactive\Master of Orion 3\
From here, we first go to the GameDataSets directory, then Classic_01, then GameData, and finally Common.

In this directory you will find four files, each with a '.mob' extension. The extension is actually a bit of a trick, the files really are '.zip' files. These files can be opened with such programs as WinZip, WinRar, etc. The file we are most interested in right now is Spreadsheets.mob. If you double-click on the file, Windows will most likely ask you how to open the file, because it doesn't know. Tell it to use whichever of the programs you have installed (and if you don't have one installed, you'll need to download one before you can proceed). Once it is open, you will see it contains a single folder, aptly called 'Spreadsheets'. Click on that folder and drag it into the same directory that contains the Spreadsheets.mob file. This will copy the folder, and all its contents into that directory. Finally, you'll need to right-click on the Spreadsheets folder that was created. A menu will pop up, and 'Properties' should be the option on the bottom. Select that. A new window will open up, listing the details of the folder. What you want to find is an option that says 'Read-only', with a checkbox beside it. Uncheck the box so that you will be able to modify the spreadsheets.
Ok, the hard part is now done. You can move into the Spreadsheets directory, where you will find a large amount of '.txt' files. These are the spreadsheets themselves. They are best edited with Excel, but you can use a normal text editor if you are careful. The spreadsheets use what's called a 'tab-delimited' format, which means that 'tab' is used to separate the columns from each other.
At this point, you may begin to look at the various spreadsheets. Some important ones you'll likely want to have a look at:

TechTables.txt - This spreadsheet contains the full list of technologies that are present in the game, as well as the numbers used in the formula that determines how many RPs are needed to research each TL.
RaceModifiers.txt - This spreadsheet contains details on all of the races present in the game, as well as the various race pick options.
TaskForceRules.txt - Here you'll find the rules that determine how a TF is made up. It also lets you increase (or decrease) the size of any TF.
FighterWeapons.txt
MissileInfo.txt
WeaponsTable.txt - Each of these tables contains the corresponding weapon information based on their type. It's where you'd look to make changes to any type of weapon.
Note: Do NOT edit the files inside the .mob file directly. Do not move any files back into the .mob file. And absolutely do not delete the .mob file itself.
Title: Re: MOO3 Information
Post by: Darkspire on July 07, 2013, 05:36:44 PM
Quote from: Huw the Poo on July 07, 2013, 05:06:00 PM
Quote from: Darkspire on July 07, 2013, 04:59:43 PM
One thing I would ask is has anyone got the Chocolate mod?

Here! (http://www.mediafire.com/?bab6i5ezwj6u1)

Thanks  :) I will dig the CD out as soon as its safe, its in the garage and the GF is welding a trike at present, shes bad enough when she is stripping engines with all the bits flying about ;D

Darkspire
Title: Re: MOO3 Information
Post by: Jarhead0331 on July 07, 2013, 05:51:10 PM
Solops...I appreciate the efforts you are making to archive all this info.  But, at some point when you have the time, I suggest it will be of equal service if you edited each post so it is not just a wall of text.  It is so difficult to read through that I'm afraid all of your effort will be lost if left as is. 
Title: Re: MOO3 Information
Post by: OJsDad on July 07, 2013, 07:53:09 PM
Quote from: Darkspire on July 07, 2013, 04:59:43 PM
Quote from: Jarhead0331 on July 07, 2013, 04:45:56 PM
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.

You forgot to mention the mountain you had to climb to learn it, I loved MOO2 and still have it installed, even with the bad vibes doing the rounds on M003 I gave it a fair chance but it was so awkward to learn, I did enjoy it though to an extent, and that was before all the mods were released to improve it.
One thing I would ask is has anyone got the Chocolate mod? I think someone else mentioned it and I had a look and can find Strawberry and Vanilla, If I can find Chocolate and find a recommended mod list that interests me I will dig the CD out.

Darkspire

The hope and promise of what MOO3 was supposed to be was killed when the company that started the development of it, got bought out a couple of times and most of the original design team was let go.  Then Atari(?) fast tracked it to production.  Once released, they quickly abandoned it.
Title: Re: MOO3 Information
Post by: Steelgrave on July 07, 2013, 08:43:55 PM
Jarhead, I know that you are a big MOO3 fan and that you play with a bunch of patches & mods. You've probably posted that before, but do you have links? I've got the game tucked away somewhere on my hard drive, it might be time to dust it off and give it a try.
Title: Re: MOO3 Information
Post by: Kushan on July 07, 2013, 09:15:45 PM
Quote from: Steelgrave on July 07, 2013, 08:43:55 PM
Jarhead, I know that you are a big MOO3 fan and that you play with a bunch of patches & mods. You've probably posted that before, but do you have links? I've got the game tucked away somewhere on my hard drive, it might be time to dust it off and give it a try.

This thread is the current discussion on modding MOO3:
http://grogheads.com/forums/index.php?topic=6507.0 (http://grogheads.com/forums/index.php?topic=6507.0)

JH's post from last year (contains most of the same information):
http://grogheads.com/forums/index.php?topic=6576.15 (http://grogheads.com/forums/index.php?topic=6576.15)
Title: Re: MOO3 Information
Post by: mikeck on July 07, 2013, 09:17:04 PM
http://www.moo3.at/mods/

This has some mods. Has Tropical 1.21

Here is tropical 1.13.1....not sure which is "newer" honestly as the original modder quit and others took it
Has a lot of mods

http://www.mediafire.com/?bab6i5ezwj6u1

Title: Re: MOO3 Information
Post by: Steelgrave on July 07, 2013, 09:21:54 PM
Coolness. Thanks, fellas  :)
Title: Re: MOO3 Information
Post by: solops on July 07, 2013, 10:25:57 PM
Quote from: Jarhead0331 on July 07, 2013, 05:51:10 PM
Solops...I appreciate the efforts you are making to archive all this info.  But, at some point when you have the time, I suggest it will be of equal service if you edited each post so it is not just a wall of text.  It is so difficult to read through that I'm afraid all of your effort will be lost if left as is.

Will do. All of it was carefully formatted, but the formatting vaporized when I copied it over. Also, if anyone has an area in particular that they are interested in, mention it and I'll see what I have. Some of this is available on the Master of Orion 3 Guardian website, but a lot of this stuff disappeared when the old Atari boards went down.
Title: Re: MOO3 Information
Post by: mikeck on July 08, 2013, 10:00:55 PM
Question: is there a reason I should t colonize every green planet with average fertility as resources i find? I'm wondering because I have about 7 colonies around 4 stars. I met my first civilization and they have only one colony. Now I am playing on "beginner level" I believe but I'm wondering...do they know something I don't?
Title: Re: MOO3 Information
Post by: solops on July 09, 2013, 09:47:09 AM
I think you should grab the greens. The potential trouble is money and people shortages. Work the migration settings carefully. Your early colonies are going to take a long time to get started when the migration is spread out from just the homeworld. Get multiple colony pods on your colonizers as soon as you get a hull big enough. Consider sending outposts out to potential colony sites to stake a claim. They are cheap. I am playing on hard and got out-expanded. Amazing how much one forgets in just 6 or 7 years :-)
Title: Re: MOO3 Information
Post by: OJsDad on July 09, 2013, 09:57:05 AM
I have the disks still and I'm running Win7 64bit.  I installed the game and the offical patch with no problem.  When I start the game, I get the intro video but the game setup screen is screwy.  I see all of the options, but there are not graphics, no race picks, not empire flags, etc.  When I click on start game, I then get the diretx error.  Any one else see this before.  I've tried compatipility mode with XP sp3 and Win2K.
Title: Re: MOO3 Information
Post by: mikeck on July 09, 2013, 09:59:40 AM
Yeah..lol population is a little thin on my worlds. Of course, who wants to leave a sweet spot to live on a mineral rich but barren heavy gravity planet?
Title: Re: MOO3 Information
Post by: mikeck on July 09, 2013, 10:02:10 AM
Quote from: OJsDad on July 09, 2013, 09:57:05 AM
I have the disks still and I'm running Win7 64bit.  I installed the game and the offical patch with no problem.  When I start the game, I get the intro video but the game setup screen is screwy.  I see all of the options, but there are not graphics, no race picks, not empire flags, etc.  When I click on start game, I then get the diretx error.  Any one else see this before.  I've tried compatipility mode with XP sp3 and Win2K.

I have had the directx error but that is the error you get whenever anything goes wrong so it doesn't tell you much. Make sure you aren't installing it in the Programs(86x) file.
If you are not, my recommendation is to eat the $10 or wherever it is and buy a copy off of GOG. That will have been designed to work on windows 7
Title: INSTALLING MOO3 IN WINDOWS 7
Post by: solops on July 09, 2013, 02:20:11 PM
Quote from: OJsDad on July 09, 2013, 09:57:05 AM
I have the disks still and I'm running Win7 64bit.  I installed the game and the offical patch with no problem.  When I start the game, I get the intro video but the game setup screen is screwy.  I see all of the options, but there are not graphics, no race picks, not empire flags, etc.  When I click on start game, I then get the diretx error.  Any one else see this before.  I've tried compatipility mode with XP sp3 and Win2K.

I have TWO sets of disks, both packed in boxes from the last move, so I got the GoG version for $5. I had the DirectX Surface error with the GoG version. It has to do with the patching process, I think. I found some instructions, followed them and have had no problems since on my Win7 64-bit machine. I have attached them below after editing for clarification. It should also work with the original disks, other than the deleting the exe part.

Steps:

#0: Download Moo3 from Gog. Download the Guerra patches from http://members.chello.nl/gbrinkers/codemods.html and one of the Tropical, Strawberry and Vanilla mods from http://www.mediafire.com/?bab6i5ezwj6u1
Bhruic's patches are included in the mod packages.

#1: Install Moo3. (this will be in the GoG directory. This avoids the problems arising from putting old games in the Windows7 "Program Files (X86)" directory...do NOT do that!)

#2: Back it up! Just copy the whole install directory and paste it right back into a backup directory you should make in the gog directory. " - this is much easier to restore than from the install.

#3: Extract the your mod package (Tropical, Strawberry, whatever) to its own directory. These mods come with their own exe file, which will cause problems with the GoG install. DELETE the mod's moo3.exe - we won't be using it, but rather the GOG (drm-free) moo3.exe. THIS IS IMPORTANT. If you don't delete the pre-modded executable you will be starting over.

#4: Copy the contents of the mod directory into your Moo3 directory. All of it. Make sure you click "yes" to the copy confirmation and to REPLACE the original files.

#5: Run Bhruic's Moo3Patcher.exe - this is what will apply the patches to the GOG moo3.exe. It and the patch data is included in the Tropical, Strawberry and Vanilla mods. If you copied the mod files over correctly, the patcher exe should be in the same file as the moo3.exe. The Bhruic and Guerra patches that were used in the mod are listed in the Tropical v1.38 readme file. These are what you need to install now, Bhruic's patches FIRST!

- this next step is critical -

#6: Underneath the patch window is a window That says "Moo3DLL.dll" - there's an install button next to it. Press it. Do this BEFORE trying to apply the mini-patches. If it can't find the file, browse to the Moo3DLL.dll file in the moo3 directory. This is from the mod files. You want this.

#7: Some tedium: You have to manually patch in all the patches you want in the window above - just click on it and hit 'patch'. If it is successful, it'll say so in the status column. If it's not successful, make sure you did step 6 (only an issue for the ones that say "Yes" in the dll column), and that in the bottom window it's pointing to the Moo3.exe file to patch. There must be a typo in the patcher database because on one patch (forget which) this has an extra "\" in the directory string and it needs to be re-pointed to the Moo3.exe file. (solops note – I did not have this problem)

#8: Apparently patching in SenateVictory breaks Allied Victory, and vice-versa. if you patched in AV first. You just need to "unpatch" Allied victory, and then "repatch" it. Oh well. Pick one.

#9: DO NOT PATCH IN WINDOWED MODE. Don't say I didn't warn you.

If you follow/ my instructions you should be able to get every patch in with the exception of the SV/AV which are exclusive for some reason.

#10. Now copy all of the Guerra patches into the main MOO3 directory and run them.

You should now be good to play.
Title: Re: MOO3 Information
Post by: vyshka on July 09, 2013, 04:34:14 PM
Anyone have a set of the mac discs? I was told a while back that the source actually ended up on the mac discs, and that was used by bhruic to do his work. Curious to find out if that was true and would be interesting to look through the source.
Title: Re: MOO3 Information
Post by: OJsDad on July 09, 2013, 08:00:22 PM
Thanks guys, I got it to work.  I uninstalled and then reinstalled on c:/games directory. After applying to official 1.2.5 patch, it worked.  I think applied Bhurics fixes and a lot of mods.  I also installed 1024x768 patch.

I do not need to run the exe in compatibility mode.
Title: Re: MOO3 Information
Post by: mikeck on July 09, 2013, 08:06:03 PM
Yeah, I found that old games and the programs 86 folder on windows7 don't mix. The system is hesitant to allow programs to alter files in that directory. It tends to put your save game folders in weird locations as well. Enjoy!
Title: Re: MOO3 Information
Post by: mikeck on July 09, 2013, 09:28:37 PM
Is there a way to pause and issue orders in combat? Had my first fight and it was over before I could do anything. Would like to pause and look around a bit...read some info and stuff.
Title: Re: MOO3 Information
Post by: solops on July 10, 2013, 04:55:06 PM
I cannot remember and I cannot find a "Pause" in the manual. It certainly needs one! I remember having trouble controlling combat, but through trial and error I think I got the hang of it... too long ago to remember. I am not doing to well in my current game...score is middle of the pack, tech is average and the Ithkul are coming...
Title: Re: MOO3 Information
Post by: OJsDad on July 10, 2013, 04:56:31 PM
I seem to remember that not having a pause button in combat was one of the complaints that never got fixed.
Title: Re: MOO3 Information
Post by: sandman2575 on July 12, 2013, 09:39:33 AM
By the way -- GOG has MoO3 on sale now for $3.49

I'm seriously tempted but also have games like Space Empires IV sitting on my desktop that I've never really touched.

Is there a 'bare minimum' that can be done to get Moo3 playable?  Like, just install the Tropical mod and off you go?  Or is it just a lot more involved than that?  (If so, I'll have to pass ... just don't have the mental energy to heavily mod-up games at the moment.)

EDIT - sorry Solops, just saw your detailed instructions in Post #35.  OK that sounds pretty involved - !
Title: Re: MOO3 Information
Post by: mikeck on July 12, 2013, 09:47:59 AM
Nope. Download and install the tropical mod. That's it
Title: Re: MOO3 Information
Post by: sandman2575 on July 12, 2013, 09:55:58 AM
So, no headaches with installation - ?  I'm running Win 7 x64

EDIT -- sorry, ignore -- I seem to be having reading comprehension problems this morning -- I see that the problems were with the disk installation, not GOG d/l
Title: Re: MOO3 Information
Post by: mikeck on July 12, 2013, 10:16:22 AM
Well, I didn't say "no headaches". Install it outside of the program(86) folder that windows always wants to out it I . That's easy. I had some issues with the tropical mod patching but others have not. Problem solved when I replaced the stock Moo3.exe with the one that came with the tropical 1.13.10 mod (which it says you are not supposed to do). Others have had no issues at all
Title: Re: MOO3 Information
Post by: mikeck on July 13, 2013, 08:23:32 PM
Ok, I have a question for you Moo3 vets. I am trying to set a policy for my planet. Basically, I want to make one a mining world and another a food world, etc.

I can creat plans for these different type worlds no problem.
The problem is when I click on a planet and bring up the "drop down" to select what type of planet it will be (to match my plan). The only choices are "new" and "player defined" how do I get to select "core, mineral, tech. Military, production, etc so that the viceroy will build accordingly?
Title: Re: MOO3 Information
Post by: Anguille on July 14, 2013, 04:31:24 PM
Quote from: mikeck on July 13, 2013, 08:23:32 PM
Ok, I have a question for you Moo3 vets. I am trying to set a policy for my planet. Basically, I want to make one a mining world and another a food world, etc.

I can creat plans for these different type worlds no problem.
The problem is when I click on a planet and bring up the "drop down" to select what type of planet it will be (to match my plan). The only choices are "new" and "player defined" how do I get to select "core, mineral, tech. Military, production, etc so that the viceroy will build accordingly?
It will remain on "new" for a certain number of turns...the new planet needs to build up the first infrastructures before it's possible to give a speciality...i don't have the manual here but i think it's correct.
Title: Re: MOO3 Information
Post by: Huw the Poo on July 14, 2013, 05:39:34 PM
FAQ covering planetary classifications (http://uk.ign.com/faqs/2003/master-of-orion-iii-colony-development-faq-390789)

According to that FAQ, Anguille is correct; the "new" classification is temporary and lasts for 15 turns.
Title: Re: MOO3 Information
Post by: mikeck on July 14, 2013, 06:46:35 PM
This is my home world and it is turn 50. I designate it as "player defined 1" and created a plane for "player defined 1" as a mining world. Should work
Title: Re: MOO3 Information
Post by: peddroelm on March 16, 2015, 03:48:32 AM
First videos cover a lot of critical game mechanics information that is mostly missing from the game's manual ..

First video presents general economy concepts (with diagrams)
Seconds video deals mostly with various DEAs output formulas

From third video on - split screen actual gameplay silicoid vs tachidi games to illustrate some mechanics by contrast/comparison ..

youtube playlist link  https://www.youtube.com/playlist?list=PLFWnpbmrXTornnsob-8zgwevwhONQ096_ (https://www.youtube.com/playlist?list=PLFWnpbmrXTornnsob-8zgwevwhONQ096_)
Title: Re: MOO3 Information
Post by: Anguille on March 16, 2015, 04:05:04 AM
That's interesting! You put a lot of work into this  O0
Title: Re: MOO3 Information
Post by: Jarhead0331 on March 16, 2015, 06:39:12 AM
Welcome! Thanks for posting. Great thread to necro!
Title: Re: MOO3 Information
Post by: bbmike on March 16, 2015, 07:59:13 AM
Thanks! I'll check this out. I just re-installed MOO3 last week and have been wanting to play it again.
Title: Re: MOO3 Information
Post by: Swatter on March 16, 2015, 12:04:56 PM
I was drawn back into MOO3 last time this thread came around. I do like the game, but its simply broken. There are bugs in the economic system that ruined every game that I started. After a moderate amount of time, little things stopped properly adding up. After a bit longer, your income just losses all touch with reality (its like flipping a switch). I believe these were hard coded bugs that mods couldn't help.

Before anyone invests time into the game, do some research in the mod forums about economy bugs. Its just terrible bugs like this could have made it past Beta, let alone several patches in. Its just goes to show how bad a state the development team was in.
Title: Re: MOO3 Information
Post by: peddroelm on March 16, 2015, 01:21:47 PM
Quote from: Swatter on March 16, 2015, 12:04:56 PM
I was drawn back into MOO3 last time this thread came around. I do like the game, but its simply broken. There are bugs in the economic system that ruined every game that I started. After a moderate amount of time, little things stopped properly adding up. After a bit longer, your income just losses all touch with reality (its like flipping a switch). I believe these were hard coded bugs that mods couldn't help.

Before anyone invests time into the game, do some research in the mod forums about economy bugs. Its just terrible bugs like this could have made it past Beta, let alone several patches in. Its just goes to show how bad a state the development team was in.

Could you be more specific as to where I might find more info on those economic system bugs ?
I've been trying to make heads and tails of the planetary economy  (mainly so I could judge spaceport worthiness) but its really slippery .. Even the simple %Tax income from GDP doesn't match after a few turns or so .. Really irritating .. Could be the mythical GOV DEA tax bonuses solar system outreach shenanigans ? (very unlikely) .. Might test again in a small empire after ripping out all GOV DEAs .. (not only on test planet) ..

Poorly explained mechanics or nasty bugs ? (in my experience based on analyzing other games those to sadly go hand in hand .. If the mechanics are not clearly explained and thus easily verifiable, bugs abound  ) 
Title: Re: MOO3 Information
Post by: Anguille on March 16, 2015, 02:53:34 PM
Quote from: Swatter on March 16, 2015, 12:04:56 PM
I was drawn back into MOO3 last time this thread came around. I do like the game, but its simply broken. There are bugs in the economic system that ruined every game that I started. After a moderate amount of time, little things stopped properly adding up. After a bit longer, your income just losses all touch with reality (its like flipping a switch). I believe these were hard coded bugs that mods couldn't help.

Before anyone invests time into the game, do some research in the mod forums about economy bugs. Its just terrible bugs like this could have made it past Beta, let alone several patches in. Its just goes to show how bad a state the development team was in.
I don't remember but i had a look at the threads about economics in the game and it all made sense (i am an auditor). Thing is that i've never seen such a complex system in any game, so yes i think it's too complex but it's not bugged.  ;)
Title: Re: MOO3 Information
Post by: bbmike on March 16, 2015, 03:04:14 PM
Quote from: Swatter on March 16, 2015, 12:04:56 PM
I was drawn back into MOO3 last time this thread came around. I do like the game, but its simply broken. There are bugs in the economic system that ruined every game that I started. After a moderate amount of time, little things stopped properly adding up. After a bit longer, your income just losses all touch with reality (its like flipping a switch). I believe these were hard coded bugs that mods couldn't help.

Before anyone invests time into the game, do some research in the mod forums about economy bugs. Its just terrible bugs like this could have made it past Beta, let alone several patches in. Its just goes to show how bad a state the development team was in.

Were you playing with any of the major mods?
Title: Re: MOO3 Information
Post by: Anguille on March 16, 2015, 03:14:20 PM
Quote from: bbmike on March 16, 2015, 03:04:14 PM
Quote from: Swatter on March 16, 2015, 12:04:56 PM
I was drawn back into MOO3 last time this thread came around. I do like the game, but its simply broken. There are bugs in the economic system that ruined every game that I started. After a moderate amount of time, little things stopped properly adding up. After a bit longer, your income just losses all touch with reality (its like flipping a switch). I believe these were hard coded bugs that mods couldn't help.

Before anyone invests time into the game, do some research in the mod forums about economy bugs. Its just terrible bugs like this could have made it past Beta, let alone several patches in. Its just goes to show how bad a state the development team was in.

Were you playing with any of the major mods?
I've just used the patches done by Bhruic. I think that most mods include them and they should be fairly easy to install but i never tried one. I should install the game on my new desktop.
Title: Re: MOO3 Information
Post by: peddroelm on March 16, 2015, 04:09:21 PM
http://www.orionsector.com/pages/moo3/dd/dd-highfinance.php

wonder if any of this made it in the game ..  (Surplus Interest Rate ??) ..Could this explain why the TAX rate shown on planet screen is higher than the adjustable tax number (without planetary finance buildings that increase tax collection)  and without GOV deas which I'm afraid do nothing to affect the TAX amount collected directly (despite the description and entire line of DEA addons dedicated to it) (they do affecting it via the economic mods by boosting DEA outputs -> thus GDP -> thus TAX collected ) .. when I try to check it on more advanced mid-game planets .... Should check vs new colonies with thin treasuries at same turn to see if the TAX is closer to the "truth" for those ..
Title: Re: MOO3 Information
Post by: Swatter on March 16, 2015, 08:01:21 PM
I think I was using the "Tropical" mod or whatever its called. I forget the bug exactly, but it killed the game a few straight times. I don't remember if it was some sort of wrap around bug (which was supposed to have a work around) or something else.
Title: Re: MOO3 Information
Post by: peddroelm on March 17, 2015, 02:20:29 AM
Quote from: Swatter on March 16, 2015, 08:01:21 PM
I think I was using the "Tropical" mod or whatever its called. I forget the bug exactly, but it killed the game a few straight times. I don't remember if it was some sort of wrap around bug (which was supposed to have a work around) or something else.

Might be wrong here since you don't recall exactly but - economy warp around bugs I can see happening in two places (empire treasury bank overflow (and flip to max negative value) and top dog income generator planets  - same thing affecting your planetary treasury ...

Both should have trivial solutions (and should explain why their test team never encountered them) that imply simply playing the game properly  ;D .. Why are you letting your money accumulate ?? (probably under AI control with "savings" setting ) ..  Money spend  now has much better utility than money used 20 turns later due to snowballing effects .. Spend your money !! Every turn !

If not under full micro control (which I assume you weren't using) switch the empire global finance policy to spending (if you have huge surplus) or balance when reaching 0 cash reserves ..
Empire wise use the research/unrest/military/grant to planets sliders to spend more ... (Research slider is the best candidate will always spend it all - however inefficiently for extra RPs ..Unrest slider will return money  back to treasury if no unrest to deal with .. Grants to poor planets will stick into their treasuries and help them develop WAY faster )

On guilty planets risking treasury overflow - could set the send gift to empire flag or design the  biggest,most expensive hull you can build - and let it choke building it on x10 batches cranking the military spend slider way into the red (very inefficient ) ..

Your cash reserves should not last long and you should never be anywhere near overflow limits ever again ..

Don't really know why the savings setting is even in the game .. Maybe you receive positive interest (right term ?) for having cash reserves ?  Any way spending all you can spend every turn is IMHO always superior due to the snowballing effects ..

Load  autosave game 1-2 turns before the bug happens - go into mad shopping spree - problem solved ..

also read Joseph's post in that thread
http://www.moo3.at/board/index.php?showtopic=2144
Title: Re: MOO3 Information
Post by: PAK on March 17, 2015, 09:12:54 AM
I was playing with Tropical and Strawberry, had to stop because crashes (directx layer error) started to occur when browsing the colony list (in my case it was when I had 20 or 30 colonies). I didn't found any remedy for that.
Title: Re: MOO3 Information
Post by: mikeck on March 17, 2015, 05:29:35 PM
Thanks for the vids! Tried desperately to learn the game but couldn't. Eventually I will give it another shot when I'm in a space mood
Title: Re: MOO3 Information
Post by: Finn on November 24, 2015, 08:48:59 PM
Hi fellows

I am playing MOO3 original disc +vanilla mod, human on "hard".  Suddenly spys stopped working.  I can train them as usually and then deploy but when i turn next they are still the in the box at ease.

Then i noticed that my fleets refuse to attack.  Other empires won't attack me either what ever i do.  I even went to Guardian's system and same thing; no battle and i got Guardian's system explored.  Guardian anyway stays there because the colony ship won't land and system shows one vessel there.

I mean, is this just me, something new in the game that i haven't face before, known bug with a solution or nasty thing that messed up my good game?

I would appreciate if some one had something on this one.

Finn
Title: Re: MOO3 Information
Post by: Xtiaan72 on November 26, 2015, 11:24:28 AM
I will be buying this retail.
Title: Re: MOO3 Information
Post by: Finn on November 29, 2015, 03:23:28 PM
Yes, do buy it Xtiaan72, it's a good game.  I allways find myself playing it, sometimes a break of year or two and then again.

I sincerely recommend you to install a modification called "Vanilla" right away.  The original game was loaded with all kind of frustrating issues.  For example technological development got stuck to some random level without possibilities to avance.  The nasty bug kept for example "improved plasma canon" on your sight but just out of reach.  That eat a mans patience like a rat, i tell you.
I mean; " How to rule the universe without a decent plasma canon, or improved disintegration beam",  I ask.

The Vanilla modification doesn't really chance anything in games character, it just fixes original releases issues so that one can play it such way as it was meant to.

Those spy and no attack problems which i asked about went away, by the way, when i re started the game.

Finn
Title: Re: MOO3 Information
Post by: PAK on November 30, 2015, 09:08:15 AM
Damn it guys, You made me try this monster once again...
Moo3 is a harsh mistress  :coolsmiley: