Author Topic: C# Suggestions  (Read 272829 times)

0 Members and 1 Guest are viewing this topic.

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Suggestions
« Reply #825 on: July 13, 2020, 10:14:40 AM »
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.

The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.

We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.

This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.

As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.
« Last Edit: July 13, 2020, 10:31:14 AM by Jorgen_CAB »
 

Offline Iceranger

  • Registered
  • Commander
  • *********
  • I
  • Posts: 391
  • Thanked: 230 times
Re: C# Suggestions
« Reply #826 on: July 13, 2020, 10:54:33 AM »
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.

The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.

We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.

This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.

As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.

So basically the 'escort' order in VB6 I guess?
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: C# Suggestions
« Reply #827 on: July 13, 2020, 10:54:50 AM »
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.

The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.

We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.

This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.

As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.

I think a cool extension of the VB6 escort mechanics would be to make a new kind of waypoint which instead of being fixed to a point in space, is determined relative to the position of the parent fleet.

So I could have two forward "fleet waypoints" that are attached to the main body, one is 45 degrees off the port beam and the other 45 degrees off the starboard beam, each 20m km away. I could have a sensor parasite be sent to one of those points and make a cycling order for it to move between the two waypoints, effectively creating a very convenient forward sensor patrol to detect targets for the main fleet.

Of course having a type of waypoint that can change position is a new concept programmatically so that can complicate things.
 

Offline skoormit

  • Rear Admiral
  • **********
  • Posts: 804
  • Thanked: 324 times
Re: C# Suggestions
« Reply #828 on: July 13, 2020, 11:19:19 AM »
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.

The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.

We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.

This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.

As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.

I think a cool extension of the VB6 escort mechanics would be to make a new kind of waypoint which instead of being fixed to a point in space, is determined relative to the position of the parent fleet.

So I could have two forward "fleet waypoints" that are attached to the main body, one is 45 degrees off the port beam and the other 45 degrees off the starboard beam, each 20m km away. I could have a sensor parasite be sent to one of those points and make a cycling order for it to move between the two waypoints, effectively creating a very convenient forward sensor patrol to detect targets for the main fleet.

Of course having a type of waypoint that can change position is a new concept programmatically so that can complicate things.

I think you could do this with the VB6 escort mechanics, without needing waypoints.
You would just create two empty escort fleets at the desired bearing and distance from the main fleet, and give your sensor craft orders to move back and forth between the two fleets.

In other words, an empty fleet can act just like a waypoint.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: C# Suggestions
« Reply #829 on: July 13, 2020, 11:34:15 AM »
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.

The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.

We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.

This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.

As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.

I think a cool extension of the VB6 escort mechanics would be to make a new kind of waypoint which instead of being fixed to a point in space, is determined relative to the position of the parent fleet.

So I could have two forward "fleet waypoints" that are attached to the main body, one is 45 degrees off the port beam and the other 45 degrees off the starboard beam, each 20m km away. I could have a sensor parasite be sent to one of those points and make a cycling order for it to move between the two waypoints, effectively creating a very convenient forward sensor patrol to detect targets for the main fleet.

Of course having a type of waypoint that can change position is a new concept programmatically so that can complicate things.

I think you could do this with the VB6 escort mechanics, without needing waypoints.
You would just create two empty escort fleets at the desired bearing and distance from the main fleet, and give your sensor craft orders to move back and forth between the two fleets.

In other words, an empty fleet can act just like a waypoint.

Empty fleets can only move at 1km/s, watpoints also don't clutter the naval OOB, though that is a minor issue at best since there are ways around it.
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Suggestions
« Reply #830 on: July 13, 2020, 12:19:30 PM »
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.

The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.

We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.

This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.

As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.

I think a cool extension of the VB6 escort mechanics would be to make a new kind of waypoint which instead of being fixed to a point in space, is determined relative to the position of the parent fleet.

So I could have two forward "fleet waypoints" that are attached to the main body, one is 45 degrees off the port beam and the other 45 degrees off the starboard beam, each 20m km away. I could have a sensor parasite be sent to one of those points and make a cycling order for it to move between the two waypoints, effectively creating a very convenient forward sensor patrol to detect targets for the main fleet.

Of course having a type of waypoint that can change position is a new concept programmatically so that can complicate things.

I think you could do this with the VB6 escort mechanics, without needing waypoints.
You would just create two empty escort fleets at the desired bearing and distance from the main fleet, and give your sensor craft orders to move back and forth between the two fleets.

In other words, an empty fleet can act just like a waypoint.

Empty fleets can only move at 1km/s, watpoints also don't clutter the naval OOB, though that is a minor issue at best since there are ways around it.

I have already suggested to bring back the escort mechanic and I would really like to have that back.

This particular suggestion that I made is more realistic in the short term as I believe most of the coding is already there and Steve could do this relatively quickly with little effort in comparison to code all of the escort mechanic from VB6.

Just adding in an expanded follow order would essentially make patrols around fleets quite viable.

I would not be against being able to say have way-points that move with fleets as an optional way to use scouting reference points. It would then be possible to have true patrols in a more dynamic fashion. But that is a different thing for the future, very good suggestion though.
« Last Edit: July 14, 2020, 02:25:16 AM by Jorgen_CAB »
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Suggestions
« Reply #831 on: July 13, 2020, 10:06:06 PM »
I think it would suffice to say that it would be really nice to have an easy-to-use escort mechanic, without speculating as to how difficult it would be to implement.

Also:
So I was talking with some dude known only as 'Niko' on the discord and he pointed out that dismantling components would be a lot more useful if it provided 'say, X% of that tech level's stuff'.

I kindof took this to mean if it provided X% of progress to every intervening tech level up to and including the final technology itself, that would make it a lot more useful.  I personally wholeheartedly approve of this notion and felt the need to post it on the forums.  Currently you are encouraged to wait until one tech level before the tech of the device, to maximize the research point gain.  I think that some kind of boost of this nature would make archeology a significantly more fun mechanic in general as it would mean you want to dismantle whatever you find as soon as possible and would be rushing to obtain artifacts and ship them off for disassembly.

In example, a component offers 10% progress towards ion drive tech, and your empire is currently at nuclear thermal.

Currently:
10% progress towards improved nuclear thermal

Proposed:
10% progress towards improved nuclear thermal
10% progress towards nuclear pulse
10% progress towards improved nuclear pulse
10% progress towards ion engines

It might sound good from a game-play perspective but not from a more realistic perspective. If a medieval society found a working computer they would never make anything out of it before they progressed through the technology to understand how it works. It is the same principle in the game. You can use the technology but you can't understand how it works unless you have a fundamental understanding of the technologies necessary.

I don't agree, it seems to me that generally speaking (by default) the vast majority of components you try to disassemble will be within 100 years of whatever tech you have now (if not like 20 to 40 years) rather than centuries upon centuries (computers vs medieval tech level).  It would be a reasonable approximation to assume that generally speaking your civilization knows what its looking at when it tries to disassemble a component, and the current mechanic is in my opinion far too harsh in its punishment of disassembling stuff that is more than one tech level past what you currently have.
 
The following users thanked this post: serger

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Suggestions
« Reply #832 on: July 14, 2020, 02:18:53 AM »
I think it would suffice to say that it would be really nice to have an easy-to-use escort mechanic, without speculating as to how difficult it would be to implement.

Also:
So I was talking with some dude known only as 'Niko' on the discord and he pointed out that dismantling components would be a lot more useful if it provided 'say, X% of that tech level's stuff'.

I kindof took this to mean if it provided X% of progress to every intervening tech level up to and including the final technology itself, that would make it a lot more useful.  I personally wholeheartedly approve of this notion and felt the need to post it on the forums.  Currently you are encouraged to wait until one tech level before the tech of the device, to maximize the research point gain.  I think that some kind of boost of this nature would make archeology a significantly more fun mechanic in general as it would mean you want to dismantle whatever you find as soon as possible and would be rushing to obtain artifacts and ship them off for disassembly.

In example, a component offers 10% progress towards ion drive tech, and your empire is currently at nuclear thermal.

Currently:
10% progress towards improved nuclear thermal

Proposed:
10% progress towards improved nuclear thermal
10% progress towards nuclear pulse
10% progress towards improved nuclear pulse
10% progress towards ion engines

It might sound good from a game-play perspective but not from a more realistic perspective. If a medieval society found a working computer they would never make anything out of it before they progressed through the technology to understand how it works. It is the same principle in the game. You can use the technology but you can't understand how it works unless you have a fundamental understanding of the technologies necessary.

I don't agree, it seems to me that generally speaking (by default) the vast majority of components you try to disassemble will be within 100 years of whatever tech you have now (if not like 20 to 40 years) rather than centuries upon centuries (computers vs medieval tech level).  It would be a reasonable approximation to assume that generally speaking your civilization knows what its looking at when it tries to disassemble a component, and the current mechanic is in my opinion far too harsh in its punishment of disassembling stuff that is more than one tech level past what you currently have.

Just have to agree to disagree then... until then you can always use the components instead. I don't find this are either game breaking or imbalanced as there is a use for the items in the mean time. At least you used to be able to use items you had in store but could not make.
 

Offline SevenOfCarina

  • Lieutenant
  • *******
  • Posts: 170
  • Thanked: 95 times
Re: C# Suggestions
« Reply #833 on: July 14, 2020, 05:38:04 AM »
I would like it if launchers became more space-efficient as their size increases. Larger missiles are not exactly in a good place right now considering how frightfully deadly point-defence is; missile ECM and sensors force a certain minimum size, but there's still a really strong incentive to downsize as far as possible.

Instead of linearly scaling launcher size with missile size, I was thinking :
Launcher Size (HS) = (Missile Size in MSP)^0.8 x (Launcher Size Modifier)

This would mean that a full-size launcher for a 2.5 ton missile would take up 50 tons, for a 10 ton missile it would be 152 tons instead of 200 tons, for a 20 ton missile it would be 264 tons instead of 400 tons, and for a max-sized 250 ton missile it would be 1,990 tons instead of 5,000 tons.

I selected 0.80 as the exponent to avoid max-sized box launchers being smaller than the missiles they hold, but the exact factor is negotiable.
« Last Edit: July 14, 2020, 06:42:25 AM by SevenOfCarina »
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Suggestions
« Reply #834 on: July 14, 2020, 11:06:25 AM »
I would like it if launchers became more space-efficient as their size increases. Larger missiles are not exactly in a good place right now considering how frightfully deadly point-defence is; missile ECM and sensors force a certain minimum size, but there's still a really strong incentive to downsize as far as possible.

Instead of linearly scaling launcher size with missile size, I was thinking :
Launcher Size (HS) = (Missile Size in MSP)^0.8 x (Launcher Size Modifier)

This would mean that a full-size launcher for a 2.5 ton missile would take up 50 tons, for a 10 ton missile it would be 152 tons instead of 200 tons, for a 20 ton missile it would be 264 tons instead of 400 tons, and for a max-sized 250 ton missile it would be 1,990 tons instead of 5,000 tons.

I selected 0.80 as the exponent to avoid max-sized box launchers being smaller than the missiles they hold, but the exact factor is negotiable.

One other way is to force a communications module on each missile based on how far you like to guide it. Scale it so short distances are larger than longer distances too. This would force larger missiles for any type of range and still force a small communications device on really short distances, including AMM missiles. I think that would make even more sense.

There could be a size efficiency as well in addition to this.

Small swarming missiles are very potent and perhaps a bit too effective currently, as has always been the case.
 
The following users thanked this post: mike2R, serger, S1mancoder, Dawa1147

Offline xenoscepter

  • Vice Admiral
  • **********
  • Posts: 1157
  • Thanked: 318 times
Re: C# Suggestions
« Reply #835 on: July 14, 2020, 09:52:10 PM »
 - I agree more with seven of carina, large missiles already have an advantage in range over small missiles. They suffer mostly from throw weight, or rather their lack of it. However, I would think being able to add an additional to hit chance via a communications module would be nice. Better yet, have Thermal Reduction / Cloak work on missiles and bring back armored missiles. I also think armor should add HtK like turret armor does, but also add the % chance to not take damage while being unable to be added in amounts of less than 1 MSP. So no 1.5 or 0.5 MSP of armor.

 - The main issue I can see with larger missiles, sans the issue of saturating enemy PD, is the lack of something to do with them. ECM/ECCM isn't very big, and neither are Active or Passive Sensors. Engines automatically use the best fuel consumption, so even range stops being a big deal after a certain level of tech. The other big issue is accuracy, there is no reason to make slow missiles... at all. Slow probes? Yes, but slow missiles? No.

 - Seven of Carina's idea has in fact already been implemented by Steve to a point, larger launchers reload much, much faster than before. However, they do not yet scale their tonnage to capacity like Reactors and Shields now do, so big launchers are still ton for ton as efficient as smaller ones. Jorgen_CAB's idea would give big missiles something to do that small missiles can't. Even ECM/ECCM can be mounted comfortably in a Size 6 or 9 missile, while Active Sensors really don't matter much for ASMs.

 - Giving the big ones the ability to load up on accuracy gives them more of a reason to exist, as the whole advantage of a biger missile woudl be more room to put stuff. Sol there needs to be stuff to make them better. I am more in favor of an Advanced FCS Module though, which is tied to sensors on the missile itself. Two such FCS Modules in fact, one for Active and one for Passive, with each FCS conferring a bonus based on it's type.

 - The Active FCS would confer an accuracy bonus that would work identically to Missile Tracking Speed Bonus, the longer the missile is tracking the target the better the bonus. The Passive FCS would provide the same kind of bonus as the Active FCS, but would scale based on enemy EM/TH output versus the missile's ability to detect said output. So a really hot target would confer a much higher bonus regardless of the passive sensor strength of the missile, while a really good passive sensor suite on the missile would confer a high bonus despite the target being relatively "cold".

 - When you combine those ideas with Cloak / Thermal Reduction and add back in armor, suddenly all kinds of new options exist for all the different missile sizes. Want slow, but accurate torpedoes for Commerce Raiding? Use a combination of Passive TH Sensors with Passive FCS and add Armor. Want a speedy shield buster? Big engines, Passive FCS and Passive EM Sensors. Want an ASM to cut through enemy PD? Size 8 with 75% Cloak to appears as a Size 6 and 1 layer of Armor to help deal with Meson / Gauss / Railguns. Want a super accurate mega missile of DOOM? Just cram a crap ton of Active Sensors, Passive Sensors and FCS, add ECM/ECCM, armor and so on and so forth.

 - Under that model, missiles get deadlier as they get bigger, but they also get more expensive. Medium sized missiles become more useful, while Cloaked Missiles get more powerful as Cloaking Tech increases. At 50% Cloak, a Size 12 is as hard to see as a Size 6, but would cost more. A slow torpedo would benefit from the Thermal Reduction and the Passive FCS, while everything that is big enough to mount a credible Active Sensor would benefit greatly from an Active FCS. Armor would make big missiles even more viable, as by adding HtK suddenly Railguns and Gauss become less powerful against small salvos, while AMMs will need to be more powerful to compensate.

 - Incidentally, Mesons should ignore missile armor's % chance to block incoming damage, and just deal HtK against any missiles they hit. Conversely, AMMs should suffer a flat reduction proportional to the number of layers, and then deal the rest to HtK. So the % chance to ignore damage only involves Non-Meson Beam PD and CIWS. As an aside, Missile Stages should have an option to "Deploy Sub munitions on..." and then two check boxes that read, "Launch" and "Sensor Contact" respectively. This would allow the player to designate something as a mine or a bus w/o the fiddly bits, while a lack of designation in this regard would allow booster stages, armored shells to carry them past Fighter PD, or to create buses for Orbital Bombs
« Last Edit: July 14, 2020, 09:55:05 PM by xenoscepter »
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Suggestions
« Reply #836 on: July 15, 2020, 03:41:15 AM »
Spacemaster Control for AI Players

This suggestion should make it possible to keep AI empires as AI empires (and not having to switch them over to play-by-player) and therefore benefitting from not having to do everything on your own.

What is the goal of having AI empires in a game? Well, we ultimately want to tell a story. But knowing everything beforehand is boring (at least for the Storyteller). So having this unknown element of AI in the game benefits the story telling.

However you have to adjust the gameplay of the human empire(s) to how the AI is playing in order to not be overwhelmed by them. At the moment AI empires have their fixed ratios of how many research they ought to build and you have to match that - or loose the tech game in the long run. Being able to except some rough control over the AIs would make it nicer to tell stories and also play at „your own pace“ if you could limit or steer some general parameters of the AI empires. At some point it might be interesting to have maybe two allied AI empires split up and one joint a human empire. Being able to control the diplomacy on some Spacemaster level would be awesome... .

What do you all thing about this? Should we as SpaceMasters have some way to steer AI in certain directions? Would you benefit from that in your storytelling?
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Suggestions
« Reply #837 on: July 15, 2020, 05:00:05 AM »
- I agree more with seven of carina, large missiles already have an advantage in range over small missiles. They suffer mostly from throw weight, or rather their lack of it. However, I would think being able to add an additional to hit chance via a communications module would be nice. Better yet, have Thermal Reduction / Cloak work on missiles and bring back armored missiles. I also think armor should add HtK like turret armor does, but also add the % chance to not take damage while being unable to be added in amounts of less than 1 MSP. So no 1.5 or 0.5 MSP of armor.

 - The main issue I can see with larger missiles, sans the issue of saturating enemy PD, is the lack of something to do with them. ECM/ECCM isn't very big, and neither are Active or Passive Sensors. Engines automatically use the best fuel consumption, so even range stops being a big deal after a certain level of tech. The other big issue is accuracy, there is no reason to make slow missiles... at all. Slow probes? Yes, but slow missiles? No.

 - Seven of Carina's idea has in fact already been implemented by Steve to a point, larger launchers reload much, much faster than before. However, they do not yet scale their tonnage to capacity like Reactors and Shields now do, so big launchers are still ton for ton as efficient as smaller ones. Jorgen_CAB's idea would give big missiles something to do that small missiles can't. Even ECM/ECCM can be mounted comfortably in a Size 6 or 9 missile, while Active Sensors really don't matter much for ASMs.

 - Giving the big ones the ability to load up on accuracy gives them more of a reason to exist, as the whole advantage of a biger missile woudl be more room to put stuff. Sol there needs to be stuff to make them better. I am more in favor of an Advanced FCS Module though, which is tied to sensors on the missile itself. Two such FCS Modules in fact, one for Active and one for Passive, with each FCS conferring a bonus based on it's type.

 - The Active FCS would confer an accuracy bonus that would work identically to Missile Tracking Speed Bonus, the longer the missile is tracking the target the better the bonus. The Passive FCS would provide the same kind of bonus as the Active FCS, but would scale based on enemy EM/TH output versus the missile's ability to detect said output. So a really hot target would confer a much higher bonus regardless of the passive sensor strength of the missile, while a really good passive sensor suite on the missile would confer a high bonus despite the target being relatively "cold".

 - When you combine those ideas with Cloak / Thermal Reduction and add back in armor, suddenly all kinds of new options exist for all the different missile sizes. Want slow, but accurate torpedoes for Commerce Raiding? Use a combination of Passive TH Sensors with Passive FCS and add Armor. Want a speedy shield buster? Big engines, Passive FCS and Passive EM Sensors. Want an ASM to cut through enemy PD? Size 8 with 75% Cloak to appears as a Size 6 and 1 layer of Armor to help deal with Meson / Gauss / Railguns. Want a super accurate mega missile of DOOM? Just cram a crap ton of Active Sensors, Passive Sensors and FCS, add ECM/ECCM, armor and so on and so forth.

 - Under that model, missiles get deadlier as they get bigger, but they also get more expensive. Medium sized missiles become more useful, while Cloaked Missiles get more powerful as Cloaking Tech increases. At 50% Cloak, a Size 12 is as hard to see as a Size 6, but would cost more. A slow torpedo would benefit from the Thermal Reduction and the Passive FCS, while everything that is big enough to mount a credible Active Sensor would benefit greatly from an Active FCS. Armor would make big missiles even more viable, as by adding HtK suddenly Railguns and Gauss become less powerful against small salvos, while AMMs will need to be more powerful to compensate.

 - Incidentally, Mesons should ignore missile armor's % chance to block incoming damage, and just deal HtK against any missiles they hit. Conversely, AMMs should suffer a flat reduction proportional to the number of layers, and then deal the rest to HtK. So the % chance to ignore damage only involves Non-Meson Beam PD and CIWS. As an aside, Missile Stages should have an option to "Deploy Sub munitions on..." and then two check boxes that read, "Launch" and "Sensor Contact" respectively. This would allow the player to designate something as a mine or a bus w/o the fiddly bits, while a lack of designation in this regard would allow booster stages, armored shells to carry them past Fighter PD, or to create buses for Orbital Bombs

I think you touched on a few great points here.

One problem with missiles is that speed is the primary defence mechanisms for missiles. ECM is not really effective unless you have level 3 or more. As adding ECM before that slows down the missile too much and also make the missile way more expensive.

In order to make larger missile more viable there need to be some space in smaller missiles that needs to be filled so they need to sacrifice both speed and range to keep the same yield or reduce the yield to keep the speed and/or range.

I still believe that agility is a problem because it will make AMM missiles over time way too powerful while benefiting offensive missiles very little in return. A missile that use low speed with good agility and ECM should for the most part be more effective than just a pure fast missile... at least over medium to long range. But currently you will need pretty high ECM... at level 3 it often is a toss up and at level 4 then ECMs start to be very powerful, both for offence and defence.

In my multi-faction games I just give all factions an agility of 100 and never touch it again. It makes the missile balance relatively well... in my opinion that speaks for agility as implemented being a "problem".

It is just pure math in what is the best solution for whatever range you want to fire your missiles at. You always want as small missiles as possible to overpower the enemy point-defence. There is no point in using large powerful missiles if they never get to hit in the first place. If you need a size 6 missiles to fit both ECM and ECCM and a 12 point yield that missiles also need to be 50% more efficient than a size 4 missile that is faster with the same yield. That is most often a tall order unless ECM/ECCM levels are relatively high.

In my opinion ASM missiles at medium to long range should probably be designed in the game to be the most effective sizes of 6-10.

If you require a guidance system in every missile you will effectively make larger missiles more space effective even at smaller ranges too. This guidance system might be based of your EM technology as it is mainly a passive system that receive data not transmitting data. If the module are say 0.1 MSP for 1mkm, 0.2 MSP for 10mkm and 0.4 for 100mkm then distance is modified by your EM tech. Just as an example. When you create the missile this "module" is automatically added and adjusted as the missile maximum range is changed. You could easily then adjust the size by modifying the fuel to get the missile at the right size.

So now... if you want a missile to fire 50 million km it also will need a guidance system at 0.333 MSP, this will inflate missile size by roughly one point and it also will make the minimum 0.25 for other electronic modules smaller in comparison as increasing the missile further in size to fit them will not impact its performance as much anymore.

I have no direct ideas how to "fix" agility as a mechanic other than reducing the overall range of the agility score. It should start higher but also end much lower during progression... so perhaps start at 80 and end at 120 or so. Increase in agility will have a very huge impact on AMM missiles and not so much on ASM in general.

Perhaps adding some more electronic warfare that is not directly related to missiles could also be something interesting in the future.

If we start to fill missiles with more stuff and make them more expensive we might also need to increase the yield tech level one up the ladder as there will be less space for the same throw weight so missiles still have the same rough power as before.
« Last Edit: July 15, 2020, 05:06:50 AM by Jorgen_CAB »
 

Offline TheTalkingMeowth

  • Captain
  • **********
  • T
  • Posts: 494
  • Thanked: 203 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
Re: C# Suggestions
« Reply #838 on: July 15, 2020, 06:28:42 PM »
Regarding agility...realistically, a missile's chance to BE HIT should scale with agility. The "issue" with agility is that it makes AMMs more efficient as technology improves (this is not necessarily a bad thing), since attack missiles can only make themselves safer by increasing speed while AMMs can make themselves more lethal via speed, agility (and smaller warheads, to a lesser extent). Making agility help attack missiles avoid AMMs would negate that mismatch.

On the topic of modifying how to-hit chances work, should smaller ships (and missiles, presumably) inherently be harder to hit? Again from a realism perspective, they would be...though if we want to bring realism into Aurora's accuracy mechanics the changes will be...drastic.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: C# Suggestions
« Reply #839 on: July 15, 2020, 07:10:16 PM »
Regarding agility...realistically, a missile's chance to BE HIT should scale with agility. The "issue" with agility is that it makes AMMs more efficient as technology improves (this is not necessarily a bad thing), since attack missiles can only make themselves safer by increasing speed while AMMs can make themselves more lethal via speed, agility (and smaller warheads, to a lesser extent). Making agility help attack missiles avoid AMMs would negate that mismatch.

On the topic of modifying how to-hit chances work, should smaller ships (and missiles, presumably) inherently be harder to hit? Again from a realism perspective, they would be...though if we want to bring realism into Aurora's accuracy mechanics the changes will be...drastic.

Agility based evasion is a bit weird from a missile on missile evasion perspective because it assumes that missiles somehow have the ability to decide to engage in evasive maneuvers. Understand that because of the small detection range of AMMs combined with the relatively large attack range of attack missiles means that missiles will somehow need to evade missile which they don't even know they exist. So such detection would require an onboard missile sensor, passive or active which in turn takes up a large part of the missiles real estate, kind of defeating the point of the exercise.

Mind you this is a realism argument, not a gameplay one. I think from that perspective the missile needs to know that the AMM exists for it to even be able to attempt evasive maneuvers.