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 - byron

Pages: [1] 2 3 ... 57
C# Aurora / Re: Replacing PDCs
« on: September 21, 2017, 07:50:23 AM »
Being an old sci fi fan I would miss the PDCs.   The free maintenance can be adjusted to the population of the planet.   a 100,000 ton
PDC is no larger than a little more than 2 Iowa class battleships.
Less, actually.  The Iowas were 45,000 tons 'treaty', but treaty displacement is a joke.  Fully loaded, more like 57,000 tons.   

A population of sufficient quantity should have no problem maintaining
one.   There are hundreds of 100,000 plus ton ships out in the real world now.   Replacing the PDCs with a new mix of just ground units
is not the same as having El Scorpio PDC (for those who remember 'Sleeping Planet).
There are no 100,000 ton warships.  The biggest (US carriers) top out around 90,000 tons.  And civilian ships don't have the same drivers as PDCs.

Steve, could this idea be used with ships as well. It has been mentioned before that training up a ships crew and then losing that experience level when the ship is scrapped makes the turnover of ships and fighters to be painful. When scrapping ships, could a second crew pool be maintained (representing the cadre from the scrapped ships) that new ships and fighters can pull crew from first, before using untrained naval crew coming from the general pool.
Something along these lines would be really nice.  I don't like the current system, where your best ships are almost always your oldest, nobody retires, and people being sent back to the pool are diluted to pool level.  Here's my suggestion (reposted) on a more realistic system:
First, the crew pool tracks people and points separately.  The academy has a level that it pumps people in at.  For example, it may add 100 people and 20000 points in a given week.  These are added to the pool values.  When a ship is commissioned, it takes the correct number of people and points, based on the pool averages.  Adjusting the academy training level only affects the inflow, not what's already in the pool.  Also, people should leave the pool.  Maybe 5% a year, of average points.  In wartime, you can check a box which temporarily slows the loss rate, but eventually (5 to 10 years later) it comes back to normal, or even goes higher.  After you uncheck it, the war timer counts backwards until it reaches 0, so people don't just toggle it on and off when they get to the point of diminishing returns.
Second, rotate people on ships.  To make it easy, whenever a ship gets shore leave, a certain number of people rotate back into the pool, based on how long it's been out.  Maybe 10% per year.  They're replaced with normal people from the pool.  This is to avoid the "ICBM station with an enormous crew rating" problem.
Third, allow picked crews, and unpicked crews.  These have maybe 150% and 50% of normal points, respectively, taking the appropriate number of people and points from the pool, and getting those values when the crew rotates.  This is to allow you to have a good crew on your fancy new battleship, and give your second-line PDCs the dregs.
Fourth, conscript-crewed ships should not feed into the pool.  Because of the nature of the crews (and to avoid flooding the pool with untrained people), the people who leave the ship at the end of their tour are just lost. 

C# Aurora / Re: Replacing PDCs
« on: September 19, 2017, 10:37:08 AM »
My thoughts run basically parallel to Garfunkel's.  I've thought about this before, and have modified my last set of suggestions.
There are three bits that I'd like to see.  First, more granularity in ground combat.  At the moment, taking over a planet is binary, either you have it or you don't.  It might be nice if larger planets had multiple sub-sections which you could conquer one at a time.  Some form of terrain system might be a good idea, too.  At the simplest, divide the planet into an 'urban' and a 'rural' section.  The rural section has a specific type, be it 'desert' or 'forest' or 'sea', with corresponding terrain effects.  Normally, you land in the 'rural' section, and have to fight your way in.  Planets with big populations (>100 million pop?) could have multiple 'urban' sections.

Second, combined arms.  At the moment, all ground units have two values, attack and defense.  And that's all.  A heavy assault battalion is better than any other battalion, and costs the same to move.  Instead, define a dozen or so different types of 'combat power', and rate each unit on them.  Some suggestions:
Fortification (granted by being dug in, not inherent)
Command and Control
Logistics (maybe)
These interact to give bonuses or penalties in combat, depending on situation, with combined arms being required to gain victory.  Some types of units would do better than others in various terrains.  For instance, infantry is more important in urban terrain, unless you just want to destroy everything.  (And avoiding damage to their infrastructure would be a reason for the defender to deploy forces in the Rural part of the planet.)  And infantry is the only thing (except maybe engineers) which can perform boarding actions and the like.  Garfunkel's 'hard' and 'soft' are a somewhat simplified version of this, but I like the overall idea.
Also, ships in orbit could be counted as part of this bonus set.  Fighters and bombardment platforms give bonuses on this stuff.  Another aspect might be to set ROE, where you trade off firepower for reduced damage to infrastructure. 

Third, more customization of units, interacting with the combined arms stuff.  Let's say we have a dozen or two different elements which are used to build units.  These are generally platoons or companies, and research improves each of them separately.  (Maybe there'd be level techs to unlock a tier and then individual techs below that, so you can't just blitz one line, while not making specialization unduly expensive.)  So you might garrison mining outposts with a battalion made of three infantry companies and a logistics element, while the 1st Armored Brigade would have three mechanized infantry companies, six armored companies, three artillery batteries, three companies of cavalry scouts, and so on.
Obviously, you'd have various types of transport to deal with this.  Maybe 'personnel', 'light' and 'heavy'.  'Heavy' covers things like naval units and titans, while 'light' is anything up to tanks.

C# Aurora / Re: Replacing PDCs
« on: September 19, 2017, 08:25:19 AM »
Yes!  This is fantastic.  I'm entirely in favor of this change.
I do think we should consider some realism in terms of what weapons work through atmospheres.  To a first approximation, high-frequency lasers will be useless, as will particle beams, plasma carronades, and high-speed projectiles (probably set by weapon range).  This would create an interesting dynamic with second-class bombardment ships (beyond the meson ships I use now.)
To a second approximation, you'll need to look at atmospheric composition to see how lasers will do.  That would probably need to be tied into a look at how atmospheric composition changes albedo and such.  Probably not worth it initially.

C# Aurora / Re: C# Aurora Changes Discussion
« on: September 15, 2017, 08:20:32 AM »
Or with some hand calculations and delay orders.
I'd rather we got scripting/extra conditionals.  That's annoying to set up (particularly if you have more than two harvester groups), planetary movement could throw it off, and it breaks completely if you add more harvesters to a fleet. 

C# Aurora / Re: C# Aurora Changes Discussion
« on: September 13, 2017, 07:26:39 AM »
Very excited about all of the changes.  The one thing I will point out is that while officer management is going to be much better, ships still have crews that stick with them for all time.  This is unrealistic, and somewhat annoying, as your oldest ships always will have the best crews.
Also, I'm not sure I like ships with weapons automatically needing a Rank 3 commander.  That seems too stringent, even if you've closed the FAC loophole.  Is there a way smaller warships could use Rank 2 commanders?

C# Aurora / Re: C# Aurora Changes Discussion
« on: August 11, 2017, 12:02:59 PM »
I probably will add some form of Admin Command module post-launch. I just want to make sure everything functions as expected before adding any further complexity.
Excellent.  I'll stop bugging you about it, as I don't want you holding up release.

C# Aurora / Re: C# Aurora Changes Discussion
« on: August 10, 2017, 04:58:53 PM »
The admin command structure looks really cool.  I'm excited to try it.

That said, I'm going to keep pushing for command ships (like the Blue Ridge, not just normal flagships).  Looking at the way you have it laid out, the obvious suggestion is that a big module (at least 25,000 tons) should give a radius of 0, affecting only the system it's in.  Or if you're willing to give it a radius of 1, that would be even better.

Aurora Suggestions / Re: Designing ship hulls instead of ships
« on: August 04, 2017, 03:19:32 PM »
Perhaps a better approach to get things going would be to consider what logically you shouldn't be able to change, and what you should. I'm assuming the premise is that the shape and size of the hull are the key requirements from a shipyard perspective, that it would be much easier to change internal rather than external components, but that even then there is a maximum size of component you can rip out of a ship before it compromises your overall structural integrity. On that basis you could come up with a fairly consistent (if arguable) list of fixed components:

Hull size: fixed
Armour: fixed
Engines: fixed (large component that materially affects hull design)
Jump drives: fixed (large component that materially affects hull design)
Hangars: fixed (the hangar doors/launch mechanisms can't be easily added or removed without major hull changes)
Construction: fixed
Terraforming: fixed
Fuel harvester: fixed
Spinal weapons: fixed
Everything else: variable if individual item is less than ?10%? of hull size, fixed if over ?10%? of hull size

So the end result would be to give you a lot of flexibility in swapping small components around. And just like in real life you can add light AA turrets to anything, but you can't expert to be able to stick a battleship turret onto a freighter.
I think this may be a bit too restrictive.  Things like fuel harvesters, mining equipment, and terraformers all seem pretty similar (assuming my memory of sizing is correct).  It seems very possible to design one hull which is good at all of the various fixed-location industrial tasks.  Likewise, it seems odd that I can't substitute a far-UV 25 cm spinal laser for a near-UV 25 cm spinal laser.  And now that I think about it, it would be nice if I had some way to put my new fuel economy upgrade on my ships without having to retool everything. 
I'm aware that trying to put together a full set of rules to reflect what should logically be possible is probably going to result in something too complex to play, and I definitely favor your proposal over what we have now, but it seems a bit too tough.

Aurora Suggestions / Re: Designing ship hulls instead of ships
« on: August 02, 2017, 10:48:00 AM »
Rather than having hulls be a designed tech as suggested, I would add a new button to the ship designer interface labeled "Add Variant".  This would work exactly like copying the design, but the hull, armor, and possibly engine would not be modifiable - removing components would not change the size of the design (instead adding "empty space"), and you would not be able to alter the amount of armor, make the ship bigger, or change the engines. 

A shipyard tooled for a given design could then build or refit to any variant of that design's hull, with the caveat that doing so is more expensive and/or slower than a properly tooled shipyard would be.  This would allow for easy construction of limited-build designs (such as flag variants of warships or jump-capable variants for example), allow basic multi-purpose hulls to be converted into a great variety of tasks (a basic 1000 ton design could be easily adapted to a light tanker, an active sensor platform to support LAC strikes, an intelligence platform packed with passive sensors, a clean-up gunship, etc - much like we use airliners for in the real world) without tying up a huge number of shipyards, or any number of similar purposes.

You could even allow for the provision of "empty space" in a given design to represent modularity, with the penalty that components using this space would be bulkier (instead of the time/cost penalty) than a fixed system.

That does seem like a very workable plan, although I'm torn on how much you want to let players flex the space.  This proposal basically gives you carte blanche so long as you don't touch the engines or armor.  The minimum variant on it would require that spaces retain the same use (weapons, sensors, etc), although that does seem like it might be too limiting, and definitely rules out things like flagships.  Maybe allow some small percentage of flexing in space usage.  No more than 5-10% of the ship can be different types than they were before.  So you can trade a bit of fuel for the extra reactors you need to power your improved weapons, or place a flag bridge in place of a few guns, but you can't just trade ship types at will.
I'm aware that this fails to capture some of the possible complexity that we saw in WW2, but I'm not sure we can capture that.  We should (IIRC) be able to capture the 'general auxiliary' conversions, even if carrier conversions are out.  Tthose don't make sense in the modern world due to the increased complexity of carrier operations, and I don't think we should slavishly imitate WW2.

C# Aurora / Re: Box Launcher Reloads
« on: July 31, 2017, 11:09:04 AM »
My impression at the time (mostly from Harpoon and Clancy :) ) was that it was RoF for missile defense.  Aegis was designed to counter the threat of massed soviet bomber attacks launching large salvoes of ASM; the main improvements in the Aegis cruisers to support this were the introduction of phased array radars for electronic steering and multiple target illumination and the VLS system for rapid launch.  Wikipedia claims that the Mk 13 one armed bandits have a RoF of 1 per 10 seconds for ASM.  This site says Mk 26 (double-rail launcher that Aegis cruisers started with) has twice that (2 per 10 seconds), while Mk 41 VLS is listed at 1 per second.

Hmmmm - just realized...  STEVE:  Have you thought about a phased array fire control that could illuminate a boatload of targets simultaneously?  Would probably screw up game balance, but it seems a reasonable extension.

I'd need to re-read the relevant Friedman (which I have at home), but I wouldn't be surprised if it was some of all of the above.  Another aspect, not mentioned, is that your missiles are not left exposed to the elements, and you can fire in worse weather, due to ship motion constraints.
That said, AEGIS doesn't use a phased-array illuminator.  What gives it better target-handling capability is that unlike earlier ships it doesn't have to use the illuminator throughout the flight of the missile.  The missiles have a programmable autopilot, which extends range (they can fly more efficient trajectories) and means that they illuminators are only required for the final few seconds of flight.  The SPG-62s are slaved the AEGIS, and in fact do not even have a receive unit to make sure that they're tracking the target.  New Threat Upgrade was a program for earlier missile ships which gave them the programmable autopilot, but they still had lower capability due to worse main radar and the fact that their illuminators had to search, unlike the SPG-62s.

C# Aurora / Re: Box Launcher Reloads
« on: July 28, 2017, 01:19:27 PM »
Side note it looks like most of the wet navies these days are going back to box launch styles, rather then magazine style AAM, atleast for their big missiles.
It's a bit more complicated than that.  Some types of missiles have always been 'box', most notably anti-ship missiles.  The FFG-7s did have Harpoon capability on their Mk 13 launcher, but that was the exception, not the rule, and I can't think of another example.  (Although I wouldn't be surprised if the Soviets had some.)  ASROC and Sea Sparrow were also box (except for the ASROCS on some of the rail launchers), although they usually had onboard reloads.  Magazine-type launchers were only seen for SAMs.  I believe that one of the main reasons they switched to VLS was that it allowed them to handle bigger missiles, mostly Tomahawk, which they couldn't fire out of Mk 13 or Mk 26 launchers.  Another aspect may have been the demise of the really big missiles, like Talos, which might have been tricky to fit in a VLS.
I'm not sure how much of this carries over into space.  One particular aspect is that you don't have sea motion in space, which is a serious constraint on missile handling.

Aurora Suggestions / Re: Designing ship hulls instead of ships
« on: July 27, 2017, 10:07:16 AM »
I definitely like the idea of trying to make the refit/parallel build rules more sensible.  It's always annoying when it's going to require retooling to install, say, improved lasers (same power, same size, better focusing), but you can just build a bunch of different small ships. 
I'm not certain this is the best way to go about it, though.  How would ship design work?  Do I have to design the hull before I'm allowed to try out equipment fits on it?  That's going to be annoying.
My thoughts would be to look for some mechanism where you can measure the degree of change.  A ship with all the same type and size of mechanisms is going to be more similar than a ship with the same size but different type, and so on.  Not sure exactly how you'd implement it, though.

C# Aurora / Re: Box Launcher Reloads
« on: July 26, 2017, 01:21:49 PM »
Somewhat late to the party here.  If we can avoid the micromanagement problems, I have no problem requiring all launchers be reloaded in hangar.

Below is an excerpt from the U.S. Naval Institute Blog regarding the replenishment of current VLS.

"Unfortunately, reloading VLS at-sea isn’t incorporated into the Navy’s logistical DNA in the same way refueling is. Reloading VLS cells in today’s status quo demands an industrially robust port facility with heavy equipment, trained rigging crews, and a large munitions storage facility. It is not uncommon to damage equipment, and people have been seriously injured during VLS loading and unloading evolutions. Experts at the Naval Weapons Stations and some Naval Support Facilities use cranes to unload spent canisters, move gas management system equipment, and place loaded canisters in cells. "
There's no IQ requirement to publish with USNI.  It's a lot like an internet forum, except that everyone involved has the letters USN after their name.  The reason the USN abandoned UNREP of VLS (which they used to have the capability to do) was that in the aftermath of the Cold War they were looking more at land-attack missions than air defense, and as such it wasn't really necessary, given the complications involved.  That said, I work across the street from the Naval Weapons Station in Seal Beach, CA, and they have like a couple of cranes.  Not big ones like you see in ports or to build skyscrapers, but the kind mounted on trucks.  And this is one of the leading weapons facilities for the Pacific Fleet.  I wouldn't want to do it at sea (missiles are big, ships move), but I don't think you'd have any real trouble doing it in any port, except for the paperwork.

Mechanics / Re: Change Log for v7.2 Discussion
« on: July 07, 2017, 03:30:53 PM »
Another question, sorry if I asked this before:
Will hydrosphere extent limit the maximum population possible if it is frozen solid?
Not having it do so seems like an invitation for hilarious mishaps when you pack Hoth full of people, melt it, and then realize that it has 99.9% hydrosphere.  Pack ice doesn't seem like a particularly good place to live, either, so keeping hydrosphere as a constant seems not entirely unrealistic.

C# Aurora / Re: C# Aurora Changes Discussion
« on: May 31, 2017, 09:45:29 AM »
I don't like the changes to missile engines.  The old system, where you had a flat multiplier for engine power, seemed to make more sense, and it's less likely to create odd results.  Missile engines will be designed differently from ship engines.  This happens in real life.  Only penalizing boosted engines makes multi-stage missiles more likely, particularly with the changes to launcher ROF (which I am very much in favor of, BTW).  A flat x2 to fuel burn would make the whole system make more sense.

Pages: [1] 2 3 ... 57