Author Topic: Suggestions Thread for v2.4.0  (Read 252111 times)

0 Members and 1 Guest are viewing this topic.

Offline alex_brunius

  • Vice Admiral
  • **********
  • Posts: 1326
  • Thanked: 211 times
Re: Suggestions Thread for v2.4.0
« Reply #435 on: June 30, 2024, 09:15:36 AM »
Add one more column in the minerals search/survey window for Totals (Similar as the Total displayed in Economics -> Mining tab)
- Search for Total Quantity
- Search for Total Accessibility


This would be great to quickly filter out interesting potential colonies with high total Quantity/Accessibility for Minerals
 
The following users thanked this post: BAGrimm

Offline serger

  • Commodore
  • **********
  • Posts: 656
  • Thanked: 129 times
Re: Suggestions Thread for v2.4.0
« Reply #436 on: June 30, 2024, 12:46:33 PM »
For me it feels highly unrealistic that you can use 100% of all Construction Capacity on a single project, and currently me + alot of other players often use "houserules" or enforced restrictions on ourself to disallow it. At least for larger main colonies.

So what if you had to assign a Commander (Civilian Administrator) for each Construction Project similar to how we do with research and said Administrators Admin rating was used as a cap for how many of the total Cap % that could be allocated to the Project?

It's actually the same problem we've discussed in a neighbouring thread: production, the same as research, in Aurora is something like always-an-emergency.

Making a hard cap the same way as with research would be slightly better in my opinion then having no limits at all, yet there would be more problems:

1. When a production admin dies/retires/removed, the project will be dissolved the same as with research projects (for the same reason - zeroed cap). The player will need to remember what a project it was to restore it. Yet production projects are harder to memorize, because it's item and quantity, not just item.

2. There will be a scaling problem: make a cap absolute (in BPs) and it would be usually too large for the smaller colonies / slow starts and too small for the major ones / late game; make it relative (in percents of the colony production) and it's just strange why admin's abilities are changing depending on a planet.

Overall, I'm sure the level of micromanagement necessary will quickly freak up most of the players.

So, a better solution will be, again, diminishing returns. The bigger part of the colonial production you're directing towards "guns" - the more "butter-suitable" production chains you need to use for "guns" - the lesser production efficiency the project has. Simple to code, self-scalable, smoothes out the micromanagement problem.
 

Offline kks

  • Lieutenant
  • *******
  • Posts: 156
  • Thanked: 31 times
Re: Suggestions Thread for v2.4.0
« Reply #437 on: June 30, 2024, 02:24:03 PM »
The best solution imho would be doing it like research or shipyard projects.

Each building/station/component/... gets added a fixed build time in addition to its cost. Which means a maximum construction you can put in it. If you have more BP you can build several items in parallel, as you can when doing ship construction(more slipways). If you have less, it takes longer to build, just like if you haven't enough labs for your scientist working on a project.

It also has no problems with scales. For a small colony, it is actually much more realistic to concentrate their efforts, for example on a new DSTS to have a warning system in place. A large homeworld would however have much more capacity than can be efficently used on one DSTS. It would have to spread its construction capacity on several projects(e.g many DSTS in parallel) to not run into overallocation problems.

While thinking about it, construction really is the only place it still works without an limit on speed? And GU recruitment, which mechanics I misremembered at first.
For science we have an limit by the administration level of the researcher, with shipbuilding we have a fixed build rate per shipyard and a ship can only build in one shipyard at a time.

However, this approach requires the player to think much more into the future. You can't simply pop a DSTS in front of the queue and have it build in a few days, if you find yourself lacking one. Which, in my mind is a plus.


Any system which allows to push more ressources than the usual into a project(e.g. in an emergency) to complete it faster with diminishing returns, could be on top. We however have no precedent of any such mechanic in Aurora yet, so that would be a major change in design philosophy imho.
« Last Edit: June 30, 2024, 02:32:09 PM by kks »
 

Offline alex_brunius

  • Vice Admiral
  • **********
  • Posts: 1326
  • Thanked: 211 times
Re: Suggestions Thread for v2.4.0
« Reply #438 on: June 30, 2024, 02:29:47 PM »
1. When a production admin dies/retires/removed, the project will be dissolved the same as with research projects (for the same reason - zeroed cap). The player will need to remember what a project it was to restore it. Yet production projects are harder to memorize, because it's item and quantity, not just item.

IMO That is just a question of clunky UI/mechanic design. Why not simply allow research (and if in this suggestion) Construction projects with no leaders and no bonuses?

Heck the UI could even show prior numbers of labs/% commited (target) somewhere if the leader dies and it is above the minimum capacity suddenly.

That in combination with proper interups to highlight what research (and construction) projects that are leaderless and need attention would make it easy to identify and rectify such problems. No need to remember anything when we have a database that is excellent at remembering 100% of all the things if we can just tell it to do so.
« Last Edit: June 30, 2024, 02:31:52 PM by alex_brunius »
 

Offline serger

  • Commodore
  • **********
  • Posts: 656
  • Thanked: 129 times
Re: Suggestions Thread for v2.4.0
« Reply #439 on: June 30, 2024, 02:53:16 PM »
Database remembers, code contains inevitable bugs. Steve is the only developer, so we need to suggest as simple-to-code solutions as it's possible. Saving previous caps and bonuses and new interrupts and hints is a bit too much to counter just a half of the awkwardnesses of this mechanics, I think.

 

Offline paolot

  • Lt. Commander
  • ********
  • p
  • Posts: 255
  • Thanked: 55 times
Re: Suggestions Thread for v2.4.0
« Reply #440 on: June 30, 2024, 03:24:56 PM »
When a scientist dies, I go through the available technologies to find the incomplete one. Only need to read the event of the death.
Then, in the Summary tab, if I find a building with decimal digits, I can decide if I wish to build some more.
Both, I can't see any need of UI modifications or explicit warnings, if I understand well the notes.
« Last Edit: June 30, 2024, 03:31:11 PM by paolot »
 

Offline wedgebert

  • Ace Wiki Contributor
  • Warrant Officer, Class 1
  • ****
  • w
  • Posts: 90
  • Thanked: 34 times
Re: Suggestions Thread for v2.4.0
« Reply #441 on: June 30, 2024, 04:14:03 PM »
Here was my idea to help with the research queues being lost on scientist death that could be modified to also work with the construction efficiency being discussed.

Basic version:

All creation of either a Research Plan or a Research Center. The former is an abstract idea (like a fleet) while the latter is an actual building you construct, but they work identically. They have

  • A scientist
  • A specified number of research labs
  • A research queue

Basically it works like research queues do now, but the queue is assigned to the plan/center rather than the scientist. If the scientist dies, the center idles (with a notification) until a new scientist is assigned to it. If the new scientists cannot manage the labs assigned, the excess are unassigned, ready to be used elsewhere.

The same thing could work with construction, only with the different officer type.



Immersive version:

When a new scientist/builder is assigned, the research/construction bonus is set back to 0%. Then every construction cycle, it increases by X% such that after 5 years (or whatever), it will be the full bonus for that officer. This represents all the normal "new job" acclimatation (learning the new facilities, hiring/training new junior staff, bending the bureaucracy to your whims, etc)

However you can also assign a 2nd officer as a protege/apprentice. They don't provide any bonuses to research/construction, but they start that timer as soon as they're assigned. So, if the lead scientist dies after only four years, the protege is already 80% ready of the way to full capacity.
 

Offline Kaiser

  • Commander
  • *********
  • K
  • Posts: 396
  • Thanked: 72 times
Re: Suggestions Thread for v2.4.0
« Reply #442 on: July 01, 2024, 12:57:57 AM »
Would it be possible to insert ground troops insigna? It would add a lot of flavour to gameplay having our space divisions with different graphic insigna + I think it would help someohow to reduce the visual amount of information and mess related to the ground troop  :)
 
The following users thanked this post: kks, serger

Offline ChubbyPitbull

  • Gold Supporter
  • Lieutenant
  • *****
  • C
  • Posts: 153
  • Thanked: 36 times
  • 2023 Supporter 2023 Supporter : Supporter of the forum in 2023
    2024 Supporter 2024 Supporter : Supporter of the forum for 2024
    Gold Supporter Gold Supporter :
Re: Suggestions Thread for v2.4.0
« Reply #443 on: July 01, 2024, 02:27:18 PM »
Suggestion for Orbital Mining automation, right now there is a Standing Order "Move to Asteroid Mineral Source." However, once this Standing Order is complete, Orbital Mining cannot commence without the player also creating a population on whatever asteroid the fleet chose. This requires the player to either check Events to see where the fleet ended up and create the colony each time an asteroid is emptied, create colonies on every mineral asteroid in the system before commencing orbital mining, or to manually choose asteroids and targets and not get to benefit from any automation.

It would be nice to have the following:

1. A Standing Order "Move to Orbital Mining Source (Create Pop If None)" - Fleet will choose an orbital-mining-compatible system body, move to it, and if a player pop does not already exist, create one to start collecting minerals. If a player pop already exists, start mining to that pop.
2. A Conditional Order "Orbital Mining Body Mineable Depleted" - If a fleet is already in orbit of a System Body that can be Orbital Mined, and all minerals on the Body have been mined, the fleet can then execute #1 automatically. This would allow one fleet to go body-by-body in a System creating populations and mining automatically, for a cargo ship to later sweep through and collect.


Thanks!
 
The following users thanked this post: AlStar

Offline Froggiest1982

  • Vice Admiral
  • **********
  • F
  • Posts: 1415
  • Thanked: 668 times
  • 2023 Supporter 2023 Supporter : Supporter of the forum in 2023
    2024 Supporter 2024 Supporter : Supporter of the forum for 2024
    Gold Supporter Gold Supporter :
Re: Suggestions Thread for v2.4.0
« Reply #444 on: July 01, 2024, 06:15:53 PM »
Starting to wonder, how far are we from implementing the 3rd conditional order?

;D ;D ;D ;D ;D

I like to throw in a random curveball from time to time.

Seriously though, is this something that could ever happen? I'm unsure about the complexity of the code or if you can simply paste and copy the functions.

One thought crossed my mind: perhaps it could only be usable by the player from the beginning? This should streamline the coding and also help with inevitable bug fixes, making the implementation on NPR smoother and potentially faster at some point.

Offline Alsadius

  • Lt. Commander
  • ********
  • Posts: 215
  • Thanked: 156 times
  • Gold Supporter Gold Supporter :
    2025 Supporter 2025 Supporter : Support the forums in 2025
Re: Suggestions Thread for v2.4.0
« Reply #445 on: July 02, 2024, 12:28:49 PM »
Starting to wonder, how far are we from implementing the 3rd conditional order?

Heck, I'd be happy with two if there was also a "Don't notify me when you run out of things to do" setting somewhere. I want to be able to set survey ships to go by themselves, without needing to turn off the conditional orders every time they finish surveying a system before the jump point is stabilized. (I don't yet use jump-capable scouts in my current game).

Or perhaps an order of "Pause conditional orders", where the conditionals pick up again if the fleet ever gets another order. Or a checkbox for conditionals being active. I'm flexible about details, really.

Offline paolot

  • Lt. Commander
  • ********
  • p
  • Posts: 255
  • Thanked: 55 times
Re: Suggestions Thread for v2.4.0
« Reply #446 on: July 03, 2024, 05:20:53 PM »
In the Galactic Map, in the Overview tab, I would like to recognize the JPs having a jump gate.
A different color of the name or of the dot in the mini-map, or a label next the name.
In this way, it's just evident where a stabilisation ship is needed, without opening each system map.
 

Offline Alsadius

  • Lt. Commander
  • ********
  • Posts: 215
  • Thanked: 156 times
  • Gold Supporter Gold Supporter :
    2025 Supporter 2025 Supporter : Support the forums in 2025
Re: Suggestions Thread for v2.4.0
« Reply #447 on: July 03, 2024, 06:37:56 PM »
In the Galactic Map, in the Overview tab, I would like to recognize the JPs having a jump gate.
A different color of the name or of the dot in the mini-map, or a label next the name.
In this way, it's just evident where a stabilisation ship is needed, without opening each system map.

That already exists - the line connecting systems is yellow if it's stabilized, and green if it's not. (It needs to be stabilized in both directions to go yellow, but tbh that's usually what I want to know.)

Offline paolot

  • Lt. Commander
  • ********
  • p
  • Posts: 255
  • Thanked: 55 times
Re: Suggestions Thread for v2.4.0
« Reply #448 on: July 03, 2024, 07:57:00 PM »
...

That already exists ...

I mean in the list on the left (or in the mini-map there), not between the systems in the map.
 

Offline alex_brunius

  • Vice Admiral
  • **********
  • Posts: 1326
  • Thanked: 211 times
Re: Suggestions Thread for v2.4.0
« Reply #449 on: July 04, 2024, 03:44:15 AM »
It would be nice to have systems sorted by importance/population size when using the "Autoroute to system" option (similar to how bodies inside a system are sorted with Colonies on top). When you reach 100/200+ systems the list starts to get pretty long, and "Sol" tend to get filtered far far below all the numbered systems  ::)

I probably could rename key systems as a workaround but I prefer to not do that since it looks smegty.