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

0 Members and 1 Guest are viewing this topic.

Offline somebody1212

  • Chief Petty Officer
  • ***
  • s
  • Posts: 30
  • Thanked: 29 times
Re: C# Aurora v0.x Suggestions
« Reply #840 on: December 29, 2018, 01:07:16 PM »
Following some discussion on the Discord, would it be possible to have a setup option to enable ramming for players?
(I understand you don't want it as a default option)
Aurora4x Discord: https://discord.gg/TXK6qcP
 
The following users thanked this post: papent, totos_totidis, Jovus, MajGenRelativity

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11669
  • Thanked: 20441 times
Re: C# Aurora v0.x Suggestions
« Reply #841 on: December 30, 2018, 11:59:43 AM »
A few mostly QoL suggestions on components:

1, a 0. 02HS 'micro' fuel tank after the tiny fuel tank research.  This is mostly to be used on fighters.  It should find its usefulness as ship engines can be smaller than 1HS in C#.  (Currently the only component <0. 1HS is the fighter crew module, which is 0. 04HS, and when it is used, the fighter tonnage will end up with xx2 or xx7 ton, which can be an eyesore for some players. )

2, larger cargo holds for research, maybe a large cargo hold = 5x standard cargo hold, and a huge one = 50x standard cargo hold.

I've added the 0.02 HS fuel tank, which costs 0.5 BP and holds 1000 litres.

I've also added a Cargo Hold - Large, which is 5x larger than the standard cargo hold. Size 2500 HS, Cost 200 BP.
 
The following users thanked this post: Garfunkel, papent, mtm84, DIT_grue, Jovus, King-Salomon, DEEPenergy, Iceranger

Offline Up_down66

  • Able Ordinary Rate
  • U
  • Posts: 2
  • Thanked: 1 times
Re: C# Aurora v0.x Suggestions
« Reply #842 on: December 30, 2018, 04:57:30 PM »
Just read about the new boarding, sounds awesome, inching ever closer to finally being able to play.  Anyways had a idea for a new ship component? A sort of boarding defense system, outfitting the ship with smaller turrets or other types of automated defenses.  I think this would allow ships to defend better against a boarding heavy race without having to carry around their own units in their ship, or support the already defending units by adding some variety.  The defense unit it self could be considered a unit that fights like everything else.  It would need a a sort of command room in the ship so if it's destroyed in ship combat or in the boarding combat I suppose the turrets would just turn off.

 It's an idea, don't know if it's good or not but might add a little something fighting automated defenses and the crew and any actual units in the halls and rooms of a ship.
 
The following users thanked this post: Barkhorn

Offline Father Tim

  • Vice Admiral
  • **********
  • Posts: 2162
  • Thanked: 531 times
Re: C# Aurora v0.x Suggestions
« Reply #843 on: December 30, 2018, 10:44:19 PM »
While that sounds like a great justification flavour-wise, wouldn't it mechanically be just an increase to the 'fortification rate' of the defenders in a boarding action?  If you want your ship to be better at repelling boarders, then you should either add extra crew (for low cost, low effectiveness fighters) or outright Infantry formations.  A 50-ton 'Infantry' unit of crew-served anti-personnel weapons isn't much different from 1 Hull Space of 'automated turrets' and the computers & crewpower to maintain and run them.
 

Offline Up_down66

  • Able Ordinary Rate
  • U
  • Posts: 2
  • Thanked: 1 times
Re: C# Aurora v0.x Suggestions
« Reply #844 on: December 30, 2018, 11:10:33 PM »
Quote from: Father Tim link=topic=9841. msg111785#msg111785 date=1546231459
While that sounds like a great justification flavour-wise, wouldn't it mechanically be just an increase to the 'fortification rate' of the defenders in a boarding action?  If you want your ship to be better at repelling boarders, then you should either add extra crew (for low cost, low effectiveness fighters) or outright Infantry formations.   A 50-ton 'Infantry' unit of crew-served anti-personnel weapons isn't much different from 1 Hull Space of 'automated turrets' and the computers & crewpower to maintain and run them.

Having defenses be different from infantry and just crew members I think would be important, like how vehicles and aircraft are different from infantry.  It would need to have trade offs for why have automated defenses rather then having a garrison or vice visa.

 You can't repair dead bodies but you can repair something automated.  And if a small ship is boarded, chances are it's gonna lose the fight, but having a h. s or two of defenses along side some crew members it really gonna annoy the opposition if they have to fight something that can't surrender on every little ship.  Might buy some time for another fleet to come in or might wear down smaller marine forces to make them even if only a little less of a threat next fight.  And the smaller the ship the less the chance of you putting any thing other then crew on it, although I suppose the smaller the ship the less the chance of it being boarded.

 Idk I doubt boarding will be common place enough to warrant a new component just to help defend against it but if it does become more common place having the option to have a more cost effective defenive force that you only have build instead of train and house might be interesting
 

Offline King-Salomon

  • Lieutenant
  • *******
  • Posts: 153
  • Thanked: 38 times
Re: C# Aurora v0.x Suggestions
« Reply #845 on: December 31, 2018, 02:55:20 AM »
Having defenses be different from infantry and just crew members I think would be important, like how vehicles and aircraft are different from infantry.  It would need to have trade offs for why have automated defenses rather then having a garrison or vice visa.

From pure logical and technobable point of view you are correct, automatic defence systems in a ship would be a great addition...

but from the game point of view I am against it... it would just make boarding "more expensive" ... boarding is something most players don't do in VB6 (as far as I see it) because it is not profitable enough to do instead of killing the target... you have to invest in troopbays, troops, have to risk your ships to get close to a vessel which might be "dead in the water" but could still have (or repair) some weapons etcpp

to add intern ship defence systems other than troops it would mean to add the systems to NPR ship-design .. so you can count on it to get into them if you try to board.. which just makes the boarding more expensive again...

I think marine detachments to defend your ships are fine for RP and if they are added into NPR ship design it's OK as I hope that the AI in C# might be smart enough to use them to board itself instead of just killing...

defence systems that only rise the cost of boarding are logical, fun to read and realistic but as long as boarding a ship is not more profitable I don't see a point in adding them...
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11669
  • Thanked: 20441 times
Re: C# Aurora v0.x Suggestions
« Reply #846 on: December 31, 2018, 03:26:57 AM »
I think marine detachments to defend your ships are fine for RP and if they are added into NPR ship design it's OK as I hope that the AI in C# might be smart enough to use them to board itself instead of just killing...

Yes, some types of NPR will use boarding tactics.
 
The following users thanked this post: bro918

Offline Barkhorn

  • Commodore
  • **********
  • B
  • Posts: 719
  • Thanked: 133 times
Re: C# Aurora v0.x Suggestions
« Reply #847 on: December 31, 2018, 11:26:02 AM »
While that sounds like a great justification flavour-wise, wouldn't it mechanically be just an increase to the 'fortification rate' of the defenders in a boarding action?  If you want your ship to be better at repelling boarders, then you should either add extra crew (for low cost, low effectiveness fighters) or outright Infantry formations.  A 50-ton 'Infantry' unit of crew-served anti-personnel weapons isn't much different from 1 Hull Space of 'automated turrets' and the computers & crewpower to maintain and run them.
The big difference I see is that those automated turrets are attached to the ship.  You can't drop them on a planet or move them to a different ship.
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #848 on: January 02, 2019, 03:29:25 AM »
I've added the 0.02 HS fuel tank, which costs 0.5 BP and holds 1000 litres.

I've also added a Cargo Hold - Large, which is 5x larger than the standard cargo hold. Size 2500 HS, Cost 200 BP.
How about a general change of all "cargo" modules? A system where you specify the amount of space/fuel/maintenance you want - as well as the amount of subdivisions (so that not the whole fuel gets lost when the fuel module is hit/destroyed - and the game simply calculates how much HS that would take.
 
The following users thanked this post: Scandinavian

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #849 on: January 02, 2019, 04:40:14 AM »
A suggestion for missiles in C# if not too complicated.

Since the new sensor system might make self guiding missiles a bit more interesting and viable how about allowing munition inside a large missile being able to use the active or passive sensor of the parent missile. You could add a small 0.25 MSP electronic guidance system or something to control them. I honestly don't remember how it worked in VB6 with mines and stuff, I rarely used mines, but I'm sure the sub munition could not use the parent sensors.

This could be interesting to build hit and run type ships or engage in sort of submarine style fighting.
 
The following users thanked this post: Scandinavian

Offline King-Salomon

  • Lieutenant
  • *******
  • Posts: 153
  • Thanked: 38 times
Re: C# Aurora v0.x Suggestions
« Reply #850 on: January 02, 2019, 10:41:48 AM »
Suggestion about seeing "previous designs" with engine designing:

I would suggest a feature in the ship module designer (like engine maybe scanner etc) were I can "load" a previous design and chance the parameters for a new design with better tech like it is possible with missile design...

in most of my games I go with 4-6 different ship engines which I update as tech progresses but the "character" of the engine is unchanged... for example most of the time the HS of the engine stays the same but output is higher and fuel consumption is lower...

So it would be great addition if I could load a previous design of the "now" engine to chance the design of it without having to write the specifics of all 6 different engines on a piece of paper after researching enough tech to design new engines...

it would be a great QoL (for me) to be able to do that - the same would be true for scanner tech etc as most of the time HS and resolution for an "old" design stay the same too with new sensor strength... maybe some of the other designs (magazine, weapons..) could profit from this too...

not sure how work intensive it would be to add something like the "previous missile design loading" for the other design-buildings but it would be great to add...
 

Offline Iceranger

  • Registered
  • Commander
  • *********
  • I
  • Posts: 391
  • Thanked: 230 times
Re: C# Aurora v0.x Suggestions
« Reply #851 on: January 02, 2019, 11:12:54 AM »
Quote from: Jorgen_CAB link=topic=9841. msg111814#msg111814 date=1546425614
A suggestion for missiles in C# if not too complicated.

Since the new sensor system might make self guiding missiles a bit more interesting and viable how about allowing munition inside a large missile being able to use the active or passive sensor of the parent missile.  You could add a small 0. 25 MSP electronic guidance system or something to control them.  I honestly don't remember how it worked in VB6 with mines and stuff, I rarely used mines, but I'm sure the sub munition could not use the parent sensors.

This could be interesting to build hit and run type ships or engage in sort of submarine style fighting.
If I recall correctly, currently in VB6 sub munitions do use their parent stage sensors.  Mines do not require sensors on the sub munitions.

I agree that for submarine style fighting, we could use a easier way of firing self-guided missiles at a TH/EM contact other than calculating the way point ourselves.
 

Offline Whitecold

  • Commander
  • *********
  • W
  • Posts: 330
  • Thanked: 88 times
Re: C# Aurora v0.x Suggestions
« Reply #852 on: January 03, 2019, 11:03:22 AM »
The thread about drop ships got me thinking about the civilian/military classification system, and how to overcome it with something that is still convenient. While I am aware this is a big idea, and unlikely to make it into the first release, I would like to get this idea out never the less.

Maintenance Size
Each component gets two new attributes, that is the maintenance size, and maintenance cost. It is based as before on cost and size of the component, times a modifier.
For weapons and sensors, this will usually be 1. For something easy to maintain as cargo holds, these would be much smaller, 100 000t of cargo holds might only take 1000t of maintenance capacity, and cost only 10% of their BP.
Armor on the other hand might be cheap to maintain, but take up more than its weight in maintenance capacity, since armor makes any other system on a ship less accessible.
The general trend of civilian versions of magazines/hangars will be less space efficient and/or less able to take damage, but more efficient and affordable in maintenance.
Similarly, large engines/shields/reactors might have lower maintenance than smaller engines, as 20 5HS engines have a lot more parts that can fail than 2 50 HS engines.
Lower power modifier will also result in easier to maintain engines due to lower stresses.

Engineering spaces will work on their percentage relative to effective maintenance size, so a single engineering space on a freighter will be much more effective than on a battleship

A special case would be work platforms. These are orbital habitats, miners, fuel extractors, terraformers, maintenance facilities, these will be considered as having maintenance facilities for themselves built in. Given enough supplies, they can maintain themselves infinitely, plus perhaps a bit spare to also cover some fuel tanks/small engines to make self propelled versions of them.

Overhauls
Every ship would now eventually need to undergo overhaul. Except for work platforms, which should be self maintaining, every ship will eventually return to a port anyway.
A standing order "Overhaul if arriving at a port with high maintenance clock" should automate most of that requirement.

Maintenance Supplies
C# already uses only maintenance supplies for all maintenance purposes, so all that is really needed is a way to automatically supply them. If you can set a tender to 'resupply nearest maintenance location' and have maintenance locations able to either request or supply the needed maintenance supplies, again a few ships should be able to distribute the needed supplies.

Shipyards
Shipyards will get a second property, a complexity limit. This is the maximum maintenance cost of a ship that can be built in a shipyard, representing the yards capability to handle high-tech components.
Increasing complexity costs additional resources, thus a yard that can build freighters will be a lot cheaper than one for supercarries. Thus you still get a variety in either complex, smaller yards for military craft, simpler large yards for tankers and such, and expensive, large complex yards for true capital ships.

Jump Drives
Jump Drives would need a change, as now there is no clear cut difference between military and commercial engine. However this is not the best anyway, since you can also jump towed ships, so the engine does not seem strictly required for a jump.
A replacement to still allow civilian jump drives would be to add a property "Jump Delay," which controls how long a ship is frozen after a jump. For a commercial tender, a full hour will still be acceptable, but a combat ship will want something faster.


This overall would allow for some more flexibility in ship design, as maintenance is now determined by all components, not the presence of a single one. If you want 2HS sensors on all your freighters, you can do it now. Similarly, Q-ships would be possible now, or equipping a 100kton freighter with some ELINT as a spy ship.
It would also allow to go for true mixed designs, putting some AMM systems on your colliers and tankers if you want, or channel the 18th century completely (or any of a number of ScFi franchises with armed merchantmen) and arm all your ships if you want. While I doubt that is optimal, it would certainly be a fun read.
 

Offline zatomic

  • Petty Officer
  • **
  • z
  • Posts: 27
  • Thanked: 11 times
Re: C# Aurora v0.x Suggestions
« Reply #853 on: January 03, 2019, 01:26:43 PM »
I had been thinking along similar lines to Whitecold regarding overhauls and the military/commercial division.

Currently a ships maintenance is based on components breaking down and requiring parts to repair combined with a maintenance life that causes the rate of breakdowns to increase the longer it's been since the last overhaul. My thought is that when a ships maintenance life hits certain criteria, it is treated as able to do 'continuous self overhaul', meaning that while it still has failures and uses supplies, the rate of failure never increases from the baseline. To avoid making it to easy to have military ships meet this criteria, I would base it on something like (with all numbers being just suggestions and adjustable for balance):

Maintenance life greater than 5 yrs.
Maintenance supply capacity greater than 4-times largest component usage.
Maintenance space equal to 20% of total HS of fail-able components(meaning that cargo holds, armor, and probably a few other things don't contribute to this size).

Thus, for a traditional cargo ship, you might need a few more engineering spaces, but those are cheap and since the cargo bays don't count towards the fail-able component mass, you get a ship that never needs overhaul and consumes a small trickle of maintenance supplies (which can be topped up every time it refuels). If you wanted to add a little bit bigger sensor or a small gauss turret, you just need a little more engineering space to meet the criteria.

For a combat ship, where most of the components are fail-able, 20% space to engineering spaces would be a big sacrifice in terms of size and impact on speed, and thus while possible, would not be as effective as a ship designed to be overhauled every few years. On the other hand, maybe for your death-star, not needing overhaul is worth the extra space just so you don't need a facility capable of doing an overhaul on your bazillion ton doom ship.

Another interesting case would be military space stations. Something not designed to move (or move much since it could have a few engines to slowly move into position, or be towed by tugs), the extra space might be worth not having to move it, or, if it's large, having a facility capable of overhauling it. Of course, your space station would still need regular deliveries of supplies as it would still have breakdowns at a steady rate.

All that said, I haven't yet had a good idea on how to handle military vs. commercial shipyards without going down a similar path to Whitecold with 2 different 'sizes' for shipyards based on total bulk size and 'fail-able' component size. One option might be to say that a shipyard doesn't have to completely enclose the ship it's building, and so make only the 'fail-able' components count (or the effective maintenance size in Whitecold's version).

In fact, taking Whitecold's suggestion and just adding my criteria for a ship not requiring overhauls (continuous self overhaul) would also be a good solution. (Having to overhaul freighters, even with an automatic order, would be tedious, especially if a whole task group gets held up or split because one freighter was due for overhaul. Having an option for military space stations to not require overhaul as well is also nice).
 

Offline Scandinavian

  • Lieutenant
  • *******
  • S
  • Posts: 158
  • Thanked: 55 times
Re: C# Aurora v0.x Suggestions
« Reply #854 on: January 03, 2019, 03:03:16 PM »
If we want to get really fancy, we could give each individual component a separate clock:
- Sensors and fire controls run up maintenance clock very slowly but continuously whether they are in use or not (as the passive sensor component decays/misaligns/needs to be calibrated by your resident Turian).
- Active sensors run up wear faster when in use, at a rate of [sensor maintenance intensity] x [sensor power] / [sensor size].
- Engines run up maintenance clock by being used (at a rate of [engine maintenance intensity] x [engine power delivered] / [engine size]).
- Shields from being on, and faster when (re)charging/reloading.
- Shuttle bays, fuel and ordnance transfer systems, and hangars/flight decks would accumulate wear from the relevant cargo operations, resp. reloading, repairing, resupplying, or reducing maintenance or deployment clocks on parasites.
- Weapons from charging their capacitors, replacing the current failure scheme (and maybe at a slower rate from holding charge on their capacitors - forcing people to make choices regarding state of readiness of, e.g. jump point defense forces).
- Mining, terraforming, refinery, maintenance, etc. modules do not accumulate failure rate or maintenance clock, as they are assumed to be continuously overhauled on-site, but have a baseline failure rate that ensures they must still be kept in supply. And maybe a higher failure rate when in use than when idle.
- Reactor maintenance would be abstracted into weapon capacitor maintenance, because turning reactors on and off separate from weapons would be tedious.
- Magazines are assumed to be dumb cargo space, with all the movable parts being baked into the launcher, and so would need maintenance but not accumulate failure rate.
- Life support, engineering spaces, damage control, bridge, fuel tanks, etc., would have supply consumption but not escalating failure rates. Jump engines should probably also go here, because allocating maintenance cycles to them in a transparent and reasonable way gets tricky when they act as jump tenders for non-jump-capable vessels.

Further, instead of failing catastrophically as components do now, have them fail at a rate of [base rate] x [size in HS, min 1] but only costing [base cost] / [size in HS, min 1] supplies to fix each time (so maintaining a 50 HS engine requires you to replace a sprocket every week instead of hot swapping the whole thing once a year).

Finally, have failure rate only begin to increase after a certain amount of time on the maintenance clock (could be tech dependent, could be fixed for a given component class, could be a design parameter), and cap failure rates at, e.g., 10x baseline rate.

The cap on failure rate would ensure that vessels which have a very low baseline supply consumption, such as jump point pickets, freighters, tankers, colliers, jump tenders, fuel harvesters, terraformers, etc. could effectively opt out of overhauls. This could be explained as vessels for which this is practical to do having been optimized for on-site maintenance - which would also be true from a mechanical perspective.