Author Topic: v1.13.0 Changes Discussion Thread  (Read 46841 times)

0 Members and 1 Guest are viewing this topic.

Offline Froggiest1982

  • Gold Supporter
  • Vice Admiral
  • *****
  • F
  • Posts: 1342
  • Thanked: 597 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: v1.13.0 Changes Discussion Thread
« Reply #75 on: December 21, 2020, 11:45:45 PM »
I think we mixing up the cakes here. One thing is unrest and another is morale. Low morale could lead to unrest while a specific event could leave to unrest regardless of the morale.
So I will keep this post within the unrest as it is in Aurora without adding anything else.

You have so much that could contribute to unrest in the way Aurora already considers it. I know some could agree with others on this post as they don't think something could be achieved while others would like to make it more interesting. Where I stand will be clear at the end of this post.

Back to the datas, you have at least 5 currently in game right now that could easily contribute in creating an equation able to satisfy many without destroying any mechanic or upset other players. Eventually such mechanic could be made optional through a check box same as the political reliability and realistic promotions.

2 out of 5 are already considered: Protection Value and Slavery (even if this could be objectively buffered a bit with more severe penalties at least).
Then you have:
Unemployment - this is an objective cause of unrest unless you live in an utopia society where people receive a universal wage to basically exist.
Access to trade goods: a shortfall of certain trade goods should cause unrest. Now this is tricky as it also affects civilian companies and such, but again something that could be easily overcome with a little buff lowering requirements perhaps.
Finally population. Same as per unemployment is unreasonable to think that in a society everybody is happy and a minimum of penalty should be applied regardless. Could even be 0.0001% per Mil pop for instance. Will require some testing of course but everything does.

The problem
While in theory all is fantastic and yes let's get more unrest and such there is a problem. At the end of the day all can be solved with more police, more Protection Value, and more and more you get the point.

So unless that can be sorted (and considering how the system is structured now I don't think you can) I don't see any reason why we should touch the system as it is right now. I mean all you are achieving is to build more ground units to counter the higher unrest penalty.

Obviously this is my view and I am sure there are many good ideas ready to change my mind. But these ideas must actually introduce a whole new mechanic and I am sure it will be super interesting but I really would like to have independence to NPR directly or even monetary aids, exchange of ships and such back from VB6 first to be honest before looking into unrest and revolts.

Online nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 3012
  • Thanked: 2268 times
  • Radioactive frozen beverage.
Re: v1.13.0 Changes Discussion Thread
« Reply #76 on: December 22, 2020, 12:14:37 AM »
I think we mixing up the cakes here. One thing is unrest and another is morale. Low morale could lead to unrest while a specific event could leave to unrest regardless of the morale.
So I will keep this post within the unrest as it is in Aurora without adding anything else.

You have so much that could contribute to unrest in the way Aurora already considers it. I know some could agree with others on this post as they don't think something could be achieved while others would like to make it more interesting. Where I stand will be clear at the end of this post.

Back to the datas, you have at least 5 currently in game right now that could easily contribute in creating an equation able to satisfy many without destroying any mechanic or upset other players. Eventually such mechanic could be made optional through a check box same as the political reliability and realistic promotions.

2 out of 5 are already considered: Protection Value and Slavery (even if this could be objectively buffered a bit with more severe penalties at least).

I feel like while the current unrest mechanic could be a bit more robust, the current system is good in its simplicity. Specifically both are tied to definite causes in-game which the player can directly influence, and the player can approach the causes of unrest in a few different ways to handle them which interact well with the core game mechanics, plus to a certain extent encourage "realistic" play without limiting options. This is a hallmark of good design.

Quote
Then you have:
Unemployment - this is an objective cause of unrest unless you live in an utopia society where people receive a universal wage to basically exist.

This is a difficult one. For starters, usually at the start of the game there is a significant unemployed fraction of the population which can be grown into economically or used to found colonies without killing Earth's manufacturing efficiency. This would also be a rather limiting mechanic unless it was toned down so much as to be barely noticeable, since often one will found a colony and populate it well in advance of relocating industry, etc. in order to stay ahead of the ball, so to speak. Finally, in realism terms a certain amount of unemployment is healthy for an economy as it facilitates a balance between labor supply, labor demand, and movement of laborers throughout the economy. In this respect, a flat "unemployment == bad" approach is not realistic, whereas an approach based around (say) a target unemployment fraction would be I think too complex for a mechanic where simplicity is preferable.

Quote
Access to trade goods: a shortfall of certain trade goods should cause unrest. Now this is tricky as it also affects civilian companies and such, but again something that could be easily overcome with a little buff lowering requirements perhaps.

This would be horrible to me as a player, because I have little if any way to actually influence trade goods. Besides the fact that only CSLs move these goods, I don't have any direct control over how to produce them to maintain a balance. And frankly, I wouldn't want the ability to do so in the game, because giving the player a knob to jiggle which only has the purpose of preventing Bad Things™ from happening is poor game design. Gameplay is best when it allows the player to work for a positive achievement, and worst when it forces the player to work for the sole purpose of staving off a negative modifier.

Quote
Finally population. Same as per unemployment is unreasonable to think that in a society everybody is happy and a minimum of penalty should be applied regardless. Could even be 0.0001% per Mil pop for instance. Will require some testing of course but everything does.

I believe PPV already incorporates a population size effect, larger populations require more PPV, so this would be somewhat redundant. Currently the PPV mechanic works well because it allows the player to address the need via any combination of ships and garrisons which meet the net PPV/unrest reduction needs, thus is quite flexible. A redundant population-based unrest modifier forces the player to maintain larger garrisons on bigger colonies regardless of PPV, which rather eclipses the effectiveness of that mechanic.

Quote
The problem
While in theory all is fantastic and yes let's get more unrest and such there is a problem. At the end of the day all can be solved with more police, more Protection Value, and more and more you get the point.

So unless that can be sorted (and considering how the system is structured now I don't think you can) I don't see any reason why we should touch the system as it is right now. I mean all you are achieving is to build more ground units to counter the higher unrest penalty.

Spot-on analysis, except that PPV does not directly reduce unrest. Only ground units do this. Otherwise though completely correct, ultimately all we're accomplishing is forcing the player to station more ground units everywhere. Currently the unrest system encourages this, but does not require it, leaving the player with flexibility to decide how he places his colonial defenses.

Quote
Obviously this is my view and I am sure there are many good ideas ready to change my mind. But these ideas must actually introduce a whole new mechanic and I am sure it will be super interesting but I really would like to have independence to NPR directly or even monetary aids, exchange of ships and such back from VB6 first to be honest before looking into unrest and revolts.

Agreed.

Independence directly to NPR is chiefly limited by the AI which presently lacks the ability to develop a strategy in-situ so to speak, i.e. if the AI is suddenly given a colony of basically random development level and ships/ground forces of variable composition, it cannot readily fit these into one of the predefined AI strategy templates and thus cannot use its resources with any effectiveness. Given that the AI when able to follow a preset strategy is...not exactly robust, let's say...I can see why this would be a rather imposing challenge.
 
The following users thanked this post: Froggiest1982, pwhk

Offline Migi

  • Captain
  • **********
  • Posts: 465
  • Thanked: 172 times
Re: v1.13.0 Changes Discussion Thread
« Reply #77 on: December 23, 2020, 12:44:16 PM »
I think it would be better for this discussion to continue in a separate thread because an overhaul of the PPV/morale system is not currently listed as a change in 1.13.
 
The following users thanked this post: Vivalas

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1710
  • Thanked: 602 times
Re: v1.13.0 Changes Discussion Thread
« Reply #78 on: December 26, 2020, 12:14:57 PM »
This might not be the correct thread but are there plans to fix naval mines / blind fired active missiles for 1.13?
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11713
  • Thanked: 20617 times
Re: v1.13.0 Changes Discussion Thread
« Reply #79 on: December 26, 2020, 01:13:00 PM »
This might not be the correct thread but are there plans to fix naval mines / blind fired active missiles for 1.13?

What is the problem with them? I haven't used them in any of my C# campaigns.
 

Offline RougeNPS

  • Lt. Commander
  • ********
  • R
  • Posts: 217
  • Thanked: 39 times
Re: v1.13.0 Changes Discussion Thread
« Reply #80 on: December 26, 2020, 02:59:24 PM »
They dont target correctly. I dont know the exact bug. EnterElysium explained the issue in one of his videos and im sure its somewhere in the bugs thread.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1710
  • Thanked: 602 times
Re: v1.13.0 Changes Discussion Thread
« Reply #81 on: December 26, 2020, 03:11:54 PM »
They dont target correctly. I dont know the exact bug. EnterElysium explained the issue in one of his videos and im sure its somewhere in the bugs thread.

This is the issue I was referrencing but I've asked for more detailed comment in the discord. EE also stated that self-guided missiles blind fired with no target would also have problems with targeting. If I get enough details I might be able to do a full bug report.

Edit - Below I'm going to post some discord testimonies over time:

"right now re targeting doesn't work for missiles for whatever reason its a bug"
"right now in C# your missile auto destroys itself if it doesn't have a target regardless of having an active sensor on it"
"even with a sensor on it it won't re target so it means over kill with missiles can be a problem"


« Last Edit: December 26, 2020, 03:14:23 PM by Droll »
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1710
  • Thanked: 602 times
Re: v1.13.0 Changes Discussion Thread
« Reply #82 on: December 26, 2020, 04:34:29 PM »
This might not be the correct thread but are there plans to fix naval mines / blind fired active missiles for 1.13?

What is the problem with them? I haven't used them in any of my C# campaigns.

Version 1.12

The above quote has my experimentation and conclusions regarding the state of active sensor missiles and naval mines posted to the bug thread. I'll delete my post of the experiment from this thread.
 

Offline Zap0

  • Captain
  • **********
  • Posts: 409
  • Thanked: 509 times
Re: v1.13.0 Changes Discussion Thread
« Reply #83 on: December 26, 2020, 04:39:30 PM »
1 - Despite standing still at the waypoint, the missiles expire after a while - seems like they still consume fuel when stationary (might be WAI for missiles but is a problem for naval mines)

The problem I have found regarding naval mines is that when an enemy fleet enters their sensor range they seek like they are supposed to. But the fact that all "salvos" of mines arrive at the same time means that they can at most destroy one ship as they tend to target the same vessel. This is the same problem that active missiles have.

Afaik mines are multi-stage missiles without an engine, which should therefore stay still in space forever. The first stage has an active sensor set to some trigger range, and if that range is set the second stage triggers (one or more actual short-range missiles). Am I right that what you're describing as mines there is just missiles fired at a waypoint where they'll idle with their timer ticking down until something is in range?

From your tests it sounds like the (re-)targeting behavior makes active missiles or minefields unviable at current anyway.

I haven't tried anything with mines/active sensor missiles in C# myself because they're, well, broken.

Here's a thread of somebody trying to use mines and their results.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1710
  • Thanked: 602 times
Re: v1.13.0 Changes Discussion Thread
« Reply #84 on: December 26, 2020, 04:55:16 PM »
1 - Despite standing still at the waypoint, the missiles expire after a while - seems like they still consume fuel when stationary (might be WAI for missiles but is a problem for naval mines)

The problem I have found regarding naval mines is that when an enemy fleet enters their sensor range they seek like they are supposed to. But the fact that all "salvos" of mines arrive at the same time means that they can at most destroy one ship as they tend to target the same vessel. This is the same problem that active missiles have.

Afaik mines are multi-stage missiles without an engine, which should therefore stay still in space forever. The first stage has an active sensor set to some trigger range, and if that range is set the second stage triggers (one or more actual short-range missiles). Am I right that what you're describing as mines there is just missiles fired at a waypoint where they'll idle with their timer ticking down until something is in range?

From your tests it sounds like the (re-)targeting behavior makes active missiles or minefields unviable at current anyway.

I haven't tried anything with mines/active sensor missiles in C# myself because they're, well, broken.

Here's a thread of somebody trying to use mines and their results.

The mines I used were single stage and had engines - firing them at a waypoint causes them to eventually expire, no good. Using "launch ready ordnance" seems to make them stay put forever (or maybe my test there was incomplete, but sensor buoys are also deployed like this)

From the way missile hit chance works you need the mine itself to have an engine, otherwise your hit chance will be 0 or damn close to it.

TBH my "mines" and "missiles" here are mechanically identical. All I did was vary the way their deployment was done. IMO stationary missiles without a target should not be running their timer down. That should happen when a target is acquired and movement begins.

I don't fully understand how a multi-stage mine works when it comes to trying to actually hit something.

So think of my mines as "active seekers" that stay put until something comes into range, where they behave as a missile.
 

Offline Froggiest1982

  • Gold Supporter
  • Vice Admiral
  • *****
  • F
  • Posts: 1342
  • Thanked: 597 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: v1.13.0 Changes Discussion Thread
« Reply #85 on: December 26, 2020, 04:56:42 PM »
1 - Despite standing still at the waypoint, the missiles expire after a while - seems like they still consume fuel when stationary (might be WAI for missiles but is a problem for naval mines)

The problem I have found regarding naval mines is that when an enemy fleet enters their sensor range they seek like they are supposed to. But the fact that all "salvos" of mines arrive at the same time means that they can at most destroy one ship as they tend to target the same vessel. This is the same problem that active missiles have.

Afaik mines are multi-stage missiles without an engine, which should therefore stay still in space forever. The first stage has an active sensor set to some trigger range, and if that range is set the second stage triggers (one or more actual short-range missiles). Am I right that what you're describing as mines there is just missiles fired at a waypoint where they'll idle with their timer ticking down until something is in range?

From your tests it sounds like the (re-)targeting behavior makes active missiles or minefields unviable at current anyway.

I haven't tried anything with mines/active sensor missiles in C# myself because they're, well, broken.

Here's a thread of somebody trying to use mines and their results.

Steve, currently second stage missiles, mines (not tested yet as general mine concept doesn't work so no point), and retarget or multi stage in general works only under an active MFC range.

I think it's fine for missiles to avoid cheaty designs of 500mkm range missile magically find its target out of a Waypoint making MFC useless otherwise so I would say WAI, however, it's impacting the mines design which are probably operating under the same rule. I dont know if you have changed something from the vb6 code, only you can answer/know that.

All other tests and attempts have failed.

Sensor buoys and Geo Probes do work fine.

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1710
  • Thanked: 602 times
Re: v1.13.0 Changes Discussion Thread
« Reply #86 on: December 26, 2020, 05:00:22 PM »
1 - Despite standing still at the waypoint, the missiles expire after a while - seems like they still consume fuel when stationary (might be WAI for missiles but is a problem for naval mines)

The problem I have found regarding naval mines is that when an enemy fleet enters their sensor range they seek like they are supposed to. But the fact that all "salvos" of mines arrive at the same time means that they can at most destroy one ship as they tend to target the same vessel. This is the same problem that active missiles have.

Afaik mines are multi-stage missiles without an engine, which should therefore stay still in space forever. The first stage has an active sensor set to some trigger range, and if that range is set the second stage triggers (one or more actual short-range missiles). Am I right that what you're describing as mines there is just missiles fired at a waypoint where they'll idle with their timer ticking down until something is in range?

From your tests it sounds like the (re-)targeting behavior makes active missiles or minefields unviable at current anyway.

I haven't tried anything with mines/active sensor missiles in C# myself because they're, well, broken.

Here's a thread of somebody trying to use mines and their results.

Steve, currently second stage missiles, mines (not tested yet as general mine concept doesn't work so no point), and retarget or multi stage in general works only under an active MFC range.

I think it's fine for missiles to avoid cheaty designs of 500mkm range missile magically find its target out of a Waypoint making MFC useless otherwise so I would say WAI, however, it's impacting the mines design which are probably operating under the same rule. I dont know if you have changed something from the vb6 code, only you can answer/know that.

All other tests and attempts have failed.

Sensor buoys and Geo Probes do work fine.

Missiles expiring at waypoints is fine since mines/sensor buoy placement actually works without waypoints, simultaneous salvos not properly re-targeting is not. Being forced to stagger launches makes PD un-penetrable for these missile/mine types.
 

Offline Froggiest1982

  • Gold Supporter
  • Vice Admiral
  • *****
  • F
  • Posts: 1342
  • Thanked: 597 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: v1.13.0 Changes Discussion Thread
« Reply #87 on: December 26, 2020, 05:11:17 PM »
1 - Despite standing still at the waypoint, the missiles expire after a while - seems like they still consume fuel when stationary (might be WAI for missiles but is a problem for naval mines)

The problem I have found regarding naval mines is that when an enemy fleet enters their sensor range they seek like they are supposed to. But the fact that all "salvos" of mines arrive at the same time means that they can at most destroy one ship as they tend to target the same vessel. This is the same problem that active missiles have.

Afaik mines are multi-stage missiles without an engine, which should therefore stay still in space forever. The first stage has an active sensor set to some trigger range, and if that range is set the second stage triggers (one or more actual short-range missiles). Am I right that what you're describing as mines there is just missiles fired at a waypoint where they'll idle with their timer ticking down until something is in range?

From your tests it sounds like the (re-)targeting behavior makes active missiles or minefields unviable at current anyway.

I haven't tried anything with mines/active sensor missiles in C# myself because they're, well, broken.

Here's a thread of somebody trying to use mines and their results.

Steve, currently second stage missiles, mines (not tested yet as general mine concept doesn't work so no point), and retarget or multi stage in general works only under an active MFC range.

I think it's fine for missiles to avoid cheaty designs of 500mkm range missile magically find its target out of a Waypoint making MFC useless otherwise so I would say WAI, however, it's impacting the mines design which are probably operating under the same rule. I dont know if you have changed something from the vb6 code, only you can answer/know that.

All other tests and attempts have failed.

Sensor buoys and Geo Probes do work fine.

Missiles expiring at waypoints is fine since mines/sensor buoy placement actually works without waypoints, simultaneous salvos not properly re-targeting is not. Being forced to stagger launches makes PD un-penetrable for these missile/mine types.

all I know is that compared to vb6 everything seems to work fine/same but mines. The reasons are yet unknown.

I am sure from time to time Steve may look into it but as it does not really use them he is just prioritizing other things which it's fine.

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1710
  • Thanked: 602 times
Re: v1.13.0 Changes Discussion Thread
« Reply #88 on: December 26, 2020, 05:26:29 PM »
all I know is that compared to vb6 everything seems to work fine/same but mines.

My point is that its not just mines but active missiles too that are borked.
 
The following users thanked this post: Froggiest1982

Offline Migi

  • Captain
  • **********
  • Posts: 465
  • Thanked: 172 times
Re: v1.13.0 Changes Discussion Thread
« Reply #89 on: December 28, 2020, 03:25:22 PM »
I just wanted to clarify, does the armour repair that happens in hangers cost MSP or is it free?