Author Topic: C# Suggestions  (Read 265994 times)

0 Members and 1 Guest are viewing this topic.

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2960
  • Thanked: 2222 times
  • Radioactive frozen beverage.
Re: C# Suggestions
« Reply #1740 on: May 10, 2021, 07:49:45 AM »
Append Template Orders To Current Orders

Right now, using an order template overwrites a fleet's current orders.
I suggest adding a way to append template orders to the end of the current orders list.

Perhaps a checkbox "Append Orders" next to the Create/Delete Template buttons?

If the box is checked, then double-clicking a template appends the orders.
Otherwise, double-clicking replaces the current orders (as it does now).

In the past Steve has been opposed to this because it would potentially create confusing bugs due to order targets not being where expected. However this already occasionally happens and is resolved through a nice event trigger and canceling the order, so I don't think it would be problematic. This would be a very useful addition.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1703
  • Thanked: 599 times
Re: C# Suggestions
« Reply #1741 on: May 10, 2021, 09:19:08 AM »
In the past Steve has been opposed to this because it would potentially create confusing bugs due to order targets not being where expected. However this already occasionally happens and is resolved through a nice event trigger and canceling the order, so I don't think it would be problematic. This would be a very useful addition.

I never quite understood this because the order templates only showed when the expected destination system matched with the system that the order template was created in, which means that it would be impossible to activate that sequence of orders in the wrong system.
 

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2781
  • Thanked: 1048 times
Re: C# Suggestions
« Reply #1742 on: May 10, 2021, 11:07:45 AM »
I would love to have a "Rename Fleet" order.

I use fleet names to indicate current assignment, and it would be great if I could, for example, have a freighter fleet rename itself after it unloads.
Wow, how have I not thought of that before? That's a great idea and it has historical merit too - during WW2 convoys were renamed based on whether they were "going in" or "coming out".
 
The following users thanked this post: skoormit

Offline RagnarVaren

  • Chief Petty Officer
  • ***
  • R
  • Posts: 31
  • Thanked: 11 times
Re: C# Suggestions
« Reply #1743 on: May 11, 2021, 04:21:37 PM »
It would be nice to have a Ground Combat Forces Summary event similar to the Ground Combat Intelligence event but for the player's forces. Currently you can only see the latest forces on the colony as no history is saved so if the formations didn't match the templates exactly (i.e no additions or losses) then it isn't possible to know exactly how many forces were present for each round. This would be very useful as I'm currently extracting the GUC vs GUC summary events from the database after the battle to look at the performance of each of my ground unit classes against the enemy and it would be nice to know the exact number of my own forces present as they fluctuate due to reinforcements arriving.
 

Offline Remilian

  • Petty Officer
  • **
  • R
  • Posts: 15
  • Thanked: 20 times
Re: C# Suggestions
« Reply #1744 on: May 11, 2021, 09:03:00 PM »
(Edited from my removed post into a more cohesive terraforming related suggestions)

Currently, there are a few issues with terraforming process and controls:
  • Terraforming always overshoots the target value. The bigger the terraforming capacity - the more it will overshoot.
    Another side-effect of the same issue is that if you set a target to lower than atmosphere already is - terraforming tick still happens next cycle, which "overshoots" target by 100% of capacity.
  • Current terraform controls feel out of place and somewhat unintuitive.

Based on the "Add Gas to Atmosphere" checkbox, certain database columns and log messages, I assume that current implementation involves unnecessary storage of TerraformStatus variable for each pop, which is then retrieved and used during production cycle in a series of checks.  In my opinion, MaxAtm (which can be more appropriately renamed into TargetAtm) variable is enough to extrapolate everything needed for terraformation calculations.

I suggest replacing terraform logic with this:
Code: [Select]
If ( Current_Atm != Target_Atm ) then        // I know about double's wonky equality check, but hear me out
    Terraform_change = Terraform_Capacity / Year_length * Cycle_length * other_modifiers....       //Amount of atm change possible on this body this production cycle
    If ( Terraform_change > 0 ) then
        Difference = Target_Atm - Current_Atm
        If ( ABS(Difference) <= Terraform_change ) then       //Can target be reached with available change?
            Current_Atm = Target_Atm         //gives people nice and clean values AND allows that target equality check at the beginning
            //Log message here? I know there are several versions of them, but maybe 1 universal "Target has been reached" is enough
        else
            If ( Difference < 0 ) then        //>0 means we need to add gas, <0 means we need to extract gas
                Current_Atm -= Terraform_change
                If ( Current_Atm < 0 ) then
                    Current_Atm = 0
            else
                Current_Atm += Terraform_change
           

This would fix the first problem and remove the need for that checkbox (and variable) completely, which is a part my proposal to fix to the second problem: change up terraform control panel from environmental tab.
  • Move terraform panel from the top of the tab to a position aligned with other panels in the tab.  It really does not stand out at the top, and making it equal to other panels will make it more visible and understandable.
  • Remove the "Add Gas to Atmosphere" checkbox.  Most new players treat it as "Enable terraforming" button, which is not exactly right and leads to confusion when they need to remove gas instead of adding it.
  • Add a simple visual indicator of any kind.  Even a text label with appropriate text would do.
  • Appropriately change said indicator based on various factors to indicate whether terraforming process is active or not.  Check if not-"None" gas is selected, if so then check for Terraform_Capacity, if >0 then check if Target Atm value is valid, if it is then indicate that the process is active.  Can add appropriate indications for each missed step too.
  • Perform said check on Gas and Target Atm control changes, as well as with other cycle-based checks for industry tabs.
  • With more space to work with, an estimated time until Target Atm is reached can be added onto the panel. 
 
The following users thanked this post: Warer

Offline Remilian

  • Petty Officer
  • **
  • R
  • Posts: 15
  • Thanked: 20 times
Re: C# Suggestions
« Reply #1745 on: May 12, 2021, 03:03:48 PM »
A lot of people still think that stacking Spaceports increases colony's cargo handling multiplier.  It doesn't, but this change is so buried in the changelogs and mentioned only in passing (with conflicting outdated statements as well) that people did not notice.  Maybe it could be put as a note in the next changelog to fully solidify that it does not stack?

As far as I understand the change has been done to increase the value of logistics technology tree, commander's logistics bonuses, and cargo handling bays (which is stackable but affects only individual ships), but that makes Spaceport inferior to triple station in almost every way.   I think Spaceport should still have some positive counterbalance to it's disadvantages.  Can't think of anything good for now, unfortunately.
« Last Edit: May 12, 2021, 03:06:29 PM by Remilian »
 
The following users thanked this post: skoormit

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1703
  • Thanked: 599 times
Re: C# Suggestions
« Reply #1746 on: May 12, 2021, 04:01:58 PM »
As far as I understand the change has been done to increase the value of logistics technology tree, commander's logistics bonuses, and cargo handling bays (which is stackable but affects only individual ships), but that makes Spaceport inferior to triple station in almost every way.   I think Spaceport should still have some positive counterbalance to it's disadvantages.  Can't think of anything good for now, unfortunately.

I think it's quite simple, the spaceport is already quite a bit more expensive than its less generalized counterparts. Just make it so that the spaceport doesn't need 1m workers and I think it's in a decent place.
 

Offline Remilian

  • Petty Officer
  • **
  • R
  • Posts: 15
  • Thanked: 20 times
Re: C# Suggestions
« Reply #1747 on: May 12, 2021, 04:29:18 PM »
I think it's quite simple, the spaceport is already quite a bit more expensive than its less generalized counterparts. Just make it so that the spaceport doesn't need 1m workers and I think it's in a decent place.
It is actually 17% cheaper than stations (3k vs 1.2k x3). But it is not enough to offset population used and 266% more cargo space required for transportation (2000kt vs 250kt x3).
The problem with just removing pop usage is that stations become kinda pointless. They were added in the first place to make specialized frontier bases possible on colonies without population. This could have been done in the past with the same pop+multiplier tweak to spaceports, but Steve decided to make stations instead. At the time it made sense, because stations were designed to not provide any bonuses while spaceports still stacked them. And now... it just adds to the unnecessary clutter.

Edit: New Idea: both ship's and spaceport's cargo handling modifiers can be set to sqrt(#). This would slightly decrease viability of Bay stacking, but it will bring back Spaceport stacking without taking away from station, technology, and commander importance. Players who just put 1 of each won't be affected at all, but it allows logistics-minded players to think about "investment vs speed gain" because of diminishing returns with large numbers.
« Last Edit: May 12, 2021, 04:53:53 PM by Remilian »
 
The following users thanked this post: serger

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1703
  • Thanked: 599 times
Re: C# Suggestions
« Reply #1748 on: May 12, 2021, 05:56:29 PM »
Right now when building ground formations you have to click once for each unit. Allow the option to have players input a number of formations to build exactly like the SM instant build. The game should also used the name typed on the dialog box.
 
The following users thanked this post: serger

Online Coleslaw

  • I got the Versacis on, stop playin'!
  • Warrant Officer, Class 2
  • ****
  • Posts: 58
  • Thanked: 53 times
Re: C# Suggestions
« Reply #1749 on: May 12, 2021, 11:39:44 PM »
This is a miniscule suggestion, but it'd be neat if bodies were to scale on the map like stars do. I can zoom in on Sol and see it increase in size on my screen proportional to the scale, but when I zoom in on planetary bodies they remain the same-sized blue dot. The only impact I imagine this having is providing a better frame of reference in naval combats nearby large planetary bodies. Recently I had a battle close to Saturn, would be really cool to see a bigger blue dot representing the gas giant as the ships and missiles involved in the combat flutter around it.
 
The following users thanked this post: serger

Offline ISN

  • Sub-Lieutenant
  • ******
  • I
  • Posts: 103
  • Thanked: 30 times
Re: C# Suggestions
« Reply #1750 on: May 13, 2021, 12:49:33 PM »
I'm not posting this in the bugs thread, since as far as I can tell from the rules post this is working as intended, but Fire at Will allows you to more or less completely negate jump shock for a well-trained fleet.  If you press the Fire at Will button after jumping it seems to overwrite the fire delay from jump shock, and if your fleet is trained then you'll end up with little to no delay.  Of course you don't get to choose your targets, and in some cases that's a big downside, but it's usually better than the alternative of not firing at all, and if your fleet outnumbers the enemy then it's often not a huge problem.

This makes taking a jump point generally much easier, but it's especially unbalanced because the AI has a tendency to jump through the jump points when attacked.  So you jump through a JP into an enemy fleet, the enemy jumps to escape you, you jump back and chase them -- and now you can use Fire at Will to wipe them out while they recover from the jump shock.

Was Fire at Will intended to negate jump shock, or just reduce the normal fire delays when crews are untrained? The balance issues could be fixed by making the AI use Fire at Will as well to counter the advantage the player has, but that just makes jump shock kind of pointless.  I think it would make the most sense to change Fire at Will so that it doesn't affect jump shock.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1703
  • Thanked: 599 times
Re: C# Suggestions
« Reply #1751 on: May 13, 2021, 01:35:37 PM »
I'm not posting this in the bugs thread, since as far as I can tell from the rules post this is working as intended, but Fire at Will allows you to more or less completely negate jump shock for a well-trained fleet.  If you press the Fire at Will button after jumping it seems to overwrite the fire delay from jump shock, and if your fleet is trained then you'll end up with little to no delay.  Of course you don't get to choose your targets, and in some cases that's a big downside, but it's usually better than the alternative of not firing at all, and if your fleet outnumbers the enemy then it's often not a huge problem.

This makes taking a jump point generally much easier, but it's especially unbalanced because the AI has a tendency to jump through the jump points when attacked.  So you jump through a JP into an enemy fleet, the enemy jumps to escape you, you jump back and chase them -- and now you can use Fire at Will to wipe them out while they recover from the jump shock.

Was Fire at Will intended to negate jump shock, or just reduce the normal fire delays when crews are untrained? The balance issues could be fixed by making the AI use Fire at Will as well to counter the advantage the player has, but that just makes jump shock kind of pointless.  I think it would make the most sense to change Fire at Will so that it doesn't affect jump shock.

So I looked at the 1.13 changelogs:
Quote
A new Fire At Will option allow ships to reduce fire delays by half, at the expense of targeting choice. This can be applied to a single fire control, a ship or a fleet.

When the order is given, each fire control is assigned a random target (based on the rules below). Each ship is then assigned a fire delay with a modifier of -50% vs normal. This fire delay will override any existing fire delay (even if the current delay is longer), except if the command is assigned to a specific fire control, rather than ship or fleet, in which case the new fire delay will only override any existing fire delay if the new delay is longer.

Based on the first paragraph, fire at will is intended to affect just training based fire delays and not necessarily the jump shock.

However the second paragraph says "This fire delay will override any existing fire delay (even if the current delay is longer)" which to me indicates that the implementation is such that, if fire delay and jump shock delay are both in play, the game will ignore the jump shock delay. So although there is most likely no bug in the code, it does seem like "fire at will" does nullify jump shock.

Is this what Steve intended? I'm honestly not sure.
 

Offline Lord Solar

  • See above
  • Warrant Officer, Class 1
  • *****
  • Posts: 83
  • Thanked: 28 times
  • Everlasting Glory to the Imperium
  • Discord Username: Lord Solar
Re: C# Suggestions
« Reply #1752 on: May 13, 2021, 01:37:15 PM »
I'm not posting this in the bugs thread, since as far as I can tell from the rules post this is working as intended, but Fire at Will allows you to more or less completely negate jump shock for a well-trained fleet.  If you press the Fire at Will button after jumping it seems to overwrite the fire delay from jump shock, and if your fleet is trained then you'll end up with little to no delay.  Of course you don't get to choose your targets, and in some cases that's a big downside, but it's usually better than the alternative of not firing at all, and if your fleet outnumbers the enemy then it's often not a huge problem.

This makes taking a jump point generally much easier, but it's especially unbalanced because the AI has a tendency to jump through the jump points when attacked.  So you jump through a JP into an enemy fleet, the enemy jumps to escape you, you jump back and chase them -- and now you can use Fire at Will to wipe them out while they recover from the jump shock.

Was Fire at Will intended to negate jump shock, or just reduce the normal fire delays when crews are untrained? The balance issues could be fixed by making the AI use Fire at Will as well to counter the advantage the player has, but that just makes jump shock kind of pointless.  I think it would make the most sense to change Fire at Will so that it doesn't affect jump shock.
Before Fire at Will existed, combining full training with flag bridge and a good flag officer (lots of reaction) can do the same thing but also select targets.
 

Offline Zhukov

  • Leading Rate
  • *
  • Z
  • Posts: 6
  • Thanked: 4 times
Re: C# Suggestions
« Reply #1753 on: May 13, 2021, 03:43:18 PM »
I would like to see the option to make labs "Sort by Date" as standard.   Every time I open this window I have to set ""by Date" to know what is finishing next.
 
The following users thanked this post: skoormit

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1703
  • Thanked: 599 times
Re: C# Suggestions
« Reply #1754 on: May 13, 2021, 04:55:49 PM »
Currently in game settings we can set the chances that a player or another NPR generates an NPR. It would be nice to also add settings to separately configure the % chance that spoilers can appear based on which ones are enabled.
 
The following users thanked this post: serger, skoormit