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 - Steve Walmsley

Pages: [1] 2 3 ... 23
C# Aurora / Re: C# Aurora Changes Discussion
« on: Today at 05:09:52 AM »
The risk is that the complexity of porting the existing rule set to C# combined with the complexity of changing the rule set leads to a more complex overall task.   Trying to combine the two goes against most modern philosophies of good software engineering practices.  I personally think this has been demonstrated with the ground combat stuff:  Steve was chugging along through the various functionality sectors until he got to ground combat, at which point my perception is that the progress got bogged down.  Some data: the original "I am seriously considering removing PDCs" post was on Sept 17, 2017 (on page 70 out of 93 in this thread), so he's been on ground combat  for four calendar months and 25% of the posts in this thread, which is probably more time than it would have taken if he'd simply transcribed PDCs and ground combat.

A more telling example of the "change while transcribing" failure mode: the Pulsar 4x project seems to have fallen prey to this it.  My recollection/perception is that they started out wanting to do a straight port of Aurora to C#, but figured "why not improve the game mechanics along the way".  They seemed to have bogged down about halfway through; I haven't seem much activity from them at all for the last year or two. 

That being said:

1)  Steve is good at this stuff (writing Aurora); he's been doing it for many years.
2)  Ground combat IS an isolated system, so he can code it up and get out of it.  In general, Steve seems to be doing a really good job of doing minor and isolated tweaks to systems as he codes them up (e.g. the refueling changes), so that he's doing "transcription with cleanup" as he goes, rather than "write a whole new game".  In other words, I think he's mostly been striking the right balance.
3)  Steve's already written one game (VB6 Aurora) and gotten it to completion, which demonstrates the tenacity and ability to complete the job, so there's a good chance he'll complete C# Aurora too.
4)  (Most important) It's Steve's free time, so if he wants to spend it working out ground combat mechanics before getting a playable version of Aurora out then that's his prerogative.

So I suspect the ground combat stuff has probably slipped the schedule by a month or two, but if that's what Steve wants to do that's his choice.  Hopefully this is the only sector for which he's planning a major rewrite, and he can get back to straight transcription to get a working version out.  If not though, c'est la vie.


I think the Ground Combat changes will probably delay completion by 3-4 months, more due to deciding exactly how to implement them than the actual coding. The ground combat design is mainly done now and a decent chunk of the coding is done. I still need to code the interactions between ground units and naval units (including new movement orders) and the logistics. As mentioned above though, this is a relatively isolated area so doesn't impact the rest of the game too much. On the plus side, ground combat was a very basic area compared to the rest of the game and I think the changes will make it much more interesting and immersive (from an RP perspective as much as a mechanics perspective)

I'm taking a break from ground combat at the moment to code the New Game window, with the intention of starting some test games. There are still some significant areas missing, including combat, AI, default/conditional orders, about half the movement orders and many of the minor windows. However, almost all the construction phase code is done (research, terraforming, production, maintenance, etc.) and most of the common movement orders, so I hope to start the first of those test games in the next month or two and then code the rest while playing.

I am moving house in the next couple of weeks, so that will slow things down a little, but should be up and running again fairly quickly.

I am well past the point now where I think there is a question of whether C# Aurora will eventually be finished. This isn't similar to early abortive attempts at Newtonian Aurora and Aurora 2. I have invested almost two years into this project (from March 2016) so I am pretty determined to complete it :).  I can't say when yet but the prospect of getting a new campaign running is my main motivation.
The following users thanked this post: froggiest1982, chrislocke2000, QuakeIV, Viridia, jonw, waffel, King-Salomon

C# Aurora / Re: C# Ground Combat
« on: January 14, 2018, 07:36:03 AM »
How far up does the chain of command go now? Do we finally have four tiers to make use of all four army officer ranks?

As far as you want. There are unlimited army ranks now and nine different HQ sizes.
The following users thanked this post: ChildServices

C# Aurora / Re: C# Ground Combat
« on: January 13, 2018, 05:03:09 PM »
Thanks for all the feedback on the proposed interactions between fighters and ground combat. I think I have now found a good way to make this work.

A new component, the Fighter Pod Bay, is similar in function to a small Box Launcher, except it will only hold Fighter Pods (see below).

Fighter pods are created on the Missile Design window. The various pod options, such as bombardment pod, autocannon pod and air-to air pod, will appear when the requisite technology has been researched. When one of those options is selected, the warhead strength field is replaced by a pod size field. The player can choose the pod size, with larger pods being more effective. The pod capabilities will be similar to the capabilities of equivalent-sized ground unit components, although the fighter pods have more flexibility in design. For example, a bombardment pod will have three shots, armour penetration equal to Racial Weapon Modifier * ((Tons / 20) ^ 0.6) and damage equal to Racial Weapon Modifier * ((Tons / 20) ^ 1.6).

Fighter pods are ordnance, in exactly the same way as missiles. They are built by ordnance factories, transported in magazines and loaded onto fighters. Unlike missiles, they are not expended when fired and will function during ground combat phases.

A fighter can be designed with fighter pod bays. Different pods can be assigned to those bays while the fighter is in a hangar, providing flexibility of loadout. The same fighter could be used for bombardment or autocannon pods, as long as the pods bays are large enough and the parent carrier has both types of pods available. The pods can be assigned to the fighter using the normal ordnance loadout.

Pods can also be assigned to normal box launchers, so a fighter designed for space combat can also be used for ground combat in an emergency. However, box launchers are three times larger than the missiles (or pods) they are designed to fire, while fighter pod bays are equivalent in size to the pods, making fighter pod bays are a much more efficient way to mount the pods. Because of this efficiency and no requirement for fire controls or sensors in ground combat missions, dedicated ground support fighters can be much smaller than their space combat equivalents. It is also possible to have hybrid designs mounting both pods and box launchers. Due to the requirement for smaller engines for dedicated ground support aircraft, ship engines can now be designed from 0.1 HS in size.

The following users thanked this post: Person012345, El Pip, Barkhorn, Xtrem532, Rye123

C# Aurora / Re: C# Aurora Changes Discussion
« on: January 07, 2018, 02:26:27 PM »
For what it's worth I entirely agree with Steve on this.

Planetary warfare is a completely different beast then galactic warfare.  In small thinking, it does not matter if you do have the best aircrafts in the world if you not able to take ports or structure on the ground with as effective troops.  This option will bring an actual different thinking level while planning invasions.  My guess is AI will use different formations and doctrines as well therefore just drop unit or bombard a planet will not guarantee your success like it was pretty much done with the old system where only a few units were available.  @Steve Walmsley sorry to bother you, but are you also thinking to introduce some sort of exhaustion to ground units? I've seen the terrain modifiers, but I believe a sort of exhaustion factor will simulate the logistic/supply penalty of long wars with the possibility of introducing an engineer or logistic division able to mitigate such effects adding an extra layer of strategy/planning.  Basically, these units will provide the required supplies to carry on daily operations.  The possibility of having these units "mandatory" (not only for invasions but pretty much used as maintenance supply works for warships) will probably make it easier to program rather than a separate mechanism which I guess will be hard for you as for anybody to set up.


There will be some form of logistic units. I've been holding off on exactly how they work because of issues around tracking supply point usage but it finally struck me how to do it. Each logistic unit (probably static base type) will use up a set amount of maintenance supply points (MSP) during creation. When combat takes place, each side will use up a certain amount of MSP (to be determined) during each combat phase, based on that type of units engaged.

Lets assume that each logistic unit includes 100 MSP. If combat consumes 230 MSP that would use up two logistic units with a 30% chance of a third unit being consumed. Over time, that will work out fine with no record-keeping needed. If no logistic units remain then combat will become far less effective (major penalty to hit, or perhaps no offensive fire at all). This will give an incentive to land a number of logistic units with the initial invasion, plus the potential for resupply runs against hostile defences.
The following users thanked this post: froggiest1982

C# Aurora / Re: C# Aurora Changes Discussion
« on: January 06, 2018, 08:08:11 AM »
not optimal but ... ground combat with all the detail the new design mechanic opens up will be highly complicated, a system wich Steve has a lot time to invest but proofs to be "the same as before", too complicated, too one-sided, too broring or too stressful etcpp would be lost time and even more unsatisfying as it would be "lots of work with nothing gained" ... better to make it workable  for the moment and plan to make it "really work with all the details" and rightly planed in C#1.1

Part of the reason for the more detailed ground design process is to give players more investment in, and attachment to, their ground forces. Other reasons includes creating more interesting invasion mechanics at a strategic level, replacing PDCs, having more interesting planetary environments and making planets harder to conquer. It isn't primarily about detailed combat mechanics at the same level as naval combat. They mechanics need to give the player some consequential decisions during combat and be heavily influenced by the player's strategic design choices. There is quite of lot of detail during combat resolution, with the various factors influencing the to hit role, but most of that happens after the player makes his decision.

The following users thanked this post: Person012345, Rye123

C# Aurora / Re: C# Aurora Changes Discussion
« on: January 05, 2018, 09:27:19 AM »
- Finally on the aircraft position have you given any thoughts to giving forces an air cover status and having bonuses / penalties based on air cover level. Ie covered, contested, unprotected, air superiority. Aircraft should have specific orders to attack other aircraft, defend or attack surface to air units. Clearly if you loose air cover you should be at a penalty on deployment and also should allow better intel for the force with air superiority.

There will be different fighter missions, including ground support, air superiority and flak-suppression.
The following users thanked this post: chrislocke2000

C# Aurora / Re: C# Aurora Changes Discussion
« on: January 04, 2018, 06:19:20 PM »
Steve can I make a suggestion that defender fires first. This would lead more into the idea that an attack tends to take more losses and needs a higher ratio of troops to take the ground.

Also will you give the option to go guerrilla, this basically take away all heavy equipment and the attacker has a much harder time, completely destroying these units. The opposing force captures the planet. But what it allows is time for reinforcements to come back and these units reconstituted with experience if they survive.

Also steve, how long do you expect to say a 10 Division v 5 Division fight to last. 1 year or like it is now like 3 months, I would like to see longer fights, to give reinforcement and supply issues, a chance to influence the battle. And can there be a small trickle to the defenders from local population for reinforcements.

Defender firing first shouldn't be necessary. Fortifications will give a huge advantage to a well-established defender.

Length of fight is a very good question. A lot will depend on the base chance to hit before any modifications, plus the frequency of the ground combat phases. I would like to have combat phases more frequently then the construction phase, so that there is interaction with fighters and orbital fire support. I am leaning toward 5-10% for the base chance to hit. I need to run some scenarios to see how that turns out. I want to avoid the VB6 situation where it can take weeks to eliminate a massively outclassed defender, although if that defender has fortifications in good terrain it should take a while. However, I also want to allow for longer sieges where the sides are relatively evenly matched.

One formation type I am considering is guerrilla, where they do little damage but are difficult to kill and cause unrest.
The following users thanked this post: MagusXIX, DIT_grue

C# Aurora / Re: Replacing PDCs
« on: January 04, 2018, 05:53:34 AM »
really cool screenshot  ;D

maybe I have my math wrong but what got me irritated:

a construction factory costs 150 BP - the quivalent in Construction Vehicle 127 BP

1 factory has a cargo space of 25.000t - 2,5 factories in Construction Vehicles without security have a cargo space of 8.000t = 3200/factory

1 factory needs 50k population - Construction Vehicle needs 0 population...

I guess if these numbers would stay that nobody would ever again build factories after he got TN-industries running, only ground unit facilities and construction Units (cheaper after you have the facilities running, 7,8x more mobile, no population need)...

"I've settled on 150t for a Construction component" does not sound like a "dummie number" - so maybe I have an error in my thinking  ??? ???

A construction factory is 120 BP, not 150 BP.

Yes, it is less space to transport construction vehicles than installations, but you need troop transport bays rather than cargo bays. A 100 HS cargo bay is 12 BP, compared to 80 BP for the same size troop transport bay. Also, you pay 12.5% maintenance per annum on ground forces so after 10 years the equivalent construction vehicles will cost double the construction factories. Finally, it is a lot easier to build construction factories than construction vehicles because they can build themselves.

The main advantage of construction vehicles is they are immediately available without the need for supporting population, so despite their higher cost they are more convenient.

The following users thanked this post: King-Salomon

C# Aurora / Re: Replacing PDCs
« on: January 03, 2018, 07:03:11 PM »
Quick screenshot showing a formation template for an Engineer Regiment. I've settled on 150 tons for a Construction component, with a build capacity equal to 1/20th of a construction factory. A vehicle base type can hold two construction components for a cost of 12.72 BP for a vehicle with 0.1 Construction Factory Equivalents (CFE). Ten such vehicles would cost 127.2 BP and be the equivalent of one factory.

In this case, the formation has the equivalent of 2.5 construction factories, plus a small security detachment. Alternatively, small numbers of construction vehicles could be included with headquarters formations or even combat units to provide a small inherent construction capacity.

I've also updated this tab to combine components into a single column and add a preferred target type column. I'll update the rules post at some point with the new screen.

The following users thanked this post: MagusXIX

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: Laurence, Demonides, MarcAFK, Viridia, Tristitan, serger, xhunterx, Rye123

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: Laurence, waresky, Demonides, MarcAFK, Hydrofoil, Viridia, Tristitan, xhunterx

Aurora Bugs / Re: Official v7.10 Bugs Reporting Thread
« on: December 28, 2017, 12:51:07 PM »
My main campaign now (85 years) is stuck with "Error in MoveToClosestItem, Error 9, Script out of range".  I had already cancel everything (industry, normal and conditional orders) without success.  Using a previous backup and just passing days end in the same problem.

Something like:

The best shot to solve is:

Is it possible to share the magical powers to look and change NPR fleet orders?

I've sent the password by private message.
The following users thanked this post: sisso

C# Aurora / Re: Replacing PDCs
« on: December 28, 2017, 12:41:38 PM »
Really great screenshots :D thanks a lot :)

some weeks ago I was sceptical if the time was worth to chance the ground-combat system so radical but since them I am convinded :) :)

some minor points I thought about as seeing the screenshots (and not something with a high priority):

1) would it be possible to colour-code some of the data you see to help to get a quick overview what is good and what is bad?
f. e.  in the Commanders View something like "excelent Health" or a high Skills color-coded as green, Bad Health as red?  I am a fan for UIs which give you as much info as possible on 1 view and relly good or bad things would be great to highlight

2) The Commanders personal History at the right top box: it is written in chronological order from  buttom to top but if there are 2 Actions at the same day (29. Nov 2109 Relieved from Command and new Assinement) it is the other way around - which is no big problem but a little strange to read the history and the new assignement is before he is relieved from his old duties).  Just the question if it is possible to get the relieve part happening before the new assignement part in chronological order

3) will the "location" of a commander be of some importance in C#? or will it be possible to "teleport" commanders as teammembers or to bew assignements as in VB atm?

Some other points which I thought about tonight:

A) with the new Ground Unit System you will have a lot of sub-units - each of the sub-units able to be moved on it's own.

Let's say you have 1 Division like your example Division on a planet - that are 3 Brigades á 12 Subunits = 36 Units with only 1 Division - if you now what to transport 3-4 sub-units you have to go through a long list at the Ship-order menue to find the units -. -
worse: if you want to be sure that the Units belong to the same Brigade you have to name them so that you will identify the parent unit or have to flip between screens to write down which sub unit belongs to which parent to make sure you transport the right sub-unit. . .

now I am thinking what kind of namelist you have with 3-4 Divisions an one place with over 100 subunits on a planet. . .

will there be a system to make unit-transport easier that it is atm? color-coding, sub menues, etc? or would it be possible to get a OOB-like list at the transport-order-menue?

Sorry but I was playing VB in the evening and was thinking about the trouble with lots and lots of sub-units -. -  - long lists of names are hard to read most of the times without some "help"  (same with the list with all the jump-points, colonies, planets, moons etc when you select a destination for an order. . . )

B) with all the new Ground-Commanders you might need - would it make sense to split the Academy in 3 Installations? Naval-Academy, Army-Military-School, University - with 1200 costs each? I know you said you have thought about it Steve and came to the conclusion that it is beter to stay with 1 installation - but I guess that was bevore the Ground-Units chanced so massivly - I guess REALLY specialisation of Academys would be helping a lot (and would be logical from the Fluff-side to give each part of the military and the civis it's own Academy) - The ability to give an Academy a Commander is great - but to slit it up in it's own in addition to giving it Commanders would be nice to have I guess.

1) History order is fixed for C# Aurora. The orders shown in the last screen shot were generated in VB6 Aurora.
2) Commanders have a specific location when they are assigned. Otherwise, they teleport around.
3) I've changed the name text to orange for commanders with poor health and red for those with very poor health.

Ground Forces
1) If by sub-units, you mean formation elements (60 x Tank for example), they cannot move independently.
2) Formations appear on the Fleet Orders menu in their command hierarchy, so they should be relatively easy to find (and that doesn't include element level). You can select a formation and order the fleet to load that formation and all subordinates formations with a single order
3) You can assign Commandants to Academies, which allow them to specialise in different types of officers and bonuses
The following users thanked this post: Robbie, King-Salomon

C# Aurora / Re: Replacing PDCs
« on: December 28, 2017, 06:48:14 AM »
On the Formation Templates tab, there is a now a rank column. This is a default set by the programme as a suggestion for that template, based on your racial rank structure. You can override this using the Change Rank button. When a formation based on that template is constructed, its required rank will be the same as the template, although it can be overridden later (see below).

The Order of Battle tab has gained new columns: AR = Assigned Rank, RR = Required Rank. Assigned Rank is the rank of the officer currently assigned to that formation. Required Rank is the rank that will be used by Automated Assignments to assign available officers to that formation. The Required Rank is initially based on the template that was used to construct the formation, but a new one can be assigned by the player. In this case, the 3rd Tallarn Raiders has been assigned a required rank of Lieutenant Colonel.

On the Commanders window, the required rank of the formation is used when displaying potential commanders. The 3rd Tallarn Raiders now requires a Lieutenant Colonel in this view. The greyed out formations already have commanders assigned. If desired, you can assign any commander to any formation. However, as commanders only benefit from the bonuses of superior officers, it will be more effective to stay within your desired command structure. Also, note there are now more ground force ranks. You have the same flexibility now as naval ranks.

In this screenshot, a brigadier has been assigned to the First Tallarn Raiders. The First Imperial Guard Brigade is still using the default, rather than a player-assigned rank, so it accounts for that by making the required rank a Major General, superior to the brigadier in the subordinate formation.

The following users thanked this post: mtm84

C# Aurora / Re: Replacing PDCs
« on: December 26, 2017, 07:27:42 PM »
First screenshot of the Order of Battle tab on the Ground Forces window. This tab helps you view and organise your ground forces. It isn't complete, but has enough functionality to demonstrate the level of detail available. While this screenshot represents a fairly standard OOB, there is a lot more flexibility than VB6 Aurora. You can add more levels in the hierarchy and attach formations directly to Division or higher command levels without having to go through lower levels. I'll show that in a later post.

This is the most basic view, where a single, lowest level formation has been selected. The top line on the right shows a summary of the entire formation, while the formation unit list shows how that summary breaks down in the constituent elements. Each element has a number of specific unit class. Morale functions at the element, rather than formation, level.

Formations, or groups of formations, can be dragged and dropped within the hierarchy, so it is very easy to rearrange the order of battle.

When you click on a higher level formation, with attachments, much more information becomes available. The formation selected is shown as above, but also the the high level summary of any directly attached formations. The total organisation is the total for the current formation, plus all formations below it in the hierarchy.

As before, there is a breakdown of the elements of the current formation. That is now accompanied by a summary of all units within the hierarchy headed by the selected formation.

Now we move up another level. A summary of the formation selected is shown as below, plus the high level summary of the directly attached formations. However, those directly attached formations also have attached formations so each summary contains the complete hierarchy for each directly attached formation. The total organisation is the total for the current formation, plus all formations at any point below it in the hierarchy.

When Location Hierarchy is selected, the tree view expands to include systems, populations and ships. Units remain in their organisation structure but are now split between different locations. In this view, the summary and organisational lists only include formations within the same location. For example, the selected Third Imperial Guard Brigade has only two of its subordinate formation on Avalon and two on Barnard's Star-III. The summary and organisation list show just those two subordinate formations. Switching between the two views will allow the player to manage his organisational structure while being able to easily see where his formations are located.

Selecting a population shows a summary of all the forces at that location.

More to follow...
The following users thanked this post: Garfunkel, JacenHan, mtm84, Shiwanabe, serger

Pages: [1] 2 3 ... 23