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

0 Members and 1 Guest are viewing this topic.

Online Steve Walmsley

  • Moderator
  • Admiral of the Fleet
  • *****
  • S
  • Posts: 6893
  • Thanked: 1547 times
    • http://www.starfireassistant.com
Re: C# Aurora v0.x Suggestions
« Reply #30 on: February 26, 2018, 12:56:43 PM »
I'll repost a possible change I suggested in the C# discussion thread: that real star systems with known planets in real life generate with those planets.  That is, something like Proxima Centauri will always have a 1. 25 Earth-mass planet orbiting 7. 2 MKm away from it.  All the known planets would exist in a database, and the existing system generation code would be modified to generate other planets and asteroids around the real planets.  So we have Prox Cen b, and then maybe some Jupiter-mass companion and asteroid belts out at 2 AU (or something).

Steve, I'm an exoplanet astronomer by day, and I'd be happy to help compile the planet information for you, suggest modifications to the system generation code, or even help modify it myself.

I have considered this in the past. The issue is that the system generation code is quite complex and it can be hard to adjust it around ensuring certain planets are in the right locations while having everything else make sense. Plus, I am not sure how what is already known about affects what else may be possible. Would there be an undetected gas giant in a system with a detected terrestrial world for example? It might be easier to have some preset systems instead.

One other consideration is the current generation method adds a lot of variety, which would not be there is the same planets are always in the same locations. Doesn't prevent it being an option though.
 

Offline Jorgen_CAB

  • Commodore
  • **********
  • J
  • Posts: 727
  • Thanked: 8 times
Re: C# Aurora v0.x Suggestions
« Reply #31 on: February 26, 2018, 01:19:53 PM »
I will repost one suggestion from another thread...

Please change the way you implement the wait command fro VB6. In VB6 this was not working great and not working at all with cycled orders, as far as I know.

I think it would be better to just have them as a regular command, three new ones... Wait in seconds, wait in hours, wait in days. You can then just inject these orders as any regular order and it is easily recognized and tracked.
 
The following users thanked this post: waresky, Conscript Gary, TMaekler

Offline gaz

  • Able Ordinary Rate
  • g
  • Posts: 2
Re: C# Aurora v0.x Suggestions
« Reply #32 on: February 27, 2018, 02:10:56 AM »

No idea whether this has been mooted before (guessing it has)  - but be awesome to have solar bodies mask / reduce sensor profiles etc.  .  .

ie the possibility for sensor blind spots based on solar bodies - or how about gas clouds etc.  .  .  .   Im thinking Wrath of Khan  star Trek.  .  .  .  .

"The invasion fleet approaching from the dark side of the moon".  .  .  .  .   Defender fleets hiding behind moons etc

Be great - Im guessing would be a ball ache to programme in - but if possible just add a whole new level of depth.
 

Offline TMaekler

  • Commander
  • *********
  • Posts: 317
  • Thanked: 41 times
Re: C# Aurora v0.x Suggestions
« Reply #33 on: February 27, 2018, 06:44:42 AM »
Please change the way you implement the wait command fro VB6. (...)

I think it would be better to just have them as a regular command, three new ones... Wait in seconds, wait in hours, wait in days. You can then just inject these orders as any regular order and it is easily recognized and tracked.
More options to "wait on a specific action or state" would be nice. E.G.: wait until fleet has joined this fleet, wait until x amount of fuel is in cargo of target fleet (for transporting them from harvesters to a colony), wait until x amount of mineral(s) is at target colony, wait until x amount of installation is at target colony, etc.
 

Offline clement

  • Pulsar 4x Dev
  • Warrant Officer, Class 1
  • *
  • c
  • Posts: 93
  • Thanked: 2 times
Re: C# Aurora v0.x Suggestions
« Reply #34 on: February 27, 2018, 09:36:31 AM »
Steve,

After seeing your screenshot of the named waypoints and specifically the "Fleet Exercise Area" waypoint, would it be possible to assign a waypoint (or other destination) to the Fleet Training action?

If assigned, the fleet would move to that waypoint/location and then stay within a certain distance while performing fleet training exercises?
If unassigned, the fleet would behave as currently designed.

As a secondary item, the UI might need to allow a distance to be added to the order to control how far the fleet ranges from the waypoint. I would require the distance to have a minimum (and default), perhaps the range of the longest ranged missile in the fleet or 25 million KM if no missiles are in the fleet.

 

Online Steve Walmsley

  • Moderator
  • Admiral of the Fleet
  • *****
  • S
  • Posts: 6893
  • Thanked: 1547 times
    • http://www.starfireassistant.com
Re: C# Aurora v0.x Suggestions
« Reply #35 on: February 27, 2018, 10:13:26 AM »
Steve,

After seeing your screenshot of the named waypoints and specifically the "Fleet Exercise Area" waypoint, would it be possible to assign a waypoint (or other destination) to the Fleet Training action?

If assigned, the fleet would move to that waypoint/location and then stay within a certain distance while performing fleet training exercises?
If unassigned, the fleet would behave as currently designed.

As a secondary item, the UI might need to allow a distance to be added to the order to control how far the fleet ranges from the waypoint. I would require the distance to have a minimum (and default), perhaps the range of the longest ranged missile in the fleet or 25 million KM if no missiles are in the fleet.

Yes, I had this in mind when I named that waypoint :)
 
The following users thanked this post: clement

Offline alex_brunius

  • Rear Admiral
  • **********
  • Posts: 946
  • Thanked: 31 times
Re: C# Aurora v0.x Suggestions
« Reply #36 on: February 28, 2018, 07:20:22 AM »
Speaking of training missile warships and fighters it might make sense if they actually had to launch fighters/expend live missiles during training or at least could do so to speed up the progress.

I like to RP that each launcher need to fire at least once and Fighters fly one sortie during training to not have a SM fail chance when used in anger for real the first time.

This could also make spying on enemy training manouvers a thing if implemented well.. or maybe I'm going into unnessecary detail here
 

Online Steve Walmsley

  • Moderator
  • Admiral of the Fleet
  • *****
  • S
  • Posts: 6893
  • Thanked: 1547 times
    • http://www.starfireassistant.com
Re: C# Aurora v0.x Suggestions
« Reply #37 on: February 28, 2018, 09:16:21 AM »
Speaking of training missile warships and fighters it might make sense if they actually had to launch fighters/expend live missiles during training or at least could do so to speed up the progress.

I like to RP that each launcher need to fire at least once and Fighters fly one sortie during training to not have a SM fail chance when used in anger for real the first time.

This could also make spying on enemy training manouvers a thing if implemented well.. or maybe I'm going into unnessecary detail here

I guess in that case there should be the option to build cheaper training missiles
 

Offline serger

  • Lieutenant
  • *******
  • Posts: 157
  • Thanked: 11 times
Re: C# Aurora v0.x Suggestions
« Reply #38 on: February 28, 2018, 01:02:39 PM »
I guess in that case there should be the option to build cheaper training missiles
Yep, it will be great!
 

Offline Bremen

  • Commander
  • *********
  • B
  • Posts: 360
  • Thanked: 20 times
Re: C# Aurora v0.x Suggestions
« Reply #39 on: February 28, 2018, 01:21:29 PM »
I guess in that case there should be the option to build cheaper training missiles

Maybe just making training use MSP then? There doesn't seem to be much point in tracking training specific missiles.

edit: If you do that it might also be a good opportunity to modify how fuel use while training works and can vary based on the speed of the slowest ship in the fleet.
 

Offline Zincat

  • Lt. Commander
  • ********
  • Z
  • Posts: 283
  • Thanked: 26 times
Re: C# Aurora v0.x Suggestions
« Reply #40 on: February 28, 2018, 02:08:20 PM »
Please no. I think I'd go insane if I had to even design, build and use training missiles.

If you really want to model training, a maintenance supplies usage will be enough...
 

Offline Graham

  • Petty Officer
  • **
  • Posts: 22
  • Thanked: 11 times
Re: C# Aurora v0.x Suggestions
« Reply #41 on: February 28, 2018, 02:16:10 PM »
I agree with Zincat.

Training already has it's costs and I would rather not have another thing to micro which I don't think will add much game play value.
 

Online QuakeIV

  • Registered
  • Lt. Commander
  • ********
  • Posts: 233
  • Thanked: 14 times
Re: C# Aurora v0.x Suggestions
« Reply #42 on: February 28, 2018, 03:55:50 PM »
Id kindof prefer a training missile item.  Doesn't need to be specially designed by the player but it adds some depth if ships out on training are carrying less live ordnance due to their load of training missiles and get caught by the enemy.  Making even more things just an MSP cost is a terrible cop out that isnt even worth adding imo.
 

Offline Whitecold

  • Lieutenant
  • *******
  • W
  • Posts: 187
  • Thanked: 21 times
Re: C# Aurora v0.x Suggestions
« Reply #43 on: February 28, 2018, 04:27:02 PM »
Can we get a proper fleet combat interface that allows to assign targets to fire controls on an entire fleet instead of having to cycle through each individual ship?

My idea involves fire controls getting set to a fleet fire control channel. These channels then manage all fire controls assigned to them, so you might have a "Beams" channel, a "Beam PD," a "Missile PD", or a "Missile" channel.
Assigning targets (Multiple selection allowed) to a channel means all fire controls will fire on those selected targets.
Channels could have various options, max salvos in flight, max salvos per target in flight, focus fire, spread fire, point defense availability

Target selection would be inherited if a lower formation doesn't override it. So if the channel "Missile" of 1st Fleet targets the enemy battleships, the channel "Missile" of 2nd Squadron of 1st fleet can target an escort, then the Squadron will fire at the escort until it is destroyed, then will switch to the battleships set by the Fleet wide level.

All this would make handling large battles much easier. I don't see anyone having fun assigning each fighter a target when a hundred fighters clash with another hundred.
 

Online Steve Walmsley

  • Moderator
  • Admiral of the Fleet
  • *****
  • S
  • Posts: 6893
  • Thanked: 1547 times
    • http://www.starfireassistant.com
Re: C# Aurora v0.x Suggestions
« Reply #44 on: February 28, 2018, 04:53:44 PM »
Can we get a proper fleet combat interface that allows to assign targets to fire controls on an entire fleet instead of having to cycle through each individual ship?

My idea involves fire controls getting set to a fleet fire control channel. These channels then manage all fire controls assigned to them, so you might have a "Beams" channel, a "Beam PD," a "Missile PD", or a "Missile" channel.
Assigning targets (Multiple selection allowed) to a channel means all fire controls will fire on those selected targets.
Channels could have various options, max salvos in flight, max salvos per target in flight, focus fire, spread fire, point defense availability

Target selection would be inherited if a lower formation doesn't override it. So if the channel "Missile" of 1st Fleet targets the enemy battleships, the channel "Missile" of 2nd Squadron of 1st fleet can target an escort, then the Squadron will fire at the escort until it is destroyed, then will switch to the battleships set by the Fleet wide level.

All this would make handling large battles much easier. I don't see anyone having fun assigning each fighter a target when a hundred fighters clash with another hundred.

In VB6 you can use the Combat Overview window to assign fleet wide targeting.
 

 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52