Author Topic: C# Aurora Changes List  (Read 153359 times)

0 Members and 3 Guests are viewing this topic.

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #195 on: January 26, 2020, 09:35:15 AM »
Diplomacy Part 2: Intrusion into NPR Territory

In each construction phase, each NPR will determine a value for each known system. In order of ascending importance the values are: Alien Controlled, Neutral, Claimed, Secondary, Primary, Core, Capital. The value is based on a number of different factors, including existing population and installations, whether it is a logistics node, mining potential, terraforming potential and proximity to other important systems. Neutral is the default state for a system in which the NPR has no current interest, while Alien Controlled is a system which the NPR acknowledges is in the territory of another race. Just because you have a presence in a system, that doesn't mean the NPR will set it as Alien Controlled. In some cases, the NPR will unilaterally flag as Alien Controlled and in other cases, it will become Alien Controlled as a result of warnings from other races or via a treaty. Sometimes, the NPR will maintain its own claim, which can lead to conflict. I'll cover the subject of 'Alien Controlled' in a future post.

If you have forces or a population in a system that is claimed by an NPR and you are detected and you are currently viewed as neutral or friendly, the NPR will issue a warning which will appear as an event. This will still happen even if you haven't detected any NPR forces. You will be notified which fleet or population received the message. If communication has not been established, you will receive notification of an "unintelligible communication of unknown origin". If you have established communication, the text will reflect the severity of the situation. This can be as mild as a suggestion that your forces leave in the near future and as strong as demanding you depart immediately or be fired upon. There are five levels of severity for messages and the one chosen by the NPR depends on the 'Threat Level'. This is calculated as follows:

Base Threat Level
Claimed = 2
Secondary = 5
Primary = 10
Core = 20
Capital = 40

Status Modifiers
Friendly Status = 0.5
Neutral with Diplomatic Points >= 0 = 1
Neutral with Diplomatic Points < 0 = 2

Threat Level = Base Threat Level * Status Modifier * (Racial Xenophobia / 100)

The messages increase in severity at threat levels of 2, 5, 10 and 20. The threat levels are also used as modifiers for the loss of diplomatic rating due to the intrusion:
Diplomatic Point Penalty = ((Detected Ship Tonnage * Threat Level * 0.001) + (Population EM Signature * Threat Level * 0.01)) * (Construction Phase Length / Year)

If at least one ship is detected, the minimum rating for Detected Ship Tonnage will be 1000 tons. If at least one population is detected, the minimum rating for Population EM Signature will be 100. The warning message are given at first detection and will be repeated during each construction phase where the violation still exists. The penalty for diplomatic points will only be applied during the construction phase. Allied Races do not receive warnings as they can freely enter the NPR territory. Hostile races do not receive warnings as they are attacked instead. Trading will allow some exceptions to the rules above and I'll cover that in a future post. I will also cover situations where the NPR considers claiming a system with a large existing player population in the 'Alien Controlled' update.

Diplomacy is a lot more complex for C# so I am posting these updates as I complete the code, rather than trying to post everything at once.

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #196 on: January 28, 2020, 02:43:00 PM »
Diplomacy Part 3: Claiming Systems from NPRs

In the same way that NPRs can warn players to leave a system, a player can warn an NPR. On the Intelligence and Foreign Relations window, there is a tab for Known Systems for each NPR. You can select a system and then set a 'Protection Status' for the selected system in connection with the selected NPR. The six statuses (with their numeric 'demand value') are:

0 No Protection
1 Suggest Leave
2 Request Leave
3 Request Leave Urgently
4 Demand Leave
5 Demand Leave with Threat

If you set a status for a specific combination of system and NPR, then whenever that NPR is detected by you in that system it will be informed of that status unless it is already allied or hostile. The NPR will decide whether to accept your claim based on five factors; the NPR assessment of system value (covered in Part 2), the NPR's racial characteristics, the strength of your demand, the relative size of any competing populations in the system and the NPRs assessment of the relative balance of military forces. This latter assessment depends on the total size of your military forces that have been detected by the NPR during the last five years in comparison to its own (with an assumption of some as-yet-unseen forces) and its assessment of relative technology based on its observation of your ships. The NPR will not relinquish its capital or a core system.

The impact of the message on the NPR decision is the square root of the Demand Value. So a Request is 41% more likely to work than a Suggestion, while a Demand with Threat is 2.25x more effective than a Suggestion. The Demand Value represents the idea that, from the perspective of the NPR, the forcefulness of your language may represent a willingness to use force.

While the strength of your demand plays a part in the NPR decision, it also has a significant effect on relations with that NPR. So a higher demand might increase the chance the NPR will leave, but it also increases the chance of starting a war. If you demand the NPR leaves a system it doesn't care about you will cause fairly minor damage, but you could have made a polite request and it may have left with hardly any impact on relations. If you demand an NPR abandons what is regards as a primary system, that might work if you have a significant military advantage and the NPR is aware of it, but it might also cause the NPR to open fire immediately.

System Values are as follows:
1 Neutral
2 Claimed
3 Secondary
4 Primary
5 Core
6 Capital

This relationship impact is equal to (Demand Value ^2) * (System Value ^2) * (Xenophobia / 50). So a demand to leave a primary system would have the impact of  256 * (Xenophobia / 50), while a request to leave a claimed system would have an impact of only 16 * (Xenophobia / 50).

The demand will be accepted if (Player Military Advantage * Message Strength * Player Population Factor * NPR Population Factor) >  ((System Value ^2) * ((Xenophobia + Militancy + Determination) / 150) * 0.2)

System Value is determined as per the explanation in Part 2. However, the value of any systems cut off from the capital by the loss of the claimed system will be included in the value of that system.

Population Factors are based on EM Signatures of all NPR populations and any detected Player populations. Player Population Factor is equal to Total EM Strength ^ (1/5). NPR Population Factor is equal to 1 / (Total EM Strength ^ (1/5)). If no population exists the respective factor is 1.

For example, if the NPR has militancy, determination and xenophobia all at 50, then the value to overcome for a Claimed system is 0.8. If there are no populations and you use a demand which is worth 2.0x, you will need an Player Military Advantage of 0.4 or greater. With the same NPR, if the NPR has a population with an EM of 100 (about 1m pop) in the system and the player has a population with an EM of 1000 (about 10m), the respective population factors would be 0.398 and 3.98, for an overall effect of 1.58. Now the required military advantage is only 0.25. I don't want to go into too much detail on the Player Military Advantage, but if the NPR believes the racial balance of forces is equal, Player Military Advantage will be equal to 1. For the NPR to believe you have an advantage, it will need to see some firepower. You won't be able to simply send in a survey ship and ask the NPR to move out. This is based on total known forces, not local known forces, so getting a high number is difficult unless you show off a large portion of your forces. The other major factor is that if the NPR is low militancy, low determination and low xenophobia, it will be much easier to push around.

If the NPR rejects your demand to withdraw, the protection status for that system for that NPR is reset to No Protection, so that further diplomatic penalties are not incurred. If you want to re-instate the demand (at whatever level), it will generate a new penalty.

If the NPR decides it must withdraw based on its assessment of the situation, it will evacuate its ships and transfer any colonies to your control. These will start at a status of Occupied. The system will be set to 'Alien Controlled' (Player controlled) from the perspective of the NPR and it will ignore the system when deploying forces. This will change if conflict breaks out.

Note that the player vs NPR and NPR vs player functionality for claiming systems are a little different. Both sides can send messages to each other and the types of messages are effectively the same. The difference is the method of delivery and the potential reaction. This is because I wanted to give the player maximum flexibility in Diplomacy, while still proving a structured approach for the NPR. For example, the player view of the NPR in terms of diplomatic points does not drop if the NPR ignores demands to leave. The player can decide whether it is necessary to go to war.

This is a complex set of interactions, so I may modify after play test (or if someone spots any errors in the algorithms).
« Last Edit: January 31, 2020, 12:57:07 PM by Steve Walmsley »
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #197 on: January 29, 2020, 12:49:12 PM »
Diplomacy Part 4: NPR vs NPR Claims

NPR vs NPR Diplomacy works as a combination of NPR vs Players and Player vs NPR.

As described in Part 2, when an NPR detects alien forces in a system that is claimed by the NPR, the NPR will issue a warning. When the target is a player this appears as an event message as per Part 2. When the target is another NPR, the first NPR sets a protection status (in the same way as a player does in Part 3) that corresponds to the same demand level as it would send to a player.

For example: An NPR detects an alien force in a system that it claims and decides this represent a threat level of 12. If the alien is a player, the NPR will send a message to the player that will appear as an event. The message will be on the lines of "We demand you leave" and that message will continue to be sent each construction phase. If the target is another NPR (let's call this NPR-B), then NPR-A will set a protection status of 'Demand Leave' instead.

Next phase (or in some cases later in the same phase), NPR-B will see the withdrawal demand from NPR-A, just as it would see a similar demand from a player. It will react to that demand in exactly the same way except for one crucial difference; NPR-B will not reduce the diplomatic points for NPR-A.

So why all the messing about with slightly different methods for Player vs NPR, NPR vs Player and NPR vs NPR? Because NPRs, even though they are much smarter in C#, will still not have the human capability to make intuitive estimates weighing the strategic benefit of claiming a system claim vs the potential downsides of reduced diplomatic relations. This strategic deficit in AI vs human ability is handled by the different reactions to claims.
  • Player vs NPR: The NPR will generally react negatively to being asked to leave a system, as that is a relatively easy to understand situation, and it can make a reasonable estimate of whether to abandon that system. The player does not react negatively to the NPR refusing to leave in game mechanics terms because the human player can make decisions himself about whether to treat the NPR differently. This also means that continual messages can be sent to remind the player without diplomatic penalties in-game.
  • NPR vs Player: The NPR will react negatively to player forces being in one of its systems, as that is also a relatively easy to understand situation. The negative impact is based on the importance of the system and the size of the player force. The player does not react negatively to the NPR asking him to leave in game mechanics terms because the human player can make decisions himself about whether to leave or treat the NPR differently.
  • NPR vs NPR: NPR-A will react negatively to NPR-B forces being in one of its systems, as that is also a relatively easy to understand situation. The negative impact is based on the importance of the system and the size of the NPR-B force. NPR-B will decide whether to leave the system but will not react negatively to being asked to do so. This allows the protection level to be reset each time without negative impact (so the NPR doesn't have to consider the huge variety of factors on when to make a new demand). Also, NPR-B may well regard the system as one of its own and will be making its own demand of NPR-A, in which case it will react negatively to a refusal from NPR-A.
The difference is that the NPR is always faced with an immediate decision and does not have to consider wider implications. The player has the ability to take those wider implications into consideration and is free to make his own decisions on relationships. When NPRs do confront each other, either one will leave because the system is not important or they will start making demands of each other, which takes care of the dual negativity. I know it sounds complex, but I think it the best option to handle the different situations.


 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #198 on: January 29, 2020, 04:24:45 PM »
Diplomacy Part 5: Restrictions on NPR Claims

There are several situations where NPRs will not make territorial claims:
  • If the NPR and the alien race share a capital system, no claims will be made in the capital system or in any adjacent system
  • The NPR will not make claims against an alien race with whom it shares a Fixed Relationship due to a Truce Countdown
  • The NPR will ignore claims from an alien race with whom it shares a Fixed Relationship due to a Truce Countdown and there will be no diplomatic penalty
  • The NPR will not claim a system if there are alien populations with a total EM signature greater than 10% * (Xenophobia / 100) of its own capital's EM signature and also greater than the total EM signatures of any AI populations in that system
The above is based on the concept that an AI is unlikely to claim a system where it knows there is a good chance that claim will cause a war. Note that from the NPR perspective an 'alien race' includes player races.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #199 on: February 02, 2020, 08:20:37 AM »
Diplomacy Part 6: Independence

In C#, you can declare a colony independent using a button on the Economics window. Colonies may also become independent in other situations, such as a rebellion following high unrest. Independence is far more complex than it first sounds, because the population will be under the control of a new race that is essentially a copy of the original race. The process is as follows:
  • The title of the new race will be based on the name of the newly-independent population.
  • A new flag will be auto-selected and random naming themes chosen for classes, systems, etc.. Commander name themes will remain the same as the original race.
  • The ranks of the new race will copy the ranks of the original race.
  • Any ground forces at the population will be transferred to the new race.
  • It is possible that an NPR population can become independent, in which cases it will retain the same tech but create a new design philosophy.
  • The new race will start with an amount of wealth equal to total original race wealth * (independent pop size / total original race pop size before independence), which will be transferred from the original race.
  • The new race will start with a number of commanders equal to original race number of commanders * (independent pop size / total original race pop size before independence). These are new commanders and not transferred from the original race.
  • A top-level admin command will be created at the population.
The new race will gain the following knowledge from the original race.
  • The same galactic map, including map labels.
  • All geological and gravitational survey data.
  • All tech systems.
  • How to build all ship components and missiles.
  • All class designs.
  • All ground unit class designs.
  • All ground formation templates.
  • All intelligence data, including alien races, classes, ships, sensors, weapons, populations and ground forces.
  • A complete set of intelligence information on the original race which will be set up as a new alien race, with known systems, ships, etc.
  • Control Race flags on galactic map.
  • Protection Status settings for different combination of alien races and systems.
  • Locations of ruins, anomalies, wrecks, etc..
  • Event colours.
For manual independence, any naval forces will have to be transferred using the Transfer Fleet option. In the case of a rebellion, some ships may be transferred automatically.

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #200 on: February 08, 2020, 04:18:57 PM »
Star System Design Part 1: Modifying Stars

C# Aurora allows you to manipulate star systems in SM Mode. While it would be difficult to design a system during the original generation process, due to the complexities involved, you can now add or modify stars and system bodies. This post covers modifying stars.

You click on a star in the System View and then click Change Star. The dialog below pops up and allows you to select spectral class, orbital distance, bearing and parent star.



Here is an example from my current test campaign that changes the B component of Alpha Centauri from a K1-V star to an F0-V, which is much hotter. The star will orbit more quickly due to the increased mass, plus all the planets orbiting the star are affected by the increased mass and luminosity of the different star. Temperatures will change, along with potentially hydrosphere type and atmospheric composition (as gases freeze out or boil). Oceans or ice sheets may convert entirely to water vapour given a significant temperature rise. Planets may change their tide-locked status.





These two screenshots show the effect of moving the star further from the primary.





Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #201 on: February 08, 2020, 05:29:38 PM »
Star System Design Part 2: Adding Stars

Adding a new star is straightforward. You click Add New Star. The dialog below pops up and allows you to select spectral class, orbital distance, bearing and parent star.



This screenshot shows the result of adding the above star to the Alpha Centauri system. New stars do not have any planets or other system bodies. These are added separately and will be covered in a future post.

 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #202 on: February 09, 2020, 12:08:52 PM »
Star System Design Part 3: Modifying System Bodies

Modifying system bodies is a more complex process than stars due to the number of factors involved. There are factors that are tied to each other, such as mass, radius, density and gravity, plus certain types of bodies have different rules (planets vs moons, gas giants vs rocky worlds).

Therefore, the following factors can be changed; distance to parent body, diameter, density, hydro extent, albedo, atmospheric composition and dominant terrain. The dominant terrain is restricted to those terrains permitted by the other factors. Factors such as colony cost, gravity, temperature, atmospheric pressure, length of year, maximum population, tidal lock status, atmospheric retention, time required to stabilise a Lagrange point, etc. will all be derived from the factors that can be changed. For example, if you change the diameter or density, the mass and gravity will automatically change. If you change the distance to parent, the temperature and year will change and perhaps the tidal lock status. Finally, factors such as escape velocity, magnetic field, etc. are not shown here because they have no current game play impact, even though escape velocity will change as a result of modifications to density or diameter.

The basic type of system body (terrestrial, dwarf, etc.) cannot be changed, but it will be possible to delete one system body and add a new one of the desired type. This is to ensure all system bodies follow the basic rules of their type, even if they are later modified.

Below is the System Body Modification popup window. You can change the green fields in the top left, the dominant terrain dropdown and can add and remove atmospheric gases by choosing a gas and the desired atm (0 to remove). As you make each change, everything else updates.



For example, here is what happens if the diameter is halved. Gravity, mass and max population all fall, while the terraform rate vs Earth and the time to stablise a Lagrange point both increase.


 
The following users thanked this post: Garfunkel, Kristover, Marski, Britich, DIT_grue, kuhaica, TMaekler, Rye123, Stryker, Alsadius, BigBacon, Ektor

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #203 on: February 09, 2020, 02:03:22 PM »
Star System Design Part 4: Deleting Stars and System Bodies

Deletion of stars or system bodies is straightforward. Click on the target object and then click Delete Body or Delete Star. You will be given two popup warnings and then the object will be deleted. Deleting a star will remove any system bodies in orbit. Deleting a planet will remove any moons of that planet. Any populations on affected system bodies will be deleted. Deleting the primary star is not possible.

When a star is deleted, any remaining stars will be renamed accordingly. For example, if you delete the B component of a primary, the original C component will now become the B component. When a planet or moon is deleted, the orbit numbers of the planets or moons will be adjusted accordingly.

For example, here are the before and after views of the Alpha Centauri-A system when the fourth planet is deleted.



 
The following users thanked this post: Garfunkel, Marski, Britich, DIT_grue, kuhaica, TMaekler, Rye123, Stryker, joansam, Alsadius, Kiri, BigBacon, Ektor

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #204 on: February 10, 2020, 06:07:53 PM »
Star System Design Part 5: Adding Planets, Comets and Asteroid Belts

Below is the form for adding all new system bodies except for additional moons. You choose a system body from the drop down, which includes Terrestrial, Dwarf Planet, Gas Giant, Superjovian, Comet and Asteroid. Each body type has a distance parameter plus one or more other additional options.
  • For terrestrial and dwarf planets you have a toggle for automatic moon generation and can choose a specific or random number of moons.
  • For gas giants and superjovians, you have the above moon options plus similar options for Trojan asteroids (on/off, random/specific)
  • For comets, you choose the starting distance and maximum distance
  • For asteroid belts, you can choose a random or specific number of asteroids and the specific or random width of the belt (how far an asteroid can be generated from the centre of the belt)
Once the planet parameters are selected, press OK and the new body or bodies will appear in the System View. You can select them and use Modify Body to customise if desired.

The various zones shown at the top affect how Aurora determines parameters such as atmosphere, hydrosphere, mineral deposits, albedo, density, number of moons, total mass of asteroid belts and a variety of other factors. There is far too much detail to list, but generally bodies in the life zone will have better conditions and mineral deposits, followed in decreasing order by Inner, Outer and Extreme. These zones also exist in VB6. Of course, those factors only affect initial generation so you can override that by directly modifying a body post-creation.



In the next post I will cover adding moons to existing planets.
 
The following users thanked this post: Garfunkel, Kristover, Britich, QuakeIV, DIT_grue, kuhaica, TMaekler, Rye123, Stryker, joansam, BigBacon

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #205 on: February 11, 2020, 03:29:36 PM »
Star System Design Part 6: Adding Moons and Lagrange Points

Below is the form for adding moons to existing planets. During planet creation you can specify appropriate moons to be created at the same time using standard moon generation based on the type of planet and is orbital distance. This form, accessed via the Add Moons button, is for creating additional moons which do not have to obey normal size restrictions. The form allows the addition of up to five moons (the drop-downs all start with no moon) with type and distance specified. If more than five moons are needed, the form can be used multiple times for the same parent planet.

After initial generation you can use Modify Body to specify additional detail if required.



The Add Lagrange button adds a Lagrange point to the currently selected body, even if it would not normally qualify for one.
« Last Edit: February 11, 2020, 03:35:35 PM by Steve Walmsley »
 
The following users thanked this post: Garfunkel, Britich, QuakeIV, DIT_grue, kuhaica, TMaekler, Rye123, Stryker, BigBacon

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #206 on: February 12, 2020, 06:52:23 AM »
Gauss Cannon Research Changes

I've lowered the research point requirements for Gauss Cannon.

The Rate of Fire tech starts at 2 shots with the following progression in RP from 2 to 6 shots: 1500, 5000, 15,000, 45,000, 135,000. Eight shots is 450,00 RP.
The Launch Velocity still has six levels with the following progression in RP: 500, 1500, 5000, 15,000, 45,000, 135,000
« Last Edit: February 12, 2020, 03:36:29 PM by Steve Walmsley »
 
The following users thanked this post: Garfunkel, Britich, Jorgen_CAB, Neophyte, kuhaica, TMaekler, Rye123, DEEPenergy, Stryker, joansam, BigBacon

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #207 on: February 12, 2020, 07:42:35 AM »
Star System Design Part 7: Deleting Asteroids and Lagrange Points

Deleting individual asteroids can be done by using the Delete Body button. To delete an entire asteroid belt or all the Trojan asteroids for a particular planet, click one of the asteroids in the belt or one of the Trojans and click Delete Asteroids. There will be two warnings before all the affected asteroids are deleted.

Lagrange Points can be removed by selecting the parent system body and clicking Remove Lagrange.

Below is the final version of the System View in SM mode with all system engineering buttons present.

 
The following users thanked this post: Garfunkel, Britich, DIT_grue, kuhaica, TMaekler, Titanian, Rye123, Stryker, joansam, Alsadius, BigBacon

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #208 on: February 14, 2020, 06:20:10 AM »
Lagrange Points for Moons

In C#, it will be possible to have Lagrange Points for moons. These will not occur naturally, but there are two situations where it is possible. Firstly, you can use a ship equipped with a Stabilisation Module on any moon with a mass of at least 0.25 Earth masses. The time required will depend on the mass of the moon but it is likely to be several years. Secondly, you can place the Lagrange Point manually using the new System Design functionality. The latter option does not have any mass restriction.

This will provide a way to have ships jump very close to the parent planet of the moon, which is very useful in logistics terms but very dangerous if you are at war.

Of course, it is entirely a coincidence that Battlestars will now be able to jump into orbit close to Ragnar Anchorage.

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 8195
  • Thanked: 5312 times
    • http://www.starfireassistant.com
Re: C# Aurora Changes List
« Reply #209 on: February 15, 2020, 07:27:40 AM »
Maintenance Storage Bays

VB6 has the Maintenance Storage Bay, which is 5 HS and carries 1000 MSP.

In C#, the new 1% weapon failure rate means that the ship design process will have to account for that additional MSP expenditure when considering engineering systems. This includes small craft such as fighters which may mount a single energy weapon or multiple box launchers. The issue for fighters is that adding sufficient engineering to cover that potential MSP cost may give them maintenance lives of many years, which is unnecessary and not very realistic.

Therefore, C# adds several new maintenance storage options. These create a reserve of maintenance supplies that can be used to repair weapons but do not affect failure rates or maintenance life. I've also doubled the storage capacity because the MSP capacity of normal engineering was not significantly lower in many cases.

Maintenance Storage Bays in C#
Large: 2000 MSP, 5HS
Standard: 400 MSP, 1 HS
Small: 80 MSP: 0.2 HS
Tiny: 40 MSP 0.1 HS
Fighter: 20 MSP: 0.05 HS.
 

 

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 53 54 55