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.

Topics - Steve Walmsley

Pages: [1] 2 3 ... 33
Off Topic / Aurora Steve
« on: March 16, 2018, 04:01:42 AM »

C# Aurora / Magazine Explosions
« on: March 11, 2018, 06:52:22 PM »
In VB6 Aurora, if you have a magazine explosion it only uses 20% of the warhead strength. I am considering using 100% for C# Aurora. It is certainly more dramatic, adds more of an incentive to consider magazine design and reduces the advantages of missiles vs beams.

For both VB6 and C#, the only missiles that can explode are those that exceed the remaining total magazine capacity. So if the current missile load is less than the post-damage magazine capacity, there won't be an explosion.

C# Aurora / Default Orders for Harvesters and Miners
« on: February 22, 2018, 10:53:07 AM »
I've almost completed writing the default orders code (and associated path finding). There are one or two new orders, such as "Move to System Requiring Geosurvey", which you can set as a secondary order for "Survey Next Five System Bodies" (for example) and you no longer have to worrying about moving Geosurvey ships between systems. There is an equivalent for gravitational surveys. All the path finding takes into account whether the fleet is jump capable, the presence of jump gates and any danger ratings for systems.

Which leads me to "Move to Gas Giant with Sorium" and "Move to Mineral Source" (the latter being mainly for NPRs and the former for civilians and NPRs, although they are open to the player). The issue is (in both VB6 and C#) that default orders cause an order to be created when the fleet has no existing orders. However, that means whenever the fleet reaches the target, the default is triggered again (and again, and again). It isn't visible to the player because it is all happening behind the scenes.

So, when those two default orders get completed I am going to unset the default orders. Instead, I will add a construction phase check for civilian and NPR harvesters and miners without default orders, so if they are not harvesting / mining anything, the order is re-instated.

The only downside is that players would have to reset the order manually (assuming it is even being used). I'm mentioning that here in case there is an issue I haven't considered.

C# Aurora / Replacing Teams?
« on: February 11, 2018, 07:13:30 AM »
This is a repost from the main VB6 suggestions thread, which triggered an idea.

I could remove the concept of teams entirely and replace them with new ground force capabilities. Thinking out loud....

1) Espionage team replaced by a scout function for ground forces. Scout formations can land on alien worlds to learn about the alien population (size, industry, tech, ground forces). They are have (expensive) stealth capabilities boosted by the formation commander (stealth bonus replaces espionage). They can be hunted by hostile ground forces or have a chance of detection by any civilian population (much higher if not same species). Might even have sabotage capabilities. In fact, this could be the Aurora equivalent of Special Forces.

2) Geology team replaced by geological survey capability for ground forces and ground survey becomes a significantly larger task requiring more personnel - to prevent simply creating vast number of geo-survey formations. Geology bonus based on the formation commander

3) Xenology team replaced by Xenoarchaeology capability for ground forces. Surveying and deciphering alien ruins becomes a significantly larger task requiring more personnel. Xenology bonus based on the formation commander.

4) Diplomacy team replaced by small but expensive ship module that can only function when in the same system as an alien population. I also change NPR responses so that their reaction to alien ships in the system is based on ship size and reduced if the ship has a diplomatic function. Diplomacy skill is based on the ship commander.

C# Aurora / Replacing PDCs
« on: September 18, 2017, 06:05:06 PM »
I posted a comment in the changes discussion thread about removing PDC and enhancing ground forces to compensate. Having given this some thought, it solves a lot of issues in the game that add complexity without really adding a lot in the way of additional game play. PDCs create exceptions for a number of rules, add complexity (in the sense of awkwardness rather than variety) to ground combat and their maintenance-free status can be an exploit. They create a lot of orders and rules around prefabrication and assembly and can't be effectively upgraded.

I've decided to replace them with some additional types of ground forces to improve defences planetary defences and keep all 'ships' in space. This thread is to look at the options for the ground combat enhancements. At the moment I am thinking along the following lines (but I am open to suggestions):

1) A unit with air defence capability that functions as a CIWS for the planet.

2) A unit with similar capability to ship-based energy weapons, designed to fire ground to orbit, rather than ground to ground.

3) Probably adding some basic form of ground unit design rather than having specific unit types. This would include (for example) CIWS techs, ground to orbit techs based on ship-weapons, ground-based attack/defence split into armour and infantry-based techs (based on weapon & armour techs), maybe the bombardment ability of Titans so as an alternative to Titans you could develop different forms of artillery. Concealment tech to make units harder to strike from orbit. 'Garrison' rating separated from defence. 'Movement' tech could be personal armour, tracked vehicles, combat walkers, etc.. A combination of these techs would determine unit cost, size, capability, etc.

4) Troop transport bays and combat drop modules would be for infantry (personal armour) types - a different module would be needed for heavy armour or ground to orbit capable units.

5) The type of planet could affect which units are most effective - specialist units for extreme temperature, or mountainous terrain (based on tectonic rating), or mostly water planets, etc. Terrain would also determine the effectiveness of different movement types.

6) An option to be considered is removing the restriction on energy weapons in atmosphere. Ground units armed with ship-type weapons would become a serious deterrent, especially given they are more dispersed than ships and harder to eliminate. I would need to add rules on destroying installations from orbit, but not sure how much of a problem that is given that most powers want to capture installations rather than destroy them. Energy-armed spacecraft in orbit could be assigned for fire-support missions when assigned to direct support of a HQ unit.

7) Units would not increase in capability with tech and would use the tech at the time of creation. However, units could be converted into a cadre unit (and retain their experience) so they can be used as the basis for a new unit with improved capability.

8) These changes could lead to a paradigm where it is very hard to bombard a well-defended planet from orbit so you (still) have to nuke from a distance and risk environmental and industrial damage, or develop very fast drop pods to get troops to the surface (through defensive fire) to take out the ground-based defences (Hoth).

Comments and suggestions welcome.

C# Aurora / Box Launcher Reloads
« on: July 18, 2017, 05:12:02 PM »
I'm working on the weapon recharge code at the moment and I have run into an issue with reloading box launchers at maintenance facilities.

In VB6, a ship with box launchers has to reload in a hangar bay or at maintenance facilities that are of sufficient size to maintain the ship. However, the maintenance rules have changed in C# Aurora so that the maintenance facilities have to be large enough for all the ships in the same location, or they only be able to provide partial maintenance. This adds a lot of complexities to reloading box launchers.

For example, if multiple ships are reloading at the same location for consistency I should check the facilities are large enough to handle them all. If not, the reload should slow down in proportion. However, that reload could then affect the ability of those maintenance facilities to carry out their normal job of maintenance during the construction phase, as they were using capacity to reload (potentially different) ships - although perhaps not for the whole increment.

Rather than expect the players to try to handle that complexity, I am leaning toward changing the mechanics for reloading box launchers. I have two options at the moment:

1) Reloading box launchers only happens during the maintenance section of the construction phase. This reduces complexity as everything happens at once, so calculating total capacity is straightforward. Also, I am probably going to make the construction phase happen every day, rather than every five days, so this isn't as onerous as it sounds.

2) Remove the ability of box launchers to reload at maintenance facilities, so they can only be reloaded in hangars. This is also a lot easier than it sounds with the introduction of commercial hangars, allowing sizeable deep space bases or support ships. With box launchers available from the start in C# Aurora, this provides a counter-balancing logistical limitation for larger, box launcher-armed ships. This is my preferred option at the moment unless there is a strong argument to the contrary.

The Academy / HELP (Or should I say Ndihmë)
« on: June 01, 2017, 03:47:25 PM »

I went into my profile to change my sadly out of date email address and somehow also changed my preferred language to Albanian :)

Now I have no idea how to change it back because everything is in Albanian!

Could you return me to English (and sanity)

In the meantime, I will try to stay away from any sharp objects...


C# Aurora / Sensor Model for C# Aurora
« on: March 26, 2017, 09:41:34 AM »
As per the recent suggestions in the Aurora Changes Discussion thread, I am looking at a new active sensor model for C# Aurora. There is an issue that active sensor ranges become so huge with large size-50 sensors, that the standard tactic is to create a ship with such a sensor so that it can watch the entire inner system, taking away some of the fog of war. In addition, such extreme-range sensors allow ultra-long range missile combat, giving the race that possesses such sensors a major advantage. The following change is intended to create a situation where:

a) Multiple scouts or pickets become a serious alternative to one huge sensor.
b) Missile combat ranges are reduced
c) Fog of war is increased, leading to more interesting exploration and combat.

The VB6 sensor model is based on the following formula, which increases range in direct relation to sensor strength:

Sensor Range = Racial Sensor Strength * HS * Racial EM Sensitivity * SQRT(Resolution) * 10,000 km

The proposed C# model uses similar basics and leaves all the existing technology in place. However, the sensor strength now has to cover an area rather than a direct range, creating diminishing returns for larger sensors. In addition, the modifier for resolution has been adjusted from square root to the power of (1 / 1.5). Because of this formula, smaller, lower resolution sensors are now more effective than the VB6 equivalents (much more in some cases), making earlier detection of missiles and fighters possible for non-specialised ships. The new formula is:

Sensor Range = SQRT((Racial Sensor Strength * HS * Racial EM Sensitivity * (Resolution ^ (1/1.5)) / PI) * 1,000,000 km

The following screenshots are based on the Commonwealth in my current campaign, which has active sensor strength 21 and EM sensitivity 11.

Mechanics / Bridge Officers
« on: March 11, 2017, 08:31:58 AM »
In C# Aurora I am adding extra officer positions for ships. In addition to the commander of the ship, there will be up to four more officers depending on the size and role of the ship (XO, Chief Engineer, Tactical Officer and Science Officer). I may add more in the future depending on how well this works. Once I have sorted all the details I will post with the specifics of how these officers benefit the ship.

As a result of these changes, I am going to replace the current system for determining the rank for a ship commander. Each class will be assigned a specific rank for the commanding officer (rather than the current range of ranks). The automatic assignments code will only assign officers of that specific rank, although you can override manually with a higher ranked officer if desired. The other officer ranks will be based on the specified commanding officer rank.

For example, the required XO rank for a ship will be one rank lower than the commanding officer. The Tactical Officer will be two ranks lower. These are fixed and can't be manually overridden. I could have based this on one rank lower than the current commander instead (rather than the class) but that could lead to a lot of complications if you manually assign a higher rank commander with an XO one rank lower and then change the commander to a lower but still eligible rank. It will be far better for a consistency POV to have the officer ranks (below the commander) fixed.

If a non-commanding officer is promoted, he will have to leave his position and be assigned a new one (this will be handled automatically). You will be able to see his progression to more senior roles in the commander history.

So a question...

What ranks should I set the Chief Engineer and Science Officers in relation to the commanding officer? As currently setup, science officers can be added to any ship of 3000 tons or more that is equipped with survey sensors. Chief Engineers can be added to military ships (not necessarily armed) of 12,000 tons or more. XO is military 6,000 tons and Tactical Officer is military 18,000 tons.

I currently have science officer set as one below the commanding officer (as they would be important on a survey ship) and chief engineer as two below the commanding officer (so he one below the XO). However, there are reasonable arguments for the opposite to be true. One other factor is that setting the science officer 2 below the commanding officer means the survey ship would need the commanding officer to be a Captain to make a Lieutenant Commander eligible. While ships large enough to need a chief engineer are much more likely to have a Captain rank and therefore 2 below is fine.

Open to suggestions.

Aurora Suggestions / Considering Changes to Terraforming
« on: January 03, 2017, 02:14:17 PM »
I am considering some changes to terraforming for C# Aurora and I am opening those up for comments before I do anything. Bear in mind there is already a major change in terms of low gravity infrastructure that allows many more bodies to be colonised. For example, under the new rules there are ten asteroids in Sol with a colony of 2.00 LG (mainly NEOs), Phobos and Deimos are both colony cost 2.00 LG and Ceres is colony cost 3.78 LG. The Galilean moons are 5.62 but all the other Jovian moons are now 5.62 LG. In my current game, Alpha Centauri has 143 bodies (mostly asteroids) with colony costs of 2.00 or 2.00 LG.

1) Availability of Water. Probably at least 2.00 colony cost with no water, with this reducing to zero once a certain hydrosphere coverage is available (maybe 20%). Water would be created by adding water vapour to the atmosphere. Over time this would condense out of the atmosphere and create a hydrosphere. Exact mechanics TBD.

2) Too much CO2 is harmful. Essentially C02 above fairly minimal concentrations would be a dangerous gas.

3) Small planets are faster to terraform than large ones. The speed at which terraformers add atmospheric pressure would be modified by the surface area of the planet (this would also apply to the hydrosphere coverage), using Earth as the baseline.

4) As a corollary to 3), a planet's gravity would determine if any gases could be added. In real-world physics, small bodies cannot hold an atmosphere because it would drift off into space. The reason for applying this would be avoid asteroids being given an atmosphere in a very short period of time using the rules for 3). The issue here is that a body such as Luna would not retain oxygen or nitrogen in real-world terms due to the low gravity, so I would have to be more generous than reality to keep the game play interesting. Rather than calculate the exact situation, which would be based on escape velocity, temperature and the molecular weight of the specific gas, I would have a fixed boundary, perhaps 0.1G, as the lowest gravity that would retain an atmosphere. This would result in a lot of low gravity bodies that could be colonised at 2.00 LG (which can't currently be colonised) but which would never improve beyond that point because they would not retain the atmosphere required for terraforming.

The combination of 3) and 4) would mean a significant disparity in how fast worlds could be terraformed, but not to extremes. For example, compared to Earth, Mars would be terraformed 3.5x more quickly, Ganymede 5.9x more quickly and Luna 13.5x more quickly. In fact, it would probably make sense to slow down the base rate of terraforming to the middle of that range, aiming for perhaps 25% - 50% of current rates. In the case of 25%, the rate of terraforming vs current would be:

Earth: 25% of current speed
Mars: 88% of current speed
Ganymede: 147% of current speed
Luna: 337% of current speed.

Large planets would take a suitably long time to terraform, with small planets and moons (that are still large enough to retain atmosphere) being terraformed relatively quickly. Depending on how much effort is required for the hydrosphere element I could make the reduction 50% instead on the assumption that the additional water vapour would also act to slow down the process.


Game/Book Reviews / Battlefleet Gothic Armada & Kirov Series
« on: December 30, 2016, 12:27:56 PM »
I've been ill over Xmas, which means I haven't been up to working on C# Aurora. However, to pass the time I have been playing Battlefleet Gothic Armada, which has proven to be a lot of fun.

I have only been playing the campaign game so far as the Terran Imperium. The campaign is relatively simple and really just an excuse for the battles, but it does have some interesting elements. The combat is 2D with a variety of different weapons and uses firing arcs, some area weapons and relatively slow-moving ballistic 'torpedoes' with powerful warheads.Damage includes critical hits and the loss of individual weapon systems. Ships and commanders gain experience during the campaign, allowing you to customise the ships with a variety of add-ons. I recommend trying it, especially if you like the Warhammer 40k background.

Also been reading the Kirov series of kindle books (up to book 11 at the moment). Despite some occasional typos and one or two inconsistencies, the series is very entertaining. A combination of time travel and detailed naval combat. I suggest trying book 1 (about £3) and see if you can resist buying the rest :)

C# Aurora / C# Aurora Database
« on: October 20, 2016, 04:16:07 AM »
While the current debate on the nature of the Aether is being resolved, I have taken a break from coding functionality to look at the database situation. VB6 Aurora uses an Access database and writes to that DB frequently (One of the reasons for the slow performance).

C# Aurora (at the moment) also uses Access, although everything is loaded into memory at game start (about 10-12 seconds on my PC). I have, however, run into a problem.

My intention is to save at user request, rather than the continual save in VB6 Aurora. One option is to flag every object that is changed/deleted at any point and then update the DB based on those flags. However, that is open to errors (if I forget to flag something) and I have to remember to ignore any 'deleted' records. So I developed a cunning plan. I would backup the DB first, then simply remove all non-static data relating to the current game and replace with it whatever was currently held in memory. Even if this took a few minutes, it would still be far superior to the current situation of slow increments and I am not going to miss anything.

Yesterday I finally got around to implementing this plan and discovered you can't use Bulk Insert on an Access database. Aaagh!

So faced with going through all the existing code and flagging every change or simply changing the database, I have decided on the latter. Fortunately the program was set up with the intention of being flexible on the DB and all data access is handled within a single class. For example, one function accepts SQL and returns a data table so I can change the code in that function without affecting any of the code that calls it.

So now the question is, which database? Or do I even need a database? Another option is to save to XML or basic files.

I use SQL Server at work and there are a few different versions, including SQL Server Express, SQL Server Local DB and Compact Edition. For deployment purposes, the last of those options seems best but Microsoft have discontinued the product with no replacement apparent. The former two require SQL Server installs on the target PC, which is not ideal.

So I have been looking at SQLite. This seems to fulfil what I need and apparently I can write a series of records before committing the transaction, which should make things much faster. So, for those who know much more about this than me, a couple of questions.

1) Does SQlite seem like a good idea in this situation. If not, can you suggest an alternative?

2) If SQLite is suitable, which GUI should I choose? So far I have downloaded trial versions of:
   a) DB Browser for SQLite (basic but free)
   b) SQLiteManager (not keen as it flickered a LOT)
   c) SQLite Expert ($100 but my favourite so far)

Any comments appreciated.

Aurora Suggestions / Commander Location
« on: September 24, 2016, 12:01:49 PM »
Interested in opinions...

Do you think it is worth tracking a commanders location if he is not on a specific ship? I am working on the orders code and playing around with 'Pickup Commander'. There are a few options:

1) Commanders can only be assigned to a ship, population, research project, ground unit, etc. if they are physically in the same location. This would require a lot of micromanagement and is really the only reason that Pickup Commander currently exists. If there is no general desire for this option, I will remove the order as it involves quite a lot of work tracking current location for everyone.

2) Commanders can be assigned anywhere instantly but once in a location they are tracked for combat purposes, so if a research lab gets hit a scientist might be killed. The commanders of ground units can be killed in action, ship officers can be killed by a hit to the bridge, etc. In this scenario, any unassigned commander is ignored and doesn't have a physical location (unless they are on a ship for some reason anyway, perhaps after being rescued from a life pod). There is some scope for exploitation (transferring someone from a ship about to be destroyed for example), but that is self-cheating so not a major issue.

3) Commanders can be assigned anywhere instantly and are only tracked for combat purposes if they are on a ship (VB6 Aurora). Non-ship-based officers are effectively immune to harm from combat.

My personal preference is currently 2) so please shout if you have a strong opinion about one of the others.

Aurora Suggestions / Considering Change to Naval Organization
« on: August 21, 2016, 06:10:30 AM »
Another considering change thread :)

I'm starting work on the new Fleet window and deciding how to structure it. I will be displaying fleets in a tree view (like populations), rather than a dropdown list, and I am going to build in some of the functionality from the current naval organisation tab. For example, you will be able to set up a hierarchy of naval 'administration' to which you attach your task groups.

You will also be able to have administrative 'sub-fleets' within a task group and be able to view the ships in that task group fleet with or without the sub fleets (so you can set up battle squadrons within a task group and see them individually or combined). A task group with admin sub-fleets will still move as a single entity. A ship will always be part of the task group but will be able to have a sub-fleet assignment too. The current 'sub-fleet' functionality will be removed.

You will be able to easily detach one of the admin sub-fleets, which will become its own task group, and I will add a 'join as sub-fleet' order so that sub-fleet can retain its identity if it rejoins the original task group.

Now the 'considering' part..

I think I may remove task forces. They are a little clumsy to manage and many of the staff officer functions aren't that useful considering the complexity involved. Also, I intend to allow more than one officer per ship (first officer, etc) so there won't be the need for lots of junior officer positions. Instead, I am considering having commanders (without staff officers) within the hierarchy of naval administration that sits above the actual task groups. The issue is exactly how they would benefit the task groups below them.

1) One option is simply that they wouldn't. Instead they would gain some experience for being in the role that would be useful when they returned to task group command.
2) They provide a portion of their skills to the TGs under their command, perhaps split by the total number of ships within that command - so more ships, less benefit per ship.
3) They provide a portion of their skills to the TGs under their command, which is fixed but they can handle a limited number of ships based on their rank - this is more complex because you would have to track that number (which is a lot of micromanagement)
4) They provide a portion of their skills to the TGs under their command but only within a certain radius of systems, based on their rank (similar to sector commanders for populations). This would entail having a fixed location for each naval admin node (this is my preference at the moment).
5) As there may be multiple levels within the naval administration, only the lowest level would benefit TGs. Higher levels would train the officers beneath them.

Another extra complexity may be to have certain types of admin commands with advantages / disadvantages. For example, a Survey admin command would benefit combat less but survey more and could have a longer reach. A logistics command would be weighted toward benefiting freighters, a 'Carrier Striking Force' admin command would have benefits for fighters, etc.

There would also be an issue of relative rank, so an 'admin commander' would not benefit a task group led by someone of higher rank.

I'm still considering exactly how to handle this so any comments and suggestions are welcome.

Aurora Suggestions / Considering Change to Maintenance Facilities
« on: June 25, 2016, 06:27:56 PM »
I am considering a change to the way maintenance facilities work for C# Aurora so I thought I would seek feedback first :)

At the moment, if you have 100 maintenance facilities (for example) you can maintain ships of up to 20,000 tons. Furthermore, you can maintain any number of ships of 20,000 tons or less. There are a couple of drawbacks with this approach:
1) It can be quite difficult to build sufficient maintenance facilities to maintain very large ships and it is often easier to build several smaller ones instead.
2) It is very easy to maintain large numbers of small ships (one of the reasons that fighters are excluded from maintenance facilities).

For C# Aurora I am considering changing maintenance facilities so that each one has a much higher capacity (perhaps 1000 - 2000 tons instead of 200 tons). However, additional ships would require additional capacity. For example, 100,000 tons of capacity could maintain a single 100,000 ton ship, five 20,000 ton ships or twenty 5000 ton ships (or any combination).

If there are insufficient facilities available, the maintenance clock on ships at the facility would be based on the missing capacity. For example, if a population had 100,000 tons of capacity and 150,000 tons of military shipping was present, all ships would advance their clocks at 1/3rd normal speed. (200,000 tons of ships would be 1/2 speed, 400,000 tons would be 3/4 speed, etc.).

There are advantages and disadvantages to this approach:
1) It is much more realistic and larger fleet bases would be much more valuable.
2) It will be a lot easier to maintain very large ships
3) I can lift the restriction on fighters using maintenance facilities.
4) It would remove the maintenance advantages of small ships vs large ones.
5) It would be less obvious whether a ship could be fully maintained at a given population (although I would add a tab to the Economics window to track this in detail for each population)

In this situation, I would add a tech line that increased the capacity of maintenance facilities. I might also consider having some form of auto-overhaul if the maintenance facilities had excess capacity vs the ships in port (based on the amount of excess capacity vs total size of ships), which would remove some of the micromanagement for overhaul.


Pages: [1] 2 3 ... 33