Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - MarcAFK

Pages: [1] 2 3 4
1
C# Aurora / Re: C# Aurora Changes List
« on: January 02, 2018, 01:55:51 PM »
Ground Forces: Part 2 - Formation Templates
The screenshot below shows the Formation Templates tab of the Ground Forces window. Formation Templates are the equivalent of VB6 Ground Unit Types, although it might be easier to think of them as serving the same function as Ship Classes. They are a detailed design that serves as a template for building Formations based on that same design, which is the same relationship as Ship Classes to Ships.

This tab is split into two halves. On the left is a list of available Ground Unit Classes created using the Unit Class Design tab (as explained in the previous rules post). All of these were created using TL4 technology, with three exceptions. For comparison purposes, the Challenger 2 Main Battle Tank and the Warrior AFV were created using Conventional, rather than Trans-Newtonian, technology, while the Challenger – Base TN Upgrade was the Challenger design with TL1 technology. It should be possible to simulate most modern army units with the new C# Aurora ground combat, so you could theoretically be landing on an alien world with Abrams and Bradleys or T-14 and T-15 Armatas. The ten columns for the Unit Class List are as follows:

1)   Type: An abbreviation for the Base Type (infantry, Vehicle, Heavy Vehicle, etc.)
2)   Name: The name assigned during Unit Class Design. This can be changed using the Rename Unit button.
3)   Size: Transport size in tons.
4)   Cost: Cost in Build Points.
5)   Arm: The Armour Strength of the Unit. This is based on the armour available at the time of design and is not upgraded when newer technology becomes available (as with ship designs).
6)   HP: The Hit Points of the Unit. This is set at design time and does not change.
7)   Components A to D: Abbreviations for each of the components included in the Unit Class. These are the same abbreviations as used on the Components table in the Unit Class Design tab. As with armour and hit points, any components use the technology available at the time of unit design. To see the detailed view of the components, click on the Unit. The Unit Summary will be shown in the bottom section on the left hand side.

As an example, the Leman Russ Battle Tank is a Heavy Vehicle of 104 tons, with 60 Armour and 60 Hit points, costing 12.48 BP. The components are Heavy Anti-Vehicle (HAV) and Heavy Crew-Served Anti-Personnel (HCAP). Looking at the summary, the HAV has 1 shot per combat phase with Penetration 60 and Damage 60, while the HCAP has 6 shots with Penetration 20 and Damage 10.

The right-hand half of the tab shows Formation Templates. A new Formation Template is created by clicking the New button. In this case, four have already been created. Each Template comprises one or more Template Elements, shown in the bottom right section Each Template Element has a specific number of specific Ground Unit Class. For example, the Guard Armoured Regiment is currently selected, which has four template elements: 60x Leman Russ Battle Tank, 1x Macharius Command Tank, 12x Hydra Flak Tank and 24x Hellhound Anti-Infantry Tank.

Each template element has the following attributes:
1)   Name: The Unit Class for this element.
2)   Units: The number of units of that Unit Class in this element
3)   Size: The total size on tons of this element. For example, 60 Leman Russ Battle Tanks at 104 tons each is 6,240 tons.
4)   Cost: The total cost in Build Points for this element.
5)   HP: The total aggregate hit points for the element.
6)   HQ: The headquarters capacity of the element’s Unit Class in tons. If there are multiple units in a template element, only one is considered for the headquarters capacity. Any additional units are for redundancy. The headquarters capacity is the total size of the formation (or formation hierarchy) that can be effectively controlled by a commander based in a unit with this component. In the case of the Macharius Command Tank, it has an HQ capacity of 10,000 tons.
7)   FFD: The total number of Forward Fire Direction (FFD) components in the template element. Forward Fire Direction allows a front-line unit to direct the fire of bombardment units from a formation in a support position, fighters on close air support missions, or ships in orbit.
8)   Const. The construction value of the element in Construction Factory Equivalents (CFEs).
9)   CIWS: The number of Close-in-Weapon-System components in the template element, capable of defending the planet (on which the unit is based) from missile attack.
10)   STO: The number of Surface-To-Orbit energy weapon components in the template element. STOs are capable of engaging ships in space within weapon range of the planet on which the unit is based.

The totals for each Template Element are added together to create the total for the Formation Template as a whole, shown in the top right section. In the example shown, the Guard Armoured Regiment has a total size of 8,942 tons, which is the combination of all four template elements. The Formation Template list has an additional column for Rank. A default rank will be suggested by the program, although this can be overridden by the player. This rank will be used by Automated Assignment process for any Formations built using this Formation Template.

To add new Template Elements to a Formation Template, use the Add Units button in conjunction with the adjacent text field to specify the number of units in the new element. This number can be subsequently edited by selecting the element and clicking the Edit Amount button. Both Formation Templates and Element Templates can be deleted using the appropriate buttons.



This screenshot shows the Macharius Command Tank on the left and the Brigade Headquarters formation template on the right. The Macharius is a super-heavy vehicle, with two super-heavy anti-vehicle weapons and an HQ4 component, which provides a headquarters capacity of 10,000 tons. This is a large and expensive vehicle at 518 tons and 93.24 BP, but is well-protected as the loss of the HQ in a formation will result in the loss of any commander bonuses (and maybe the commander himself).

The Brigade Headquarters formation template includes two Guard Brigade Headquarters units, in case one is destroyed, plus thirty-six large artillery pieces, twelve flak tanks and a company of Guardsman. Combat involves three locations. Front-Line, Support or Rear-Echelon. Units in a Support position can only attack using bombardment weapons, or defend themselves against air attack. This formation is intended to serve in the Support location and is organising accordingly. However, it is possible for a Support Formation to temporarily find itself moved into a Front-Line position, so the Guardsman Element will provide additional protection in that case.

The following users thanked this post: MarcAFK

2
C# Aurora / Re: C# Aurora Changes List
« on: January 02, 2018, 10:11:41 AM »
Ground Forces: Part 1 - Unit Design

Ground Forces and Ground Combat are undergoing a huge expansion in C#. The VB6 Ground Unit becomes the Formation and the VB6 Ground Unit Type becomes the Formation Template. However, there are no longer any fixed unit types or unit values. Instead, there is endless scope for Formations and Formation Templates, based on a detailed design process at the Formation level and below. This will allow the simulation of ground forces from many science fiction genres. As this is a long topic, I am going to break it into several posts each covering a different topic.

The most granular level is the Ground Unit Class, which is an individual soldier or vehicle. One or more of the same Ground Unit Class are grouped into Formation Elements, which in turn are grouped into Formations. Formations remain intact for movement purposes, but combat involves each individual unit (each soldier or vehicle). As individual units are now tracked for casualty purposes, readiness no longer exists. Morale is tracked at the Formation Element level (which is a group of the same unit class), so the infantry in a Formation may have a different morale than the anti-tank guns or artillery.

The process of design starts with the Ground Unit Class. Two important factors in this design process are the Racial Armour Strength and Racial Weapon Strength, shown at the top of the Ground Forces window.

Racial Armour Strength is based on the strength of the highest racial armour technology. Conventional Armour is 3, Duranium Armour is 5, et cetera. For this screenshot, the Commonwealth has researched Ceramic Composite, which has a strength of 10.

Racial Weapon Strength is based on the highest tech level (TL) among Laser Focal Size, Railgun Type, Meson Focal Size, Particle Beam Strength and Carronade Calibre. For example, 15cm Laser Focal Size is TL3 as it is the third tech of that type. Racial Weapon Strength is the value of armour at the same tech level. In this case, the Commonwealth has researched 20cm Laser Focal Size, which is TL4. The fourth Armour Tech is Ceramic Composite, which has a strength of 10, so the Racial Weapon Strength is 10. The reason for using Armour as the basis of Weapon Strength is partly because that means Ground Armour and Ground Weaponry are aligned, and partly because it is straightforward way to assign value based on very different weapons.

The Ground Unit Design tab of the new ground Forces window is shown below. First, a 'base type' is chosen, which is infantry, several sizes of vehicle, or static. Static in this sense is a weapon that is not self-mobile, such as a towed anti-tank gun, towed artillery, et cetera. Static weapons remain in place when firing so they are easier to hit than infantry or vehicles. Each base type has six main characteristics:

1) Size (in tons): Size is the basis for transport requirements and cost, although there are other modifiers to cost (discussed below)
2) Hit Points: Unit hit points are compared to weapon damage during combat to determine the chance of destruction (the Damage Check). The chance of a weapon destroying a unit is Weapon Damage / Hit Points.
3) Slots: The number of component slots available for the base type
3) To-Hit Modifier: Used to modify the chance of the unit being hit during combat (based on the mobility of the unit). This only applies if the unit is not fortified.
4) Maximum Fortification: The maximum strength to which the unit can be fortified by construction factories or construction units. The Chance to Hit for a firing unit is divided by the Fortification Level of the target unit.
5) Maximum Self-Fortification: The maximum strength to which the unit can be fortified without construction factories or construction units.

The next section is Armour Type. The Armour of a unit is compared to the Armour-Penetration (AP) value of a weapon. The chance to penetrate is equal to (AP / Armour) ^2. For example, a weapon with AP 4 attacking a unit with Armour 6 has a 45% chance to penetrate. The overall process for checking if a shot destroys a target is Chance To-Hit, followed by Armour Penetration Check, followed by Damage Check. All three must be successful to destroy the target. Each type of Armour has two values.

1) Base AR: The Base Armour Rating is multiplied by Unit Size (including components below) to determine cost. So a unit with 6 armour would be 50% more expensive than the same unit with 4 armour.
2) Racial AR: Racial Armour Rating is the Base Armour Rating multiplied by the Racial Armour Strength (shown at top of window).

Below the base type and armour is a large section showing Components. Infantry, static and light vehicles all have one 'component slot', vehicles and heavy vehicles have two slots, while super-heavy and ultra-heavy vehicles have three and four slots respectively. Each slot can hold one component from the list and the same component can be put into multiple slots. Certain components are only available with certain base types. For example, the Super-Heavy Anti-Vehicle component can only be used by super-heavy and ultra-heavy vehicles. The primary component is selected from the main table, while any additional components are selected from the dropdown(s) below the main table. Each component has a name and an abbreviation and is rated in nine different areas:

1) Size: The size in tons is added to the size of the base unit type.
2) Armour-Penetration (AP): If the component is a weapon, the chance to penetrate a target's armour is (AP / Armour) ^2. The AP Rating is the underlying AP of the component (not shown), multiplied by the Racial Weapon Strength.
3) Damage:  If the component is a weapon, the chance to destroy a target after the armour has been penetrated is Weapon Damage / Hit Points. The damage value is the underlying damage rating of the component (not shown), multiplied by the Racial Weapon Strength.
4) Shots: The number of times a weapon will fire during each ground combat phase
5) CIWS: 'Y' indicates this component is a Close-in-Weapon-System, capable of defending the planet (on which the unit is based) from missile attack. This CIWS will use the values in the CIWS section, which will become visible when a CIWS component is selected. More on this in a later rules post.
6) STO: 'Y' indicates this component is a Surface-To-Orbit energy weapon, capable of engaging ships in space within weapon range of the planet on which the unit is based. The weapon type used for the STO component can be selected in the section to the centre right, which will become visible when an STO component is selected. More on this in a later rules post, although see the second screenshot.
7) HQ: The headquarters capacity of the component in tons. This is the total size of the formation (or formation hierarchy) that can be effectively controlled by a commander based in a unit with this component. To assign a commander to a formation, one of the units within that formation requires a headquarters component. More details on command hierarchies will be provided in a future rules post.
8) FFD: 'Y' indicates this component is a Forward Fire Direction (FFD) component. Forward Fire Direction allows a front-line unit (more on that later) to direct the fire of bombardment units from a formation in a support position, fighters on close air support missions, or ships in orbit. A later rules post will explain this function.
9) Const. The construction value of the component in Construction Factory Equivalents (CFEs).

At the top-right of the window is the Capability section. One or more Capabilities can be selected for the Unit Class. The Boarding Combat capability is required for a Unit to be able to board another ship. For all other capabilities, the Chance to Hit is doubled in the environment specified. If a unit has multiple capabilities, such as Mountain Warfare and Jungle Warfare on a world with a dominant terrain of ‘Jungle Mountain’, the bonus is cumulative (i.e. 4x to-hit in this case). Each capability selected for a Unit will increase the cost by the multiple specified. Some capabilities are only available for infantry units.

In the bottom right section, a summary of the unit is shown in a similar style to the Class Summary for naval designs. When the sizes of all the units in a formation are aggregated, that is the transport requirement for that formation in tons. Cost is in BP. When the costs of all the units in a formation are aggregated, that is the build point requirement to construct the formation. Armour and Hit Points have been described previously. Below that is a list of components, followed by the materials required for construction and the research cost to develop the unit once designed.

I'll cover Formation Templates in the next rules post.



This screenshot shows a static unit with an STO component selected. The chosen weapon (which is any developed for shipboard use) is selected on the right. Spinal Weapons can be selected for ground use with penalty. The STO mount includes the weapon, a reactor of the exact size needed for the recharge rate and a built-in beam fire control with a 4x range modifier. The cost is equal to the static platform, the weapon, the reactor and half the fire control. STO weapons have a 25% bonus to fire control range. The damage shows two numbers, which is the damage at minimum and maximum range.

The following users thanked this post: MarcAFK

3
C# Aurora / Re: Diplomacy Overhaul?
« on: December 09, 2017, 11:52:39 AM »
I haven't started with diplomacy yet but I do intend for it to be more detailed. There will be a lot more clarity from AI players about which systems they consider to be their territory and which are neutral space. They may change their mind about which systems to claim. There will also be warning messages and the potential for negotiated settlements, rather than fighting to the death.
The following users thanked this post: MarcAFK

4
C# Aurora / Re: Replacing PDCs
« on: October 03, 2017, 11:55:28 PM »
I also would like to promote using company as the smallest stack and working up from there through battalion - brigade - division. We can change the ground unit default ranks to Captain - Major - Colonel - General and thus each has a specific level of command to take on. And it means that a battalion can already be a combined arms unit as well as makes the possibility of specialized small units for boarding and asteroid clearing and other similar tasks where you don't want to lug around big forces.
The following users thanked this post: MarcAFK

5
C# Aurora / Re: C# Aurora Changes List
« on: September 17, 2017, 12:12:11 PM »
Ordnance Transfer Orders

With the new ordnance transfer rules, I am changing how some of the ordnance transfer orders work.

The first major change is that a collier within a fleet can be set to automatically transfer ordnance to or from other ships in the fleet. You can flag a collier as being at one of seven ordnance transfer statuses; None, Load Fleet, Replace Fleet, Remove Fleet, Load Sub-Fleet, Replace Sub-Fleet, Remove Sub-Fleet.

When this flag is set to Load Fleet or Load Sub-Fleet, each collier will load ordnance into the magazines of non-colliers within its own fleet (or sub-fleet) as that fleet continues with its normal orders (the transfer itself is not an order). Essentially, the collier will keep the fleet's magazines topped up. The rate of ordnance transfer will be based on the ordnance transfer system of the collier multiplied by the parent race’s underway replenishment tech (unless the fleet is stationary). The missiles being loaded will be based on what is missing from the ship's magazine when compared to the class loadout, starting with the largest missiles first (although smaller missiles will be loaded if there is insufficient time in the sub-pulse to load a larger one). However, missiles will only be added using this order and missiles that do not match the current class loadout will not be removed.

When this flag is set to Replace Fleet or Replace Sub-Fleet, each collier will remove any missiles that do not match the current class loadout and replace them with those from the class loadout (assuming the collier has a sufficient stockpile) for any non-colliers within its own fleet (or sub-fleet) . The collier will remove non-loadout missiles from the target ship while it has magazine space remaining, then add class loadout missiles to create space. Essentially, the collier will alternate loading and unloading as necessary to create the correct loadout.

When this flag is set to Remove Fleet or Remove Sub-Fleet, the collier will unload all missiles from non-colliers within its own fleet (or sub-fleet), as long as it has space to store them.

The current ‘Provide Ordnance to Fleet’ order has been replaced with several new orders to facilitate the above. These include:

Join and Add Ordnance to Fleet
Join and Add Ordnance to Sub-Fleet
Join and Replace Ordnance in Fleet
Join and Replace Ordnance in Sub-Fleet
Join and Remove Ordnance from Fleet
Join and Remove Ordnance from Sub-Fleet

The fleet containing the collier will become part of the target fleet and switch to an appropriate ordnance transfer status depending on the order. You can also use an 'Absorb' order to collect a collier with an existing status set. I may look at adding ship-level conditional orders (rather than fleet) so that colliers/tankers can detach when empty and return home without player supervision.

A new 'Load from Ordnance Transfer Hub' order has been added. This order requires a second fleet containing at least one ordnance transfer hub as the destination. On arrival, any ships in the fleet with magazines will receive ordnance according to their class loadouts until all magazines are full, or the ordnance transfer hub runs out of ordnance. No ordnance will be removed by the hubs. All ships in the fleet will receive ordnance, including colliers. Once completed, the fleet will move on to its next order. If the fleet containing the ordnance transfer hub has any movement orders, the ordnance transfer will not take place and the ordnance transfer order will be marked as completed. Multiple hubs in the target fleet will not increase the rate of ordnance transfer but they can all contribute ordnance.

A new 'Replace at Ordnance Transfer Hub' order has been added. This order functions in a similar way to above except that any ordnance not in the class loadout will be removed by the hubs. The mechanics of this process are the same as the ordnance transfer within fleets above.

A new 'Unload to Ordnance Transfer Hub' order allows colliers to deliver ordnance to the hubs.

The existing ‘Load Ordnance from Colony’ order will remain but can only be used at colonies that have either a Spaceport or an Ordnance Transfer Station. On arrival, the fleet will receive ordnance until all its magazines are full, or the colony runs out of appropriate ordnance. All ships in the fleet will be receive ordnance, including colliers. Once completed, the fleet will move on to its next order. Multiple spaceports or ordnance transfer stations at the colony will not increase the rate of ordnance transfer.

The 'Unload Ordnance to Colony' order also remains but can only be used at colonies that have either a Spaceport or an Ordnance Transfer Station.

Any order involving the transfer of ordnance to or from a colony or ordnance transfer hub will use the current racial ordnance transfer tech to determine the rate of transfer.

Note this means that significantly more planning will be required in this version of Aurora to ensure missile-armed ships can be reloaded at the frontier. It will no longer be possible to dump ordnance on the nearest available rock. Colonies will require a spaceport or an ordnance transfer station before they can support missile-armed fleets. Alternatively, colliers can accompany fleets, or a deep space base with an ordnance transfer hub can be established.
The following users thanked this post: MarcAFK

6
Aurora Suggestions / Re: More secondary commander naming themes?
« on: July 03, 2017, 12:06:23 PM »
A "United Nations" commander theme would be nice to have. The US theme provides some variety, but Chinese, Indian, African, and South/Pacific Asian names are underrepresented there for the purpose of reflecting a world government. The theme-switching suggested previously doesn't seem like it would quite shuffle the deck enough to get a consistent mix rather than small gluts of similar names.
The following users thanked this post: MarcAFK

7
C# Aurora / Re: Release date?
« on: June 01, 2017, 03:52:10 PM »
Still no idea on release date. Hardly did anything in April but back on track recently. I am going to work on missile and turret design next, then probably the new game window. Still not even looked at detection or combat or the galactic map and a lot of the movement orders are not done. However, I am away a lot in June so not much progress then either. My plan is to try to start a test game before the end of the summer, even if a good chunk of the game isn't there yet. Playing will motivate me to fill in the missing pieces :)

In terms of a finished game, my latest guess is late this year or early next.
The following users thanked this post: MarcAFK

8
C# Aurora / Re: C# Aurora Changes List
« on: May 28, 2017, 07:16:09 AM »
Missile Engines

In C#, Missile Engines follow the same size-based fuel consumption rules as Ship Engines using the formula: SQRT (10 / Engine Size in HS)

The above increases the fuel consumption of missile engines based on size alone. However, VB6 also had a flat x5 multiplier for the overall fuel consumption for missile engines as they were treated as a different engine type than ship engines. As C# is aiming for consistency between ship and missile engines, this x5 multiplier cannot remain as it was before. Removing the x5 multiplier entirely would cancel out the fuel consumption increase resulting from the changes in the size-based fuel consumption calculation. As one of the objectives of C# is a reduction in missile ranges, a new rule is required that increases fuel consumption but that is still consistent with ship engines.

Therefore, the calculation for fuel consumption based on boosting engines will now include an additional multiplier if the boost being used is higher than the maximum racial boost tech. Only missile engines have the capability to use higher boosts than the racial maximum, so this still allows consistency between ship and missile engines in the spectrum where they both operate. Once you move outside of the boost range possible for ships, additional fuel consumption can be added without breaking consistency. This rule adds a linear multiplier from 1x to 5x depending on the level of boost beyond the racial maximum. The formula is as follows:

if Boost Used > Max Boost Multiplier Tech then
      High Boost Modifier = (((Boost Used - Max Boost Multiplier Tech ) / Max Boost Multiplier Tech) * 4) + 1;

So if a race has Max Boost Tech of 2x, any missile with a Boost Level of 2x or less will use the standard boost fuel modifier calculation of Boost Level ^ 2.5.

Above a Boost Level of 2x, the linear High Boost Modifier will come into effect, reaching a maximum of 5x fuel consumption at 4x Boost Level.

Here is a comparison between VB6 and C# using MPD engines and an engine size of 1 MSP. The Max Boost Tech for this race is 2x:


VB6 Missile Engine with 2x Boost
Engine Power: 1.6      Fuel Use Per Hour: 81.51 Litres
Fuel Consumption per Engine Power Hour: 50.944 Litres
Engine Size: 1 MSP      Cost: 0.4
Thermal Signature: 1.6
Materials Required: 0.4x Gallicite
Development Cost for Project: 80RP

C# Missile Engine with 2x Boost
Engine Power 1.60      Fuel Use Per Hour 76.8 Litres
Fuel Consumption per Engine Power Hour 48.0 Litres
Size 1.00 MSP  (2.5 tons)      Cost 0.80
Development Cost 80 RP

Materials Required
Gallicite  0.80


VB6 Missile Engine with 4x Boost
Engine Power: 3.2      Fuel Use Per Hour: 922.18 Litres
Fuel Consumption per Engine Power Hour: 288.182 Litres
Engine Size: 1 MSP      Cost: 0.8
Thermal Signature: 3.2
Materials Required: 0.8x Gallicite
Development Cost for Project: 160RP

C# Missile Engine with 4x Boost
Engine Power 3.20      Fuel Use Per Hour 4344.5 Litres
Fuel Consumption per Engine Power Hour 1357.6 Litres
Size 1.00 MSP  (2.5 tons)      Cost 1.60
Development Cost 160 RP

Materials Required
Gallicite  1.60
The following users thanked this post: MarcAFK

9
C# Aurora / Re: C# Aurora Changes Discussion
« on: May 28, 2017, 06:50:29 AM »
With the above in mind, I have added the following to the missile engine fuel efficiency calculation

if Boost Used > Max Boost Multiplier Tech then
      High Boost Modifier = (((Boost Used - Max Boost Multiplier Tech ) / Max Boost Multiplier Tech) * 4) + 1;

So if a race has Max Boost Tech of 2x, any missile with a Boost Level of 2x or less will use the standard boost fuel modifier calculation of Boost Level ^ 2.5.

Above a Boost Level of 2x, the linear High Boost Modifier will come into effect, reaching a maximum of 5x fuel consumption at 4x Boost Level.

Here is a comparison between VB6 and C# using MPD engines and an engine size of 1 MSP. The Max Boost Tech for this race is 2x:


VB6 Missile Engine with 2x Boost
Engine Power: 1.6      Fuel Use Per Hour: 81.51 Litres
Fuel Consumption per Engine Power Hour: 50.944 Litres
Engine Size: 1 MSP      Cost: 0.4
Thermal Signature: 1.6
Materials Required: 0.4x Gallicite
Development Cost for Project: 80RP

C# Missile Engine with 2x Boost
Engine Power 1.60      Fuel Use Per Hour 76.8 Litres
Fuel Consumption per Engine Power Hour 48.0 Litres
Size 1.00 MSP  (2.5 tons)      Cost 0.80
Development Cost 80 RP

Materials Required
Gallicite  0.80


VB6 Missile Engine with 4x Boost
Engine Power: 3.2      Fuel Use Per Hour: 922.18 Litres
Fuel Consumption per Engine Power Hour: 288.182 Litres
Engine Size: 1 MSP      Cost: 0.8
Thermal Signature: 3.2
Materials Required: 0.8x Gallicite
Development Cost for Project: 160RP

C# Missile Engine with 4x Boost
Engine Power 3.20      Fuel Use Per Hour 4344.5 Litres
Fuel Consumption per Engine Power Hour 1357.6 Litres
Size 1.00 MSP  (2.5 tons)      Cost 1.60
Development Cost 160 RP

Materials Required
Gallicite  1.60

The following users thanked this post: MarcAFK

10
The Academy / Re: Population vs Wealth
« on: April 19, 2017, 06:12:59 PM »
I wish financial centers were transportable like other installations are.  Then you could just fill up your terraformed but mineral-less worlds with financial centers built elsewhere, and plunk a wealth bonus leader on them.  Pretend the whole planet is a giant call center, cold call selling products made elsewhere to markets all over your empire. ;)

I can see it now...

"Sir! The invading aliens have scoured Telemarketing II to bedrock!"

"Well, they should have abided by the No Call List."
The following users thanked this post: MarcAFK

11
Aurora Chat / The GRAND AURORA TOURNAMENT
« on: April 03, 2017, 02:55:49 AM »
Not sure where else to put this, but. . .

Attention all Fleet Designers and God Emperors of Mankind!

Getting tired of the same old enemies? Want to see how your fleet ACTUALLY compared against other people's? Well then now's your chance!

Within the next 2 months, I will be running the (to my knowledge) first ever Grand Tournament for Aurora 4X.  All are welcome, see the rules below:

All competitors will have a certain amount of BP to spend (to be decided in a few days).  You don't have to spend it all, but you are not allowed to go over.
The competition will be in a standard Sol system.
Tech levels available to each competitor will be posted along with the BP limits soon.
Each competitor can select a system body to serve as a supply base - this base will have unlimited (will possibly change) fuel, ammunition and supplies, but no other structures.  If you build a PDC on it, the cost comes out of your BP budget.  Your fleet will also be spawned from there.
Each competitor will know the general direction of the other player's base at the start of the match (though this may change due to orbits).
I will operate the game and stream (if I can work out how without giving away info, otherwise just record instead)/report events to their respective players.  A neutral party will do this for matches I am involved in.
Cheesy ship designs and combos (such as chained tractor beam ships), or things that exploit known bugs and issues will not be allowed - specific semi-cheesy mechanics may be allowed, ask in the comments if you're not sure.
Finally, all competitors must have fun!

Rewards will be the satisfaction of domination and victory over the competition, unless someone wants to pitch in something more material.

Comment if you're in and watch this space for more information over the next few days!
The following users thanked this post: MarcAFK

12
Mechanics / Re: Bridge Officers
« on: March 12, 2017, 11:57:16 AM »
What if the bridge would become an automaticly scaling component like armor, changing size dependent on size of the vessel or the amount of crew members onboard?

Or the other way around, bonuses provided by officers are divided by vessel size or number of crew members. To compensate, one could install more bridge space, therefore providing space for more officers, whose bonuses add up? That way, huge battleships would house dozens of officers, and tiny ships just one, but on average, one officers gives bonusses to the same mass of ship.

I am going to add Auxiliary Control, Main Engineering, CIC, Primary Flight Operations and Science Department as new modules. Each one makes a different officer available to be recruited to the ship (XO, Chief Engineer, Tactical Officer, Commander Air Group and Science Officer) and will add 1 to the Control Rating of the ship. These requirements add the effect of larger control spaces while maintaining some variety. An officer can be killed if his station is damaged. I may also add 'temporary promotions' if the commander is killed, with the most senior surviving officer taking over as commander until relieved or promoted. The modules will also affect the minimum commander rank for the ship.

I am also going to change how certain bonuses are applied. The commander of a ship will only apply half his bonus for Crew Training, Survey, Fighter Operations, Engineering (new skill) and Tactical (new skill), with the appropriate officer applying his full bonus. The commander of the ship is now a jack-of-all-trades, applying a portion of his bonus while the specialists provide the larger bonuses. Larger ships gain an advantage as they can afford the space to accommodate the specialists, while smaller ships have to make do with the commander handling everything (at half efficiency).

A bonus from the Chief Engineer will only apply if Main Engineering is undamaged. A bonus from the Science Officer will only apply if the Science Department is undamaged. A bonus from the Tactical Officer will only apply if CIC is undamaged. A bonus from the Commander, Air Group will only apply if Primary Flight Operations is undamaged. Bonuses from the commander and XO will only apply if the ship has a control rating greater than zero (they can command the ship from any of the surviving control spaces).

If this works OK, I might add other officers in the future and modify other bonuses in the same way.
The following users thanked this post: MarcAFK

13
Engine secondary explosion strength is random between 1 and 25% of engine power.
The following users thanked this post: MarcAFK

14
C# Aurora / Re: Aurora C# Screenshots
« on: December 16, 2016, 07:22:45 AM »
I think it's about time for some more screenshots soon. How about an early Christmas gift for us in the form of a few Screenshots or update?  :)

I've been working on mainly back-end code, movement orders and system generation recently. I've successfully tested the exploration of an unexplored jump point, although full system generation isn't done yet. Should be finished over Xmas though.
The following users thanked this post: MarcAFK

15
C# Aurora / Re: C# Aurora Changes List
« on: October 06, 2016, 04:05:08 PM »
Standard transits by Fleets with Commercial and Military Ships

In VB6 Aurora, fleets that included at least one ship with military engines could only use military jump drives for standard transits, which meant you had to split out commercial-engined ships into a separate fleet and escort them with a commercial jump drive ship.

In C# Aurora, commercial-engined and military-engined ships are treated separately. So if you have a fleet with mixed engine types that also includes ships with commercial and military jump drives, it will still carry out a standard transit if the respective jump drives are large enough for the ships with the matching respective engine types. However, if any ship with either engine type can't jump, the whole fleet will fail to transit.

Squadron jumps are handled differently so I will cover that in a separate post.
The following users thanked this post: MarcAFK

Pages: [1] 2 3 4