Author Topic: Suggestions Thread for v2.0  (Read 85330 times)

0 Members and 1 Guest are viewing this topic.

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: Suggestions Thread for v2.0
« Reply #75 on: August 17, 2022, 07:27:14 PM »
If there's a fuel hub stationed at a DSP, it would be nice if the "refuel from/transfer fuel to Hub" actions were listed at the DSP, so that you don't have to specifically target the fleet the hub is contained in.

What do you suggest happens if there are multiple hubs in different fleets at that location? One might be temporarily station or passing by, as rare a case that might be.
 

Offline Destragon

  • Lieutenant
  • *******
  • D
  • Posts: 151
  • Thanked: 87 times
Re: Suggestions Thread for v2.0
« Reply #76 on: August 17, 2022, 08:54:12 PM »
If there's a fuel hub stationed at a DSP, it would be nice if the "refuel from/transfer fuel to Hub" actions were listed at the DSP, so that you don't have to specifically target the fleet the hub is contained in.

What do you suggest happens if there are multiple hubs in different fleets at that location? One might be temporarily station or passing by, as rare a case that might be.
The ship would move to the DSP, then upon arrival look for a hub that is stationed there.
What happens when you tell a ship to refuel from a hub at a fleet that has multiple hubs in it and one of them gets tractored away by a tug? Probably the same kinda stuff.
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2991
  • Thanked: 2248 times
  • Radioactive frozen beverage.
Re: Suggestions Thread for v2.0
« Reply #77 on: August 17, 2022, 09:21:36 PM »
The ability to award medals to ships, or edit their history tab. I really like to build up history of my ships particularly which battles they were a part of. But I can only award medals to officers of those ships, not the vessel it self. I can't edit its history to include some information about it either (If one can do it, please tell me how, I don't see any edit button to do so)

I like the idea, but what would happen mechanically? The medals currently go to the officer's promotion score. Ships don't have that. What would you propose it do?

Collect dust in the Captain's quarters Tastefully adorn the prow of the ship for roleplay purposes.  :)
 
The following users thanked this post: papent, Kiero, Warer, Pury

Offline Pury

  • Warrant Officer, Class 2
  • ****
  • Posts: 52
  • Thanked: 23 times
Re: Suggestions Thread for v2.0
« Reply #78 on: August 18, 2022, 08:43:35 AM »
Ability to set fleet color in naval organisation window so one can easier and better organise his navy.
 
The following users thanked this post: papent

Offline Barkhorn

  • Commodore
  • **********
  • B
  • Posts: 719
  • Thanked: 133 times
Re: Suggestions Thread for v2.0
« Reply #79 on: August 18, 2022, 08:23:40 PM »
Two related suggestions to drastically improve conditional orders:

  • Let us have more than two.  Preferably an arbitrary number.
  • Let conditional orders trigger order templates.  I understand this can cause problems if, say, the condition happens but the orders template is impossible for whatever reason.  Best option here is to just throw an interrupt and tell the player to deal with it.
 

Offline Kiero

  • Bronze Supporter
  • Lieutenant
  • *****
  • Posts: 175
  • Thanked: 118 times
  • In space no one can hear you scream.
  • Bronze Supporter Bronze Supporter : Support the forums with a Bronze subscription
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
    2024 Supporter 2024 Supporter : Donate for 2024
Re: Suggestions Thread for v2.0
« Reply #80 on: August 19, 2022, 02:58:18 PM »
Mines.

- Mines as a variant of a missile whose engine is dormant at the start.
- Mines. Just like missiles with Active sensors but will act when an enemy ship is detected (like 10k km at start and 500k at top tech).
- Minelayer module (or the ability of a missile launcher during design, more effective than a missile launcher).
- Minesweeper module (the module that can sweep enemy or friendly mines or probes if its neutralization range is greater than mine detection range).
- Mines that can be launched as a two-stage missile or as a mine.
 

Offline Barkhorn

  • Commodore
  • **********
  • B
  • Posts: 719
  • Thanked: 133 times
Re: Suggestions Thread for v2.0
« Reply #81 on: August 19, 2022, 03:08:03 PM »
Mines.

- Mines as a variant of a missile whose engine is dormant at the start.
- Mines. Just like missiles with Active sensors but will act when an enemy ship is detected (like 10k km at start and 500k at top tech).
- Minelayer module (or the ability of a missile launcher during design, more effective than a missile launcher).
- Minesweeper module (the module that can sweep enemy or friendly mines or probes if its neutralization range is greater than mine detection range).
- Mines that can be launched as a two-stage missile or as a mine.

Mines already exist, and iirc are no longer bugged.  Make a two-stage missile with one or more sensors and no engine as a first stage, and one or more missiles as a second stage.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: Suggestions Thread for v2.0
« Reply #82 on: August 19, 2022, 05:24:03 PM »
Mines.

- Mines as a variant of a missile whose engine is dormant at the start.
- Mines. Just like missiles with Active sensors but will act when an enemy ship is detected (like 10k km at start and 500k at top tech).
- Minelayer module (or the ability of a missile launcher during design, more effective than a missile launcher).
- Minesweeper module (the module that can sweep enemy or friendly mines or probes if its neutralization range is greater than mine detection range).
- Mines that can be launched as a two-stage missile or as a mine.

Mines already exist, and iirc are no longer bugged.  Make a two-stage missile with one or more sensors and no engine as a first stage, and one or more missiles as a second stage.

Note, the second stage should also have a sensor as targetless missiles despawn
 

Offline ArcWolf

  • Lieutenant
  • *******
  • A
  • Posts: 160
  • Thanked: 80 times
Re: Suggestions Thread for v2.0
« Reply #83 on: August 19, 2022, 09:44:15 PM »
A "reassign Ground (officers)" and a "Unassign All Ground" and "Unassign all Naval" Buttons would be nice in the Commanders window.
 

Offline pwhk

  • Warrant Officer, Class 1
  • *****
  • p
  • Posts: 83
  • Thanked: 32 times
Re: Suggestions Thread for v2.0
« Reply #84 on: August 20, 2022, 09:42:15 AM »
Currently commanders are DNR (Do Not Retain) by default when they retire/die. While keeping them all would probably bloat the DB unnecessarily, what about having DNR disabled when they have certain medals, configurable from the medals screen?
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: Suggestions Thread for v2.0
« Reply #85 on: August 20, 2022, 10:13:57 AM »
Currently commanders are DNR (Do Not Retain) by default when they retire/die. While keeping them all would probably bloat the DB unnecessarily, what about having DNR disabled when they have certain medals, configurable from the medals screen?

Sounds like it would work well with the story character flag
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2991
  • Thanked: 2248 times
  • Radioactive frozen beverage.
Re: Suggestions Thread for v2.0
« Reply #86 on: August 20, 2022, 11:27:14 AM »
Suggestion: Add a separate tech line to upgrade ground unit racial attack.

Rationale: Currently, GU racial attack is improved by the "caliber" tech for Lasers, Railguns, Plasma, and Particle Beams. This means that if a race wants to use missiles, Gauss, HPM, or Mesons as their main weapon(s), their ground units will be basically screwed unless they invest into one of the former four weapon types. This can be worked around most easily by developing plasma weapons, but it seems silly to force a race to do this if it is not within the player's roleplay canon for that race, and it adds an extra RP burden at the start of the game if the player wants to stay within the allocated starting RP. Basically, the current mechanics effectively are a nerf to missiles and mesons, neither of which needs the extra hurting in the current state of Aurora.

Additionally, this mechanism can upset GU balance if the player chooses to research very cheap Plasma weapons to boost GU attack, as the low RP cost means that GU racial attack can easily reach ~50% greater than racial armor, which tends to upset the ground combat balance in a way that minimizes the value of armor and reduces interesting decision-making as a result - ground combat is intrinsically balanced around the expectation that racial attack and armor are usually equal at a given nominal tech level. I don't think it is good for interesting gameplay decisions to be flattened if the player decides they want plasma guns for their ships - note that plasma is just fine for ships and doesn't need to be a special bonus for ground forces to be useful or viable.

Finally, while this isn't really a rationale for a gameplay change, I will observe that for DB modders it is not possible to change the ship armor techs without affecting the ground unit balance. Pulling GU attack into its own tech line would allow a DB modder to rebalance GU attack if they decide to change the ship armor techs.
 
The following users thanked this post: Scandinavian, El Pip, Droll, Kiero, superstrijder15, BAGrimm, Snoman314

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: Suggestions Thread for v2.0
« Reply #87 on: August 20, 2022, 11:39:14 AM »
I'm reposting this from it's own thread as I think it might be interesting to at least think about:

Technically, you CAN attack their home system, sorta. If you board a vessel of theirs that then retreats and is captured in that system, you are free to do whatever you like there. Good luck...
Steve also stated that their system doesn't really serve a practical purpose in terms of production or having a functional colony at all if I remember correctly. Even if you somehow managed to glass their planet, the ships are spawned in via script, so what Zeebie fears might be correct: There is likely an infinite and regular number of them. (and killing will only stall them)

The fact that this is the first non-npr threat that can research doesn't lie well with me either through this. They are the only ones you can never shut down, and they will always improve? It really does sound quite bothersome, which is a shame, because otherwise I like their idea.

Now, if there were more instances of this race that could spawn, kind of how remnants could be considered their own local faction in each system they are in, that I would welcome. A new raider clan once in a while to keep the game interesting, that sounds nice to me.
The same invincible and improving threat all the time however seems to take away control from the player, which is not good for sandbox. I will test how I can edit them in database to see if they can be 'defeated' there after some time. If that doesn't work, I would probably deactivate them pending further player reports.

Spoiler for Rahkas rant:

The problem I have with stuff like Rakhas for example spawning an instance for every planet is that after a while you can get clutter in the intel screen of all these dead races. It also is a bit redundant and unnecessary for the Rakhas to have an instance per planet as due to their nature they will never interact with other Rakhas and have very simple and uniform foreign policy regarding NPRs and player races.

But I digress

Spoiler for my Raider rework:

I actually really support the idea of there being a % chance for a system that you first explore to be declared a raider system where they have a colony and basic infrastructure. You could then add a special raider-only component to their ships that allows them to partially circumvent the JP network by allowing them spool up this component and enter anywhere on the outskirts of any system connected to their current system through JPs. This component would probably have a decently sizeable cooldown so it can't be spammed and not be mutually exclusive with the existing jump drives, allowing the raiders to also use JPs like everyone else, maybe as a desperate escape attempt.

This means that you can predict where the pirates will appear/travel through based on where their system(s) are but not completely be able to stop them through JP blockades. Giving the player the choice either escort everything, or build surveillance on problem frontier systems to spot entering pirates and remove them before they move deeper into your territory, allowing you to maybe not escort absolutely all civilian traffic in the core of your empire.

Under this rework, you would be able to have multiple Raider systems each emanating an aura of piracy around them from different directions, with the colony in the raider system (would be cool if they were the new DSPs so that even otherwise empty systems are candidates) producing a set amount of resources (+ whatever is looted) and with certain shipyard capacity producing new problems until dealt with. It might be a good idea to give the raiders strong static defenses for their colonies/defensive fleets so that the player needs to assemble some force to remove them, possibly different colony sizes for the raiders too for varying severity.


I might repost this to the suggestions thread if it finds popularity here but I really do think these new Raiders would fit the "no exceptions" philosophy of C# much better than "there is a magic system you can never legitimately access".

One other addition that Vandermeer points out is the idea of potentially having Raiders spawn in an as yet undiscovered system. This could be done by having a setting for raider generation % per system and when it procs. The game picks a free JP and generates a path of undiscovered systems that is lets say 2-5 jumps away. Forcing the player to spend time actually finding the hideout. It also generates a use-case for those stars and planets that are 100s of billions of KM away, as thanks to their unique travelling the raiders could have those as their pirate havens. Especially if you combine this with their colonies being DSPs.
« Last Edit: August 20, 2022, 11:43:27 AM by Droll »
 
The following users thanked this post: Mayne

Offline alex_brunius

  • Vice Admiral
  • **********
  • Posts: 1240
  • Thanked: 153 times
Re: Suggestions Thread for v2.0
« Reply #88 on: August 20, 2022, 02:44:09 PM »
Suggestion: Add a separate tech line to upgrade ground unit racial attack.

Rationale: Currently, GU racial attack is improved by the "caliber" tech for Lasers, Railguns, Plasma, and Particle Beams. This means that if a race wants to use missiles, Gauss, HPM, or Mesons as their main weapon(s), their ground units will be basically screwed unless they invest into one of the former four weapon types. This can be worked around most easily by developing plasma weapons, but it seems silly to force a race to do this if it is not within the player's roleplay canon for that race, and it adds an extra RP burden at the start of the game if the player wants to stay within the allocated starting RP. Basically, the current mechanics effectively are a nerf to missiles and mesons, neither of which needs the extra hurting in the current state of Aurora.

Additionally, this mechanism can upset GU balance if the player chooses to research very cheap Plasma weapons to boost GU attack, as the low RP cost means that GU racial attack can easily reach ~50% greater than racial armor, which tends to upset the ground combat balance in a way that minimizes the value of armor and reduces interesting decision-making as a result - ground combat is intrinsically balanced around the expectation that racial attack and armor are usually equal at a given nominal tech level. I don't think it is good for interesting gameplay decisions to be flattened if the player decides they want plasma guns for their ships - note that plasma is just fine for ships and doesn't need to be a special bonus for ground forces to be useful or viable.

Finally, while this isn't really a rationale for a gameplay change, I will observe that for DB modders it is not possible to change the ship armor techs without affecting the ground unit balance. Pulling GU attack into its own tech line would allow a DB modder to rebalance GU attack if they decide to change the ship armor techs.

I would like to see it be slightly more nuanced in a way where different types of space weapons synergize with different types of ground offense instead. I don't mind ground being a secondary consideration with the focus being on Space weapons.

My suggestion is to split offensive ground weapons damage into 3 categories:
  • Small arms damage (rifles = PWL,PW,PWI,CAP,LAA ...) which can use highest level of gauss rate of fire or capacitor recharge (balanced in a way that compensates for different RP costs)
  • Direct fire damage (vehicle guns = LAC, MAC, MAA, MAV ...) which is using same as current (lasers/railguns/plasma/particle beam caliber, but also balanced such that carronades are not overly valuable for RP cost)
  • Explosives damage (artillery = LB, MB ... ) which use missile damage as a base

It would also be cool if the UI displayed which current tech was providing the damage level so it's clear what needs to be researched to increase it further.
 
The following users thanked this post: superstrijder15

Offline alex_brunius

  • Vice Admiral
  • **********
  • Posts: 1240
  • Thanked: 153 times
Re: Suggestions Thread for v2.0
« Reply #89 on: August 20, 2022, 05:33:26 PM »
UI quality of life improvement suggestion:
Enable double clicking on the Installation type line to bring up the "Edit Supply" or "Edit Demand" window of that type to not have to select the type in dropdown first and then click the button at the bottom of the screen ( possibly also prefill the list with a few common ones you want to move around like Infrastructure, Mass Driver, Automine, DSTS for all new colonies with 0/0 set for even quicker access ):







 
The following users thanked this post: Zeebie, Kyle