C# Suggestions

[TMaekler]

QoL to minimize micromanagement: A new command for ships to refit to a new class. You can add this command in the fleet tab. It check's if the shipyard has a free slipway and auto inserts itself into its queue. When done, the command is deleted - even if the fleet is set to cycle commands.
If at the time of checking the command there is no slipway free the command is kept alive - or if the fleet is on cycle commands, it is just skipped and added at the end of the queue and rechecked next time the fleet is back at the shipyard.

[TMaekler]

The system generator gave me a system with 291 Asteroids. They are unfortunately at a distance of 97 to 448bkm to the main star. A bit annoying to have to manually select the asteroids the exploration ship has to go to. Is there any way you can give us a special "go to closest system body" auto command which goes beyond the actual limit of I think 10bkm search radius?

[nuclearslurpee]

The system generator gave me a system with 291 Asteroids. They are unfortunately at a distance of 97 to 448bkm to the main star. A bit annoying to have to manually select the asteroids the exploration ship has to go to. Is there any way you can give us a special "go to closest system body" auto command which goes beyond the actual limit of I think 10bkm search radius?

Bit of a counter point: Having two orders to go survey a body is likely to confuse players, and the 10b km limit exists for a good reason with this system actually being a good example of that, if the nearest asteroid is 97b km your survey ships will almost certainly run out of fuel and get stranded in a very inconvenient place.

I would honestly take a hint from the game mechanics and leave the asteroid belt alone at that point, even exploiting it would be tricky at best, but if one does want to survey it I think having to manually manage that is a fair game, basically the Aurora version of 'sudo' in telling the game "Yes, I do think I know what I'm doing, let me screw things up the way I want to". 

[Stormtrooper]

I'd argue this limit could either be removed or configurable, this hurts especially with gas gaints with bazillion of moons just outside default range or binary systems even when you have lagrange points so that distance travelled is much shorter than distance between stars.

We have "survey nearest wreck" that is too automated because ships will automatically travel between systems to execute it, often ending up killed if the war is still raging on, meanwhile I can't even survey a big system without 28273651515 manual orders.

Also take into consideration that not all ships have the range to only go up to 10b km away and back, for my ships there are no systems big enough that'd prevent them exploring all, at least with real stars.

[Droll]

The system generator gave me a system with 291 Asteroids. They are unfortunately at a distance of 97 to 448bkm to the main star. A bit annoying to have to manually select the asteroids the exploration ship has to go to. Is there any way you can give us a special "go to closest system body" auto command which goes beyond the actual limit of I think 10bkm search radius?

Bit of a counter point: Having two orders to go survey a body is likely to confuse players, and the 10b km limit exists for a good reason with this system actually being a good example of that, if the nearest asteroid is 97b km your survey ships will almost certainly run out of fuel and get stranded in a very inconvenient place.

I would honestly take a hint from the game mechanics and leave the asteroid belt alone at that point, even exploiting it would be tricky at best, but if one does want to survey it I think having to manually manage that is a fair game, basically the Aurora version of 'sudo' in telling the game "Yes, I do think I know what I'm doing, let me screw things up the way I want to". 

I would agree but this messes up the automation of surveys, specifically the "go to system requiring geosurvey" standing order will make ships to to the system with the asteroid belt and just idle around there when there are other systems with more useful geosurvey targets. So being able to flag systems as "do not survey" or allowing some way to set up survey orders for them I think is a good idea.

[nuclearslurpee]

I would agree but this messes up the automation of surveys, specifically the "go to system requiring geosurvey" standing order will make ships to to the system with the asteroid belt and just idle around there when there are other systems with more useful geosurvey targets. So being able to flag systems as "do not survey" or allowing some way to set up survey orders for them I think is a good idea.

Excellent point I hadn't thought of. There is the flag we can set to mark a system for military access only but that's obviously a bit limiting as the only option.

[TMaekler]

Bit of a counter point: Having two orders to go survey a body is likely to confuse players, and the 10b km limit exists for a good reason with this system actually being a good example of that, if the nearest asteroid is 97b km your survey ships will almost certainly run out of fuel and get stranded in a very inconvenient place.

I would honestly take a hint from the game mechanics and leave the asteroid belt alone at that point, even exploiting it would be tricky at best, but if one does want to survey it I think having to manually manage that is a fair game, basically the Aurora version of 'sudo' in telling the game "Yes, I do think I know what I'm doing, let me screw things up the way I want to". 

Wanted to start a discussion about it. The 10bkm limit is a leftover from VB6 Aurora - where such gigantic systems weren't possible if I recall correctly; so it wasn't a big issue. Additionally, I don't think C# Aurora will slow down immensely if the search radius would be bigger.

My actual survey ship can fly roughly 190bkm - so it could fly back and forth. And I even have a special fuel ship that could accompany it to extend the range :-)

My main issue with that system is simply that there are over 290 of these asteroids. I surely won't fly to the outmost of them (448bkm which is what? Over a lightyear...), but a lot of them are in a belt between 90 and 120 bkm. I had send a ship there to begin investigating. But the space between them often is more than 10bkm... . Maybe Steve can make the search radius depending on the system. If the outmost object is 20bkm out, search in 10bkm radius. But if it is 200bkm why not allowing the search radius to be 20 or 30bkm to keep automation working and reflect the bigger spaces between objects? Or else a new base game parameter. Don't create objects beyond x bkm in system generation... .

Just floating out some ideas... .

[nuclearslurpee]

Bit of a counter point: Having two orders to go survey a body is likely to confuse players, and the 10b km limit exists for a good reason with this system actually being a good example of that, if the nearest asteroid is 97b km your survey ships will almost certainly run out of fuel and get stranded in a very inconvenient place.

I would honestly take a hint from the game mechanics and leave the asteroid belt alone at that point, even exploiting it would be tricky at best, but if one does want to survey it I think having to manually manage that is a fair game, basically the Aurora version of 'sudo' in telling the game "Yes, I do think I know what I'm doing, let me screw things up the way I want to". 

Wanted to start a discussion about it. The 10bkm limit is a leftover from VB6 Aurora - where such gigantic systems weren't possible if I recall correctly; so it wasn't a big issue. Additionally, I don't think C# Aurora will slow down immensely if the search radius would be bigger.

My actual survey ship can fly roughly 190bkm - so it could fly back and forth. And I even have a special fuel ship that could accompany it to extend the range :-)

My main issue with that system is simply that there are over 290 of these asteroids. I surely won't fly to the outmost of them (448bkm which is what? Over a lightyear...), but a lot of them are in a belt between 90 and 120 bkm. I had send a ship there to begin investigating. But the space between them often is more than 10bkm... . Maybe Steve can make the search radius depending on the system. If the outmost object is 20bkm out, search in 10bkm radius. But if it is 200bkm why not allowing the search radius to be 20 or 30bkm to keep automation working and reflect the bigger spaces between objects? Or else a new base game parameter. Don't create objects beyond x bkm in system generation... .

Just floating out some ideas... .

I certainly don't dislike the suggestion, I just like to look at the other side of things.

I wouldn't want to necessarily eliminate the limit entirely, as it is a useful limit to prevent survey ships from running about to extreme distances in systems with distant binaries or Oort clouds when they're not built to handle that or if the player doesn't want to waste all that fuel (why survey something that won't be easy to exploit with freighters, after all?). On the other hand, the current limit can definitely stand to be raised as even in the Sol system I usually have to manually control the last dozen or so surveys which involves searching through all the bodies and etc.

Maybe an increase to 30b km (Sol system diameter, roughly) would be a good compromise and easy enough for Steve to implement as it's just changing one constant in the code. That should be large enough to automatically survey those distant belts, after giving a single order to jump-start things, which should be a good compromise as the player still has to "give permission" to survey those big systems, but hopefully only once or twice.

[Polestar]

Perhaps replace the 10b km limit on auto-survey with two time- and fuel-based triggers?

IF, time needed to reach the next closest unsurveyed body or destination is greater than 180 days,
OR, if fuel is expected to run out before reaching the destination,
THEN, cancel the automatic survey order and state why.

ELSE IF, time needed to reach the next closest unsurveyed body or destination is greater than 60 days,
OR, if fuel remaining at destination is expected to be less than the limit set by the player (or 10% if no limit was specified),
THEN, continue but issue a warning with the expected transit time or fuel remaining.

[nuclearslurpee]

Perhaps replace the 10b km limit on auto-survey with two time- and fuel-based triggers?

IF, time needed to reach the next closest unsurveyed body or destination is greater than 180 days,
OR, if fuel is expected to run out before reaching the destination,
THEN, cancel the automatic survey order and state why.

ELSE IF, time needed to reach the next closest unsurveyed body or destination is greater than 60 days,
OR, if fuel remaining at destination is expected to be less than the limit set by the player (or 10% if no limit was specified),
THEN, continue but issue a warning with the expected transit time or fuel remaining.

Conditional standing orders would definitely solve this and many other issues which are raised on a frequent basis. It has been suggested quite often but thus far we have seen no movement in this direction. I believe based on similar discussions about (regular) movement orders that Steve worries it would cause too many spurious bug reports.

[TMaekler]

Seems like that there is no message in the log that indicates that a fleet couldn't be refueled to it's max capacity. A bit annoying realizing this when the 20% warnings begin to pop up whilst the fleet is already underway and way out.

Could you add such a warning message when refueling doesn't fill up? Thanks.

[Droll]

Seems like that there is no message in the log that indicates that a fleet couldn't be refueled to it's max capacity. A bit annoying realizing this when the 20% warnings begin to pop up whilst the fleet is already underway and way out.

Could you add such a warning message when refueling doesn't fill up? Thanks.

I would like to add that this might be difficult to do for underway replenishment but is a really good idea for stationary refueling, both planetary and tanker based.

[TMaekler]

I would like to add that this might be difficult to do for underway replenishment but is a really good idea for stationary refueling, both planetary and tanker based.

That is true. Don't need message spam during an underway replenishment 

[xenoscepter]

 - I'd like to see weaponized tractor beams, to be honest. Have ships that can use their tractor beam to "latch on" for the purposes of boarding actions, maybe a special kind of Tractor Beam that's smaller and can't tug things? Perhaps instead have a Troop Transport Bay that is heavier than a normal Boarding Bay, but has the function of buffing the success chance. Maybe some sort of "Boarding Harpoon" that can be fired like a normal weapon, at range that is, and makes boarding way easier, but also slows down both ships... with the faster and/or bigger ones getting advantages over slower and/or smaller ones.

[Vivalas]

This has probably been suggested in some form but having cargo bays be able to transport formations consisting solely of logistical elements would be a nice little boost to logistics for protracted ground combat, while also making a good deal of thematic sense. (Logistical elements embedded inside formations don't necessarily 'disappear' when they are used. A batallion of men can't eat a truck, no matter how hungry they are! The transports are simply hauling supplies to replenish the ground forces with)