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
1
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

2
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

3
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

4
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

5
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

6
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

7
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

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

9
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

10
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

11
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

12
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

13
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

14
C# Aurora / Re: C# Aurora Changes List
« on: October 01, 2016, 06:34:44 PM »
Shipping Line Earnings and Tax

For C# Aurora, the distance a civilian ship has travelled (in terms of systems) will affect how much the shipping line receives in payment and how much tax is generated.

All VB6 payment rates will be halved as a baseline but multiplied by the number of systems travelled. So a civilian ship travelling to a destination two transits away will receive the same payment as in VB6 Aurora. A ship travelling to a destination five transits away will receive 250% of the current payment. This applies to trading and to player contracts.

A civilian ship travelling within the same system will be paid half of the one-system rate (which is half what is currently paid in VB6).

This should reduce some of the early game bloating of civilian traffic but make it workable for the later game with longer distances (especially with the new jump point generation in v7.1 of VB6 Aurora).
The following users thanked this post: MarcAFK

15
C# Aurora / Re: C# Aurora Changes List
« on: September 25, 2016, 10:17:22 AM »
Naval Organization

Instead of the Task Forces and Task Groups in VB6 Aurora, C# Aurora takes an approach similar to the optional functionality of the VB6 Naval Organisation tab, albeit with much easier and more flexible UI. There are four primary components of Naval Organisation; Admin Commands, Fleets (VB6 Task Groups), Sub-Fleets and Ships. Every race starts with a single top level Admin Command (which can't be deleted but can be renamed). All other Admin Commands descend in a tree from this one. You can only attach an Admin Command to another Admin Command but you can have an unlimited number of levels in the Admin Command hierarchy.

Fleets can only be attached to Admin Commands. Many fleets can be attached to the same Admin Command but each fleet can only be attached to one Admin Command

Sub-Fleets can only be attached to a Fleet, or to another sub-fleet. You can have an unlimited number of levels within the sub-fleet hierarchy. These are used to organise the ships within the larger fleets. Sub-fleets have no on-map function and all ships within the sub-fleet hierarchy move within the parent fleet. You can detach a sub-fleet, at which point it becomes a full fleet in its own right. Any sub-fleets further down the sub-fleet hierarchy become sub-fleets of this new fleet. A new 'join as sub-fleet' order is available. When one fleet joins another using this order, its ships will automatically form a sub-fleet within the joined fleet, allowing them to subsequently detach as a whole unit.

A Ship can be attached to a Fleet or to a sub-fleet. When attached to a sub-fleet, it is still a member of the parent Fleet at the top of the sub-fleet hierarchy.

The sidebar tree of the new Naval Organisation window (see Screenshots thread) has full drag and drop functionality so you can move Admin Commands, Fleets, Sub-Fleets and Ships around as long as the above rules are followed. You can also drag ships and sub-fleets between different fleets as long as they are in the same physical location. Entire sections of the tree can be moved with a single drag-drop. Also, you can open up multiple Fleet windows and drag and drop between the trees in two different windows.

The following users thanked this post: MarcAFK

Pages: [1] 2 3