C# Aurora v0.x Suggestions

[Kytuzian]

He'd also have to be careful to prevent queries from breaking the DB.  Don't want to let anyone run any table drop queries.

Sure, but it's just a singleplayer game, so it's not that big a deal I think. I don't know if sqlite has users/permissions like MySQL/some of the others, but he could set it up so that the user used for these queries only has select privileges or something like that.

[TMaekler]

In VB6 it was only possible to shut down a full part of the economy or bring them on also in full (with 180 days of startup time). Would be nice, if the shutdown could be done for parts of an industry (for example if you run into a shortage of sorium mining, you simply shut down 80% of the refineries, until the resupply is going up again).

[TMaekler]

Well there is a database for the game, so we could have a screen that display the results of SQL queries on the database, maybe let you save a few different queries so you could easily access multiple reports. That'd be about as much flexibility as you could get.

That would be something... . Being able to create some queries, which will be updated after time progressions... .

[Bremen]

Maybe more of a general Aurora suggestion, but I was experimenting with ship design and I noticed the GPS (strength to passive EM sensors) of an active sensor scaled linearly based on the resolution of the sensor, by which I mean a sensor with twice the resolution has twice the GPS. This creates an odd situation since the range of an active sensor does not scale as fast; a resolution 10 sensor doesn't have double the range of a resolution 5 one. This means that low resolutions sensors have vastly longer ranges compared to where they would be "picked up" by passive em sensors while high resolution sensors have the opposite. This doesn't come up as often in VB6 Aurora where long range active sensors tend to dominate the battlefield but will probably be more relevant with the new sensor model.

Instead I'd suggest that either GPS doesn't scale at all (so that equivalent size active sensors would have the same EM signature regardless of resolution) or scale at the same ratio as active sensor range(area in C#) based on resolution, instead of scaling faster.

[zatomic]

Some thoughts after reading the digression into lagrange points in the questions thread:

Rather than deal with a separate jumping mechanic to deal with distant companion stars, why not allow inter-system jump points? I see a couple of ways to approach it. For all, lets assume some arbitrary cutoff is set where if a companion star is more than D distance from the primary where D is farther than is practical to travel with mid-game tech levels, we'll call it a Distant Companion.

Option 1: In the real-stars data-set, just make distant companions into their own systems. Thus you might find the Star A component system, and later discover a route through the jump point network to the Star B component system (or vice-versa). They act as fully separate systems and only the naming shows them as distant members of the same system. (In the random stars mode, just don't generate companions farther than D from the primary)

Option 2 (which I like better): Distant companion stars get their own set of grav survey points with associated jump points to discover. The lore seems to be that stars are more likely to have jump points to nearer stars than more distant ones (based on actual locations in the real-stars data-set and approximated by the clustering percentage for random stars). Thus we can set a specific probably that there will be a jump point from a primary to a distant companion. This could be 100% if we always want a connection or lower (possibly an adjustable parameter). If lower, you may still find a route through the jump network to the distant companion and may even get interesting situations where the primary component is closer to empire A in the jump network and the distant companion is closer to empire B. This could mean that long-hauling between components that don't have a direct jump point link becomes a way to get behind enemy front lines. It may not even be known that an enemy exists on a distant component until you find a route through the network to get there.

Giving distant components their own jump-points but keeping them in the same system map means either allowing jump points to move with the stars orbit, which could be complicated, or disabling orbital motion for distant components. I think assuming D is large enough, disabling motion would not be particularly noticeable since the orbital period of a distant companion would be very long relative to typical game length.

[TCD]

Very interesting suggestion zatomic. Of course logically you're right, it makes perfect sense that every star in a system should have its own potential jump points, rather than just the primary. I assume there is some technical problem with doing that though, maybe around system generation?

I suppose the main problem would be that if the inter-system connection chance is too high then you'd greatly increase the chance that binary/trinary stars are dead ends only connecting to themselves.

You could get around that by stating the opposite to your initial premise, that inter-system connections are banned for hand-wavium reasons. Doesn't help you travel in system to a companion star, but it would make all planets accessible via the jump network eventually.

[misanthropope]

i can attest from personal experience (running Starfire games) that a system with two (or more...) distant components each with valuable real estate and its own jump points is a natural site for major PVP mayhem.  when each component is more accessible to *other systems* than to each other, the stage is set for a pleasingly stable hostile split ownership of the system. 

perhaps aurora is too low-level (micro-intensive, i mean) or solitaire-oriented for the benefits to pertain, but a guy can dream.

[TMaekler]

Less of a feature suggestion, more for what Aurora is doing in the background.
C# version will be somehow a lot faster (which I am looking forward to). However, I was thinking in the direction of "using all the resouces". Basically, a turn based game like aurora most of the time sleeps (while the user is working), and then begins to work on all necessary stuff when the user told the game to "do the turn" (in the past, whilst the user was sleeping ;-).

I was wondering if some of the calculations needed could be pre-done in the background whilst the user is working on his move.

[Jovus]

I was wondering if some of the calculations needed could be pre-done in the background whilst the user is working on his move.

Almost certainly some of them could be at least partially pre-done. E.g. when you change your prod queue, calculate right then and there what the prospective 5 (or 30) day turn looks like, and just store that until the prod timer ticks over for real, thus saving apparent time on advancement. Or when a new system is created (discovered) allow the user to work with it while figuring out during user-time how this updates civilian shipping. Or figure out starting bits of NPR response based on 1-day projections whenever you're setting up orders for TGs in their systems and close the TG window. Etc. etc.

However, all that is probably kinda boring to actually code.

[Triato]

I wold like for some companion stars to keep being hard or imposible to acces. It gives us a long term project, a choice to make and a diferent situation. Yes, some are so distant that they only serve as ornaments but even that gives a bit more of flavor to the game I think.

Maybe we could have a new tech branch that allows you to create intrasystem jump points at hi cost.

[ExChairman]

Not sure if its said before, I would like to have an order that works like this: "keep x km´s distance from enemy" So I can stay out of his weapons effective range.

[Father Tim]

There is such an order.  A couple, in fact.  There is 'Follow at {distance}' that takes any ship, missile, contact, or task force as a target; along with various 'Formation' options that only accept your own or allied ships as the target, but allow you to specify an offset distance and direction (such as 60 degrees (one-sixth clockwise, if I remember correctly) or 270 degrees (one-quarter counterclockwise)) with respect to the targets' direction of travel.

Combining both, you can chase an enemy TF with your beam escorts five seconds in the lead -- split half-and-half to either side of your formation to guard against sudden lunges by beam-armed enemies -- and your scout/sensor ship tucked safely behind the rest of the fleet by ten or fifteen seconds' flight time.

'Follow' is on the regular orders/movement window (it may only come up if you first select a unit or contact as target).  Formations are on the Task Force / Fleet Organization window.  I think.  I haven't bothered to open the game to check.

[Barkhorn]

The problem with "follow" is that when you kill the contact you were following, the order stops and your ships stop dead in their tracks.  This can be deadly if you're kiting beam ships.

[Steve Walmsley]

The problem with "follow" is that when you kill the contact you were following, the order stops and your ships stop dead in their tracks.  This can be deadly if you're kiting beam ships.

You should always kill the ship you are following last

[QuakeIV]

Thats generally how I do it, just follow the guy on the bottom of the list.  It would be quite nice if you had a 'keep x distance from hostiles' order I suppose.