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 - Steve Walmsley

Pages: [1] 2 3 ... 440
1
Aurora Bugs / Re: Official v7.10 Bugs Reporting Thread
« on: Today at 11:23:20 AM »
Well, I certainly didn't touch the DB.

If you can figure out which system, you can break the link in SM mode and correct the error.

2
C# Aurora / Re: C# Aurora Changes Discussion
« on: Today at 11:21:30 AM »
How will this work though? Can we seize territory in ground combat, ideally also set fixed claims when we want peaceful coexistence?

If another race grows its population, that is restricting your ability to grow. In effect the planetary environment has a limited capacity to support a population, regardless of their nationality.

On Earth, overall population growth is slowing even though there are considerable difference by region.

3
C# Aurora / Re: C# Aurora Changes Discussion
« on: Today at 05:09:52 AM »
The risk is that the complexity of porting the existing rule set to C# combined with the complexity of changing the rule set leads to a more complex overall task.   Trying to combine the two goes against most modern philosophies of good software engineering practices.  I personally think this has been demonstrated with the ground combat stuff:  Steve was chugging along through the various functionality sectors until he got to ground combat, at which point my perception is that the progress got bogged down.  Some data: the original "I am seriously considering removing PDCs" post was on Sept 17, 2017 (on page 70 out of 93 in this thread), so he's been on ground combat  for four calendar months and 25% of the posts in this thread, which is probably more time than it would have taken if he'd simply transcribed PDCs and ground combat.

A more telling example of the "change while transcribing" failure mode: the Pulsar 4x project seems to have fallen prey to this it.  My recollection/perception is that they started out wanting to do a straight port of Aurora to C#, but figured "why not improve the game mechanics along the way".  They seemed to have bogged down about halfway through; I haven't seem much activity from them at all for the last year or two. 

That being said:

1)  Steve is good at this stuff (writing Aurora); he's been doing it for many years.
2)  Ground combat IS an isolated system, so he can code it up and get out of it.  In general, Steve seems to be doing a really good job of doing minor and isolated tweaks to systems as he codes them up (e.g. the refueling changes), so that he's doing "transcription with cleanup" as he goes, rather than "write a whole new game".  In other words, I think he's mostly been striking the right balance.
3)  Steve's already written one game (VB6 Aurora) and gotten it to completion, which demonstrates the tenacity and ability to complete the job, so there's a good chance he'll complete C# Aurora too.
4)  (Most important) It's Steve's free time, so if he wants to spend it working out ground combat mechanics before getting a playable version of Aurora out then that's his prerogative.

So I suspect the ground combat stuff has probably slipped the schedule by a month or two, but if that's what Steve wants to do that's his choice.  Hopefully this is the only sector for which he's planning a major rewrite, and he can get back to straight transcription to get a working version out.  If not though, c'est la vie.

John

I think the Ground Combat changes will probably delay completion by 3-4 months, more due to deciding exactly how to implement them than the actual coding. The ground combat design is mainly done now and a decent chunk of the coding is done. I still need to code the interactions between ground units and naval units (including new movement orders) and the logistics. As mentioned above though, this is a relatively isolated area so doesn't impact the rest of the game too much. On the plus side, ground combat was a very basic area compared to the rest of the game and I think the changes will make it much more interesting and immersive (from an RP perspective as much as a mechanics perspective)

I'm taking a break from ground combat at the moment to code the New Game window, with the intention of starting some test games. There are still some significant areas missing, including combat, AI, default/conditional orders, about half the movement orders and many of the minor windows. However, almost all the construction phase code is done (research, terraforming, production, maintenance, etc.) and most of the common movement orders, so I hope to start the first of those test games in the next month or two and then code the rest while playing.

I am moving house in the next couple of weeks, so that will slow things down a little, but should be up and running again fairly quickly.

I am well past the point now where I think there is a question of whether C# Aurora will eventually be finished. This isn't similar to early abortive attempts at Newtonian Aurora and Aurora 2. I have invested almost two years into this project (from March 2016) so I am pretty determined to complete it :).  I can't say when yet but the prospect of getting a new campaign running is my main motivation.

4
Aurora Bugs / Re: Official v7.10 Bugs Reporting Thread
« on: January 17, 2018, 05:30:03 PM »
I've run into "Error: WP Link not found in GetWarpPointData" while opening the galaxy screen.  Also, when I do anything in the galaxy screen, such as zooming or moving systems, I get an Error 5.  What I think happened is that I found a new system and started to grav survey, completing some points.  I then discovered that it was inhabited by a new NPR, so I pulled out pending diplomacy, leaving the system's survey incomplete.

This is caused by a jump point believing it is connected to another jump point that doesn't actually exist. It could be caused (for example) by deleting a system via the DB rather than via the UI.

5
C# Aurora / Re: Alpha-testing
« on: January 17, 2018, 03:24:47 AM »
Literally I recall Steve saying that one of the impetus for starting the upgrade to C# was that he wanted something to do during his campaign turn times and decided to code C# aurora in the breaks whilst he was waiting for turns to process.

Yes, this is true :)

Then it gained a life of its own and I started concentrating on C# Aurora instead of campaigns.

6
C# Aurora / Re: C# Ground Combat
« on: January 16, 2018, 12:56:52 PM »
Pods won't be expended, so you will need to carry enough for a single loadout. If you want more flexibility you need multiple pods to support different loadouts.

Fighters already have maintenance requirements (maintenance facilities or hangars, plus maintenance supplies) so they won't need additional maintenance during combat. Ground units outside combat will require wealth but no consumable supplies or basing. I still haven't finalised ground unit in-combat logistics.

I know pods in box launchers seems a little odd but it provides a non-efficient way for space fighters to contribute to close air support. Having said that, it probably won't be common because even light-weight pods are likely to be size 8 or more.

7
C# Aurora / Re: C# Ground Combat
« on: January 14, 2018, 10:24:50 AM »
This means that effectively there are 9 ranks. It'd be nice if we had an option like with naval forces for there to be an administrative command system.

There are 9 HQ 'components' but you can have more than 9 ranks if you wish because you can use the same components for different units at multiple levels. It is up to you to define your own command structure. That being said, it probably isn't necessary to have more than six or seven. The HQ system is the equivalent of the naval admin command system.

8
C# Aurora / Re: C# Aurora Changes Discussion
« on: January 14, 2018, 07:37:56 AM »
I'm a bit worried about feature creep, both for the sake of my sanity and my processor.

Will C# get some performance upgrades?

C# will run a lot faster than VB6.

9
C# Aurora / Re: C# Ground Combat
« on: January 14, 2018, 07:37:06 AM »
Are there going to be extra officer positions for ground forces like there are for ships? Will there be smaller and larger organization of ground forces available (companies, armies, etc).

Yes, you can have any formation size you want, from company or platoon up to army or army group.

10
C# Aurora / Re: C# Ground Combat
« on: January 14, 2018, 07:36:03 AM »
How far up does the chain of command go now? Do we finally have four tiers to make use of all four army officer ranks?

As far as you want. There are unlimited army ranks now and nine different HQ sizes.

11
C# Aurora / Re: C# Ground Combat
« on: January 14, 2018, 07:34:54 AM »
So, question, maybe this was answered elsewere and I just forgot, how will basing fighters at planets work now? Obviously they can't be based in PDC hangers and it would seem odd if you couldn't base atmospheric fighters on a planet at all (not to mention this would give an attacker a major advantage if having space dominance totally precludes the use of atmospheric fighter support for the defender).

Also forgive me if this question is stupid, I've never actually used fighters so far and am under the impression that right now if you want to base fighters at a planet then you use PDC hangers, if that's not how it works then my question is ignorant.

You will be able to base fighters at planets using maintenance facilities. However, I may add some form of airbase as well.

12
C# Aurora / Re: C# Ground Combat
« on: January 14, 2018, 07:33:39 AM »
Do fighter pods get a techlevel modifier? They'll probably need one because otherwise you get insane podsize requirements to pierce enemy armour as technology develops.

Yes, the pod ratings are modified by the racial weapon modifier in the same way as ground units. I've added that to the original post.

13
C# Aurora / Re: C# Ground Combat
« on: January 13, 2018, 05:03:09 PM »
Thanks for all the feedback on the proposed interactions between fighters and ground combat. I think I have now found a good way to make this work.

A new component, the Fighter Pod Bay, is similar in function to a small Box Launcher, except it will only hold Fighter Pods (see below).



Fighter pods are created on the Missile Design window. The various pod options, such as bombardment pod, autocannon pod and air-to air pod, will appear when the requisite technology has been researched. When one of those options is selected, the warhead strength field is replaced by a pod size field. The player can choose the pod size, with larger pods being more effective. The pod capabilities will be similar to the capabilities of equivalent-sized ground unit components, although the fighter pods have more flexibility in design. For example, a bombardment pod will have three shots, armour penetration equal to Racial Weapon Modifier * ((Tons / 20) ^ 0.6) and damage equal to Racial Weapon Modifier * ((Tons / 20) ^ 1.6).

Fighter pods are ordnance, in exactly the same way as missiles. They are built by ordnance factories, transported in magazines and loaded onto fighters. Unlike missiles, they are not expended when fired and will function during ground combat phases.





A fighter can be designed with fighter pod bays. Different pods can be assigned to those bays while the fighter is in a hangar, providing flexibility of loadout. The same fighter could be used for bombardment or autocannon pods, as long as the pods bays are large enough and the parent carrier has both types of pods available. The pods can be assigned to the fighter using the normal ordnance loadout.

Pods can also be assigned to normal box launchers, so a fighter designed for space combat can also be used for ground combat in an emergency. However, box launchers are three times larger than the missiles (or pods) they are designed to fire, while fighter pod bays are equivalent in size to the pods, making fighter pod bays are a much more efficient way to mount the pods. Because of this efficiency and no requirement for fire controls or sensors in ground combat missions, dedicated ground support fighters can be much smaller than their space combat equivalents. It is also possible to have hybrid designs mounting both pods and box launchers. Due to the requirement for smaller engines for dedicated ground support aircraft, ship engines can now be designed from 0.1 HS in size.




14
C# Aurora / Re: C# Aurora Changes Discussion
« on: January 09, 2018, 07:27:18 AM »
I think we need a way to have the ground combat module work for all ground targets (including atmospheric fighters).  In real life, practically every fighter can carry every type of ordnance.  The F18 Hornet can carry dumb bombs, GPS-guided bombs, laser guided bombs, unguided rockets, multiple kinds of air-to-air missiles, multiple kinds of anti-tank missiles, multiple kinds of anti-ship missiles, gun pods of varying calibers, extra fuel tanks, and ECM pods.  And these are all attached shortly before take-off.  You don't have to buy totally separate plane if you want to change from dropping bombs to shooting rockets. 

I think instead, we should have one ground combat module that, when the fighter is launched from the mothership, must be set as to what kind of weapon it will carry.  I would give fighters a higher chance to target their preferred target type as well.  As a trade-off I would require the fighters to return to their carrier and rearm, draining MSP (or a new kind of supply, called "Conventional Ordnance" or something) from the carrier.

I prefer the dedicated modules for a couple of reasons. Partially because I am aiming for a more WW2 / WH40k feel to ground combat, but mainly for consistency. If the fighters can have multi-purpose modules, why can't the ground units? Think of this of more like F-15 vs A-10 vs SU-25, etc..


15
C# Aurora / Re: C# Aurora Changes Discussion
« on: January 09, 2018, 07:23:49 AM »
I think that the idea is that having logistics units means a fleet can just drop the infantry units and leave orbit without also needing an order to drop x MSP.

Instead, would it be possible to just set an MSP stockpile for a formation in the same way that you set deployment time while designing ships? Ideally it would then show you an estimate on how long the supplies would last for normal usage and combat. Then the formation's cost and transport size could increase proportionately (but without any additional units/elements in the formation), and when you landed the units they would take the MSP with them. If on a planet with an MSP stockpile ground units would then attempt to refill up to their designated stockpile size.

The issue with the MSP stockpile concept is getting the MSP to the planet. For cargo, colonists and troops, you need time to unload. I haven't decided whether to extend this to maintenance yet. Even so, it doesn't seem realistic to instantly dump a large stockpile of maintenance during an invasion, which is then impervious to hostile attack. The logistics units represent the challenge of establishing the required logistical support and the requirement to defend that logistic support, plus they create a significant decision regarding the division of transport lift between combat and logistical formations.

Pages: [1] 2 3 ... 440