Recent Posts

Pages: [1] 2 3 ... 10
1
In terms of mapping, unless you extremely unlucky, you can use the matryoshka approach.

Basically, long connections run around and inside you have the rest of the systems, if you use a squared map system.

If you use a spiral approach, you should then be able to keep the same approach by dragging the connections on the out arms and spiral inwards.

Skoormit, out of curiosity can you send your DB? I would like to have some fun with your map. I am asking because I never really encountered a really messy run in terms of inter system connections. I guess I have been lucky (or unlucky, depending on point of view) so far. It is true I only play with Real Stars map, and I noticed that this situations are most common in non Real System starts or if you mess around local systems connections.

Steve, in your case you only need to switch the position of Tannauser gate on North West side and move Kodiak up of Andromeda.
Once you done that, you should be able to quickly figure out the best position for Barbarossa and Dark Heaven to pass on the west side of Sol while keeping Paragon and Argonar in the right place, as they don't need to intersect. Proxima connection can be placed anywhere free and out of the way at this point.
I'll admit that Regulus will require some creativity. To be fair, create space for that part of the galaxy should be doable until a new connection turns the table. I think you'll have to skew the whole map to the south west side until you can squeeze the last intersection through Lethe, considering Alpha Centauri should be already in an ideal position due to the previous Barbarossa move.

If I may, this presents the perfect opportunity for me to brainstorm on a couple of ideas. If you ever played Avorion (please don't or Aurora will get put aside for too long :) ) I like the warp concept there, so basically the map does have these long warp points from one end to another of the galaxy. If we can have some means to "rearrange" selected branches to pass on top of systems circles or elements and not underneath, then this will already be a possibility (it will require for them to be of a darker/lighter colour though). I do know there is something going on there, because I noticed that intersection pass over other intersections with a discovery priority? Basically, they do not exist in the same layer. You can notice that when you build gates and the line becomes orange, and by using Skoormit map it becomes evident. Some goes on top some others below. Perhaps there may be space for layer optimization here as well, helping with performance opening large maps. Am I correct? If not scrap it.

Eventually, the branch could have a selection and a toggle called long connection, which will make that particular branch of a different colour if selected. I don't know, perhaps red and pink if gate connected.

While at it, and I know it is a pain, Zoom and grid size selection features back will be highly appreciated :)

There is always the good old don't touch it if not broken approach.
2
General Discussion / Re: Questions Not Worth Their Own Thread: C# Edition
« Last post by skoormit on Yesterday at 11:44:50 AM »
I don't know if I could stand playing with the way you've got your map setup - too many long connections cutting across the entire map; like the Afbull connection to whatever system you've got just offscreen to the top left, or the Aha system connecting to AKA in the top left and way off down the bottom left. Unfortunately, there's just not much to be done with what we've got - I suspect we'd need an actual 3d grid to make sense of it all.

LOL.
Yes, the long connections are annoying, but there's literally no way to arrange that map without having any.
Try to shorten one, and another will appear.
3
General Discussion / Re: Questions Not Worth Their Own Thread: C# Edition
« Last post by AlStar on Yesterday at 10:42:32 AM »

I always aim to minimize the number of intersecting JP paths, but there's only so much you can do.

See the attached for some suggestions. After you do those, you might notice some further easy adjustments.

Don't worry: the longer your game goes, the more fun it gets. See the other attached for an example.
Those suggestions look good - as you say, they should at least reduce the overlap.

I don't know if I could stand playing with the way you've got your map setup - too many long connections cutting across the entire map; like the Afbull connection to whatever system you've got just offscreen to the top left, or the Aha system connecting to AKA in the top left and way off down the bottom left. Unfortunately, there's just not much to be done with what we've got - I suspect we'd need an actual 3d grid to make sense of it all.

Maybe it's me, but I cannot find a way to promote the civilian administrators.
I need a planetary admin of level x, but the ones at level x-1 have better parameters and I don't find how to promote them.
As far as I know (and this could well be wrong), they'll naturally self-promote as long as there are free governorships of a higher level available; it just might take some time. I think there's a way to force-promote them if you turn on SM mode.
4
General Discussion / Re: Questions Not Worth Their Own Thread: C# Edition
« Last post by paolot on Yesterday at 10:26:01 AM »
Maybe it's me, but I cannot find a way to promote the civilian administrators.
I need a planetary admin of level x, but the ones at level x-1 have better parameters and I don't find how to promote them.
5
C# Suggestions / Re: Suggestions Thread for v2.4.0
« Last post by Pedroig on Yesterday at 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.

6
C# Suggestions / Re: Suggestions Thread for v2.4.0
« Last post by skoormit on Yesterday at 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.
7
General Discussion / Re: Questions Not Worth Their Own Thread: C# Edition
« Last post by skoormit on Yesterday at 08:41:27 AM »
I've been playing with my galaxy layout, since I just found a connection that joined the far western side of my map with the far eastern side.

Does anyone with a better sense for these things have any idea how to make this constellation of jumps not be a total rat's nest?

I always aim to minimize the number of intersecting JP paths, but there's only so much you can do.

See the attached for some suggestions. After you do those, you might notice some further easy adjustments.

Don't worry: the longer your game goes, the more fun it gets. See the other attached for an example.
8
I've been playing with my galaxy layout, since I just found a connection that joined the far western side of my map with the far eastern side.

Does anyone with a better sense for these things have any idea how to make this constellation of jumps not be a total rat's nest?

You just need to move them around a few at a time and try to figure it out. It's usually a fun problem to solve, trying to get the best layout. This is my current campaign, which has quite a few loops.

9
C# Suggestions / Re: Suggestions Thread for v2.4.0
« Last post by KriegsMeister on Yesterday at 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
10
General Discussion / Re: Questions Not Worth Their Own Thread: C# Edition
« Last post by kyonkundenwa on Yesterday at 12:40:40 AM »
Does anyone with a better sense for these things have any idea how to make this constellation of jumps not be a total rat's nest?
Move the systems into an arrangement with the least number of offensive links. And then SM-delete those offending links.
Pages: [1] 2 3 ... 10
SMF spam blocked by CleanTalk