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

Pages: [1] 2 3 4
C# Aurora / Re: danger ratings for systems
« on: Today at 09:53:40 AM »
Well, there's two problems here. The first is that for some systems you really want to more or less indefinitely keep them from being used by civilians. Like with Jumpgate linked systems when there's [spoilers] or an NPR making a mess of it when you've got colonies at either end. It would be inconvenient to have half your civilian cargo fleet commit suicide because the danger rating lapsed but you haven't managed to clear out the threat.

That could be handled by having danger rating not reduce automatically, but only when your own warships are in the system and there is no sign of enemy contacts. So you have to be in effective control for a while before civilians would consider entering.
The following users thanked this post: TMaekler

C# Aurora / Re: C# Aurora Changes List
« on: Yesterday at 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
The following users thanked this post: TMaekler

C# Aurora / Re: C# Aurora v0.x Suggestions
« on: February 21, 2018, 12:28:06 PM »
I would like to suggest a new way to exploit distant binary systems.

As we know, hyperdrive didn't really work that well and was removed. Frankly, I do not want to see it back, it would probably still be problematic. That, and having to have a new, different engine for all ships required to make the trip between the distant companions would be problematic.

I think a much more elegant and "realistic" solution would be, after researching an appropriate technology, the possibility to build in-system gates between stars. You could justify it as a technology that "replicates the natural lagrange points", only that because of the imperfect results due to it being artificial, it requires the mass of a star.

Mechanically, it would be similar to the already present gate constructors. You would build a "lagrange constructor" ship, with the appropriate module. Send it to a star. Order a "build gate to <other star in system>" command, and then wait until it is complete. That would create a one-way gate, as for the other normal type of system-to-system gates. If you want  a two-way artificial lagrange point, you would send the constructor to the other side and build the gate on that side as well.

I hope that this solution would be relatively simple to implement, and once it's done it can work with the already present code for routing ships. And it would allow to finally use systems with distant stars companions.
The following users thanked this post: TMaekler

C# Aurora / Re: C# Aurora Changes List
« on: February 21, 2018, 07:40:50 AM »
Default Order for Unload Colonists

I've completely rewritten the default order for unloading colonists (used by shipping lines, NPRs and your own ships if desired). The process is as follows:

1) Colony fleet looks for a suitable population with less than 25m pop and no other colony fleets inbound, checking its current system first and then using the path finding algorithm to search everywhere else in the empire.
2) Same as 1) but without the check for inbound colony ships.
3) Searches for any suitable population with a status of Colonist Destination (which you can set for any pop of at least 25m).

When determining if a population is a suitable destination, the fleet checks the following:

1) How many colonists it is carrying.
2) If the species is the same as the colonists.
3) The available capacity of the system body on which the population is situated, taking into account other populations.
4) The available capacity of the infrastructure (normal or LG depending on the gravity), taking into account the current population size.
5) The lesser of 2) and 3) is used as the base capacity of the population to accept new colonists.
6) Any available space in orbital habitats is added to that capacity.
7) The total number of colonists on ships already inbound to the colony is deducted from that capacity.
8) if the capacity exceeds the number of colonists in the checking fleet and the species match, the colony is suitable.

This should prevent the current problem of many colony ships delivering to a colony without the capacity to support them all. As soon as a fleet determines a colony is suitable, the orders are issued, which means other fleets checking in the same increment will be aware of the extra inbound colonists.

Because of these changes, Passenger Liners will no longer search their current system for a potential destination (otherwise they could load and unload at the same population).
The following users thanked this post: TMaekler

C# Aurora / Re: C# Aurora Changes Discussion
« on: February 19, 2018, 04:19:43 AM »
Minor milestone - a geosurvey ship just executed the first default order in C# Aurora.

Well into the default orders code now, which is one of the major areas remaining. As a side-benefit of completely rewriting the path-finding code, you will have the ability to pick a system from a list on the fleet orders window and have the game plot all the jumps for you (including using Lagrange points). I'll do the same for populations and way points.
The following users thanked this post: TMaekler

C# Aurora / Re: C# Aurora Changes Discussion
« on: February 10, 2018, 09:52:29 AM »
As another minor QOL suggestion, I wonder if it would be better for the "total accessibility" box in the mining tab to be changed to display the actual total of the accessibility of the planets minerals, rather than the average. This would help show at a glance the number of total minerals that a planet could produce. I would argue that this is more useful than the average accessibility, which does not take into account the effects of having different kinds of minerals. A planet with a single mineral at 1.0 accessibility would have an average accessibility of 1.0, the highest possible, even though another planet with a lower average accessibility but more types of minerals might produce far more minerals in total, with the same number of mines.

Good idea. I have made that change.
The following users thanked this post: TMaekler

The Academy / Re: Ranks of Staff Officers
« on: February 09, 2018, 10:56:29 AM »
The staff officer positions are a Maximum rank of 1 less than the commanding officer.
The following users thanked this post: TMaekler

C# Aurora / Re: Selecting Commanders Screen Suggestion
« on: February 03, 2018, 05:13:29 PM »
I think the new Commanders window has some of what you are looking for. You can compare commanders based on four different bonuses.
The following users thanked this post: TMaekler

C# Aurora / Re: Custom game setups - tech
« on: December 23, 2017, 07:38:43 AM »
For C#, it would be relatively easy to setup an SM Tech Control Window where you could flag techs as available, ruin-only or not available.
The following users thanked this post: TMaekler

C# Aurora / Re: C# Aurora Changes Discussion
« on: September 01, 2017, 09:30:50 AM »
Question on Commander Careers:
The automatic assignment in VB6 often switched officers between the same spot on identical ships or offices - which I always found to be a bit strange. Is there a way to include a routine which checks if an officer was assigned to one spot on ship A and if he is auto-assigned to the same spot on ship B that he is kept on ship A?

The problem occurs because in VB6 officers are unassigned after a fixed period of time (the tour length). That doesn't happen in C#.

In C#, an officer will only undergo auto-assignment if he is currently unassigned, or he is a junior officer moving to a ship command position, or he had to leave his old command because he was promoted. In all those cases, the new assignment cannot be similar to his previous assignment.
The following users thanked this post: TMaekler

C# Aurora / Re: Aurora C# Screenshots
« on: August 06, 2017, 09:47:08 AM »
Another update.

The Detection code is now complete. I actually finished it a week ago but had a performance bug that took some time to pin down. It isn't really possible to do a direct comparison to VB6 as VB6 loads everything into memory at the start of each increment while C# already has everything in memory. However, if we compare a single sub-pulse within a 5-day increment from the start of actual detection (i.e. everything already loaded into memory in both versions), then C# seems to be about 10-20x faster.

The worst situation for VB6 in terms of comparison is a single 5 second increment, as VB6 Aurora has to load everything before running a turn. In my current campaign (23 races, 500 systems, 2300 ships, 345 populations, 46 shipping lines) with detection switched off in Sol, it takes VB6 52 seconds to run a 5 second increment (and this is why I am now rewriting in C# :) ).  C# Aurora isn't using AI yet and not all movement orders are operational, plus a few other items aren't running. However, it is running full detection and it runs the whole 5 second increment in 0.7 seconds, which is very encouraging.

To make it a little more interesting, if I let C# Aurora run a full construction cycle during that 5 second increment, which includes orbital movement, harvesters, terraforming, mining, pop growth, factory production, shipbuilding and shipyard upgrades, ground unit training, new shipping line ships, civilian mining, research, genetic conversion, refining, maintenance, wealth calculation and trade, then the increment takes 2.6 seconds.

Even though there is still a lot of work to do, I think it is safe to say at this stage that there will be a substantial increase in performance for C# Aurora.
The following users thanked this post: TMaekler

C# Aurora / Re: Aurora C# Screenshots
« on: July 22, 2017, 07:11:41 PM »
Below is the Combat section of the Naval Organization window. This replaces the combat overview window.

This new version is much cleaner and more user-friendly than the VB6 equivalent, with most functions handled via drag and drop. You can drag and drop weapons, targets, ECCM systems and point defence modes directly on to fire controls. Missiles are dragged on to missile launchers. Any assigned targets and point defence modes are listed below the fire control, before the assigned weapons. If you click 'Drag All', dragging a single weapon will drag all weapons of that type in the same location to the new location. Similarly, dragging a single missile will equip all launchers under the same fire control. You can also drag to and from Unassigned Weapons and Unassigned ECCM.

Potential targets are listed by alien race.

The Assign buttons on the right allow you to copy the complete combat setup for the selected ship to all other ships of the same class, or just those within the same sub-fleet, fleet or system.

There are also buttons for activating sensors, raising & lowering shields and firing using either a single fire control or all of them.

This screenshot shows a more developed naval organization on the left. On the right, note that when a fire control is given the order to fire it is displayed as Orange instead of Green.

A couple more to show different layouts

The following users thanked this post: TMaekler

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: TMaekler

C# Aurora / Re: Aurora C# Screenshots
« on: March 19, 2017, 09:35:08 AM »
Will we be able to add rules for Auto Assignment? Would be nice for planetary governors to be able to define a rule as to what kind of attributes you want the local governor to have and then let the auto assign do that job for you... .

VB6 Aurora doesn't handle auto-assignment for planetary governors, although I am considering it for C# Aurora. I'm not sure rules would work as you intend though. It would probably be easier to use the search functionality and choose your governor than set rules for each individual population. There is also a lot more intelligence required in terms of assessing the weight of different bonuses compared to the needs of each pop.

The following users thanked this post: TMaekler

C# Aurora / Re: C# Aurora Changes List
« on: March 18, 2017, 11:55:06 AM »
Command & Control Rules

I am introducing new command and control rules for C# Aurora. The commander of a ship will only apply half his bonus for Crew Training, Survey, Fighter Operations, Engineering (new skill) and Tactical (new skill). However, additional officers can be assigned to the ship with each officer applying his full bonus for his chosen speciality (more on that later). 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). Any bonuses not mentioned here (such as Reaction or Production) will still be at full value for the commander.

Five new command and control modules have been added, the cost of the bridge has been doubled and the role of the flag bridge has been changed. Each module adds one to the Control Rating of the ship.

1) Bridge is 1 HS and costs 20 BP. Minimum rank for the ship commander is the racial minimum.

2) Auxiliary control is 1 HS and 15 BP. Allows the assignment of an Executive Officer to the ship who will apply his full Crew Training Bonus. Minimum rank for the ship commander is one above the racial minimum.

3) Science Department is 2 HS and 50 BP. Allows the assignment of a Science Officer to the ship who will apply his full Survey Bonus. Minimum rank for the ship commander is one above the racial minimum.

4) Main Engineering is 3 HS and 75 BP. Allows the assignment of a Chief Engineer to the ship who will apply his Engineering Bonus to affect maintenance and damage control. Minimum rank for the ship commander is two above the racial minimum.

5) Combat Information Centre (CIC) is 3 HS and 75 BP. Allows the assignment of a Tactical Officer to the ship who will apply his Tactical Bonus to various combat-related function (TBD). Minimum rank for the ship commander is two above racial minimum.

6) Primary Flight Control is 4 HS and 100 BP. Allows the assignment of a Commander Air Group to the ship who will apply his full Fighter Operations Bonus. Minimum rank for the ship commander is one above the racial minimum.

7) Flag Bridge is 5 HS and 125 BP. A fleet that includes a ship with a flag bridge can assign a 'fleet commander' senior to the commander of the ship. If a fleet has multiple flag bridges, the most senior officer assigned to any of them will be the fleet commander. The fleet commander will improve the fleet's overall reaction rating by his Reaction Bonus. If there are no flag bridges in a fleet, the senior ship commander will be the de facto fleet commander, but his reaction bonus will not affect other ships. Minimum rank for the ship commander of the ship with the flag bridge is two above the racial minimum. There are no longer any task forces or staff officers. Any commander assigned to a flag bridge who is not the most senior in the fleet will be referred to as a 'Flag Officer'.

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.

Except for the ship commander and the executive officer, the bonus from each specialist will only apply if their associated module 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). Ships smaller than 1000 tons automatically have a control rating of 1, even without a bridge. This is to simulate that small ships do not require a dedicated centralised command function.

I don't plan to scale the modules to ship size or add extra crew. That would add extra complexity and make designing ships more difficult. For small ships, most command and control modules won't be used, and once you get past a certain size of ship, they will probably all be used. I am not trying to create a decision as to whether a battleship should have a CIC or Main Engineering, but rather to create meaningful choices for mid-range ships.

For auto-assignment purposes, each ship class now has a specific rank requirement for its commander, based on its command and control modules. The rank requirement for the XO, CAG and Science Officer is one lower than for the ship commander. The rank requirement for the Chief Engineer and Tactical Office is two lower than the ship commander. The rank requirement for a fleet commander is one higher than for the ship commander. You can manually assign higher-ranked ship commanders and fleet commanders if desired but other officers can only be assigned at the specified rank. The commander priority setting for each class of ship remains as before and is still set manually. It also applies to the other officer types as well. Auto-assignment will work in the following sort order:

1)   Class Priority
2)   Survey Ships by descending size
3)   Warships by descending PPV
4)   Unarmed Military Ships by descending size
5)   Construction Ships by descending construction speed
6)   Terraformers by descending terraforming capacity
7)   Sorium Harvesters by descending harvesting capacity
8)   Asteroid Miners by descending mining capacity
9)   Salvage Ships by descending salvage capacity
10)   All other ships (primarily freighters and colony ships) by descending size

Ship commanders will be assigned first (checking every category above), followed by executive officers, science officers, air group commanders, chief engineers and tactical officers. The ships will cycle through in priority order and commanders will be assigned if they meet the criteria for the ship type (correct rank and suitable bonus).

These changes should make ship design more interesting, create better histories for commanders (as they progress through different roles) and provide lots of potential roles for the junior commanders.
The following users thanked this post: TMaekler

Pages: [1] 2 3 4