Main Menu

MOO3 Information

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

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Darkspire

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
Trying to prove the existence of God with the Bible is the same thing as trying to prove the existence of Orcs using the Lord of the Rings books.


Huw the Poo


solops

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

solops

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

solops

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

solops

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

solops

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

Darkspire

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!

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
Trying to prove the existence of God with the Bible is the same thing as trying to prove the existence of Orcs using the Lord of the Rings books.


Jarhead0331

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. 
Grogheads Uber Alles
Semper Grog
"No beast is more alpha than JH." Gusington, 10/23/18


OJsDad

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.
'Here at NASA we all pee the same color.'  Al Harrison from the movie Hidden Figures.

Steelgrave

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.

Kushan

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

JH's post from last year (contains most of the same information):
http://grogheads.com/forums/index.php?topic=6576.15
PanzersEast: Have to think to myself.... will I play the first one by the Winter Sale?  Probably not, then I should remove Dragonfall
PanzersEast: but that is thinking too logically.... and Steam Sales are about ignoring Logic

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

mikeck

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

"A government large enough to give you everything you want is strong enough to take everything you have."--Thomas Jefferson

Steelgrave

Coolness. Thanks, fellas  :)

solops

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