Author Topic: C# Aurora v0.x Suggestions  (Read 351993 times)

0 Members and 3 Guests are viewing this topic.

Offline L0ckAndL0ad

  • Lieutenant
  • *******
  • L
  • Posts: 168
  • Thanked: 59 times
Re: C# Aurora v0.x Suggestions
« Reply #1665 on: January 06, 2020, 02:19:49 PM »
I was reading through all the changes notes and found the info about the AI using fuel now in C#, while still being given a leeway to travel without fuel while searching for it, which is a great change IMO.

With the new maintenance system in place, hasn't there been anything similar done to AI ship usage of MSP? In my current 7.1 campaign, I see two NPRs (now both friendly, thankfully  :)) mass hundreds and hundreds of ships. They don't need maintenance and it's frankly terrifying and... discouraging.

If similar (to fuel) changes cannot be made to AI ship MSP usage, can, at least, AI ships have some sort of rules to scrap old ships to prevent huge  NPR navies?

Also, I'd welcome any features involving giving more control to Civilian sector, like moving minerals between planets the same way they can transport installations for you.

Otherwise, all the C# changes I've read about so far sound absolutely great. Thank you for your work, Steve!
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11672
  • Thanked: 20454 times
Re: C# Aurora v0.x Suggestions
« Reply #1666 on: January 06, 2020, 02:49:49 PM »
I was reading through all the changes notes and found the info about the AI using fuel now in C#, while still being given a leeway to travel without fuel while searching for it, which is a great change IMO.

With the new maintenance system in place, hasn't there been anything similar done to AI ship usage of MSP? In my current 7.1 campaign, I see two NPRs (now both friendly, thankfully  :)) mass hundreds and hundreds of ships. They don't need maintenance and it's frankly terrifying and... discouraging.

If similar (to fuel) changes cannot be made to AI ship MSP usage, can, at least, AI ships have some sort of rules to scrap old ships to prevent huge  NPR navies?

Also, I'd welcome any features involving giving more control to Civilian sector, like moving minerals between planets the same way they can transport installations for you.

Otherwise, all the C# changes I've read about so far sound absolutely great. Thank you for your work, Steve!

I will tackle AI maintenance at some point, but probably not for initial release.
 

Offline JacenHan

  • Captain
  • **********
  • Posts: 454
  • Thanked: 115 times
  • Discord Username: Jacenhan
Re: C# Aurora v0.x Suggestions
« Reply #1667 on: January 06, 2020, 03:53:52 PM »
Does the AI currently try to stay within (or near) the limit of its maintenance facilities, even if it doesn't technically use them? That seems like the easiest implementation without making them care about actual maintenance.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11672
  • Thanked: 20454 times
Re: C# Aurora v0.x Suggestions
« Reply #1668 on: January 06, 2020, 04:52:48 PM »
Does the AI currently try to stay within (or near) the limit of its maintenance facilities, even if it doesn't technically use them? That seems like the easiest implementation without making them care about actual maintenance.

To do that, it would also have to consider building extra maintenance facilities when needed, or predict they will be needed, and to prioritise that over other construction tasks. For the full maintenance, the AI will have to take into account availability, location and production rates of maintenance supplies. It's not straightforward, but I will probably aim for something similar to fuel, where the AI does the best it can, but isn't penalised too heavily if it runs out.

 
The following users thanked this post: AlStar, JacenHan, Alsadius, L0ckAndL0ad

Offline AlStar

  • Lieutenant
  • *******
  • Posts: 197
  • Thanked: 147 times
  • Flag Maker Flag Maker : For creating Flags for Aurora
    Race Maker Race Maker : Creating race images
Re: C# Aurora v0.x Suggestions
« Reply #1669 on: January 08, 2020, 10:05:16 AM »
I was thinking that a ground-based invasion risk (which isn't combined with a major space force) could be interesting.
Basically, motherships that, upon getting within range of a colony, fire off dozens of armored shuttles which drop off an assault force - possibly consuming the mothership in the process.

Now as to how to actually get these motherships within range of colonies, I had two ideas - first, that they come from unexplored jump points, and will head towards habitable planets (if any exist in the system).  Once they get within active sensor range of the planet, if they detect anything, they launch.  If no planets have a colony they can detect (or if no habitable planets exist), they pick a random (explored) jump point and jump through it.

Alternatively, the motherships are generated in the system, powered down (and/or stealthed), within passive sensor range of habitable planets.  Once a colony gets large enough to trigger their sensors, they power up and drop their shuttles.
 
The following users thanked this post: Alsadius

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1670 on: January 08, 2020, 11:37:13 AM »
One suggestion that might be interesting about Beam Fire-controls.

I don't particular like that fighter fire-controls are just arbitrarily smaller, I do understand that it is game balance... but I think it could be better. I offer an alternative that give more options.

When you create a fire-control you select whether it should be ship, turret or fixed (or ground based).

The ship fire-control is tied to the ships speed and can never deliver more accuracy than the speed of the ship with a lower cap of the basic speed of the fire-control. This fire control are x2 the speed of the normal fire-control.

The turret fire control is pretty much your standard fire-control.

Fixed installation fire-controls can only function on space station or structures with no engines. They get a x1.5 modifier to the range efficiency.

Ground based fire-controls get the same x2 range bonus as it does in C# currently.

Or some variation of this... shure... you could probably game some if this with tractoring space station modules for better FC or something, but that could possibly be fixed or just ignored.
« Last Edit: January 08, 2020, 12:08:22 PM by Jorgen_CAB »
 
The following users thanked this post: JustAnotherDude

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11672
  • Thanked: 20454 times
Re: C# Aurora v0.x Suggestions
« Reply #1671 on: January 08, 2020, 12:12:16 PM »
I don't think I mentioned anywhere but I removed the fighter beam fire control. All beam fire controls now have the same rules.
 

Offline JustAnotherDude

  • Sub-Lieutenant
  • ******
  • J
  • Posts: 114
  • Thanked: 56 times
Re: C# Aurora v0.x Suggestions
« Reply #1672 on: January 08, 2020, 02:48:36 PM »
Are there any plans to replace them with some other mechanic? It seems like beam fighters have no real niche as it is.
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1673 on: January 08, 2020, 03:45:18 PM »
Are there any plans to replace them with some other mechanic? It seems like beam fighters have no real niche as it is.

Beam fighters can be quite effective against other fighters and as PD for other fighters or even ships for that matter. It is far cheaper to kill enemy fighters with beam weapons than missiles. They could also work well against more or less unarmed scouts for example.

With the new sensor rules in C# it is quite cheap and effective to keep a small PD screen for your fighter-bombers.
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1674 on: January 08, 2020, 03:51:03 PM »
I don't think I mentioned anywhere but I removed the fighter beam fire control. All beam fire controls now have the same rules.

That sounds good... although I still think you could do something more with beam fire-controls.

For example having longer range on station beams would make them more viable as defensive obstacles in space other than used as missile platforms, especially if you want to defend a point in space, such as a jump point.

Then having a fire-control that act sort of like the fighter fire-control did but available for any ship could also be interesting.

Or perhaps something completely different.

Not something I would suggest for the release of C#, but something down the road perhaps.

I would also not mind if fire-controls had some more limitation such as how many weapons they can serve and what type of weapons. I guess that a fire-control for a laser would probably be very different from a fire-control for a rail-gun for example.
« Last Edit: January 08, 2020, 04:39:57 PM by Jorgen_CAB »
 

Offline shepard1707

  • Leading Rate
  • *
  • s
  • Posts: 10
  • Thanked: 2 times
Re: C# Aurora v0.x Suggestions
« Reply #1675 on: January 09, 2020, 06:31:18 AM »
Another one off of my head, though I'd be very surprised if it hasn't been suggested in some way before:

Changing the way power plants and thrusters both work.

Specifically, Power-Plants now require fuel to operate, demanding a given amount of fuel per power-hour they produce.  Like with engines, if they are not using their full power, they do not use their full fuel consumption.  Like with engines, their efficiency is closely related to both their size, and their 'boost' out put, with high efficiency 'commercial' engines having low total output and large size, and on the other end high boosted engines being much much less efficient, but much smaller and with better total power outputs.  The explosion chance upon destruction would likely remain.

The big thing this would change, however would be that now, everything requires some degree of power output.
  • Active sensors require power based on their active element and their size.  This means that there's good reason to make a low power-ed active element, but highly sensitive sensor.
  • Passive sensors require power based on their size.
  • Shields require power in a manner which would functionally mimic their fuel use previously.
  • Missile Launchers require power to fire, based on size.  This would be to imitate the loading mechanisms at work.  Reduced Launcher Size reduces power need at the same rate it reduces reload time (with box launchers requiring no power)
  • Jump Drives now Require power based on their total jump tonnage, but possibly with efficiency inversely proportional to their mass efficiency.
  • Cloaking Tech requires Power, again, based on it's efficiency.
  • All other 'non designed' technologies require power as well, with the exception of fuel tanks.
  • last, but not least: Engines Require Power

Engines, in this case, would no longer require any fuel to operate.  This is because, rather than being based on our modern understanding of Newtonian physics where fast thing goes out back, ship moves forward, they instead impel against the Aether/Sub-Space in some way.  Making this single change alone, however, does certainly flatten the granularity of engine design, which is why I propose a pair of further additions, this time onto Engines: Top Speed/Cruising Speed and Acceleration.  They might both be taken, or neither.

In the case of Top Speed/Cruising-Speed, the power necessary to operate an engine could be on a curve towards 100% at 100%, such that at 50% speed the engine is using less than 50% power, and thus, less than 50% fuel.  Boosted engines would basically expand the curve, while more efficient engines would shrink it back.  More powerful engines produce more engine power for a given amount of power input, thus producing a different function of efficiency to speed.

Alternately, one could include acceleration: Ships now do not automatically go 0 to x000km/s But require some time to accelerate towards their top speed.  More efficient engines are slower to accelerate, while less efficient engines have much higher acceleration.  This could be combined with the concept of Top/Cruising Speed by having engines use their full power requirement during acceleration, but require only HALF power when above or below a certain speed threshold.  A 'Commercial Engine' in this case would have it's cruising speed BE it's top speed, but perhaps still being inefficient in size, while a fighter or missile engine wouldn't have any cruising speed at all, but be at reduced size.

In this case, 'Acceleration' also becomes the measure of maneuverability, rather than top speed.  Determining how quickly a vessel can change course, how easily it can avoid enemy fire, etc.  (In the case of the former, perhaps the percentage of acceleration compared to top-speed functionally determines how fast it can turn within a 5 second interval).

I dunno.  A lot of this was written while forced awake by nasty gas pain.
 
The following users thanked this post: GeaXle

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1676 on: January 09, 2020, 07:14:05 AM »
Sounds interesting... I agree that handling the power grid of ships would make an additional variable to juggle and could be fun. I certainly like engines that would have differences in acceleration versus efficient etc... that sounds fun.

You could build a ship that could fire all their weapons, power the shield and run at max acceleration or speed at the same time, but you would compromise the space for weapons and defences to accommodate for powering all those systems at the same time.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11672
  • Thanked: 20454 times
Re: C# Aurora v0.x Suggestions
« Reply #1677 on: January 09, 2020, 09:13:43 AM »
Are there any plans to replace them with some other mechanic? It seems like beam fighters have no real niche as it is.

The 'fighter-only' beam fire control was removed because there wasn't really any reason that a fighter could have that and a normal ship couldn't. I am trying to rationalise as much as I can for C# and remove any 'special' rules. Fighters aren't F-18s, they are just small ships. Besides, BFC are smaller and cheaper than when the 'fighter-only' rule came into effect, plus sensors are smaller for fighters in C#, so there is more room for the fire control anyway.

I'm using beam fighters in my current campaign and they seem fine so far.
 
The following users thanked this post: serger

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2794
  • Thanked: 1054 times
Re: C# Aurora v0.x Suggestions
« Reply #1678 on: January 09, 2020, 12:37:13 PM »
We've had multiple flavours of suggestions over the years about power plants, power management, and fuel/power budget. It would be a massive changed to everything ship-related in Aurora. I'm not sure that a complex power management system, in both ship design and ship use, is where Aurora should go or needs to go - especially as Steve already removed one micromanagement aspect: shields no longer consume fuel, as well as making Fire Control/Weapon assignments easily automated.

Power management is great in a space sim game where you control a single ship. Not so much when you could have a hundred ships/fighters engaged in battle and you might need to fiddle with them. And if you only implement power management at ship design, you're going to have a lot of people demanding that it should be a part of combat too - all power to the shields and all that jazz.
 
The following users thanked this post: Bremen

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1679 on: January 09, 2020, 01:34:31 PM »
We've had multiple flavours of suggestions over the years about power plants, power management, and fuel/power budget. It would be a massive changed to everything ship-related in Aurora. I'm not sure that a complex power management system, in both ship design and ship use, is where Aurora should go or needs to go - especially as Steve already removed one micromanagement aspect: shields no longer consume fuel, as well as making Fire Control/Weapon assignments easily automated.

Power management is great in a space sim game where you control a single ship. Not so much when you could have a hundred ships/fighters engaged in battle and you might need to fiddle with them. And if you only implement power management at ship design, you're going to have a lot of people demanding that it should be a part of combat too - all power to the shields and all that jazz.

Well it works pretty well in games such as Distant Worlds which have far less intricate ship design systems. They work pretty much as described above and it work fairly well and is not difficult to comprehend or design around. There you have three different speed settings which all use different amounts of energy and thus fuel. You need fuel to power the power plants and the efficiency of burning fuel is connected to the type of power plants that you have.

I don't think it would be difficult to handle if it was changed down the line, it would at least open up several new possibilities to build ships and why you do it.