Recent Posts

Pages: [1] 2 3 ... 10
C# Aurora / Re: C# Aurora Changes List
« Last post by Steve Walmsley on Today at 11:19:29 AM »
Ground Support Fighters

Fighters equipped with fighter pods can provide support to ground unit formations during ground combat.

To be eligible, a fleet with fighters is given an order to "Provide Ground Support" with a friendly population as the destination. This order functions in a similar way to a 'Follow' order, with the order remaining in place until removed by the player. On the Ground Combat Window, eligible fleets appear in their own section for each population. These fleets can be dragged and dropped on to formations in the same way as superior and subordinate formations. Fleets with this order that are at their target population cannot be targeted in normal naval combat or by STO weapons.

In combat, the ground support fighters attack at the same time as bombardment elements and have the same target selection as medium / heavy bombardment.

Ground support fighters have the same chance to hit as ground units, although they are not affected by any negative environmental modifiers (such as high gravity or extreme temperatures). Each fighter's to hit chance is affected by its own crew grade and morale.

Each Forward Fire Direction component in a formation allows support from up to six ground support fighters. If more fighters are assigned to a formation than can be supported, the chance to hit is modified by (Number of FFD * 6) / Number of Fighters.

I will edit this post with details of anti-aircraft fire once the code is completed.

C# Aurora / Re: C# Aurora Changes List
« Last post by Steve Walmsley on Today at 07:05:33 AM »
Fighter Pods and Fighter Pod Bays

In C# Aurora, fighter-sized ships can be equipped with a new component, the Fighter Pod Bay, which 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. The pods require a missile fire control to operate, although this can be minimal size (0.1 HS) as there are no range or resolution restrictions.

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, the minimal-size fire control and no requirement for active 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.

Other Games / Re: StarLords3k
« Last post by QuakeIV on Yesterday at 11:20:17 PM »
This has started up again, for anyone who is interested.
C# Aurora / Re: C# Ground Forces Composition
« Last post by Bremen on Yesterday at 08:02:09 PM »
Although it'd be nice if we could have a way to find STO units from orbit before they fire.

I actually think it would be kind of fun if you couldn't. Would add a reason to use ground troops instead of planetary bombardment against a planet, and the game could use more of those.
C# Aurora / Re: C# Ground Forces Composition
« Last post by Hazard on Yesterday at 04:09:03 PM »
IIRC STO units benefit from Fortification bonuses, so there's no need to wait on the enemy to get close if they're fortified enough. Likewise, you can do a 'general bombardment' of the planet even without any specific targets and maybe hit some important defense units, but for actually effective orbit to surface fire you need FFDs or STO units actively firing at your fleet.

Although it'd be nice if we could have a way to find STO units from orbit before they fire.
C# Aurora / Re: C# Ground Forces Composition
« Last post by DEEPenergy on Yesterday at 02:55:30 PM »
Something that lightly armored mass infantry is really good at - policing planets after you've conquered them. IIRC unrest suppression is based on the amount rather than the quality of troops.
C# Aurora / Re: C# Ground Forces Composition
« Last post by TCD on Yesterday at 02:19:01 PM »
I agree. And just because I know that super heavy vehicles aren't the absolutely most efficient strategy doesn't mean I'm not going to build an army of ATATs. They just have to be viable enough.

The other detail I think still needs answering before you can decide on ground force composition is how ground forces even get onto the ground. It looks like we could potentially have large numbers of STO units, potentially with very heavy weapons. Do you wait until you've destroyed all the enemy STOs before attempting a landing*? If so presumably you can use large transports and any combination of mixed forces you want.

But if you're aiming for a contested landing then you may need to use an overwhelming number of smaller transports, and only infantry and light vehicles. And you probably need to accept heavy losses in the landing. So presumably whatever you land needs to be an all rounder. It would be very sad to only have support units survive the drop!

*Does anyone know if it will be possible to target STOs before they fire? Because if not you might be tempted to build some plasma cannonade STOs and keep them in reserve until the enemy heavy troop transports are 5s out.
C# Aurora / Re: C# Ground Forces Composition
« Last post by Father Tim on Yesterday at 01:22:57 PM »
What it sounds like to me is that there will be no "one right answer" -- which makes me very happy.  One of the things that annoyed me about Starfire was the "BC(R) problem" -- the combination of size, speed, and firepower meant that everyone built capital-missile armed battlecruisers that were pretty much the same design.

I look forward to building my historical-themed armies and watching them clash with some AI formations.
C# Aurora / Re: C# Aurora v0.x Suggestions
« Last post by MasonMac on Yesterday at 11:50:33 AM »
That reminded me of Halo
Quasar4x / Re: Quasar4x - An early look at an Aurora4x clone in the works
« Last post by Kyle on Yesterday at 11:24:55 AM »
Hello!  So I've been working on Q4X for a couple hours already this morning, and have been every day since my last update (!) and began to feel a little overwhelmed (that happens a lot with this project, go figure, right?)  so I figured hey why don't I take a break and write a progress report?  That should help me regain perspective on how much I'm accomplishing, so here's my progress update for 2018-09-21

No screenshots again.  Mainly just to save time and get back to coding, but also there's nothing milestone-y to show, just a lot of misc. stuff.  Next time I promise I'll have some.  I will just list what I've done since my last post:  (Kinda wish I'd done this for my previous post, the list would be about as long)

Main Menu:
- calculations > loadout calculation
- calculations > dice rolls
- empires > ammo transfer (layout only)
- empires > order of battle
- empires > class deployments
- empires > transfer system knowledge (layout only)
- empires > foreign aid (layout only)
- empires > linked everything that opens a window that you can open from the F3 screen
- Add rank
- delete rank
- rename rank
- retire commander
- rename commander
- auto rename commander
- reorder seniorities
- potential assignments list
- grant title
- pp rules
- create medals - new medal
- create medals - select medal image from disk
- create medals - list
- create medals - name, prom value, and description
- create medals - save changes
- award medal
- graphics in Medals Awarded pane

Still a lot more to do in the commanders window.  When you take into account that the Award Medal, Create Medals, Commands, Vacancies, and Highly Rated buttons all open up new panels with their own batch of controls, there is actually a *lot* going on in the Commanders window.  Lots more to do in the Main Menu too, but I'm done with it for awhile.

Why focus on main menu / commanders in particular?  No major reason, but I do have a well-defined objective of replicating everything that A4X does, so it's gotta be done at some point, so might as well.  The items I do first are things that don't depend on other things being done -- the Race window, System view, Commanders window, and portions of the Main Menu are well encapsulated areas that can be completed with minimal knowledge or dependency on other areas of the game.  (As compared to, say, "Ships Requiring Repair" which requires me to have some ships first, and then damage them)

I think next up will be the Colony Summary window and its 12 beefy sub-tabs (eep!) at least the portions that are relevant on turn 1.  But before that I'll need to implement having multiple empires in a single game, and the mechanics that go into "logging in" to particular empires.  Additionally I'll need to add support for going between two different games rather than requiring a restart -- since A4X supports that, I gotta too!  Once I finish the Commanders window though, I'll publish a new build in case anyone wants to play a pointless micromanage-the-commanders minigame. ;)
Pages: [1] 2 3 ... 10