Author Topic: Semi-Official 7.x Suggestion Thread  (Read 173928 times)

0 Members and 2 Guests are viewing this topic.

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2794
  • Thanked: 1054 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #285 on: April 26, 2016, 04:24:17 AM »
Could we change the 'Continual expansion' box for shipyards to an 'expand to'?  I often find myself needing to get a shipyard to some specific value which isn't divisible by 500, and it's annoying to have to keep an eye on the shipyard when I'm doing so.  Instead, set it so that it expands to the value you give it, and then sends an alert, with a target tonnage of 0 triggering the system as it currently works.
This would be great. Especially for commercial yards, where you always use the 10,000 tons increase anyway.
 
The following users thanked this post: serger, Silvarelion

Offline Sheb

  • Commodore
  • **********
  • Posts: 789
  • Thanked: 30 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #286 on: April 26, 2016, 08:01:01 AM »
Also would be awesome for all the OCD people like me around who hate ending up with a shipyard at 4783 tons.
 
The following users thanked this post: Silvarelion

Offline bean

  • Rear Admiral
  • **********
  • b
  • Posts: 921
  • Thanked: 58 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #287 on: April 26, 2016, 09:21:13 AM »
Also would be awesome for all the OCD people like me around who hate ending up with a shipyard at 4783 tons.
I'm with you on that.  The other way to deal with that is to only use the stepwise expansions, which always round to the nearest hundred.  But that's annoying when you want to add 200 tons, and have to keep checking the completion percentage to make sure you get it when it's at or just above 40% done.
This is Excel-in-Space, not Wing Commander - Rastaman
 

Offline bean

  • Rear Admiral
  • **********
  • b
  • Posts: 921
  • Thanked: 58 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #288 on: April 26, 2016, 08:41:51 PM »
I had an idea for how to make industrial production easier to allocate.  Instead of assigning a fixed percentage of your industry to each project, you assign each one an arbitrary number of 'tokens'.  Each project gets a percentage of the total industrial output (the actual percentage utilization would be set separately) equal to the percentage of active tokens it has.  This makes doing things like building ship parts much, much easier because you don't have to reduce allocation to something else first (instead, the hit is taken across the whole basket unless you reduce something to match), and when projects finish, the rest of the basket is re-shuffled to match.  The only problem is that it doesn't really leave much room for the queue.  Maybe set it up so that if the queue is in use, tokens, instead of disappearing, go to the queued project until it gets the number it's supposed to have.
Also, can we please get an event message when shipyards and GFTFs are built?  It's annoying to go to the shipyards tab, see a new one, and think 'how long has that been sitting there?'.
This is Excel-in-Space, not Wing Commander - Rastaman
 
The following users thanked this post: serger

Offline cakepie

  • Able Ordinary Rate
  • c
  • Posts: 4
  • Thanked: 1 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #289 on: April 27, 2016, 09:19:46 AM »
So, you're suggesting that we specify the amount of industrial output to be allocated to each project as a ratio or proportion among the active projects, rather than as a percentage of total industrial output.  Mathematically speaking, "find the sum total number of 'tokens', normalize that as 100% of the industrial output, and calculate that as percentage utilization (the existing system)"

As for queuing, if I understand you correctly, a scenario might work like this:

Code: [Select]
Active projects (in expected order of completion; tokens): A(2),B(2),C(1) at {40%,40%,20%}
Queued projects (in priority order; tokens acquired/required): D(0/3),E(0/2)

Project A completes, freeing up two tokens, given to D, but not enough to start D, so:
Active projects: B(2),C(1) at {66%,33%}
Queued projects: D(2/3),E(0/2)

Project B completes, freeing up two tokens, D has enough tokens to start, but not E so:
Active projects: C(1),D(3) at {25%,75%}
Queued projects: E(1/2)

Project C completes, E can start:
Active projects: D(3),E(2) at {60%,40%}
Queued projects: none

Based on the use case you described, you want to be able to inject tokens into the system to force a queued project to start alongside existing ones, eg.  from the example above:
Code: [Select]
Active projects. A(2),B(2),C(1)
Queued projects: X(5/5),D(0/3),E(0/2)
Here, adding project X to the front of the queue, and giving it sufficient tokens effectively results in:
Code: [Select]
Active projects: A(2),B(2),C(1),X(5) at {20%,20%,10%,50%}
Queued projects: D(0/3),E(0/2)
By extension, you could inject tokens at any point in the queue:
Code: [Select]
Active projects: A(2),B(2),C(1)
Queued projects: D(0/3),X(5/5),E(0/2)

When projects A & B complete:
Active projects: C(1),D(3),X(5)
Queued projects: E(1/2)
You don't have to inject the full number of tokens needed, either:
Code: [Select]
Active projects: A(2),B(2),C(1)
Queued projects: D(0/3),X(4/5),E(0/2)

Conversely, if a project completes and there are no other projects in the queue to accept the freed up tokens, then those tokens would simply "fall out of circulation" and disappear. 


I see a number of potential issues with such an arrangement:
1.  Possible to queue a project that will never acquire enough tokens to start
2.  Non-constant (potentially highly variable) production rates over the course of a project
3.  The assumption that you always want 100% of possible industrial output

An example of (1) would be if we change my above original example such that project D queues up at 0/6 tokens -- it will never start since it can acquire at most 5 tokens from A,B,C -- and project E is also stuck as it is forced to wait behind D.  The simplest, obvious solution here is to prohibit queuing a project that requires more tokens than currently circulating in the system.  (Other, fancier scheduling algorithms, eg. allowing E to leapfrog over D, would only get unnecessarily complicated and would still have to contend with potential starvation problems. )

(2) is evident from the example above; the percentage of total industrial capacity used by each project can fluctuate quite wildly.  Compared to such behavior, the existing system (setting percetage utilization) has the key advantage that the production rate of each project is constant (assuming no changes in the colony's industrial capacity).  This also means that estimated completion dates for projects are reliable, which makes it simple to plan ahead, coordinate between different production projects, or even synchronize industry with other parts of the economy, eg. :
a) You can easily and reliably ensure that you've assigned sufficient production capacity to a project must be completed by a certain date -- eg.  your shipyard needs to expand and/or retool in order to start building a new class design, and you want to use this time while waiting for the shipyard to ready up to pre-build some ship components -- those components must be finished on time so that they are available for use by the shipyard at the start of ship construction. 
b) You can adjust the production rate according to the raw material availability -- eg.  say you want to build 10 fighter factories; however, your colony has no standing stockpile of vendarite, and you aren't shipping/shooting it in from elsewhere, just a stable production of 90 vendarite per year from local mining -- then it is pointless to assign the project any more than 120 production (the mines won't be able to keep up). 

Matching industrial production rate to raw material availability is also a reason why you'd might want to run at less than full capacity, which brings us to (3).  I'm not sure it is safe to assume that you'd always want to normalize the token-based industrial output allocation over a total of 100% of production capacity.  A setting could be added so that you could specify for the tokens to be normalized over less than 100%, but that seems a bit kludgy and doesn't really do much to help the issue of inconstant production rates (at least, not without user intervention each time a project starts/finishes).  Another possibility is to allow scheduling "idle" projects that occupy a certain number of tokens and "complete" after a fixed period of time or upon "consuming" a certain amount of "build cost" (albeit consuming/producing nothing) -- but this would probably be rather unintuitive and hard to use considering that you'd basically find yourself fiddling with the "idle" project in order to try to (indirectly) regulate the production rates of other projects. 


The existing percentage based allocation empowers the player with a lot of freedom and control to make fine adjustments (down to 4 decimal places of a percentage point!) to suit a wide variety of situational gameplay needs, and is capable of supporting different playstyles and arbitrary roleplay rules.  I can understand the use case you cited, but I'm concerned that the proposed token-based method would instead reduce the amount of choice and control that players have -- it's significantly less powerful; I'm not convinced the benefits are worth the trade off. 


Since you cited "don't have to reduce allocation to something else first", it suggests that your goal may be convenience, or you wish to "preserve the relative allocation across existing concurrently running projects".  Have you considered pushing 100% of existing projects back down into the queue? This preserves their relative allocations, and if you set your ship components to build sequentially, all at 100%, then the pre-existing projects will all pop back out of the queue upon completion of the ship components, and resume where they left off.  Basically, "drop everything you're doing, build these as a priority; once these are done, resume what you were doing before.  " Numerically, this is generally similar to building the ship components alongside with the "whole basket" of pre-existing projects, since in any case you'd have to divert an amount of production capacity equivalent to the build cost of the ship component project(s) away from the basket of pre-existing projects.  The difference is that by running both types alongside one another, some pre-existing projects might actually complete before the ship components are done.  On the other hand, pumping out the ship components first means that they are available sooner (advantageous in a way, given that components must be available in stockpile at the start of shipbuilding to be used. )
« Last Edit: April 27, 2016, 09:22:51 AM by cakepie »
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #290 on: April 27, 2016, 10:53:32 AM »
A production queue for ships and ground forces would be nice, too. It would make life much easier when you try to handle multiple nations.
 

Offline bean

  • Rear Admiral
  • **********
  • b
  • Posts: 921
  • Thanked: 58 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #291 on: April 27, 2016, 12:12:49 PM »
Cakepie:
You're pretty much correct, with a few minor exceptions.  First, I'd solve the starvation problem by allowing projects to begin work with fewer than their full set of tokens.  They'll take tokens up to their maximum, but work with however many are currently assigned.  This also makes it easy to re-allocate production from one thing to another, and then have the production go back to to the first thing when the second one finishes by setting the 'cap' for the first one to the original allocation.
Second, I'm aware of the swings that could take place.  It's an unavoidable consequence of this idea, and I think it would probably be worth it.  You'd have to keep an eye on time-critical projects, but I'm not sure it would be worse than it is now.
Third, there's no way to avoid having some semi-kluged mechanism for using less than 100% of industry, which is why I suggested it.
And I wasn't aware you could push existing projects back into the queue.  That would help a lot, actually.
This is Excel-in-Space, not Wing Commander - Rastaman
 

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2794
  • Thanked: 1054 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #292 on: April 27, 2016, 04:15:16 PM »
Also, can we please get an event message when shipyards and GFTFs are built?  It's annoying to go to the shipyards tab, see a new one, and think 'how long has that been sitting there?'.
There already is an event when they are constructed.
 

Offline Gabethebaldandbold

  • last member of the noob swarm
  • Lt. Commander
  • ********
  • Posts: 242
  • Thanked: 30 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #293 on: April 27, 2016, 07:12:32 PM »
Why do we not have live fire exercises? I was expecting to get the chance of testing my ships and crew before feeding them to the spoiler races...  (and if that or something like that already exists, how do I do it?)
To beam, or not to beam.   That is the question
the answer is you beam. and you better beam hard.
 
The following users thanked this post: serger

Offline 83athom

  • Big Ship Commander
  • Vice Admiral
  • **********
  • Posts: 1261
  • Thanked: 86 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #294 on: April 28, 2016, 09:50:33 AM »
Why do we not have live fire exercises? I was expecting to get the chance of testing my ships and crew before feeding them to the spoiler races...  (and if that or something like that already exists, how do I do it?)
Task Force Training. Its the big button in one of the TG order window.
Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life.
 

Offline Gabethebaldandbold

  • last member of the noob swarm
  • Lt. Commander
  • ********
  • Posts: 242
  • Thanked: 30 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #295 on: April 28, 2016, 10:27:13 AM »
Task Force training. Its the big button in one of the TG order window.
I know task force training, I meant like shooting missiles at allies to get them experience, you know, test the crew and see how it holds up
To beam, or not to beam.   That is the question
the answer is you beam. and you better beam hard.
 

Offline bean

  • Rear Admiral
  • **********
  • b
  • Posts: 921
  • Thanked: 58 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #296 on: April 28, 2016, 02:41:06 PM »
I know task force training, I meant like shooting missiles at allies to get them experience, you know, test the crew and see how it holds up
There are about three different ways this could be read:
1. You want to run experiments to learn about how your tech is working.  This is doable already.  Create a pop 0 race sharing your home planet.  Transfer stuff to them when you want to do experiments.
2. You want a faster way to get TF training.  This isn't a terrible idea, although it's been made somewhat redundant with the addition of automatic low-level TF training.  The easy way would be to have the ships train at full speed instead of half-speed, for maybe 50% more training per unit time.
3. You want something like TF training, but for crew quality.  I like this one, although it's mechanically difficult to work out.  What exactly does it cost you?  Missiles are an obvious choice, although the equally obvious counter is to make a training missile which has a conventional engine and is otherwise as cheap as possible.  And it leaves non-missile ships out in the cold.  I can't think of a non-gameable way to solve this.
This is Excel-in-Space, not Wing Commander - Rastaman
 
The following users thanked this post: Gabethebaldandbold

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #297 on: April 29, 2016, 11:03:05 AM »
It is possible to Transfer parts of ship components via a cargo ship (happens in 0.2 increments). But since the stockpile does not show decimals, you might 'loose' a viable ship component, if you don't pay attention if you have transferred the whole part.

If you have 5 parts of one component and happen to transfer only 1.8 of them to another colony, the stockpiles would tell you 3 for the origin and 1 for the target stockpile - and not 3.2 and 1.8 as there would be in reality.
 

Offline serger

  • Commodore
  • **********
  • Posts: 634
  • Thanked: 120 times
  • Silver Supporter Silver Supporter : Support the forums with a Silver subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Re: Semi-Official 7.x Suggestion Thread
« Reply #298 on: April 30, 2016, 09:57:19 AM »
It looks like our commanding officers appear at their 21-y academy graduate age, and not as graduate lieutenants, but as lt.  -commanders/colonels at once, however not annually - let it be in the middle of a year (1st July) - after theyr graduate party, but at random date.   
As for administrators and scientist program leaders, their invariable 21-y commission ages seems to be even more fanciful. 

So, I think it will be good, if our junior leaders (both commanders and administrative leaders - relevant window and buttons have quite deceptive name now, so far as administrators and scientists are _not_ commanders) will appear at random own ages too, not only random dates of commission, and average age of this commission should be somewhat higher, about 30-35 Earth years.   
 

Offline iceball3

  • Captain
  • **********
  • Posts: 454
  • Thanked: 47 times
Re: Semi-Official 7.x Suggestion Thread
« Reply #299 on: April 30, 2016, 09:22:54 PM »
Could we get the ability to add notes to specific bodies/colonies, either on the F9 system generation screen, or the F2 economy screen. It would help with general fluff type info to flesh out the RP of the game if we were able to add things.
Would be pretty nice, actually! I agree this should be something that needs to be added.

A current workaround for you, though, could be designing a tiny PDC called a "Planetary Archives Base", which you build on the surface of the planet in question, and then add notes to the PDC/Task group of it (i forget which one retains notes). This should be an exceptionally fluffy workaround in the meantime.