Post reply

Warning - while you were reading 12 new replies have been posted. You may wish to review your post.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

shortcuts: hit alt+s to submit/post or alt+p to preview

Please read the rules before you post!


Topic Summary

Posted by: AlStar
« on: Today at 01:05:42 PM »

Exactly like that!  ;D

Although (IMO) it'd be better if Steve integrated that functionality into the game itself, so we don't have to use a 3rd-party solution.

Maybe build it into the events tab - clicking on an event will let you change the text/background color (as now), and if it does/doesn't cause interrupts.
Posted by: skoormit
« on: Today at 12:37:49 PM »

...a screen that lists all events, and has a checkmark for "does this stop time? y/n" would be ideal (although probably a lot more work than I'd expect.)

Even better if the screen lets us import/export our preferred interrupts.

Like this?
Posted by: AlStar
« on: Today at 08:49:35 AM »

It would be nice to be able to toggle a checkbox on the fleet orders screen to control if finishing shore leave stops auto-turns.
To build on this, a screen that lists all events, and has a checkmark for "does this stop time? y/n" would be ideal (although probably a lot more work than I'd expect.)

Even better if the screen lets us import/export our preferred interrupts.
Posted by: vorpal+5
« on: Today at 08:00:50 AM »

And on the contrary (sorta...) entering overhaul will halt the time interval. Is it that important?
Posted by: skoormit
« on: Today at 06:42:34 AM »

The Shore Leave Complete event does not stop auto-turns.
Usually, that is my preference.
Sometimes, though, I am waiting for a ship to complete shore leave before I give further orders.

It would be nice to be able to toggle a checkbox on the fleet orders screen to control if finishing shore leave stops auto-turns.
Posted by: paolot
« on: May 11, 2024, 08:27:48 AM »

I am liking the capacity of stabilization ships.
To further improve their value/ability, and have more Lagrange Points in a system, in Standing Orders would it be possibile to include the orders "Build Jump Gate at Nearest Terrestrial Planet", "Build Jump Gate at Nearest Gas Giant" and "Build Jump Gate at Nearest Superjovian"?
I think that a general order only (i.e. "build JG at nearest massive planet") would be limiting.
Instead, using these three ones, we can choose where to build new LPs, to have faster ships around.
Posted by: skoormit
« on: May 09, 2024, 12:03:28 PM »

Does the issue resolve itself after a time increment? (Theoretically) as long as you've got "use max speed" checked, the fleet should speed back up to max speed once they get underway.

I've seen similar display issues when giving orders to tugs that had dropped off terraformers - their orders will give an ETA that's based on their laden speed, but they'll actually get there much faster.

Negative.
The issue persists after time is incremented.
Move orders given to such a fleet will be undertaken at 1km/s.
Posted by: AlStar
« on: May 09, 2024, 09:46:11 AM »

Does the issue resolve itself after a time increment? (Theoretically) as long as you've got "use max speed" checked, the fleet should speed back up to max speed once they get underway.

I've seen similar display issues when giving orders to tugs that had dropped off terraformers - their orders will give an ETA that's based on their laden speed, but they'll actually get there much faster.
Posted by: skoormit
« on: May 09, 2024, 08:49:42 AM »

Merging fleets with tugs can be problematic.

Say Fleet A has one or more ships with a tractor beam, and all these ships are tractoring engineless ships.

If Fleet A executes an order to join some Fleet B (which may or may not also have ships with engaged tractor beams), then sometimes (not always) the speed of Fleet B drops to 1km/s.

If I drag Fleet A into Fleet B, same thing happens: sometimes (not always) the speed of Fleet B drops to 1km/s.

The only way to reliably join the fleets without reducing the speed of Fleet B to 1 km/s is to individually drag the tractors from Fleet A to Fleet B in the left hand tree view.
(Dragging this way automatically brings the tractored ships along.)

Obviously, this can be very tedious for large fleets, and can only be done when the fleets are in the same location.
And it means that you just can't use the Join Fleet order when tugging ships.
And I do a *lot* of tugging, so this adds a lot of micromanaging to my playtime.

I'm hoping there's something easy to tweak in the fleet merging logic that can resolve this.
I wonder if the resulting speed is being determined by iterating through the list of all ships, which might be in ascending order of ship construction time, and it doesn't recognize that a ship is tractored unless the tractor has already been processed.

Note: I don't know if the situation only occurs when engineless tractors are targeted, because I only very rarely tractor ships with engines.

Other note: the same thing happens when detaching subfleets with tractors from fleets. Sometimes the newly detached fleet has a speed of 1km/s. Perhaps the same code is handling this as well.
Posted by: Steve Walmsley
« on: May 08, 2024, 04:45:21 AM »

In the Environment tab, together with the Annual Terraform capacity, I would like to read the number of the Terraforming Istallations active on (or near) a body.

Added for v2.6.
Posted by: paolot
« on: May 07, 2024, 06:31:05 PM »

In the Environment tab, together with the Annual Terraform capacity, I would like to read the number of the Terraforming Istallations active on (or near) a body.
Posted by: ISN
« on: May 06, 2024, 08:04:18 PM »

I've noticed that if an NPR fleet with jump-capable ships gets spooked and flees through a jump point, it will often not make a squadron transit even in cases where I'm pretty sure at least some of the ships could. I don't know if this is a bug or WAI -- I have no idea what factors the NPR code takes into account when deciding when and how to flee, whether to squadron transit, etc. -- but this particular behavior makes it really easy to exploit them (even if you're not trying to) and I feel like some better logic here would be a big improvement.
Posted by: Pedroig
« on: April 30, 2024, 09:09:07 AM »

Wow lots to digest here, in no particular order:

Quote
I think this is too complicated. We currently have a grand total of seven ground unit types, adding several more just for aircraft seems rather awkward. I would also suggest that it is unnecessary, and an easier approach would be to simply model air units as a capability which can be applied to any vehicle type, conferring (say) 2x size, 2x GSP, 0.5x HP, and 0.5x armor multipliers in exchange for using the air combat mechanics instead of normal ground combat mechanics. I would prefer this approach as it keeps the ground units UI simple while allowing for a lot of roleplay freedom - for example, having an armor multiplier means I could use a VEH base type and choose between light armor for 'normal' warplanes and medium armor for my A-10 Warthog equivalents. On the other hand, designing a UHV with flight capability to model a massive hovering skybase sort of aircraft is very fitting for some settings.

Using the existing unit types as the basis also means the question of weaponry is cleared up as well, and personally I see no reason to add weapon restrictions and restrict roleplay - heavier weapons are generally more specialized anyways, so I doubt we're opening up some silly exploit involving UHV aircraft with 4x SHAV or something.
I'm not opposed to the idea of flight being a capability, I think what you suggest would be far more convoluted to implement as currently all capabilities only affect the To-Hit and Hit Chances when fighting in different terrain/environment (and boarding allowing a new "environment" which is kinda iffy as it only works for offense since all ground units work defensively on board). Adding new mechanics for size/GSP/HP multipliers I would think would be significantly more code intensive rather than adding new Base Unit Types. There's plenty of space in the Ground Unit Design window for 4 more.

Adding as a capability would seem the easiest, also give Infantry a "Jet Pack" option. 

Quote
Partially agreed on fortification, disagreed on terrain. I think aircraft should be able to benefit from terrain, it may not be the most "realistic" but I think a lot of headcanons imagine, say, aircraft sweeping around mountain peaks or skimming forests to fly beneath enemy radar before popping up to fire a torpedo down the exhaust port... or something more realistic.  :P  Again, no need to restrict it here.

As far as fortification goes, I would say it can still apply when aircraft are the target of normal ground unit fire - representing them being caught at base in a hangar, surely an airbase can be fortified to some degree? Of course, fortification should not apply when facing AA fire during the AA fire phase.
Valid points, I could concede on my suggestion for the permanent hidden aircraft capability reducing the terrain factor rather than negating it outright. And while I understand the want to have aircraft protected in hangars able to be fortified, again in headcannons, you may also have to worry about your actual runways being damaged and not all your aircraft being stowed away at the same time. I think its a good trade off with aircraft essentially being glass cannons for all intents and purposes

Terrain modifiers being ignored or amplified would be most appropriate.  Air units have trouble seeing/attacking folks in dense forest and in caves, pretty easy time for those out in the open.

In order for an airbase to have appreciable fortification, it must cost something.  It's just not the planes, its the ordance, fuel, parts, etc that are about.  At a bare minimum, it should cost TIME to DEPLOY, so they provide nothing to damage output of the unit until X number of ticks, with the X being reliant upon the fortification level.  Overall, these assets should be in the way back with the STO's and have no need for fortification.  For Jump Infantry, they get could get a modifier/perk which ignores this, or reduces it.

There is no practical way of fortifying an airbase in today's world, versus trenchworks, pillboxes, and Hesco walls. (Encircling an airbase with any does little to nothing to protect it from air/arty attack.

One thing that perhaps is being overlooked, why not simply have a tech which allows for pure ground based fighters, which would have a base defense characteristic based upon engine tech, and then an inverse relationship with anything added to it, with LAA and no armour being the baseline of zero, and then an inverse relationship between defense proportional with added/reduced weight.

Posted by: skoormit
« on: April 30, 2024, 08:51:46 AM »

I wish we could separate the Research Speed game setting into two settings: one for technology research, and the other for component design.

I play with research speed 20%, because I like stretching out the time between tech eras.
But I don't like that it also takes five times as long to design each new component.
Posted by: KriegsMeister
« on: April 30, 2024, 02:43:19 AM »

words

This is quite an effortful post and deserves far more credit than I can give it. As it happens, I shall have to suffice with a simple reply.

I'll not wade too deeply into the mechanics here, and keep my comments to a relatively high level. In short: I like the ideas, but I think it is rather too complex for the fidelity and mechanics of Aurora's ground combat as it currently stands, and I'd prefer to keep that simplicity where possible. Furthermore, I think we can accomplish a lot of this by simply repurposing the existing ground support fighter (GSF) mechanics in terms of targeting, combat, etc. so that we are adding a minimum of new mechanics and rules to the system.

A couple of mechanics notes:
Thank you, probably could merit its own individual suggestion thread, but I already had open as just a reply when I first started about ~60 hours ago. And don't worry I got pretty thick skin and after my last effort post forever ago try to reel back on my own abrasiveness. You do bring up some good and valid points, and I think we are both trying to think of the best and most simple ways to do this. I'd say my suggestion is focused more on using existing ground vehicle mechanics with some minor/major tweaks to replicate GSF mechanics, whereas you are trying to mesh GSF mechanics into ground combat. Ultimately its up to Steve to decide which way he wants to go
Quote
Quote
my words
Note that GSFs currently have access to LAC, LB, and LAA-like components as fighter pod loadouts, so there's not really a reason to preclude aircraft from using bombardment components.
Yep, I had a lot of the Changelog mechanics posts open for reference while typing everything out. The problem with the bombardment pod is that it is treated as always long range/heavy bombardment, ignoring the mechanics of the short range bombardment weapons, which if we give aircraft access to those will it require extra tuning and coding? ALso GSF also don't have a direct AV equivalent so do you not allow aircraft to equip them and will the range properties of them need to get changed up? Its why I'm partial to creating a new AG component thats a blend of both, but I don't know the code well enough to say which would be easier to adapt and why I listed both options.
Quote
Quote
my words
Note that FFD only works in a frontline formation, AFAIK, so recon aircraft are limited to organic assets in frontline formations unless we change that mechanic - which we could, but I'd prefer to keep things simple and keep the impact on existing ground unit mechanics minimal.
I shoulda/coulda/woulda clarified, though this was assumed. It is Forward Fire Direction after all, not Backward Fire Direction.
Quote
Quote
my words
This functionality already exists in the game if you use LVH logistics. However, this conflicts with INF logistics managed through the replacements/unit series mechanic, which is population-based and does not depend on the order of battle. I don't think it is worth reworking this mechanic and making it much less convenient in the general case to support this specific case - destruction of headquarters already has enough benefits to be worthwhile, I think.

----
Good catch, the replacements strategy was only half way in my mind thinking. Again, in my post in the bonus suggestions, I do have a slight disagreement with how resupply works with units being "consumed". It may be a future effort post topic for a revamp of the system to actually track its supply usage which is already done in some form with combat units tracking their 10 combat cycles before needing resupply.
Quote
As far as my more general thoughts:
Quote
my words

I think this is too complicated. We currently have a grand total of seven ground unit types, adding several more just for aircraft seems rather awkward. I would also suggest that it is unnecessary, and an easier approach would be to simply model air units as a capability which can be applied to any vehicle type, conferring (say) 2x size, 2x GSP, 0.5x HP, and 0.5x armor multipliers in exchange for using the air combat mechanics instead of normal ground combat mechanics. I would prefer this approach as it keeps the ground units UI simple while allowing for a lot of roleplay freedom - for example, having an armor multiplier means I could use a VEH base type and choose between light armor for 'normal' warplanes and medium armor for my A-10 Warthog equivalents. On the other hand, designing a UHV with flight capability to model a massive hovering skybase sort of aircraft is very fitting for some settings.

Using the existing unit types as the basis also means the question of weaponry is cleared up as well, and personally I see no reason to add weapon restrictions and restrict roleplay - heavier weapons are generally more specialized anyways, so I doubt we're opening up some silly exploit involving UHV aircraft with 4x SHAV or something.
I'm not opposed to the idea of flight being a capability, I think what you suggest would be far more convoluted to implement as currently all capabilities only affect the To-Hit and Hit Chances when fighting in different terrain/environment (and boarding allowing a new "environment" which is kinda iffy as it only works for offense since all ground units work defensively on board). Adding new mechanics for size/GSP/HP multipliers I would think would be significantly more code intensive rather than adding new Base Unit Types. There's plenty of space in the Ground Unit Design window for 4 more.

-edit, forgot about HP modifier of infantry genetic enhancement. But Size/GSP/Armor constraints still might be an issue
Quote
Quote
my words

Partially agreed on fortification, disagreed on terrain. I think aircraft should be able to benefit from terrain, it may not be the most "realistic" but I think a lot of headcanons imagine, say, aircraft sweeping around mountain peaks or skimming forests to fly beneath enemy radar before popping up to fire a torpedo down the exhaust port... or something more realistic.  :P  Again, no need to restrict it here.

As far as fortification goes, I would say it can still apply when aircraft are the target of normal ground unit fire - representing them being caught at base in a hangar, surely an airbase can be fortified to some degree? Of course, fortification should not apply when facing AA fire during the AA fire phase.
Valid points, I could concede on my suggestion for the permanent hidden aircraft capability reducing the terrain factor rather than negating it outright. And while I understand the want to have aircraft protected in hangars able to be fortified, again in headcannons, you may also have to worry about your actual runways being damaged and not all your aircraft being stowed away at the same time. I think its a good trade off with aircraft essentially being glass cannons for all intents and purposes
Quote
Quote
my words

As mentioned, I would simply take the ground support fighter rules (including the following ground-based AA fire rules) and paste them onto the new Flight capability. Since those rules are already written out in sufficient detail for discussion purposes, I won't rehash them here.

One simplification here is that, since we can't set orders for ground units in the UI, I would probably use existing mechanics for bombardment and AA targeting to make this work. In short, aircraft formations can be assigned to support frontline formations or left unassigned. In most cases, regardless of assignment they have the same targeting options as HB units (aside from eliminating the target size reduction for support/rear formations, as you stated). The exception would be AA components which fire as AA weapons following the targeting rules for HAA.

This does mean the bombardment components are a tad lackluster since they won't have any special ability making up for their inflated sizes, but I think that's fine as not every component needs to be equally useful in every situation.

Like I said above, I had those open for referencing. I do feel like you are kinda repeating what I was proposing though. I probably should have added some more examples in my post. Currently as stands for GSF, they can be assigned to Provide Ground Support to units with fire support as bombardment does, Search and Destroy which just gives them open range on all ground units (though I'm not clear in the wording of the rule saying they can target any formation regardless of position if it factors in positional weighting), or Flak Suppression to directly target ground AA. All of these can be replicated just with the current positional, support, and FFD functions already in place for ground forces. Search and Destroy is the easiest, its just aircraft set to Frontline Attack. Ground support is also simple with setting an air formation to support. Flak suppression is a little tricky, while there are no current mechanics for GU to target specific elements, it can be pretty simply be represented by air units supporting another air unit. If the front-line aircraft are targeted (preferably those equipped with FFD) by surface to Air ordnance, then the supporting unit can engage the attacking units in the same manner as Counter Battery fire mechanics. We also have another function that GSF's lack to simulate Escort Fighters, aircraft with AA weapons supporting air units with AV/B/AG weapons and "counter battering" enemy aircraft targeted your bombers.

Quote
Quote
my words

I would actually prefer to keep the same rules, as this makes it easier to control the flow of supplies. I suppose an alternative would be to have airborne supply distributed last in the resupply order, which would ensure it ends up where it is needed while maintaining the special flavor, but I'm not sure if that mechanic would see a lot of use in practice. Resupply is already a big enough cost that I don't see airborne supply being very cost-effective - and Aurora doesn't really model the kinds of tactical situations where airborne supply is most useful (e.g., formations aren't getting surrounded and cut off tactically, Aurora simply does not model this).

I did state that Air logistics should be resolved last vs internal and parent supply draw. Though like you had mentioned above, the replacement unit tactic does kinda negate the benefit of aircraft logistics being able to resupply any formation regardless of hierarchy. Once again, the consumption of whole units as supplies is a bit of a bore.
Quote
Quote
#1 What the hell should the 3/4 letter acronym be!?!?

I'd settle for an '(A)' following the unit base class abbreviation, e.g., "LVH(A)" or "VEH(A)". Should be easy enough to pick out of a lineup.
That would be acceptable if flight was a capability trait, though not a fan of it for base unit types.
Quote
Quote
The other big thing being in order to make aircraft somewhat viable and interesting in my eyes is that we have to give them very specific rule exceptions which kinda breaks Steve's design philosphy for Aurora C#,

This is another major reason why I prefer to work within the existing mechanics as much as possible by treating flight as another capability and repurposing the existing GSF rules. We could keep GSFs as they are but I personally see no reason to, space-to-ground fighters can use regular weapons and rules like everybody else IMHO.

----

Again, great post, and I hope this doesn't come across as being overly critical, my goal is really more to look at how we can best mesh new air units with the existing mechanics without upsetting the bucket too much and still get a satisfying flight mechanic that promotes strategic decisions and roleplay openness in equal measure.
I do feel like we are both are trying to reach the same goal just from different starting points. We both want to make a dagger, one of us is elongating a knife while the other is shortening a sword. And agreed, GSF's are just a bit too clunky for my taste (which is almost universally agreed on), and while the concept of trans-atmospheric fighters is appealing, I don't think there is a really good way to bridge the very different gameplay mechanics of Naval Combat and Ground Combat. Its best to just let fighters operate under the already existing orbital bombardment mechanics.

The only exception that I think would be pretty fantastic but would actually be a newish, utilize the GSF's ability to not be targeted by STO's with a new order similar to Flak Suppression that specifically targets STO units. That would be fantastic for setting up invasions trying to run fighters in from a carrier to destroy some of the batteries preventing the full scale invasion without the excessive collateral damage and atmospheric dust build up of general orbital bombardment