Recent Posts

Pages: [1] 2 3 ... 10
1
C# Suggestions / Re: reserve fleet idea
« Last post by M_Gargantua on Today at 11:48:43 AM »
I do like the idea of using Repair yards to move ships in and out of Mothball. But I agree that it should take many months per ship, regardless of BP capacity. Getting a ship into long term layup is a lot more effort than just turning off the lights, and restoring it to combat readiness takes a huge amount of work. It would make even more sense if crew training played a bigger role, as a ship coming out of mothball will often have even worse crew readiness than new construction. At least with new construction most crews would be stood up before commissioning and be taking training and ownership as things are completed before launch.

But above all I would absolutely love the SM toggles to disable maintenance on a per ship basis so it opens up RP options for this in the meantime to a real mechanic.
2
C# Suggestions / Re: Draft of an idea for a change to sensing
« Last post by Steve Walmsley on Today at 03:38:14 AM »
I think that detection could be less binary and more uncertain as they are in reality thus if there are more ships you are more likely to detect something and even identify some of them but you will never be able to know for sure how many there are unless you manages to follow them for a longer time. It also means that more sensors means more chances to make positive contact too.

So contact should be in three states, something detected but you are not entirely sure what it is or even exactly where it is. You have a firm sensor indicator but you don't know anything more than that something is there and lastly you have a firm lock and managed to identify the source.

Sensors should need more than just detecting something and not be binary... in my opinion it would be more fun.

I don't think that more ships should be easier to detect but it will be more likely that you detect something and further out the more ships that are there. It also would remove the need to spreading them out and micro things.

I also think the game would benefit with more sensor mechanics in terms of stealth, detection and identification. More electronic warfare and possibility to spoof sensors and trick them. Why not be able to trick them to thinking there is a ship when it is just a decoy for example, sending the enemy out on a wild ghost chase for example.

I do think that the game would be more fun if sensors were not binary and there were ways to mask ships, say around planets and asteroids for example.

Sure... it would make "combat" in general more spread out in a system perhaps, but generally I would have no big problem with that. It also would mean that a better sensor are not guaranteed to find something before a worse one, just more likely to do so.

The calculation does not have to be more complicated than now, just a few more states before something is fully identified. Even a passive sensors detection should be able to eventually determine with a very high certainty what enemy design it is, you can in real life as all emissions usually are very unique for each type of platform. I also think this would be a good way to make "Flag Bridges" more interesting... they could be made to influence the chance to fully identify sensor sources as they combine the information from en entire squadron or small task force of ships.

The game used to be like that in the early years. For example, you would have a thermal contact but no ID or even IFF, so you had to get closer and try to identify ship type and race (similar to Harpoon). However, while that is interesting for the first few contacts, it became very tedious after micromanaging investigation of a hundred such contacts. I changed sensor detection to the current model, which assumes target identification, or even target motion analysis, was handled by the your staff behind the scenes so you could get on with deciding how to handle it.

If I ever get around to a more tactical game than Aurora, it would definitely include something on these lines.
3
C# Suggestions / Re: reserve fleet idea
« Last post by QuakeIV on Yesterday at 08:53:30 PM »
The main reason you would want to mothball a ship is because it would deteriorate more slowly than if it was in use.  What if it was allowed to undergo maintenance failures as if it had no MSP remaining, but at a diminished rate?  So, maintenance clock will begin to run up and at some point components will start failing.  It would then implicitly require yard time (as suggested by others) to repair the failed components.  If nothing failed in the interim, then bully for you.
4
C# Suggestions / Re: reserve fleet idea
« Last post by Pedroig on Yesterday at 06:53:18 PM »
Oh no doubt, in fact most ships if they don't leave the mothball fleet within 30 years are scrapped, and for the more modern platforms that has been almost halved. 

It also makes light of the lesson learned with the Red Lead Fleet and the luxury of having plenty of crews which were simply waiting for the final signoff by the yard to go home for good.

That said, micrometeorites are less corrosive than saltwater and oxygen.  I don't see a need for a reserve system in Aurora as it is rarely mentioned in Sci-Fi in general...
5
C# Suggestions / Re: Draft of an idea for a change to sensing
« Last post by Garfunkel on Yesterday at 06:20:53 PM »
Flag bridge as the hub for sensor fusion and C4I? Sounds good but complicated to pull off.
6
C# Suggestions / Re: reserve fleet idea
« Last post by Jorgen_CAB on Yesterday at 05:56:01 PM »
In space, not really, heck it only took the USN abut 6 months for the yarddogs to mothball status a couple of thousand ships, and just several years later they were able to reativate 540 for the Korea Conflict, these then when back into mothball status and then another 600+ were reactivated during Vietnam. 

Keep in mind, the last month or so of a ship's "active status" was spent by the crew readying it for the reserve, logging and fixing problems, using up and transporting perishables, and securing non-perishables, along with stripping paint and begin setting up dehumidifiers before they hit they yards.

It is a bit suger coating how easy this was and also don't account for the size and complexity of the platforms. The less complex and less advanced something is the easier it is to store and reactivate. It is far easier to store and reactivate a bicycle than a car for example.  It also is far easier to restore a 1950 model car than a 2020 model car that both have been mothballed for 30 years in a garage. The latter are just more complex.

It will also become more and more of a challenge to reactive a specific platform the longer it has been stored for the pure fact of know how to operate them will eventually become a problem. It is the human factor.
7
C# Suggestions / Re: Draft of an idea for a change to sensing
« Last post by Jorgen_CAB on Yesterday at 05:37:37 PM »
I think that detection could be less binary and more uncertain as they are in reality thus if there are more ships you are more likely to detect something and even identify some of them but you will never be able to know for sure how many there are unless you manages to follow them for a longer time. It also means that more sensors means more chances to make positive contact too.

So contact should be in three states, something detected but you are not entirely sure what it is or even exactly where it is. You have a firm sensor indicator but you don't know anything more than that something is there and lastly you have a firm lock and managed to identify the source.

Sensors should need more than just detecting something and not be binary... in my opinion it would be more fun.

I don't think that more ships should be easier to detect but it will be more likely that you detect something and further out the more ships that are there. It also would remove the need to spreading them out and micro things.

I also think the game would benefit with more sensor mechanics in terms of stealth, detection and identification. More electronic warfare and possibility to spoof sensors and trick them. Why not be able to trick them to thinking there is a ship when it is just a decoy for example, sending the enemy out on a wild ghost chase for example.

I do think that the game would be more fun if sensors were not binary and there were ways to mask ships, say around planets and asteroids for example.

Sure... it would make "combat" in general more spread out in a system perhaps, but generally I would have no big problem with that. It also would mean that a better sensor are not guaranteed to find something before a worse one, just more likely to do so.

The calculation does not have to be more complicated than now, just a few more states before something is fully identified. Even a passive sensors detection should be able to eventually determine with a very high certainty what enemy design it is, you can in real life as all emissions usually are very unique for each type of platform. I also think this would be a good way to make "Flag Bridges" more interesting... they could be made to influence the chance to fully identify sensor sources as they combine the information from en entire squadron or small task force of ships.
8
C# Suggestions / Re: reserve fleet idea
« Last post by Pedroig on Yesterday at 06:44:35 AM »
In space, not really, heck it only took the USN abut 6 months for the yarddogs to mothball status a couple of thousand ships, and just several years later they were able to reativate 540 for the Korea Conflict, these then when back into mothball status and then another 600+ were reactivated during Vietnam. 

Keep in mind, the last month or so of a ship's "active status" was spent by the crew readying it for the reserve, logging and fixing problems, using up and transporting perishables, and securing non-perishables, along with stripping paint and begin setting up dehumidifiers before they hit they yards.
9
C# Bug Reports / Re: v2.1.1 Bugs Thread
« Last post by Steve Walmsley on September 27, 2023, 01:33:16 PM »
After researching minimum squadron jump size 8, the tech design screen is not auto-filling jump engine size, and is kicking out a "function 1050:  object reference not set to an instance of an object", presumably in relation to that empty field for jump engine size.   

Conventional start, random stars, decimal is a decimal point, and it's reproducible—it keeps popping up after closing and re-opening the project window as well as after closing and re-starting the game.

Um, and only 9 years in.   I have research set globally to 400% if that matters.

Doesn't seem to be any problem with functionality; once I fill in the blank I can design & research jump drives.

Yes, its a known bug with a fix already in the next version.
http://aurora2.pentarch.org/index.php?topic=13090.0
10
C# Bug Reports / Re: v2.1.1 Bugs Thread
« Last post by IceKobold on September 27, 2023, 12:42:31 PM »
After researching minimum squadron jump size 8, the tech design screen is not auto-filling jump engine size, and is kicking out a "function 1050:  object reference not set to an instance of an object", presumably in relation to that empty field for jump engine size.   

Conventional start, random stars, decimal is a decimal point, and it's reproducible—it keeps popping up after closing and re-opening the project window as well as after closing and re-starting the game.

Um, and only 9 years in.   I have research set globally to 400% if that matters.

Doesn't seem to be any problem with functionality; once I fill in the blank I can design & research jump drives.
Pages: [1] 2 3 ... 10
SMF spam blocked by CleanTalk