Author Topic: C# Aurora Changes List v1.00  (Read 573319 times)

0 Members and 9 Guests are viewing this topic.

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #60 on: February 22, 2018, 09:50:05 AM »
Chance of Ruins

This is a copy of a post in the VB6 7.2 Changes List. I didn't release the updated VB6 version so this is still a change from the released VB6 Aurora.

I've added the chance of alien ruins to the game window, so it can be adjusted.

It is normally 20% for any terrestrial world, terrestrial moon or small terrestrial moon with gravity > 0.4G and temperature between 200K and 360K (about -73C to +87C).
« Last Edit: February 22, 2018, 11:16:54 AM by Steve Walmsley »
 
The following users thanked this post: Garfunkel, SpikeTheHobbitMage, TMaekler, Rye123, Detros

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #61 on: February 22, 2018, 10:13:26 AM »
Structural Shells

This is a copy of a post in the VB6 7.2 Changes List. I didn't release the updated VB6 version so this is still a change from the released VB6 Aurora.

A 'No Armour' check box has been added to the class window. Clicking this removes the normal armour from the class.

Designs with no armour instead have a new type of armour called 'structural shell'. This costs 1 per unit and has a strength of 20, essentially making it 5% of the cost of normal armour in terms of strength.

There are severe limitation on ships with no armour:
1) They cannot have engines
2) They cannot have military systems
3) The structural shell does not prevent damage. In effect, weapon fire passes straight through the 'armour'

This type of ship is ideally suited for orbital habitats or space stations of some type, such as fuel harvesting platforms, mining stations, etc., that require towing to move.
 
The following users thanked this post: Garfunkel, Flying Dice, Doren, SpikeTheHobbitMage, TMaekler, Rye123, Detros, lordcirth

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #62 on: February 22, 2018, 10:22:38 AM »
Maintenance Storage Bays

This is a copy of a post in the VB6 7.2 Changes List. I didn't release the updated VB6 version so this is still a change from the released VB6 Aurora.

In C# Aurora, Maintenance Storage Bays are no longer a military system.
 
The following users thanked this post: Garfunkel, Britich, Flying Dice, Doren, SpikeTheHobbitMage, TMaekler, Rye123, Detros

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #63 on: February 22, 2018, 10:36:13 AM »
Orbital Habitats

This is a copy of a post in the VB6 7.2 Changes List. I didn't release the updated VB6 version so this is still a change from the released VB6 Aurora.

The population capacity of orbital habitat modules has been increased from 50k to 200k. In combination with the new 'No Armour' option this significantly reduces the cost of building orbital habitats. For example, the habitat shown here supports a population of one million for a cost of 1145 BP. To support one million colonists with infrastructure on a colony cost 2.0 world with acceptable gravity would cost 400 BP, so the colony cost would have to be approaching 6.0 before the Orbital Habitat became cheaper, although it is probably practical at lower colony costs because the ground-based infrastructure would require a larger proportion of population for environment. For low-gravity worlds it is comparable with the cost of low-gravity infrastructure and it is the only option for high gravity worlds or small bodies with low population capacities.

Sidon class Orbital Habitat      1,252,970 tons       162 Crew       1144.7 BP       TCS 25059    TH 0    EM 0
1 km/s      No Armour       Shields 0-0     HTK 132      Sensors 1/1/0/0      DCR 1      PPV 0
MSP 0    Max Repair 200 MSP
Habitation Capacity 1,000,000   
Lieutenant Commander    Control Rating 1   BRG 
Intended Deployment Time: 3 months   

Commercial Active Sensor (1)     GPS 1920     Range 27.3m km    Resolution 120

This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as an Space Station for construction purposes
« Last Edit: December 12, 2018, 09:59:47 AM by Steve Walmsley »
 
The following users thanked this post: Garfunkel, Flying Dice, Doren, SpikeTheHobbitMage, TMaekler, Nori, Rye123, lordcirth

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #64 on: February 22, 2018, 06:23:45 PM »
Space Stations

The rules on construction factories building spacecraft are changing in C# Aurora. Any class with a Structural Shell instead of armour is classed as a Space Station. Space Stations can be built by construction factories at any population that includes a Spaceport. Note this means you no longer need an orbital habitat in order to use construction factories, which means you can create huge deep space logistical bases, terraforming stations or small observation platforms, or anything in between, using construction factories.

The downside to this flexibility is no armour, no engines and no military systems, so space stations will require protection from defensive bases (which can be maintained by the space station if it has sufficient maintenance facilities). As an example, if you were channelling Starship Troopers (movie, not book) you could build the following station and deploy in deep space, near the Arachnid Quarantine Zone:

Ticonderoga class Fleet Base      823,223 tons       5,867 Crew       30,310.1 BP       TCS 16,464    TH 0    EM 0
1 km/s      No Armour       Shields 0-0     HTK 708      Sensors 1/11/0/0      DCR 1      PPV 0
MSP 20,023    Max Repair 2400 MSP
Hangar Deck Capacity 20,000 tons     Magazine 10,000   
Commander    Control Rating 2   BRG  AUX   
Intended Deployment Time: 3 months    Flight Crew Berths 400   
Recreational Facilities
Maintenance Modules: 80 module(s) capable of supporting ships of 128,000 tons
Refuelling Hub - Capable of refuelling multiple ships simultaneously
Ordnance Transfer Hub - Capable of transferring ordnance to multiple ships simultaneously

Fuel Capacity 20,000,000 Litres    Range N/A

CIWS-200 (12x6)    Range 1000 km     TS: 20,000 km/s     ROF 5       Base 50% to hit
Perseus Anti-ship Missile (1200)    Speed: 32,000 km/s    End: 65m     Range: 125.3m km    WH: 6    Size: 4    TH: 106/64/32
Huron Anti-missile Missile (5200)    Speed: 31,700 km/s    End: 1m     Range: 3.5m km    WH: 1    Size: 1    TH: 137/82/41

Commercial Active Sensor (1)     GPS 2520     Range 42.3m km    Resolution 120
Commercial EM Sensor (1)     Sensitivity 11     Detect Sig Strength 1000:  26.2m km

This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as a Space Station for construction purposes

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #65 on: February 24, 2018, 01:36:47 PM »
Standing Orders

Standing Orders are the C# equivalent of Default Orders in VB6 and function in exactly the same way. If your ship has no active movement orders, it will act on the Primary Standing Order. If that is not possible, it will act on the Secondary Standing Order.

Standing orders will only be checked if the increment length is greater than one hour. In addition, acting on the Standing Orders for "Move to Gas Giant with Sorium" and "Move to Asteroid Mineral Source" will unset the standing order (to prevent continuous issuing of the same order). Civilians and NPRs will monitor ships in this situation and reactivate the standing order if required.

Conditional Orders are Standing Orders linked to a Condition. When the condition is met, the associated conditional order will be executed where possible. Secondary conditional orders will not be executed if the fleet is already acting on the primary conditional order.

Each potential order is accompanied by an S or an A. This indicates whether the order will look at potential destinations in the same system (S) or all systems (A). When the order involves moving to a different system, the algorithm calculating the best path will take into account whether the fleet will try to Avoid Danger and try to Avoid Alien Systems. These two values are set by the Check Danger Rating and Exclude Alien-Controlled check boxes respectively, which are located on the Movement Orders tab (see Auto Route rules post for more details).

There will be some new standing orders for C#, which I will list here as I add them:
  • Land on Assigned Mothership: Can be used for Standing or Conditional orders and will only be executed if there is a common mothership for the fleet. An example of use would be survey carrier ops, where the parasites would return to the mothership if they were low on fuel or had surveyed all potential destinations.
  • Move to System Requiring GeoSurvey: Can be used for Standing Orders. The fleet will move a system where the 'Standing Order Geo Survey Complete' flag is not set . This flag is set when a survey ship with an order of "Survey Nearest Body" or "Survey Next Five System Bodies"  cannot find a system body within ten billion kilometres. It doesn't mean the system is completely surveyed, but that it is surveyed in practical terms. If you need to you can send a survey ship to a distant planet or star (more than 10b km) and it will still automatically survey everything within ten billion kilometres of the last surveyed body, but the earlier setting of the flag means that other survey ships will not arrive automatically to survey the very distant bodies.
  • Move to System Requiring Gravsurvey: Same as above but for survey locations.
  • Refuel at Hub. This is part of several different orders. A Refuelling Hub is a large module intended for space stations (although it can be used on ships) which can simultaneously refuel an unlimited number of ships (while the fuel supply lasts) if it is stationary.
  • Move to Closest Rendezvous Point: A new type of waypoint (see changes post following this one) is the Rendezvous Point. This can be assigned as a destination for a Standing Order or a Conditional Order
  • Investigate Closest Point of Interest: A new type of waypoint (see changes post following this one) is the Point of Interest, which is a temporary waypoint that remain in place until a fleet arrives at the location or for six months, whichever happens first. The function of this order and the new waypoint is for the player to designate areas in a system which he wishes a fleet to visit automatically. Different fleets operating with the “Investigate Closest Point of Interest” order will take account of each other’s activity to avoid duplication of destination. Points of Interest can be designated as Urgent and these will take priority over other POIs.



« Last Edit: February 26, 2018, 05:11:33 PM by Steve Walmsley »
 
The following users thanked this post: Garfunkel, SpikeTheHobbitMage, Viridia, Kytuzian, Tristitan, TMaekler, serger, jonw, Rye123, lordcirth

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #66 on: February 25, 2018, 09:33:29 AM »
Waypoints

Waypoints will be much more useful in C# Aurora. It will be possible to add the following five types to the system map:
  • Normal: The standard waypoint from VB6 Aurora. This will appear on the map as Waypoint #1, Waypoint #2, etc. with the number unique to the system. A normal waypoint will remain until manually removed and can be assigned as a destination in movement orders.
  • Named: Functions as a normal waypoint with the exception that during placement you can assign a name to the waypoint, that will be displayed instead of the normal text.
  • Rendezvous: Functions as a normal waypoint and will also be used as a target for the new Standing / Conditional Order “Move to closest Rendezvous Point”.
  • Point of Interest (POI): A temporary waypoint that remain in place until a fleet arrives at the location or for six months, whichever happens first. The POI will be used as the destination for the new Standing Order “Investigate Point of Interest”. The function of this waypoint is for the player to designate areas in a system which he wishes a fleet to visit automatically. Different fleets operating with the “Investigate Point of Interest” order will take account of each other’s activity to avoid duplication of destination.
  • Urgent Point of Interest: Similar in function to a POI waypoint. The differences are that this waypoint type will remain in place until a fleet arrives at the location or for one year, whichever happens first, and that any fleet with the Standing Order “Investigate Point of Interest” will visit Urgent POIs before normal POIs.
Clicking on a system body icon when placing a waypoint of any kind will link the waypoint to the system body and it will move with that system body.

Example screenshots below:



« Last Edit: February 25, 2018, 11:57:18 AM by Steve Walmsley »
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #67 on: February 26, 2018, 02:51:12 PM »
Fleet Movement Auto Route

The Fleet Movement Orders section of the Naval Organization window has an option called Auto Route by System. When this option is selected, the normal movement destinations list will be replaced by a list of systems that the Fleet is capable of reaching. Clicking on a system and clicking Add Move will generate all the movement orders from the current system to the destination system. The System Locations option will be automatically selected and the destination list for the new system will be displayed, so the player can complete any specific orders. 

The determination of which systems can be reached is based on three check boxes to the right hand side of the same tab.
  • Assume Fleet is Jump Capable: If checked, the algorithm will assume the fleet will be able to transit any jump point. If not checked, the fleet will have to be jump capable to reach any system beyond a jump point without a gate.
  • Check Danger Rating: If checked, the fleet will not be able to travel through any system where the danger rating is higher than the protection value of the friendly warships in that system
  • Exclude Alien-Controlled: If checked, the fleet will not be able to travel through any system that the player has flagged as alien controlled (assigned a flag)
Fleets have two stored values, Avoid Danger and Avoid Alien Systems. These are set on by clicking the second and third check boxes above and will affect the algorithm used for Standing and Conditional Orders for that fleet in addition to the Auto Route.

A system can also be flagged on the Galactic Map as excluded from auto-route. For example, there may be a shorter route in terms of kilometres but longer in terms of transits. You can block one of the systems on the original route so the algorithm will always choose your preferred path.

The list of systems will highlight any populated systems in light green and any other colony systems in dark green. The total population will be shown (if greater than zero) or the number of the most important installation type. In order of priority these are automated mines (including asteroid miners), then terraformers (including orbital), then tracking stations. This is similar to the population tree view on the Economics window functions.

These four screenshots below show an example journey. In the first, a US fleet in the Eta Cassiopeiae system (highlighted at the bottom) wants to return to Sol. In the second, the potential system list is displayed. As the Exclude Alien-Controlled option is checked, the fleet cannot travel through the Commonwealth systems starting with EV Lacertae so none of those systems are an option. The third screenshot shows the results as the path finding algorithm takes the fleet on a longer route via Oregon then displays the destination list for Sol. The fourth screenshot shows the journey of a French survey ship. In this case, the algorithm has determined that using Lagrange points in two of the systems will make the journey shorter.







« Last Edit: December 21, 2019, 12:22:54 PM by Steve Walmsley »
 
The following users thanked this post: Theeht, Garfunkel, hubgbf, SpikeTheHobbitMage, Kytuzian, Tristitan, TMaekler, jonw, Rye123, lordcirth

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #68 on: March 01, 2018, 03:27:36 PM »
Civilian Trade

For C# Aurora, I've updated civilian trade to use a better algorithm.

In VB6, civilian freighters without orders will move to a 'Trade Location', which is defined as a population with a balance in one or more trade goods that is greater than the capacity of the freighter. On arrival, the freighter will check the trade balances and try to find a suitable destination for one of them. If a destination is found, the move will be plotted. If not, the freighter will search for a new trade location. It could be more intelligent but not without a larger performance overhead.

In C# Aurora, a freighter without orders, regardless of current location, will search known space for the closest population that has export trade goods, taking into account any other freighters already en route to collect that trade good (and any path finding restrictions such as danger). If a suitable trade good is located, the freighter will look for the population closest to the pick up point which has an import requirement for that trade good (again taking into account any freighter already en route to drop off the same good at that destination). If no destination is found, the freighter checks the pick up point for any other trade good options with suitable destinations. If that doesn't work, the freighter checks the next population based on distance, etc., until it has checked every possible combination of populations and trade good routes in known space. If a valid route is found, all the orders are plotted including any Lagrange short-cuts. Then the next freighter repeats the process, etc..

Infrastructure is checked first at each population before any other trade good. Freighters understand the difference between low gravity infrastructure and normal infrastructure and will move the correct type of infrastructure to appropriate destinations.

Given that every civilian freighter without orders is checking every system, population and trade good in known space to find a suitable trade route, there might be a concern regarding performance. My current campaign is an ideal test bed, as I have removed every order from every fleet due to the incompatibility of the VB6 and C# database structures. Which means in the first trade phase after program start, the code is checking all 364 civilian freighters in a universe with 495 star systems, 1343 jump points, 380 Lagrange points, 345 populations and 23 different races. That first trade phase, including identifying routes for all freighters and creating 1896 individual movement orders (including load/unload, transits and LG points) required 1.01 seconds.

Colony fleets follow similarly complex rules, explained in the link below. Routing 198 civilian colony fleets using these rules, along with every other ship with Standing Orders, added a further 619 movement orders and required 0.56 seconds.

http://aurora2.pentarch.org/index.php?topic=8495.msg106715#msg106715

« Last Edit: March 01, 2018, 03:34:23 PM by Steve Walmsley »
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #69 on: March 03, 2018, 01:54:02 PM »
Civilian Movement of Installations

As in VB6, Civilians will still transport installations for player races. However, there are changes to the UI, the path finding and the costs for the this service.

In terms of cost, in VB6 the cost was a set fee of 10 wealth for multi-system transportation and 5 wealth for same system, regardless of freighter size. In C# Aurora, the cost is:
5 x Number of Installations x Systems Travelled x (Installation Type Cargo Points / 25000)

So for a standard freighter (single cargo hold) transporting a construction factory to a destination four systems away, the cost would be 20 wealth. The calculation is 5 x 1 x 4 x (25,000 / 25,000). Destinations in the same system as the start point count as half a system.

For path finding, civilian ships will use the same logic as transporting trade goods (see link below). They will search for player contracts before searching for trade goods. Note this means you can effectively commandeer civilian shipping for your own needs in an emergency, but doing so will disrupt normal civilian operations such as moving infrastructure.

http://aurora2.pentarch.org/index.php?topic=8495.msg106954#msg106954

There is a Civilian Economy tab on the Economics window, which has three lists. To the left is a list of installations at the colony, the centre has a list of installations demanded and the right has a list of installations supplied. Above the centre list is a dropdown with all types of known installations. Above the right-hand list are the installations that the colony can supply. For both the latter lists, there is an Amount column, which is the amount Demanded or Supplied, and an Assigned Column, which is the number of the installations for which a freighter contract is already assigned (this is a sub-set of the Amount). The lists can be managed with the buttons below. Adding or editing will trigger a popup box so you can type in the amount required.

The screenshots below show:
  • A colony in Zeta Herculis with Supply contracts for various installations. Most are already fully assigned.
  • The Avalon colony with several Demand contracts. Again, most are already assigned.
  • A civilian freighter has been assigned one of the above contracts and is en route to the pickup point. Note that Shipping Lines will show up on the Naval Organization window if desired, although you can't give them orders.





 
The following users thanked this post: Garfunkel, SpikeTheHobbitMage, Tristitan, TMaekler, smoelf, Rye123

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #70 on: March 03, 2018, 02:05:35 PM »
Spacemaster Changes to Installations

When in Spacemaster Mode, the Civilian Economy tab gains an extra dropdown and three extra buttons. These allow the Spacemaster to change the number of installations at a colony, or add new types. This replaces part of the functionality from the VB6 SM Modification window.

 
The following users thanked this post: Garfunkel, Doren, SpikeTheHobbitMage, Tristitan, TMaekler

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #71 on: March 03, 2018, 04:14:49 PM »
Maintenance Locations View

There is a new display option on the galactic map to highlight Maintenance Locations. They are displayed as a dashed blue circle.

 
The following users thanked this post: Garfunkel, Flying Dice, SpikeTheHobbitMage, Tristitan, TMaekler, Detros

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #72 on: March 03, 2018, 04:19:05 PM »
Automatic Pop Selection from Galactic Map

A minor but useful change. If you select a system on the galactic map and then click one of the buttons for the Economics window (Summary, Industry, Research, etc.), the Economics window will open with the most important population in that system (if one exists) already selected. Important in this context uses the same rules as the orders of populations in each system on the Economics tree view.
 
The following users thanked this post: Garfunkel, Flying Dice, SpikeTheHobbitMage, Tristitan, TMaekler, Rye123

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #73 on: March 11, 2018, 08:17:23 AM »
Armour Damage Templates

In VB6 Aurora, the damage templates for each weapon are held in a database table, with one row for each combination of weapon type and damage amount. While this is simple, it mean any new weapon or change to damage model has to be laboriously updated in the table.

For C#, the damage templates are generated in code as needed based on a 'gradient' system. All the damage starts at a single point and is distributed right and left according to the gradient setting. Any column which has damage greater than the gradient, checks left and right. If an adjacent column has a damage amount that is lower than the current column damage minus the gradient, a single point of damage is moved to that column. The adjacent column with lower damage is used first. The code cycles back and forth through the columns until no more adjustments are necessary

For example, missile damage has a 'gradient' of 1. Therefore, there cannot be a gap of 2 damage between adjacent columns. Laser damage has a gradient of 3, so any gap of 4 damage between columns is corrected. Here are some examples for 25 damage:

Gradient 1 (Missile, Carronade, Ramming):  1,2,3,4,5,4,3,2,1
Gradient 2 (Railgun, Particle Torpedo):  1,3,5,7,5,3,1
Gradient 3 (Laser):  3,6,8,5,3

Particle Lances cause damage in a single column, gauss cause only a single point of damage and meson ignore armour.

The template generation takes about a millisecond so there is no performance issue. This means that new weapons with higher gradients can be added very easily.
« Last Edit: March 11, 2018, 09:18:32 AM by Steve Walmsley »
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #74 on: March 13, 2018, 02:39:46 PM »
Ship Class Components View

The components view has been expanded considerably for C# Aurora.

The tab still has the functionality from VB6, showing the component breakdown by Amount, Size, Cost, Crew and HTK. To that has been added ordnance loadout, fuel and maintenance supplies, plus a breakdown of minerals and wealth. The mineral and wealth breakdown takes into account the mineral requirement and/or cost for the full loadout of fuel, maintenance and ordnance, so you can see the full cost of the design

Two new columns have been added which replace the damage allocation chart from VB6. Instead, this is the percentage chance that a component of the specified type will be selected for internal damage. E-DAC is for weapons that only target electronics.

« Last Edit: March 13, 2018, 06:35:21 PM by Steve Walmsley »
 
The following users thanked this post: Garfunkel, Doren, SpikeTheHobbitMage, Tristitan, TMaekler, Rye123, lordcirth