C# Suggestions

[TMaekler]

I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.

As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .

[Jorgen_CAB]

I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.

As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .

I think it should stay the way it is... I see no reason why the rules should be different just because the ship is small, that make very little sense. Just because it might be inconvenient for fighters in general is not a good argument. We are only suppose to refit fighters with mainly fire-controls and other minor changes... otherwise we should just scrap them and build new ones.

The only issue is retaining the crew skill, but that is a different issue and should not be solved in changing the refit mechanics.

[Droll]

I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.

As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .

I think it should stay the way it is... I see no reason why the rules should be different just because the ship is small, that make very little sense. Just because it might be inconvenient for fighters in general is not a good argument. We are only suppose to refit fighters with mainly fire-controls and other minor changes... otherwise we should just scrap them and build new ones.

The only issue is retaining the crew skill, but that is a different issue and should not be solved in changing the refit mechanics.

I think the underlying problem is that it is annoying/time consuming to replace fighters which is why people want refitting to be easier for them, not that refit mechanics are bad for fighters. Some aspects of this will improve when 1.13 hits thanks to the carrier hoover mechanic.

Still, I would propose implementing a replace task for fighter factories. You tell them to replace a certain fighter design in orbit for the target design you selected. Mechanically, what this does is build a new copy of the modern fighter, then scrap an old fighter that is in orbit on the relevant body but not docked at a carrier at the body. This gives a quick and easy way to replace large numbers of outdated fighters.

Some error handling might be wanted to handle cases where the factories are told to replace more fighters than there are available to be replaced.

[Jorgen_CAB]

I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.

As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .

I think it should stay the way it is... I see no reason why the rules should be different just because the ship is small, that make very little sense. Just because it might be inconvenient for fighters in general is not a good argument. We are only suppose to refit fighters with mainly fire-controls and other minor changes... otherwise we should just scrap them and build new ones.

The only issue is retaining the crew skill, but that is a different issue and should not be solved in changing the refit mechanics.

I think the underlying problem is that it is annoying/time consuming to replace fighters which is why people want refitting to be easier for them, not that refit mechanics are bad for fighters. Some aspects of this will improve when 1.13 hits thanks to the carrier hoover mechanic.

Still, I would propose implementing a replace task for fighter factories. You tell them to replace a certain fighter design in orbit for the target design you selected. Mechanically, what this does is build a new copy of the modern fighter, then scrap an old fighter that is in orbit on the relevant body but not docked at a carrier at the body. This gives a quick and easy way to replace large numbers of outdated fighters.

Some error handling might be wanted to handle cases where the factories are told to replace more fighters than there are available to be replaced.

A replace mecahnc seem like a good solution to that particular problem, I would be in favour if this. But I don't like to change the refit mechanic to do it.

[Droll]

I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.

As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .

I think it should stay the way it is... I see no reason why the rules should be different just because the ship is small, that make very little sense. Just because it might be inconvenient for fighters in general is not a good argument. We are only suppose to refit fighters with mainly fire-controls and other minor changes... otherwise we should just scrap them and build new ones.

The only issue is retaining the crew skill, but that is a different issue and should not be solved in changing the refit mechanics.

I think the underlying problem is that it is annoying/time consuming to replace fighters which is why people want refitting to be easier for them, not that refit mechanics are bad for fighters. Some aspects of this will improve when 1.13 hits thanks to the carrier hoover mechanic.

Still, I would propose implementing a replace task for fighter factories. You tell them to replace a certain fighter design in orbit for the target design you selected. Mechanically, what this does is build a new copy of the modern fighter, then scrap an old fighter that is in orbit on the relevant body but not docked at a carrier at the body. This gives a quick and easy way to replace large numbers of outdated fighters.

Some error handling might be wanted to handle cases where the factories are told to replace more fighters than there are available to be replaced.

A replace mecahnc seem like a good solution to that particular problem, I would be in favour if this. But I don't like to change the refit mechanic to do it.

The whole point is to solve the problem without touching the refit mechanics. The way the refit system does not favour small ships like fighters makes a lot of thematic sense anyways. It's generally not worth it to overhaul and redo something so small when you can recycle and make a new one cheaper. They didn't start turning F16s into F22s/F35s when they became available for a reason.

[papent]

The whole point is to solve the problem without touching the refit mechanics. The way the refit system does not favour small ships like fighters makes a lot of thematic sense anyways. It's generally not worth it to overhaul and redo something so small when you can recycle and make a new one cheaper. They didn't start turning F16s into F22s/F35s when they became available for a reason.

an more apt comparison would F-16Cs to F-16XL's or DC-10's to KDC-10's But again that's an real world example which has no place ingame.


It may be simpler to implement a simple change such as:

Code: [Select]

IF( (Original.ShipClass / New.ShipClass) < 0.2 ) == TRUE OR IF(New.ShipClass - Original.ShipClass <= 500) == TRUE then REFIT For refitting the small craft instead creation of an all new function to replace small craft using fighter factories to do so.
Why write new code that functionally that does the same thing as another part of the code? Also, that this new function may introduce new bugs.

[serger]

I'll add a notion, that Aurora tonns are not weight measure, but volume measure - it's a mass of liquid hydrogen, displaced by craft's hull, and there is no such thing in Aurora as above-water part of ship.
So, 20% - is 20% of hull's volume, that's not adding some heavy stuff inside the same hull.
I don't know a difference of volumes between F-16XL and F-16Cs, but I doubt it's much greater than 20%, the same as DC-10's / KDC-10.

And it's the purport of refit: you have to make some changes, but not to redo your hull.

[Jorgen_CAB]

I'll add a notion, that Aurora tonns are not weight measure, but volume measure - it's a mass of liquid hydrogen, displaced by craft's hull, and there is no such thing in Aurora as above-water part of ship.
So, 20% - is 20% of hull's volume, that's not adding some heavy stuff inside the same hull.
I don't know a difference of volumes between F-16XL and F-16Cs, but I doubt it's much greater than 20%, the same as DC-10's / KDC-10.

And it's the purport of refit: you have to make some changes, but not to redo your hull.

In Aurora term this generally mean you can't change engine or weapons as these are hard defining of what the ship actually is.... a change to either is simply too much of a change and it is just cheaper to build a new fighter around the new engine or weapon. In general you might be able to change the fire-controls or maybe the sensors as long as they are not too big. An Aurora fighter is not like a jet fighter either as they are way bigger, more like a small real life Corvette or something.

Anyway... I could see a mechanic where you could "replace" the fighter and even retain the crew experience. Your factories would build a new fighter, scrap the old one and reuse the old crew in the new one. It would feel like it was refitted but it really is not.

In fact I think that regular ships could have something similar. If the new ship require more crew then new crew is added as if the ship received losses. If it require less crew the excess is added to to the crew pool. This would be a good way to retain experienced crew for older ship in a more "realistic" manner. But then... crew in this game can be around for hundreds of years which really is not very realistic to begin with. All ships should require some sort of crew rotation which should make experience do down to some equilibrium, the same goes for fleet training, but this is a different issue. Crew rotation should be part of the mechanic when your crew is resting. Some part of the crew is then replenished and experience and fleet training are changed accordingly. How much crew is replaced should be based on policy and the time the ship has been away. A ship that stay at port for a long time would have a small part of the crew replaced all the time, just like they pay a small amount of supplies all the time.

[papent]

Why create an new mechanic to do something that functionally already exist? An if then statement is a simpler task than creating an entire scrap and replace system.

If I remember correctly from VB6  Excess crew did return to the pool and it presumably should work or is planned to work the same in C#.

An Aurora fighter is not like a jet fighter either as they are way bigger, more like a small real life Corvette or something.

Like refitting an workboat, converting a cruiser to a carrier, making a Razee, or an Huey to Cobra.

But again IRL is irrelevant. If you must find a real-world grounding for this idea it does exist and has and will continue to occur, As I previously mentioned several times before.

It does happen on RL designs for heavy/small military aircraft and small boats. I once had the pleasure of crewing an EC-130H that was a former WC-130 and before that spent time as a HC-130 that started it's USAF life as a slick C-130E. all those variants and the added mods in between had significant weight differences between them and greater than 20% of previously modification weight. That isn't even considering some of the franken airframes that make up the KC-135 fleet or B-1 fleet.

The U-2 various Electronic packages makeup over 50~25% of dry weight depending on package and that's a field level swap.

same can be said of ocean workboats, as they often do get refitted drastically when acquired by a different owner or for a new project. 

If a grounding IRL you looking for it then that does exist, if a simplicity of operation in terms of game mechanics, how could we justify suggestion of creating a brand new mechanic and associated hooks into other parts of the code.

[Droll]

Why create an new mechanic to do something that functionally already exist? An if then statement is a simpler task than creating an entire scrap and replace system.

To add scalability in regards to micromanagement? Obviously this is not anything you cant do right now but its time consuming and tedious which is why this discussion exists in the first place...
We also want to avoid exception cases in the refit system since that was one of the main things about C# in general to make things more mechanically consistent.

[Jorgen_CAB]

Why create an new mechanic to do something that functionally already exist? An if then statement is a simpler task than creating an entire scrap and replace system.

If I remember correctly from VB6  Excess crew did return to the pool and it presumably should work or is planned to work the same in C#.

An Aurora fighter is not like a jet fighter either as they are way bigger, more like a small real life Corvette or something.

Like refitting an workboat, converting a cruiser to a carrier, making a Razee, or an Huey to Cobra.

But again IRL is irrelevant. If you must find a real-world grounding for this idea it does exist and has and will continue to occur, As I previously mentioned several times before.

It does happen on RL designs for heavy/small military aircraft and small boats. I once had the pleasure of crewing an EC-130H that was a former WC-130 and before that spent time as a HC-130 that started it's USAF life as a slick C-130E. all those variants and the added mods in between had significant weight differences between them and greater than 20% of previously modification weight. That isn't even considering some of the franken airframes that make up the KC-135 fleet or B-1 fleet.

The U-2 various Electronic packages makeup over 50~25% of dry weight depending on package and that's a field level swap.

same can be said of ocean workboats, as they often do get refitted drastically when acquired by a different owner or for a new project. 

If a grounding IRL you looking for it then that does exist, if a simplicity of operation in terms of game mechanics, how could we justify suggestion of creating a brand new mechanic and associated hooks into other parts of the code.

All of the things that you point to is what I would constitute to being within the 20% margin as what the game represents as the constraints. There just need to be a hard limit as it is a game so the limit have to be at some point.

The issue is that it should not be different for a 125t fighter than what it is for a 12500t destroyer. It is all based on the change in cost of the parts to replace... if the cost is too great it is abstracted as too big of a change from the former design so it have to be a new design.

It is way better to introduce a mechanic to replace one design with another that also can transfer crew from one platform to the next. A system that scrap one item and build a new one in it's place.

This would be useful for both fighters and ships... I don't see why it should be limited to fighters only.

I also don't see why fighter factories can't refit and scrap fighters as well as build them, that is just odd to me as well. Why do you need shipyards to do that?!?

[nuclearslurpee]

I also don't see why fighter factories can't refit and scrap fighters as well as build them, that is just odd to me as well. Why do you need shipyards to do that?!?

I think ultimately the reason it is this way is that the factory GUI doesn't have a way to do so. Currently fighters are built from the exact same GUI as all other construction projects (unless built at a shipyard of course), so to add refit ability to fighter factories Steve would have to either fit new elements into that window or rewrite the window to switch GUI elements when fighter construction is selected.

Personally I'd like to see the former as it would be good to apply the same functionality to space stations, in that case not as much for crew training purposes as to be able to upgrade old tech to keep old stations in service since scrapping them is often inconvenient at best.

[Jorgen_CAB]

I also don't see why fighter factories can't refit and scrap fighters as well as build them, that is just odd to me as well. Why do you need shipyards to do that?!?

I think ultimately the reason it is this way is that the factory GUI doesn't have a way to do so. Currently fighters are built from the exact same GUI as all other construction projects (unless built at a shipyard of course), so to add refit ability to fighter factories Steve would have to either fit new elements into that window or rewrite the window to switch GUI elements when fighter construction is selected.

Personally I'd like to see the former as it would be good to apply the same functionality to space stations, in that case not as much for crew training purposes as to be able to upgrade old tech to keep old stations in service since scrapping them is often inconvenient at best.

Yes... I think that adding some element to the GUI so we can refit, replace and scrap using both construction and fighter factories would be really nice.

[TMaekler]

Separating the two messages "civilian mining colony founded" and "extended". I don't care so much if they extend a colony, but I do care if I make it a "send me your minerals" or "I will milk money out of you" - mining complex. So if I could color the "founded" message different to "extended" would be great.

[nuclearslurpee]

I'd like to request a slight tweak to jump transit with mixed engine types in a fleet.

With the change to military/commercial drives only jumping engines of that type, I've found that trying to use paired mil/comm jump tenders is rather micro-intensive Trying to stick a naval fleet, a military jump tender (commercial ship & engines), and a commercial jump tender in one fleet doesn't work for jumping as you get the "no suitable jump drive" failure event. I guess Aurora still only uses one jump drive to transit an entire fleet and doesn't check if the fleet is able to transit using the combination of jump drives.

It would make life easier and make commercial jump tenders for military fleets less painful if the jump transit logic was adjusted to check for both military and commercial jump drives as necessary.