Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - MarcAFK

Pages: [1] 2 3 4
1
C# Aurora / Re: Replacing PDCs
« on: October 03, 2017, 11:55:28 PM »
I also would like to promote using company as the smallest stack and working up from there through battalion - brigade - division. We can change the ground unit default ranks to Captain - Major - Colonel - General and thus each has a specific level of command to take on. And it means that a battalion can already be a combined arms unit as well as makes the possibility of specialized small units for boarding and asteroid clearing and other similar tasks where you don't want to lug around big forces.
The following users thanked this post: MarcAFK

2
C# Aurora / Re: C# Aurora Changes List
« on: September 17, 2017, 12:12:11 PM »
Ordnance Transfer Orders

With the new ordnance transfer rules, I am changing how some of the ordnance transfer orders work.

The first major change is that a collier within a fleet can be set to automatically transfer ordnance to or from other ships in the fleet. You can flag a collier as being at one of seven ordnance transfer statuses; None, Load Fleet, Replace Fleet, Remove Fleet, Load Sub-Fleet, Replace Sub-Fleet, Remove Sub-Fleet.

When this flag is set to Load Fleet or Load Sub-Fleet, each collier will load ordnance into the magazines of non-colliers within its own fleet (or sub-fleet) as that fleet continues with its normal orders (the transfer itself is not an order). Essentially, the collier will keep the fleet's magazines topped up. The rate of ordnance transfer will be based on the ordnance transfer system of the collier multiplied by the parent race’s underway replenishment tech (unless the fleet is stationary). The missiles being loaded will be based on what is missing from the ship's magazine when compared to the class loadout, starting with the largest missiles first (although smaller missiles will be loaded if there is insufficient time in the sub-pulse to load a larger one). However, missiles will only be added using this order and missiles that do not match the current class loadout will not be removed.

When this flag is set to Replace Fleet or Replace Sub-Fleet, each collier will remove any missiles that do not match the current class loadout and replace them with those from the class loadout (assuming the collier has a sufficient stockpile) for any non-colliers within its own fleet (or sub-fleet) . The collier will remove non-loadout missiles from the target ship while it has magazine space remaining, then add class loadout missiles to create space. Essentially, the collier will alternate loading and unloading as necessary to create the correct loadout.

When this flag is set to Remove Fleet or Remove Sub-Fleet, the collier will unload all missiles from non-colliers within its own fleet (or sub-fleet), as long as it has space to store them.

The current ‘Provide Ordnance to Fleet’ order has been replaced with several new orders to facilitate the above. These include:

Join and Add Ordnance to Fleet
Join and Add Ordnance to Sub-Fleet
Join and Replace Ordnance in Fleet
Join and Replace Ordnance in Sub-Fleet
Join and Remove Ordnance from Fleet
Join and Remove Ordnance from Sub-Fleet

The fleet containing the collier will become part of the target fleet and switch to an appropriate ordnance transfer status depending on the order. You can also use an 'Absorb' order to collect a collier with an existing status set. I may look at adding ship-level conditional orders (rather than fleet) so that colliers/tankers can detach when empty and return home without player supervision.

A new 'Load from Ordnance Transfer Hub' order has been added. This order requires a second fleet containing at least one ordnance transfer hub as the destination. On arrival, any ships in the fleet with magazines will receive ordnance according to their class loadouts until all magazines are full, or the ordnance transfer hub runs out of ordnance. No ordnance will be removed by the hubs. All ships in the fleet will receive ordnance, including colliers. Once completed, the fleet will move on to its next order. If the fleet containing the ordnance transfer hub has any movement orders, the ordnance transfer will not take place and the ordnance transfer order will be marked as completed. Multiple hubs in the target fleet will not increase the rate of ordnance transfer but they can all contribute ordnance.

A new 'Replace at Ordnance Transfer Hub' order has been added. This order functions in a similar way to above except that any ordnance not in the class loadout will be removed by the hubs. The mechanics of this process are the same as the ordnance transfer within fleets above.

A new 'Unload to Ordnance Transfer Hub' order allows colliers to deliver ordnance to the hubs.

The existing ‘Load Ordnance from Colony’ order will remain but can only be used at colonies that have either a Spaceport or an Ordnance Transfer Station. On arrival, the fleet will receive ordnance until all its magazines are full, or the colony runs out of appropriate ordnance. All ships in the fleet will be receive ordnance, including colliers. Once completed, the fleet will move on to its next order. Multiple spaceports or ordnance transfer stations at the colony will not increase the rate of ordnance transfer.

The 'Unload Ordnance to Colony' order also remains but can only be used at colonies that have either a Spaceport or an Ordnance Transfer Station.

Any order involving the transfer of ordnance to or from a colony or ordnance transfer hub will use the current racial ordnance transfer tech to determine the rate of transfer.

Note this means that significantly more planning will be required in this version of Aurora to ensure missile-armed ships can be reloaded at the frontier. It will no longer be possible to dump ordnance on the nearest available rock. Colonies will require a spaceport or an ordnance transfer station before they can support missile-armed fleets. Alternatively, colliers can accompany fleets, or a deep space base with an ordnance transfer hub can be established.
The following users thanked this post: MarcAFK

3
Aurora Suggestions / Re: More secondary commander naming themes?
« on: July 03, 2017, 12:06:23 PM »
A "United Nations" commander theme would be nice to have. The US theme provides some variety, but Chinese, Indian, African, and South/Pacific Asian names are underrepresented there for the purpose of reflecting a world government. The theme-switching suggested previously doesn't seem like it would quite shuffle the deck enough to get a consistent mix rather than small gluts of similar names.
The following users thanked this post: MarcAFK

4
C# Aurora / Re: Release date?
« on: June 01, 2017, 03:52:10 PM »
Still no idea on release date. Hardly did anything in April but back on track recently. I am going to work on missile and turret design next, then probably the new game window. Still not even looked at detection or combat or the galactic map and a lot of the movement orders are not done. However, I am away a lot in June so not much progress then either. My plan is to try to start a test game before the end of the summer, even if a good chunk of the game isn't there yet. Playing will motivate me to fill in the missing pieces :)

In terms of a finished game, my latest guess is late this year or early next.
The following users thanked this post: MarcAFK

5
C# Aurora / Re: C# Aurora Changes List
« on: May 28, 2017, 07:16:09 AM »
Missile Engines

In C#, Missile Engines follow the same size-based fuel consumption rules as Ship Engines using the formula: SQRT (10 / Engine Size in HS)

The above increases the fuel consumption of missile engines based on size alone. However, VB6 also had a flat x5 multiplier for the overall fuel consumption for missile engines as they were treated as a different engine type than ship engines. As C# is aiming for consistency between ship and missile engines, this x5 multiplier cannot remain as it was before. Removing the x5 multiplier entirely would cancel out the fuel consumption increase resulting from the changes in the size-based fuel consumption calculation. As one of the objectives of C# is a reduction in missile ranges, a new rule is required that increases fuel consumption but that is still consistent with ship engines.

Therefore, the calculation for fuel consumption based on boosting engines will now include an additional multiplier if the boost being used is higher than the maximum racial boost tech. Only missile engines have the capability to use higher boosts than the racial maximum, so this still allows consistency between ship and missile engines in the spectrum where they both operate. Once you move outside of the boost range possible for ships, additional fuel consumption can be added without breaking consistency. This rule adds a linear multiplier from 1x to 5x depending on the level of boost beyond the racial maximum. The formula is as follows:

if Boost Used > Max Boost Multiplier Tech then
      High Boost Modifier = (((Boost Used - Max Boost Multiplier Tech ) / Max Boost Multiplier Tech) * 4) + 1;

So if a race has Max Boost Tech of 2x, any missile with a Boost Level of 2x or less will use the standard boost fuel modifier calculation of Boost Level ^ 2.5.

Above a Boost Level of 2x, the linear High Boost Modifier will come into effect, reaching a maximum of 5x fuel consumption at 4x Boost Level.

Here is a comparison between VB6 and C# using MPD engines and an engine size of 1 MSP. The Max Boost Tech for this race is 2x:


VB6 Missile Engine with 2x Boost
Engine Power: 1.6      Fuel Use Per Hour: 81.51 Litres
Fuel Consumption per Engine Power Hour: 50.944 Litres
Engine Size: 1 MSP      Cost: 0.4
Thermal Signature: 1.6
Materials Required: 0.4x Gallicite
Development Cost for Project: 80RP

C# Missile Engine with 2x Boost
Engine Power 1.60      Fuel Use Per Hour 76.8 Litres
Fuel Consumption per Engine Power Hour 48.0 Litres
Size 1.00 MSP  (2.5 tons)      Cost 0.80
Development Cost 80 RP

Materials Required
Gallicite  0.80


VB6 Missile Engine with 4x Boost
Engine Power: 3.2      Fuel Use Per Hour: 922.18 Litres
Fuel Consumption per Engine Power Hour: 288.182 Litres
Engine Size: 1 MSP      Cost: 0.8
Thermal Signature: 3.2
Materials Required: 0.8x Gallicite
Development Cost for Project: 160RP

C# Missile Engine with 4x Boost
Engine Power 3.20      Fuel Use Per Hour 4344.5 Litres
Fuel Consumption per Engine Power Hour 1357.6 Litres
Size 1.00 MSP  (2.5 tons)      Cost 1.60
Development Cost 160 RP

Materials Required
Gallicite  1.60
The following users thanked this post: MarcAFK

6
C# Aurora / Re: C# Aurora Changes Discussion
« on: May 28, 2017, 06:50:29 AM »
With the above in mind, I have added the following to the missile engine fuel efficiency calculation

if Boost Used > Max Boost Multiplier Tech then
      High Boost Modifier = (((Boost Used - Max Boost Multiplier Tech ) / Max Boost Multiplier Tech) * 4) + 1;

So if a race has Max Boost Tech of 2x, any missile with a Boost Level of 2x or less will use the standard boost fuel modifier calculation of Boost Level ^ 2.5.

Above a Boost Level of 2x, the linear High Boost Modifier will come into effect, reaching a maximum of 5x fuel consumption at 4x Boost Level.

Here is a comparison between VB6 and C# using MPD engines and an engine size of 1 MSP. The Max Boost Tech for this race is 2x:


VB6 Missile Engine with 2x Boost
Engine Power: 1.6      Fuel Use Per Hour: 81.51 Litres
Fuel Consumption per Engine Power Hour: 50.944 Litres
Engine Size: 1 MSP      Cost: 0.4
Thermal Signature: 1.6
Materials Required: 0.4x Gallicite
Development Cost for Project: 80RP

C# Missile Engine with 2x Boost
Engine Power 1.60      Fuel Use Per Hour 76.8 Litres
Fuel Consumption per Engine Power Hour 48.0 Litres
Size 1.00 MSP  (2.5 tons)      Cost 0.80
Development Cost 80 RP

Materials Required
Gallicite  0.80


VB6 Missile Engine with 4x Boost
Engine Power: 3.2      Fuel Use Per Hour: 922.18 Litres
Fuel Consumption per Engine Power Hour: 288.182 Litres
Engine Size: 1 MSP      Cost: 0.8
Thermal Signature: 3.2
Materials Required: 0.8x Gallicite
Development Cost for Project: 160RP

C# Missile Engine with 4x Boost
Engine Power 3.20      Fuel Use Per Hour 4344.5 Litres
Fuel Consumption per Engine Power Hour 1357.6 Litres
Size 1.00 MSP  (2.5 tons)      Cost 1.60
Development Cost 160 RP

Materials Required
Gallicite  1.60

The following users thanked this post: MarcAFK

7
The Academy / Re: Population vs Wealth
« on: April 19, 2017, 06:12:59 PM »
I wish financial centers were transportable like other installations are.  Then you could just fill up your terraformed but mineral-less worlds with financial centers built elsewhere, and plunk a wealth bonus leader on them.  Pretend the whole planet is a giant call center, cold call selling products made elsewhere to markets all over your empire. ;)

I can see it now...

"Sir! The invading aliens have scoured Telemarketing II to bedrock!"

"Well, they should have abided by the No Call List."
The following users thanked this post: MarcAFK

8
Aurora Chat / The GRAND AURORA TOURNAMENT
« on: April 03, 2017, 02:55:49 AM »
Not sure where else to put this, but. . .

Attention all Fleet Designers and God Emperors of Mankind!

Getting tired of the same old enemies? Want to see how your fleet ACTUALLY compared against other people's? Well then now's your chance!

Within the next 2 months, I will be running the (to my knowledge) first ever Grand Tournament for Aurora 4X.  All are welcome, see the rules below:

All competitors will have a certain amount of BP to spend (to be decided in a few days).  You don't have to spend it all, but you are not allowed to go over.
The competition will be in a standard Sol system.
Tech levels available to each competitor will be posted along with the BP limits soon.
Each competitor can select a system body to serve as a supply base - this base will have unlimited (will possibly change) fuel, ammunition and supplies, but no other structures.  If you build a PDC on it, the cost comes out of your BP budget.  Your fleet will also be spawned from there.
Each competitor will know the general direction of the other player's base at the start of the match (though this may change due to orbits).
I will operate the game and stream (if I can work out how without giving away info, otherwise just record instead)/report events to their respective players.  A neutral party will do this for matches I am involved in.
Cheesy ship designs and combos (such as chained tractor beam ships), or things that exploit known bugs and issues will not be allowed - specific semi-cheesy mechanics may be allowed, ask in the comments if you're not sure.
Finally, all competitors must have fun!

Rewards will be the satisfaction of domination and victory over the competition, unless someone wants to pitch in something more material.

Comment if you're in and watch this space for more information over the next few days!
The following users thanked this post: MarcAFK

9
Mechanics / Re: Bridge Officers
« on: March 12, 2017, 11:57:16 AM »
What if the bridge would become an automaticly scaling component like armor, changing size dependent on size of the vessel or the amount of crew members onboard?

Or the other way around, bonuses provided by officers are divided by vessel size or number of crew members. To compensate, one could install more bridge space, therefore providing space for more officers, whose bonuses add up? That way, huge battleships would house dozens of officers, and tiny ships just one, but on average, one officers gives bonusses to the same mass of ship.

I am going to add Auxiliary Control, Main Engineering, CIC, Primary Flight Operations and Science Department as new modules. Each one makes a different officer available to be recruited to the ship (XO, Chief Engineer, Tactical Officer, Commander Air Group and Science Officer) and will add 1 to the Control Rating of the ship. These requirements add the effect of larger control spaces while maintaining some variety. An officer can be killed if his station is damaged. I may also add 'temporary promotions' if the commander is killed, with the most senior surviving officer taking over as commander until relieved or promoted. The modules will also affect the minimum commander rank for the ship.

I am also going to change how certain bonuses are applied. The commander of a ship will only apply half his bonus for Crew Training, Survey, Fighter Operations, Engineering (new skill) and Tactical (new skill), with the appropriate officer applying his full bonus. The commander of the ship is now a jack-of-all-trades, applying a portion of his bonus while the specialists provide the larger bonuses. Larger ships gain an advantage as they can afford the space to accommodate the specialists, while smaller ships have to make do with the commander handling everything (at half efficiency).

A bonus from the Chief Engineer will only apply if Main Engineering is undamaged. A bonus from the Science Officer will only apply if the Science Department is undamaged. A bonus from the Tactical Officer will only apply if CIC is undamaged. A bonus from the Commander, Air Group will only apply if Primary Flight Operations is undamaged. Bonuses from the commander and XO will only apply if the ship has a control rating greater than zero (they can command the ship from any of the surviving control spaces).

If this works OK, I might add other officers in the future and modify other bonuses in the same way.
The following users thanked this post: MarcAFK

10
Engine secondary explosion strength is random between 1 and 25% of engine power.
The following users thanked this post: MarcAFK

11
C# Aurora / Re: Aurora C# Screenshots
« on: December 16, 2016, 07:22:45 AM »
I think it's about time for some more screenshots soon. How about an early Christmas gift for us in the form of a few Screenshots or update?  :)

I've been working on mainly back-end code, movement orders and system generation recently. I've successfully tested the exploration of an unexplored jump point, although full system generation isn't done yet. Should be finished over Xmas though.
The following users thanked this post: MarcAFK

12
C# Aurora / Re: C# Aurora Changes List
« on: October 06, 2016, 04:05:08 PM »
Standard transits by Fleets with Commercial and Military Ships

In VB6 Aurora, fleets that included at least one ship with military engines could only use military jump drives for standard transits, which meant you had to split out commercial-engined ships into a separate fleet and escort them with a commercial jump drive ship.

In C# Aurora, commercial-engined and military-engined ships are treated separately. So if you have a fleet with mixed engine types that also includes ships with commercial and military jump drives, it will still carry out a standard transit if the respective jump drives are large enough for the ships with the matching respective engine types. However, if any ship with either engine type can't jump, the whole fleet will fail to transit.

Squadron jumps are handled differently so I will cover that in a separate post.
The following users thanked this post: MarcAFK

13
C# Aurora / Re: C# Aurora Changes List
« on: October 05, 2016, 03:50:47 PM »
Assignment of Ships to Populations

In VB6 Aurora, ships such as terraformers or asteroid miners have to be assigned to populations in order to provide that population with any applicable production. This is because an empire may have multiple populations on the same world and the ships can only provide support to one of them. When a fleet reaches a population, the ships within it are automatically assigned. However, there are still situations (such as transferring between fleets) when this assignment is not always picked up. While the problem can easily be fixed by ordering the fleet to the population, it is not always obvious it needs to be fixed. This can lead to ships sitting idle in orbit.

In C# Aurora, the assignment to the population will be at the fleet level, rather than by ship, and the same auto-assignment will happen when a fleet moves to a population. However, when a population checks orbital space for any assigned fleets during production, it will automatically grab any unassigned fleets in orbit and assign them to itself. This should avoid any situations where ships remain idle.
The following users thanked this post: MarcAFK

14
C# Aurora / Re: C# Aurora Changes List
« on: October 02, 2016, 03:17:13 PM »
Refuelling Changes

In C# Aurora, refuelling is no longer instant and ships without specialised equipment cannot exchange fuel in space. A ship can only refuel at a Spaceport, a Refuelling Station, a ship with a Refuelling System or a base with a Refuelling Hub.

A new technology line - Refuelling Systems - provides the basis of the rate of refuelling and allows ships to mount systems to refuel other ships. The baseline system (Refuelling System: 50,000 LPH) sets the racial refuelling rate at 50,000 litres per hour and allows the use of the first ship-mounted Refuelling System. There are ten further steps in the tech progression with the highest tech system allowing refuelling at 500,000 litres per hour.

Spaceports, Refuelling Stations or Refuelling Hubs will always use the highest tech refuelling rate and can refuel an unlimited number of ships simultaneously. However, the ships being refuelled must be stationary.

Spaceports have doubled in cost to 2400 BP but can now be moved by freighters. They are equal to four research facilities for transport purposes (or 80 factories). They retain their existing bonuses to loading and unloading cargo.

Refuelling Stations are a new installation with a cost of 1200 BP. They do not require workers and can be moved by freighters. They have a transport size equal to 10 factories. Essentially, they are a cut-down version of a spaceport intended to facilitate refuelling in forward areas, transferring fuel from the surface of a planet to the waiting ships. They have no bonuses for loading or unloading cargo.

A Refuelling Hub can be mounted on a ship. It is a commercial system with a research cost of 10,000 RP, build cost of 2400 BP and a size of 100,000 tons. In practical terms, this is likely to form part of a large, deep-space station, due to the size and cost, rather than being deployed on tankers that will accompany fleets

A Refuelling System is 500 tons and has a cost ranging from 10 BP to 100 BP, depending on the tech level. A ship with a Refuelling System can refuel a single ship at once, so will take some time to refuel a whole fleet, although this will improve with higher technology. At the early tech levels, the Refuelling System can only be used if both ships (tanker and target ship) are both stationary. Another new tech line, Underway Replenishment, allow the refuelling to take place while both ships are in the same fleet and underway. Priorities can be set for the refuelling order when multiple ships are involved. The first Underway Replenishment tech allows refuelling at 20% of the normal rate (2500 RP), rising to 100% with the highest tech (40,000 RP).

Refuelling order types will be adjusted to deal with the new requirements. Fuel will be transferred during each movement increment as time passes until the target ship has full tanks. I may add some other options regarding partially filling as well.

I will be adding some rules along the same lines regarding ordnance transfer.
The following users thanked this post: MarcAFK

15
C# Aurora / Re: C# Aurora Changes List
« on: October 02, 2016, 12:18:16 PM »
Load & Unload Cargo

In VB6 Aurora, ships load or unload cargo, colonists, etc. on arrival and then undergo a wait period before their next order (based on how long it takes for the load/unload process).

In C# Aurora, the wait period will take place first and then the cargo will be loaded or unloaded at the end. Because of this change, if the fleet abandons the order before it is complete, no transfer of cargo will have taken place.
The following users thanked this post: MarcAFK

Pages: [1] 2 3 4