Author Topic: C# Suggestions  (Read 273099 times)

0 Members and 2 Guests are viewing this topic.

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: C# Suggestions
« Reply #1395 on: January 30, 2021, 02:09:32 PM »
Would it be possible to get checkbox for ground units to not show on the list of units when loading ground troops to transports? I have garrison troops on my planet that I have no intention to move and I have to scroll through them to find my assault units.

Better yet - when you select the SUB checkbox it removes all formations that have no subordinates of their own from the list
 
The following users thanked this post: DIT_grue, nuclearslurpee

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2989
  • Thanked: 2247 times
  • Radioactive frozen beverage.
Re: C# Suggestions
« Reply #1396 on: January 30, 2021, 02:13:43 PM »
I think Power Plants should either be expanded in their use or just be taken out and added on to the HS of beam weapons.

I get that they are there to make beam weapons a little less HS efficient when compared to missiles that need (usually multiple) launchers, a big magazine + a FC and AS, but I don't think they justify being their own customizable part ATM.

If they also powered shields or if having a surplus of power somehow increase the performance of beam weapons then that would justify their inclusion.

I support this. Just make reactors another integral component of a beam weapon and leave it at that, as they are easily the most boring component presenting very little in the way of interesting decisions. Presently the only real reason they exist separately is so that building bigger reactors can be more tonnage-efficient, which I would be fine living without and just tacking a few more HS onto my lasers.

What about when your ship (or the bad guy) takes internals and the power plant goes? Unless he has gauss or missiles, he's mission killed.

If the only purpose of a component is to introduce a weakness, I question the inclusion of that component in the game.

Reactors to me already struggle to make sense since the rest of the ship components are generally considered to be "powered" by the ship's engines. Beam weapons are the only component that apparently needs a separate power source, and that power source is arguably the most boring component in the game when combining the design and "what does it do" elements (as plasma carronades at least shoot at things which is fun).

I'd also be happy with an alternative rework that made all ship systems require reactor power, but I doubt that ever happens.

Decline arbitrary tonnage margins between fighters, FACs (w/o bridge) and ships (with bridge), with these changes to ship mechanics:

1. Bridge component reveals an ability to add other command components and makes Crew Quarters 3 times more effective (that are 3 watches, and without command components you cannot relieve watch for commanding personnel, because your Crew Quarters are the only action stations available for them).
2. Add a property "max spacecraft size able to take off" for any planet, dependent on it's mass or gravity. Colony and spacecraft design windows to show these properties accordingly.
3. Fighter Factories becoming Shipbuilding Factories, able to produce space components and build unarmored (yet-to-be-assembled by shuttles) stations and any spacecraft, that can take off this planet.
4. Construction Factories becoming unable to produce spacecraft components and unarmored stations, they are to build surface objects only.

I agree the limits are a bit arbitrary but I dislike these proposals to address them.

(1) if I understand it correctly would not have the desired effect as it represents a nerf to FACs and fighters. I would suggest as an alternative that the definition of a FAC (not fighter) be defined in terms of a maximum crew count which can be commanded without a bridge module, probably with a tech to increase this limit over time as components become more complex. This would be simpler and since the FAC definition does not interact with other game mechanics it is okay to change this.

(2) would add needless complication as now I cannot just design my fighter craft to a given standard, I have to arbitrarily limit tonnage based on which planet(s) I want to build them on. This reduces player flexibility, and also doesn't play neatly with the fact that the game needs a consistent definition of a "fighter" e.g to correctly apply the commander skill for Fighter Combat. As arbitrary as it may seem, having a round tonnage mark for "fighter" definition is good for gameplay and an acceptable abstraction.

(3) and (4) again place restrictions on the player where currently there exists an interesting choice, mainly (4) as currently the choice of what to use construction capacity on is a relevant one in many cases. Why remove decision making from the player? (3) by itself is probably okay as I wouldn't mind making fighter factories more interesting.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: C# Suggestions
« Reply #1397 on: January 30, 2021, 02:22:46 PM »
I think Power Plants should either be expanded in their use or just be taken out and added on to the HS of beam weapons.

I get that they are there to make beam weapons a little less HS efficient when compared to missiles that need (usually multiple) launchers, a big magazine + a FC and AS, but I don't think they justify being their own customizable part ATM.

If they also powered shields or if having a surplus of power somehow increase the performance of beam weapons then that would justify their inclusion.

I support this. Just make reactors another integral component of a beam weapon and leave it at that, as they are easily the most boring component presenting very little in the way of interesting decisions. Presently the only real reason they exist separately is so that building bigger reactors can be more tonnage-efficient, which I would be fine living without and just tacking a few more HS onto my lasers.

What about when your ship (or the bad guy) takes internals and the power plant goes? Unless he has gauss or missiles, he's mission killed.

If the only purpose of a component is to introduce a weakness, I question the inclusion of that component in the game.

Reactors to me already struggle to make sense since the rest of the ship components are generally considered to be "powered" by the ship's engines. Beam weapons are the only component that apparently needs a separate power source, and that power source is arguably the most boring component in the game when combining the design and "what does it do" elements (as plasma carronades at least shoot at things which is fun).

I'd also be happy with an alternative rework that made all ship systems require reactor power, but I doubt that ever happens.

Decline arbitrary tonnage margins between fighters, FACs (w/o bridge) and ships (with bridge), with these changes to ship mechanics:

1. Bridge component reveals an ability to add other command components and makes Crew Quarters 3 times more effective (that are 3 watches, and without command components you cannot relieve watch for commanding personnel, because your Crew Quarters are the only action stations available for them).
2. Add a property "max spacecraft size able to take off" for any planet, dependent on it's mass or gravity. Colony and spacecraft design windows to show these properties accordingly.
3. Fighter Factories becoming Shipbuilding Factories, able to produce space components and build unarmored (yet-to-be-assembled by shuttles) stations and any spacecraft, that can take off this planet.
4. Construction Factories becoming unable to produce spacecraft components and unarmored stations, they are to build surface objects only.

I agree the limits are a bit arbitrary but I dislike these proposals to address them.

(1) if I understand it correctly would not have the desired effect as it represents a nerf to FACs and fighters. I would suggest as an alternative that the definition of a FAC (not fighter) be defined in terms of a maximum crew count which can be commanded without a bridge module, probably with a tech to increase this limit over time as components become more complex. This would be simpler and since the FAC definition does not interact with other game mechanics it is okay to change this.

(2) would add needless complication as now I cannot just design my fighter craft to a given standard, I have to arbitrarily limit tonnage based on which planet(s) I want to build them on. This reduces player flexibility, and also doesn't play neatly with the fact that the game needs a consistent definition of a "fighter" e.g to correctly apply the commander skill for Fighter Combat. As arbitrary as it may seem, having a round tonnage mark for "fighter" definition is good for gameplay and an acceptable abstraction.

(3) and (4) again place restrictions on the player where currently there exists an interesting choice, mainly (4) as currently the choice of what to use construction capacity on is a relevant one in many cases. Why remove decision making from the player? (3) by itself is probably okay as I wouldn't mind making fighter factories more interesting.

I agree that power plants as they are currently aren't very interesting. Making them have uses outside of beam weapons and just power the whole ship in general makes more sense to me.
It allows you to do more things with power plants - they might be made to have their own fuel requirements with boosting decreasing fuel efficiency much like engines
Every ship could also be made to have batteries so that if the generator goes, the ship has some life support left before everything shuts off, now you might want to avoid firing some weapons to ration power.
Each beam weapon benefits from power surplus, some may hit harder, others may shoot more shots and some may be able to fire further by drawing extra power, shields that have extra power may be able to recharge faster than normal.
Hell you could configure a design to "overclock" its life support, using more power but making crew quarters more efficient with an increased chance for maintenance failures for them.

Having power act as a ship-wide resource instead of a beam weapon "reload rate" opens the grounds for a lot of interesting tactical decisions IMO.
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Suggestions
« Reply #1398 on: January 30, 2021, 03:37:38 PM »
I rather like the idea of having a tonnage limit for fighters/land based ship construction based on the planet somehow.

Among other things you would desire to colonize a low gravity body to facilitate easier shipbuilding, which does make a degree of sense.  It would reduce the energy requirements for moving stuff off of the surface.

I can't think of a good set of rules for that personally though.
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Suggestions
« Reply #1399 on: January 30, 2021, 03:48:19 PM »
I agree that power plants as they are currently aren't very interesting. Making them have uses outside of beam weapons and just power the whole ship in general makes more sense to me.
It allows you to do more things with power plants - they might be made to have their own fuel requirements with boosting decreasing fuel efficiency much like engines
Every ship could also be made to have batteries so that if the generator goes, the ship has some life support left before everything shuts off, now you might want to avoid firing some weapons to ration power.
Each beam weapon benefits from power surplus, some may hit harder, others may shoot more shots and some may be able to fire further by drawing extra power, shields that have extra power may be able to recharge faster than normal.
Hell you could configure a design to "overclock" its life support, using more power but making crew quarters more efficient with an increased chance for maintenance failures for them.

Having power act as a ship-wide resource instead of a beam weapon "reload rate" opens the grounds for a lot of interesting tactical decisions IMO.

We already had this discussion before... a couple of times... Steves answer have so far been that he don't want an energy mechanic for ships as that will shift focus from the game strategic and tactical operations of fleets or squadrons of ships to individual ships too much.

I don't think he is against the idea itself, just that it is one step too far in the detail and management of the ships in general.
« Last Edit: January 31, 2021, 11:43:31 AM by Jorgen_CAB »
 
The following users thanked this post: DIT_grue, captainwolfer

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: C# Suggestions
« Reply #1400 on: January 30, 2021, 05:09:51 PM »
(1) if I understand it correctly would not have the desired effect as it represents a nerf to FACs and fighters.

Rather minor nerf and very natural.
I'd like to see much more lowering of small craft deployment times, though it might be in combination with some racial or game property, that can switch deployment time off, to play with robotic or other strange race, that needs no life intercourse nor much life support.

I would suggest as an alternative that the definition of a FAC (not fighter) be defined in terms of a maximum crew count which can be commanded without a bridge module

That will be just another arbitrary interracial margin we'll have to shut our eyes wide.

(2) would add needless complication as now I cannot just design my fighter craft to a given standard, I have to arbitrarily limit tonnage based on which planet(s) I want to build them on.

I'll say with fighters you must have nearly no limit for habitable planets, because with this mechanics Steve will have an ability to implement even small tenders (several kt), that will have no need to use shuttles.
Though it will add some complication with logistics, yes. Personally I'd prefer to have an ability to land any ship and use more local (planetary or on-board) loading facilities abstraction (not shuttles), but that's what Steve have made, we need to deal with it.

and also doesn't play neatly with the fact that the game needs a consistent definition of a "fighter" e.g to correctly apply the commander skill for Fighter Combat. As arbitrary as it may seem, having a round tonnage mark for "fighter" definition is good for gameplay and an acceptable abstraction.

I'd say that "fighter" tag can be defined as direct fire* armed mobile (not orbital) craft with no more than 2 crewmen (that's pilot and operator). Give them an ability to lead fighter squadrons (providing them with bonus) - and it will be great.
All heavier crafts will be FACs quite naturally, their tactics and operational requirements have no fundamental difference from corvettes or even frigates.

(*) now it's named often as "beam"despite gauss and railguns are kinetic weapon, not beam

(3) and (4) again place restrictions on the player

Nope. What I proposed to take away from Construction Factories - will be added to Shipbuilding (former Fighter) Factories.
That's not a restriction, that's replacing. Why? Because Fighter Factories are now too much restricted, too specialised (and some players even have no desire to make fighters at all), while Construction Factories are overburden with diverse tasks.
With Construction Factories and Shipbuilding Factories it might be much more balanced.
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Suggestions
« Reply #1401 on: January 30, 2021, 05:20:28 PM »
I'm definitely starting to like the idea of shipbuilding factories in general, particularly if they supported shipyard operations and were also the way to pre-build ship components, I always thought construction factories were way too multifaceted.
 

Offline captainwolfer

  • Lt. Commander
  • ********
  • c
  • Posts: 224
  • Thanked: 88 times
Re: C# Suggestions
« Reply #1402 on: January 31, 2021, 10:43:50 AM »
Suggestion:
1. Make missiles with sensors that are not controlled by a missile fire control pick targets using a weighted selection process like how the "Fire at Will" command for missile fire controls will work in 1.13, except make it so it uses the sensors the missile has, IE if missile has thermal sensors, the weighting is thermal signature/distance, if it has EM sensors then it uses EM signature/distance, etc.
2. Make it so that if a missile is fired at a target and the target is destroyed, the missile will continue heading on its current path, instead of just stopping in space

This way, missiles with sensors won't all hit the same ship in an enemy fleet, and it will actually be possible to use them when chasing an enemy fleet, instead of the sensors only being useful when running from an enemy fleet.
 
The following users thanked this post: serger, BAGrimm, Sunmannus

Offline Barkhorn

  • Commodore
  • **********
  • B
  • Posts: 719
  • Thanked: 133 times
Re: C# Suggestions
« Reply #1403 on: January 31, 2021, 11:06:03 AM »
Suggestion:
1. Make missiles with sensors that are not controlled by a missile fire control pick targets using a weighted selection process like how the "Fire at Will" command for missile fire controls will work in 1.13, except make it so it uses the sensors the missile has, IE if missile has thermal sensors, the weighting is thermal signature/distance, if it has EM sensors then it uses EM signature/distance, etc.
2. Make it so that if a missile is fired at a target and the target is destroyed, the missile will continue heading on its current path, instead of just stopping in space

This way, missiles with sensors won't all hit the same ship in an enemy fleet, and it will actually be possible to use them when chasing an enemy fleet, instead of the sensors only being useful when running from an enemy fleet.
This is how they worked back in VB6 and I believe how they're supposed to work now, they're just bugged.
 

Offline dlathro1

  • Petty Officer
  • **
  • d
  • Posts: 20
  • Thanked: 6 times
Re: C# Suggestions
« Reply #1404 on: January 31, 2021, 08:25:11 PM »
Would it be possible to have the Assign New Labs option work with research queues?

It is somewhat annoying to reenable Assign New Labs every time research is completed.
 
The following users thanked this post: serger, nuclearslurpee

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Suggestions
« Reply #1405 on: January 31, 2021, 11:42:01 PM »
This is how they worked back in VB6 and I believe how they're supposed to work now, they're just bugged.

Missiles are bugged?!?
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Suggestions
« Reply #1406 on: February 01, 2021, 12:26:48 AM »
My general understanding is its more like they are incomplete.
 

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: C# Suggestions
« Reply #1407 on: February 01, 2021, 10:30:22 AM »
Have an idea about heavy weapon supply problem.
Suggestion is to make any weapon to do supply roll against it's target armour*HP, not against weapon's own GSP (that will be max GSP instead of constant GSP).

That's not ideal, not as if it will be some sort of anti-personnel shells, that will be able to kill several units of the same element, proportionally to shell power, and targetted specifically at largest units and elements, but this first rule might be much simpler to code.
 
The following users thanked this post: nuclearslurpee

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2989
  • Thanked: 2247 times
  • Radioactive frozen beverage.
Re: C# Suggestions
« Reply #1408 on: February 01, 2021, 11:21:12 AM »
Have an idea about heavy weapon supply problem.
Suggestion is to make any weapon to do supply roll against it's target armour*HP, not against weapon's own GSP (that will be max GSP instead of constant GSP).

That's not ideal, not as if it will be some sort of anti-personnel shells, that will be able to kill several units of the same element, proportionally to shell power, and targetted specifically at largest units and elements, but this first rule might be much simpler to code.

This...isn't the worst idea actually. It could probably work though I do think it is a bit opaque, and it makes sense as e.g. a tank planning to attack infantry instead of enemy armor would load a cheaper HE shell instead of an expensive AP/APCR/HEAT/etc.

That said, I do want to point out that it does require a bit more implementation than just adding the rule, specifically the way supply is currently handled (and you can see this in the DB) is that every unit has enough supply for 10 rounds of combat; internally this 10-round mark is what is tracked, not the actual total GSP of the element. Thus probably a simpler implementation is to have a %chance of consuming a round of supplies for "sub-caliber" targets, which is similar to how resupply is implemented already.

Compared to Jorgen's rule proposal this means heavy weapons will be guaranteed to always shoot but the cost of shooting small targets will be reduced. Net effect, supply consumption with this change is probably somewhat higher overall but weapon kill rates are also a little higher. Notably I've realized this avoids problems with e.g. heavy artillery not firing which would crop up with the other approach.
 

Offline Sunmannus

  • Leading Rate
  • *
  • S
  • Posts: 5
  • Thanked: 6 times
Re: C# Suggestions
« Reply #1409 on: February 01, 2021, 12:45:10 PM »
I'm sure it's been suggested before, but to bring it back to your attention:

I would like some kind of visual indicator regarding the fuel needed to fulfill the orders assigned to a fleet.  A simple indication in the naval organization> fleet tab (maybe next to the all orders distance and travel time required) that indicates in red if the fleet lacks enough fuel to finish all current orders or yellow if it passes the point of no return.
This would definitely help us better plan routes and avoid stranded fleets out of fuel in the middle of nowhere. 
 
The following users thanked this post: serger, Warer, LiquidGold2