Recent Posts

Pages: [1] 2 3 ... 10
1
C# Suggestions / Re: Fighter Module
« Last post by nuclearslurpee on Today at 12:00:26 AM »
What about allowing Fighters (and maybe FACs) to utilize the 'No Armor option to significantly reduce their size.  I just mucked about with some convential start designs for a single shot railgun fighter, and it was quite the challenge to even get it into the 500T limit with just the railgun, bfc, powerplant, engine and a fighter fuel tank.  Mostly due to the fact that conventional armor took up over half the tonnage.  Granted, that can be significantly reduced, but not after several tech levels in multiple fields will you be able to get a sub-100T vessel.  Removing the armor all together would make those small designs far more feasible, and really the armor is all but useless as is due to shock damage.  And building up to the full 500T (or 1000T) would allow you to pack a lot of punch in a small but very fragile package.

This would technically work: a quick test build shows that at MaxTech (i.e. best armor tech) you can just barely squeeze in a single-shot 10cm railgun with R1 power plant (again, MaxTech), 0.5-HS engine + 1,000 L of fuel, and a SW-BFC with 0.25x range and 3.0x speed - you'd really like to tune the engine + BFC to get 4x tracking speed but that's not feasible in 100 tons. This leaves you with 5 tons extra to make an even 100 tons, probably the optimal design would be a 3.1x or 3.2x BFC speed multiplier and a 97-ton craft to match speed and BFC, but for the sake of example I just threw an engineering space or fuel storage on to fill tonnage. Total armor weight was 0.04 HS (2 tons) so not a limiting factor at all.

However, for pretty much anything significantly below MaxTech the only thing you can make a 100-ton fighter out of is a Gauss cannon (bad) or a box launcher (boring, to the kind of person who desires viable sub-100 ton fighters), even if you neglect armor weight, as you simply lose so much tonnage to reactor, BFC, etc. at lower tech levels. A single-shot railgun already takes 49 tons before even thinking about a power plant, BFC, or engine to work up a useful speed. At TN Start tech, a single-shot 10cm Railgun plus R1 power plant already take 1.61 HS (about 80 tons), decreasing to 1.07 HS (about 53 tons) at MaxTech, basically you need to get this total under ~60 tons (~11 tons for the reactor) to have a viable 100-ton fighter. Really armor is not the limiting factor for fighters at most tech levels, the bigger challenge is the discrete nature of firepower and components. As Steve said, this isn't necessarily a bad (or good) thing, it is a consequence of maintaining equity between small and large ships.

Which brings up another question: if we allow this exception for fighters/FACs, what reason is there to not allow the same for larger ships? I think having such an exception would be questionable given Steve's position on the subject, since it allows fighters/FACs a capability that larger ships are not allowed to use. Although, you can argue that there is a tenuous precedent since fighters/FACs already don't have to mount Bridge components, but this is not really a capability as much as a design concession to these special classes so I am not sure such an argument holds up.
2
C# Suggestions / Re: Fighter Module
« Last post by KriegsMeister on Yesterday at 11:09:18 PM »
What about allowing Fighters (and maybe FACs) to utilize the 'No Armor option to significantly reduce their size.  I just mucked about with some convential start designs for a single shot railgun fighter, and it was quite the challenge to even get it into the 500T limit with just the railgun, bfc, powerplant, engine and a fighter fuel tank.  Mostly due to the fact that conventional armor took up over half the tonnage.  Granted, that can be significantly reduced, but not after several tech levels in multiple fields will you be able to get a sub-100T vessel.  Removing the armor all together would make those small designs far more feasible, and really the armor is all but useless as is due to shock damage.  And building up to the full 500T (or 1000T) would allow you to pack a lot of punch in a small but very fragile package.
3
C# Mechanics / Re: v1.14.0 Changes Discussion Thread
« Last post by pwhk on Yesterday at 08:39:56 PM »
About facilities sizes. Actually I would prefer the size being displayed somewhere in the game proper. Possibly in fleet order screen where we can see how many facilities it will be able to move.
With that, then we don't need to refer to a picture outside the game and do mental calculations while still allowing differing facility sizes.
4
C# Suggestions / Re: C# Suggestions
« Last post by ArcWolf on Yesterday at 08:18:36 PM »
What if abandoning ship didn't make it self-destruct, but rather just spawned lifepods equal to the remaining crew and set the ship's crew to 0?  I mean the button IS abandon ship, not scuttle ship.

I too would like an actual "abandon ship" button to go along with the current "Self destruct' button.
5
C# Mechanics / Re: v1.14.0 Changes Discussion Thread
« Last post by Scandinavian on Yesterday at 05:49:42 PM »
If a research facility is anyway a whole multiple-location thing with off-site data centers, several laboratory wings and so on, it doesn't really make a lot of sense that it can't be built and shifted piecemeal. I get the argument that there might be economies of scale and a certain minimum size to get started, but that's also true for construction factories and their supply chains.

Infrastructure I would just measure in tons cargo space instead of points - in practice it is always deployed in large enough quantities that the discrete units don't matter, and there's no mechanic that requires us to "allocate" infrastructure point by point.

Keeping the Terraformer at 10 factories load weight makes sense to me, since that makes keeps it comparable to the orbital terraforming module. Spaceports also seem like they should be 10x, both for gameplay and fluff reasons. I could construct an argument either way for the GMC, depending on how you fluff it.

The GFCF is a middle case. It clearly includes all manner of manufacturing and even heavy industry, which it seems to me should operate on the same principles as the construction factories. But it also includes actual training facilities, which have to be large and are generally cumbersome to relocate (it takes a lot of space to do effective training maneuvers, especially once you get to division and corps level deployments - it's expensive too, but it is absolutely essential to maintain a good state of readiness).
6
C# Mechanics / Re: v1.14.0 Changes Discussion Thread
« Last post by nuclearslurpee on Yesterday at 05:31:15 PM »
IIRC Steve was considering switching ground force production to use a similar system to construction/ordinance/fighter factories, though I don't remember if that ever went through.

I know it has not yet been done, but I sincerely hope Steve chooses to implement this. Although the change to double generation of ground (and naval) officers should help indirectly since the necessary formation sizes for efficient use of commanders will be reduced somewhat, but this isn't really a fix per se.

Quote
Honestly, I'd really love for facility size to be standardized as much as possible,  if only because then I wouldn't have to keep looking up how many freighters/how much to repeat every time I wanted to move something. Maybe not feasible for spaceports, since those kind of feel like it's supposed to be a big hauling job to make a colony "established", and I get the reasoning involved in refueling stations and forced labor stuff being hard to move. But I'd love it if infra, research facilities, terraforming installations, ground force training, etc all got standardized at 25,000 tons while keeping the same efficiency per ton.

I'd probably not want to see standardization at a single size, flavor-wise it makes sense that different things should be at different sizes, but I do think collapsing the sizes into more comprehensible values would be very helpful. Something like 2,500-tons for infrastructure, 25,000 tons for most production facilities, and 250,000 tons for the large facilities (terraformer, lab, GFTC, etc.) makes sense. This is 10x, 1x, and 0.1x to a cargo hold which is a lot easier to remember but still varied in a sensible way.
7
C# Mechanics / Re: v1.14.0 Changes Discussion Thread
« Last post by Bremen on Yesterday at 03:27:52 PM »
One thing I think maybe should be changed is subdividing the current laboratories (10x factory cargo size, 1 mil pop, 2400 construction cost, 200 RP generated) into 10 factory-sized facilities (scaling scientist admin capacity accordingly). Partly out of a desire to avoid having to deal with partial loading of facilities, which Aurora handles... acceptably but not well. And partly out of a desire to make conventional starts more practical (when you can only churn out 1 lab every 3 years you get a strange outcome where you lay the last brick and suddenly your research capacity is increased by 20 %).

Ideally I'd want to turn research point generation into a pool that scientists draw from until her project is fully funded (per her admin cap), then the next scientist in the queue gets to draw, etc. down the priority queue (with the possibility to set a cap on how much a given scientist can draw, e.g. if you want to synchronize certain projects, or want to spread out research for RP reasons). But that is a much more intrusive change than just re-scaling the installation size.

(Also, the same logic could be applied to ground forces formations and even factory construction, giving all non-shipyard planetary production a unified mechanic and interface. Which seems aesthetically pleasing, reasonable and in line with the ambition to unify more game mechanics in this edition.)

IIRC Steve was considering switching ground force production to use a similar system to construction/ordinance/fighter factories, though I don't remember if that ever went through.

Honestly, I'd really love for facility size to be standardized as much as possible,  if only because then I wouldn't have to keep looking up how many freighters/how much to repeat every time I wanted to move something. Maybe not feasible for spaceports, since those kind of feel like it's supposed to be a big hauling job to make a colony "established", and I get the reasoning involved in refueling stations and forced labor stuff being hard to move. But I'd love it if infra, research facilities, terraforming installations, ground force training, etc all got standardized at 25,000 tons while keeping the same efficiency per ton.
8
C# Mechanics / Re: v1.14.0 Changes Discussion Thread
« Last post by Scandinavian on Yesterday at 02:14:00 PM »
One thing I think maybe should be changed is subdividing the current laboratories (10x factory cargo size, 1 mil pop, 2400 construction cost, 200 RP generated) into 10 factory-sized facilities (scaling scientist admin capacity accordingly). Partly out of a desire to avoid having to deal with partial loading of facilities, which Aurora handles... acceptably but not well. And partly out of a desire to make conventional starts more practical (when you can only churn out 1 lab every 3 years you get a strange outcome where you lay the last brick and suddenly your research capacity is increased by 20 %).

Ideally I'd want to turn research point generation into a pool that scientists draw from until her project is fully funded (per her admin cap), then the next scientist in the queue gets to draw, etc. down the priority queue (with the possibility to set a cap on how much a given scientist can draw, e.g. if you want to synchronize certain projects, or want to spread out research for RP reasons). But that is a much more intrusive change than just re-scaling the installation size.

(Also, the same logic could be applied to ground forces formations and even factory construction, giving all non-shipyard planetary production a unified mechanic and interface. Which seems aesthetically pleasing, reasonable and in line with the ambition to unify more game mechanics in this edition.)
9
C# Mechanics / Re: v1.14.0 Changes Discussion Thread
« Last post by nuclearslurpee on Yesterday at 12:55:10 PM »
I have always considered that a "laboratory" in Aurora actually represents a large set of research infrastructure including various institutes, user facilities, server farms, universities and other educational institutions, and others all of which might be grouped purely as an administrative unit or might be earmarked to support a flagship facility - ITER, LHC, and so on. All of course highly abstracted, with your "scientist" really being the head of a quite large research division or department. I think this is generally the best way to look at planetary facilities in Aurora, not as single discrete units but rather as reflecting the infrastructure in place to direct the efforts of the employed population towards the goals of your space empire - which can then be shipped around to the desired colonies to direct the efforts of the entire space empire, an important element in a game which has space logistics at its heart I would say.

I will agree that it is quite unrealistic to have labs be hot-swapped at a moment's notice, but frankly it is the same issue we have with construction factories so it is not unique to labs. We could in principle implement some kind of "retooling" mechanic for labs, factories, etc. but while I don't think this would be a "bad" mechanic I do think it is not well-suited for Aurora. It adds simulationism, but not really interesting decisions besides forcing a particular style of gameplay - what I mean by this is that it does force the player to "intelligently" set their industrial or research priorities and only change them slowly, but this doesn't actually add any mechanical depth to the game as the player is only incentivized to make a change when their hand is forced by the game situation. The economic depth of mechanics is not enough that a game of micromanaging the economic balance is really engaging.

IMO the mechanics work best as they are, as far as Aurora works, because the flexibility while it may not be the "most realistic" allows freedom of roleplay while maintaining good balance of gameplay. For those who want a very specific style of play Aurora has always offered great flexibility to create house rules to model whatever we want.
Pages: [1] 2 3 ... 10
SMF spam blocked by CleanTalk