Author Topic: C# Aurora v0.x Suggestions  (Read 343206 times)

0 Members and 3 Guests are viewing this topic.

Offline sloanjh (OP)

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
C# Aurora v0.x Suggestions
« on: February 21, 2018, 12:15:53 PM »
Starting a suggestions thread per Steve's request.

Please be sure to post all suggestions for C# Aurora to this thread; this will help Steve keep track of them.  Any suggestions posted elsewhere are likely to be "lost" by Steve after he has read them the first time.

If discussions balloon (more than a few back-and-forth rounds) and/or go off-topic (into long historical, philosophical, reasonableness, etc. exchanges), please start a new thread and post a reference to that thread here.  Since Steve will be using this thread as his "suggestion database", we should try to keep the signal (specific suggestions) to noise (discussions thereof) down so that he can easily browse/find the suggestions.

If you suspect you're posting a controversial and/or major suggestion that will generate a lot of discussion, please start a new thread and post a synopsis and reference to that thread here.  That being said, please be conscious of the fact that Steve often starts new threads on specific topics to ask for input; we don't want to knock such threads off the front page by starting a bunch of small threads that don't generate a lot of discussion.

Thanks, and have fun!!

John
 

Offline Zincat

  • Captain
  • **********
  • Z
  • Posts: 566
  • Thanked: 111 times
Re: C# Aurora v0.x Suggestions
« Reply #1 on: February 21, 2018, 12:28:06 PM »
I would like to suggest a new way to exploit distant binary systems.

As we know, hyperdrive didn't really work that well and was removed. Frankly, I do not want to see it back, it would probably still be problematic. That, and having to have a new, different engine for all ships required to make the trip between the distant companions would be problematic.

I think a much more elegant and "realistic" solution would be, after researching an appropriate technology, the possibility to build in-system gates between stars. You could justify it as a technology that "replicates the natural lagrange points", only that because of the imperfect results due to it being artificial, it requires the mass of a star.

Mechanically, it would be similar to the already present gate constructors. You would build a "lagrange constructor" ship, with the appropriate module. Send it to a star. Order a "build gate to <other star in system>" command, and then wait until it is complete. That would create a one-way gate, as for the other normal type of system-to-system gates. If you want  a two-way artificial lagrange point, you would send the constructor to the other side and build the gate on that side as well.

I hope that this solution would be relatively simple to implement, and once it's done it can work with the already present code for routing ships. And it would allow to finally use systems with distant stars companions.
« Last Edit: February 21, 2018, 01:01:30 PM by Zincat »
 
The following users thanked this post: TMaekler

Offline Dr. Toboggan

  • Chief Petty Officer
  • ***
  • D
  • Posts: 30
  • Thanked: 4 times
Re: C# Aurora v0.x Suggestions
« Reply #2 on: February 21, 2018, 02:28:16 PM »
I would like to suggest a new way to exploit distant binary systems.

As we know, hyperdrive didn't really work that well and was removed. Frankly, I do not want to see it back, it would probably still be problematic. That, and having to have a new, different engine for all ships required to make the trip between the distant companions would be problematic.

I think a much more elegant and "realistic" solution would be, after researching an appropriate technology, the possibility to build in-system gates between stars. You could justify it as a technology that "replicates the natural lagrange points", only that because of the imperfect results due to it being artificial, it requires the mass of a star.

Mechanically, it would be similar to the already present gate constructors. You would build a "lagrange constructor" ship, with the appropriate module. Send it to a star. Order a "build gate to <other star in system>" command, and then wait until it is complete. That would create a one-way gate, as for the other normal type of system-to-system gates. If you want  a two-way artificial lagrange point, you would send the constructor to the other side and build the gate on that side as well.

I hope that this solution would be relatively simple to implement, and once it's done it can work with the already present code for routing ships. And it would allow to finally use systems with distant stars companions.

Could it be easier to make it more likely to have jump points have a greater chance of connecting to other systems? I recall that at some point in either The Mote in God's Eye or The Gripping Hand that oftentimes it is easier for ships to take a route through more systems, but the overall distance covered is less.  So instead of trying to go to System-1 B from the jump point right next to System-1 A, you could go through System-2, which links to System-3, which leads to System-4, which connects to a point right next to System-1 B. 
I would personally just like a greater chance of systems connecting to each other, so that the galactic map is more of a web than a subway system, but I am not sure whether that would be harder to implement than artificial Lagrange points.  It just gets a bit tedious when all paths lead back to Sol.
 
The following users thanked this post: Alucard

Offline Frank Jager

  • Chief Petty Officer
  • ***
  • F
  • Posts: 36
  • Thanked: 15 times
Re: C# Aurora v0.x Suggestions
« Reply #3 on: February 21, 2018, 07:50:24 PM »
Re-Posting from the Semi Official 7. x suggestions thread.  (Cleaned up and made relevant to significant changes in Aurora C#)

TL/DR Make Kinetic weapons useful and add a logistical ammunition component into the game. 

I propose a change to the weapons mix that I hope is easy to implement.  This should complement the recent changes to Missile design.

Kinetic Weapons
Railguns
Specifications;
Non Turretable.
Spinal design choice.  2x HS Requirement, but with a 33% increase in BP, increase calibre size by one step.
Long range.
          Able to fire at maximum range with a 4x BFC.
Only produce one projectile per times fired.
Maintain the Missile damage profile.
Calibre and Missile Warhead size damage.
          120mm      5 WH (25 Damage,    5 Layers of Armour Penetration)     10 HS
          150mm      6 WH (36 Damage,    6 Layers of Armour Penetration)     12 HS
          175mm      7 WH (49 Damage,    7 Layers of Armour Penetration)     15 HS
          200mm      8 WH (64 Damage,    8 Layers of Armour Penetration)     17 HS
          250mm      9 WH (81 Damage,    9 Layers of Armour Penetration)     20 HS
          300mm    10 WH (100 Damage, 10 Layers of Armour Penetration)    30 HS
          300mm    11 WH (121 Damage, 11 Layers of Armour Penetration) [Spinal Only]
Firing Rate and Tech Progression.
          Base     120 Seconds
          Double    60 Seconds
          Triple       30 Seconds
          Quadruple 15 Seconds
Require 1 MSP (Missile Size Point) per shot of ammunition.

Gauss Cannon
Specifications;
These weapons should have;
The ability to be turreted.
Barrel Tech Line.
             Single        1 Projectile
             Dual          2 Projectiles
             Tri             3 Projectiles
            Quad          4 Projectiles
Medium range, max range at 2x BFC, accuracy increases with bigger BFCs.
Calibre, Missile Warhead Damage Profile and HS.
                30mm            3 Damage, 1 Layers of Armour Penetration)    3 HS
                40mm            8 Damage, 2 Layers of Armour Penetration)    5 HS
                50mm          15 Damage, 3 Layers of Armour Penetration)    7 HS
                60mm          24 Damage, 4 Layers of Armour Penetration)  10 HS
                70mm          35 Damage, 5 Layers of Armour Penetration)  12 HS
                80mm          48 Damage, 6 Layers of Armour Penetration)  15 HS
Firing Rate and Tech Progression.
          Base       60 Seconds
          Double    30 Seconds
          Triple      15 Seconds
Require 0. 5 MSP (Missile Size Point) per shot of ammunition.

Auto Cannon
Specifications;
Turret-able
Provides CIWS component to allow civilians access to the weapons tech for defensive purposes.
Max Size 1HS.
          Reduction techs.
              100% Size   100% Accuracy
              75% Size      80% Accuracy
              50% Size      60% Accuracy
              25% Size      40% Accuracy
Baseline 10 projectiles per 5 second increment (120 Rounds Per Minute), double and triple fire rate techs
1 Damage per projectile.
Max Range 10km
0. 1 MSP (Missile Size Point) per increment of ammunition. 

Other Considerations
A spinal design tag added to prevent more than a SINGLE spinal weapon regardless of type, similar to the tag given to engines.
A Minimum targetable (Combat) range of 2km, to take advantages of the increase in processor time.  (Ignorant of C# code base, if this is not true please let me know. )

Ammunition
Production.  1 point of Ammunition requires . 25 Duranium and can be produced in ordnance factories.
Types.  There should only be one type of ammunition and it is used universally between the different weapon systems.
(Half Ton slugs of Duranium cut to size on-board the ship)
Transport.  These should only be able to be transported within a magazine, civilian or military.

It doesn't make sense to me that civilian ships can have CIWS missile defenses but not have to pay any cost for the systems. 


Regards

Frank
 

Offline ardem

  • Rear Admiral
  • **********
  • a
  • Posts: 814
  • Thanked: 44 times
Re: C# Aurora v0.x Suggestions
« Reply #4 on: February 21, 2018, 10:37:49 PM »
I believe orbiting space craft should get a 50% or more reduction to their profile, as the background noise of the planet hides their signature, or simulates they are on the other side, this would result in some nice ambushes, in have space terrain involved. The biggest problem with Aurora Sensor ability is it see everything even when terrain features could be used.

(Did not see this new post so posting it here to make sure it added into the suggestions page.)
 
The following users thanked this post: obsidian_green

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #5 on: February 22, 2018, 06:28:45 AM »
Defining which events break up the time progression cycle

Copy of posting from here:
http://aurora2.pentarch.org/index.php?topic=9835

Would be nice if we could choose which actions stop a time progression cycle early and which don't. At least for some of them I cannot understand why they stop it early.
 
The following users thanked this post: Scandinavian, Bughunter, obsidian_green

Offline the obelisk

  • Sub-Lieutenant
  • ******
  • t
  • Posts: 109
  • Thanked: 11 times
Re: C# Aurora v0.x Suggestions
« Reply #6 on: February 22, 2018, 08:56:27 AM »
Quote from: TMaekler link=topic=9841. msg106753#msg106753 date=1519302525
Defining which events break up the time progression cycle

Copy of posting from here:
hxxp: aurora2. pentarch. org/index. php?topic=9835

Would be nice if we could choose which actions stop a time progression cycle early and which don't.  At least for some of them I cannot understand why they stop it early.

Since this is being reposted, I'll repost my agreement.

Have to agree.    A toggle would be nice, at least for some things.    I want to know if there's a mineral shortage, but if I can't deal with the problem immediately, I don't wan't that shortage preventing me from using the auto feature.
 

Offline Tuna-Fish

  • Chief Petty Officer
  • ***
  • T
  • Posts: 30
  • Thanked: 10 times
Re: C# Aurora v0.x Suggestions
« Reply #7 on: February 22, 2018, 10:34:22 AM »
So, my current campaign is a bit bogged by micromanagement, and I couldn't help but think that three orders would greatly reduce the necessary amount of clicks.   In order of importance:

1.   Tractor any ships. 

Available on a fleet that contains at least one ship with tractor beams when targeting any other fleet.   When the fleet arrives at the target, every ship with a tractor beam in it attempts to tractor one ship from the target (in any order).   The order succeeds and execution of order list continues if at least one ship was tractored, if no ships were tractored (or target fleet no longer exists, etc) the order list of the fleet is cleared and a message is printed. 

Rationale: Moving 200 terraforming satellites is a total pain currently, as you have to do many clicks per each satellite.   With this, you could set up the target fleet, take your tug fleet, order "tractor any ships at old terraforming fleet -> release tractored ships at new terraforming fleet" and hit repeat and the entire terraforming fleet gets moved (eventually). 

2.   Unload cargo. 

Available for fleets with any cargo space (possibly only if something occupies that space at this point in orders?) when targeting anything with any cargo space or a colony.   Attempts to unload everything from own cargo space to target.   Succeeds if after the order there is nothing in own cargo space (even if there was nothing to start with!), fails with message and order clearing if after this there is still something loaded. 

Rationale: reduces clicks when moving around various stuff.   Allows the use of a single order to guarantee that after that the cargo space is clear.   No more fleets moving minerals with a third of their capacity because you forgot to unload that one jump gate construction module!

3.   Load any ship components

Available for fleets with some cargo space when targeting a colony.   Loads the cargo space full of any ship components (regardless of type) from the colony.   Succeeds if at least one component was loaded, fails with message if none were. 

Rationale: right now, moving a random assortment of ship components takes a lot of clicks. 

Would there be any chance of having something like those for C# Aurora?
 
The following users thanked this post: Scandinavian, Alucard, Rye123

Offline King-Salomon

  • Lieutenant
  • *******
  • Posts: 153
  • Thanked: 38 times
Re: C# Aurora v0.x Suggestions
« Reply #8 on: February 22, 2018, 10:44:12 AM »
About Orbital Habitats:

wouldn't it make more sense to chance the "Commander" of a non-military habitat to a "Civil Admin slot" instead of a Naval Commander slot? The example habitat Steve posted today is a pure living station, so a civil commander would be better suited than a military officer.. a miltary station should still need a military commander

Quote
Orbital Habitats

This is a copy of a post in the VB6 7.2 Changes List. I didn't release the updated VB6 version so this is still a change from the released VB6 Aurora.

The population capacity of orbital habitat modules has been increased from 50k to 200k. In combination with the new 'No Armour' option this significantly reduces the cost of building orbital habitats. For example, the habitat shown here supports a population of one million for a cost of 1145 BP. To support one million colonists with infrastructure on a colony cost 2.0 world with acceptable gravity would cost 400 BP, so the colony cost would have to be approaching 6.0 before the Orbital Habitat became cheaper. For low-gravity worlds it is comparable with the cost of low-gravity infrastructure and it is the only option for high gravity worlds or small bodies with low population capacities.

Sidon class Orbital Habitat      1,252,970 tons       162 Crew       1144.7 BP       TCS 25059    TH 0    EM 0
1 km/s      No Armour       Shields 0-0     HTK 132      Sensors 1/1/0/0      DCR 1      PPV 0
MSP 0    Max Repair 200 MSP
Habitation Capacity 1,000,000   
Lieutenant Commander    Control Rating 1   BRG 
Intended Deployment Time: 3 months   

Commercial Active Sensor (1)     GPS 1920     Range 27.3m km    Resolution 120

This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as an Orbital Habitat for construction purposes
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11644
  • Thanked: 20339 times
Re: C# Aurora v0.x Suggestions
« Reply #9 on: February 22, 2018, 10:46:51 AM »
About Orbital Habitats:

wouldn't it make more sense to chance the "Commander" of a non-military habitat to a "Civil Admin slot" instead of a Naval Commander slot? The example habitat Steve posted today is a pure living station, so a civil commander would be better suited than a military officer.. a miltary station should still need a military commander

It would add complexity to allow civilians to command naval ships (and give them naval-related bonuses) and I don't think the game play benefit would be worth it.
 

Offline Nori

  • Bug Moderators
  • Lt. Commander
  • ***
  • Posts: 234
  • Thanked: 42 times
  • Discord Username: Nori Silverrage
  • Bronze Supporter Bronze Supporter : Support the forums with a Bronze subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: C# Aurora v0.x Suggestions
« Reply #10 on: February 22, 2018, 02:38:59 PM »
Just thought of this, could FACs get a minor tracking speed bonus? They are so similar to fighters, but lose the best part (from a direct fire perspective). If they could get a 2x bonus (vs the 4x for fighters).

Can a ship be setup to do something once x is reached at another location? For instance, it'd be great to have a cargo group setup to load materials from a colony once that colony hits a certain level.

Similar to that, can a order template have more flexibility for modifying earlier orders? For instance, if I have a template to pickup mines, it'd be great if I could easily change that to automated mines without redoing the whole template, or changing the final unload location (same system though).
 

Offline swarm_sadist

  • Lt. Commander
  • ********
  • s
  • Posts: 263
  • Thanked: 21 times
Re: C# Aurora v0.x Suggestions
« Reply #11 on: February 22, 2018, 04:04:02 PM »
Just thought of this, could FACs get a minor tracking speed bonus? They are so similar to fighters, but lose the best part (from a direct fire perspective). If they could get a 2x bonus (vs the 4x for fighters).

Perhaps something like a to-hit chance based on the size of the target instead of a fixed, arbituary number. A smaller fighter could just be harder to target than a large fighter, and a larger fighter is harder to hit than an FAC.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11644
  • Thanked: 20339 times
Re: C# Aurora v0.x Suggestions
« Reply #12 on: February 22, 2018, 04:09:21 PM »
For instance, it'd be great to have a cargo group setup to load materials from a colony once that colony hits a certain level.

You can already do this one in VB6. The move order is "Load Mineral when X available"

 
The following users thanked this post: Nori

Online Conscript Gary

  • Lt. Commander
  • ********
  • Posts: 292
  • Thanked: 27 times
Re: C# Aurora v0.x Suggestions
« Reply #13 on: February 22, 2018, 11:47:12 PM »
This is almost more of an idle thought than a fully-weighed suggestion, but-

At present, the only hard distinctions between ship classes are as follows: Whether a ship has military or commercial drives for the purposes of using jump drives, whether a ship is military or civilian for maintenance and morale purposes, and whether a ship is a fighter or literally anything else.

That last one sticks out to me as the most 'arbitrary' of them. Whether you're a conventional empire, a fledgling TN race, or someone with mastery of the stars strong enough to challenge the [spoilers]- a fighter factory can only produce designs up to 500 tons, across the entire span of the game. Your industrial base and shipyard tech might reach the point where you have gargantuan warships as your standard combatants, but a fighter will only ever be 500 tons or less.

So, my suggestion is to add a new tech line that determines the capacity of your fighter factories. It can be an extremely expensive tech, but I feel like allowing even a bit of wiggle room in the flexibility of those factories would jive well with overall progression.
 
The following users thanked this post: orfeusz, Tree, Nori, Rye123

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #14 on: February 23, 2018, 12:24:32 AM »
Initiate Unrest:

For roleplaying reasons it might be nice if the SpaceMaster could initiate (and end) events of unrest on a certain colony.
Example: I conquered an alien race with three planets in one system and decided to relocate all of them to one colony (to repopulate the one I am emptying with my own pop). Doing that in real life would cause some kind of protests - so to simulate this in game it would be nice if the spacemaster can set flags so that the political and economical modifiers would increase.