4th bug: Deployment counter on fleets above 50k worlds is still rising in between production turns. It does not on motherships with recreational module.

The parasites should also rest 10% faster than on orbit. This was not tested but I'm very certain they will. I have experimentally confirmed that 1514 is responsible for parasites not having deployment time increase in motherships.

Ok, I think I've got it. lastShoreLeave is a date, in the same format as gameTime. 2765 is called every construction cycle, so in between the cycles, we need 1514 to update lastShoreLeave because 2824 won't do it. Initially I thought there can be a simple check what population the fleet is assigned to but that won't work the same as 2765: the fleet can be assigned to an empty population on the same body as a populated one. This forces an iteration over all populations. However, 1514 doesn't work the same as 2765 for motherships either. Because in 2765 they don't need to be motherships at all, they just need to be close. I'm starting to feel like this isn't a bug in the end. Though certainly does look like one. Priorities need to be evaluated, does players not seeing the counter rise justify the extra CPU time.

I have an idea: a flag for the fleet: "isOnShoreLeaveOrMothership". Updated in 2765 and used in 1514 to determine whether to increase lastShoreLeave or not. No extra computation cost, doesn't need to go into the database. But would have to be updated every time the fleet leaves the planet too. Or splits. Or moves away from the recreational module. Or the module moves... unless updating it in within a construction cycle is irrelevant. That technically increases operational time by up to 1 construction cycle, idk.

For my own binary, I added the flag, false by default. Set it appropriately in 2765 and changed 1514 to depend on the flag instead of the mothership. Still ticks up for the first construction cycle since loading but not after.

About "my own binary": I've read the post. I'm not going to publish this. Just give suggestions like above. Messing with the game is part of gameplay for me.

You are not considering migrating to Linux, are you?

It's a .NET app as you said, I highly doubt.

Tooltip text at bottom of Research tab for Railgun Velocity techs:

The muzzle velocity of the railgun. Railguns with higher velocities can shoot their ammo further and inflict damage at greater ranges. This works in a similar wave to laser wavelengths

There will be no general power usage, apart from energy weapons. Power plants tend to be fairly compact, but expensive for their size, so the % cost might be 4-6% even if the size is 1-2%. Aurora is an operational, rather than tactical, game so ship level power assignment is mainly abstracted. I made the decision long ago not to go down the Star Fleet Battles route. That is a great game, but its on a different scale.

Just want to add my support to this design decision and go into more depth why.
In a game where you control a single ship it could be fun and make sense to distribute power between systems. In a game with fleets of ships over a whole empire it adds very little and opens alot of cans of worms like...
- Want to kite the AI enemy and kill 30 x your tonnage without a scratch? All power to engines.
- In a position to fire a first strike laser barrage? All power to weapons.
- The enemy is targeting your dreadnaught or you know a big incoming missile salvo? All power to shields on that ship.
Alot of very simple decisions that requires very little thought/strategy and just allow easier victories over the AI, and add more micromanagement clicks.

My own definition of "early game" is ships built before any opposition is encountered.  The only pre-contact space combat an empire may have had may have been piracy, insurrections, coups, civil wars and war games.  As such, they will be creatures of politics.

A Frigate may be essentially built around its spinal gun, intended to outrange any improvised weapons of an outpost, and efficiently reduce it, prompting it to surrender without a fight most of the time.

Once an enemy is actually encountered, those pre-contact ships get tossed into the maelstrom.

Another aspect of "early game" is a focus on individual ships, and not fleet missions.  In one game I had, my missile ships, about 12k tons, so similar size and role, had a single hangar on them for integral scouting fighters and/or sub 1000 ton boats.  The idea would be that the missile boats would upgrade their missiles and fire controls and thus stay in operation for a long time, with their scouting complement continually replaced and upgraded over time.  And then the entire class ran into a boojum and upgrading them became a moot point.

For me, the size was determined by the size of a shipyard that could be retooled.  Or rather, one shipyard would stay in production while the other retooled, and then the first shipyard was retooled. But that was with a pre-Trans Newtonian start.  With a start that assumed significant production of pre-contact designs, you are not limited to the retooling issues of shipyards.

With pre-Contact designs, it is perfectly fine to design them with RP considerations more than anything else.  Assume the designers have no experience with ship warfare, no idea what technologies are coming out in the near future, and part of the fun is trying to get some use out of the white elephants while you frantically work to develop a doctrine.

Quote from: Froggiest1982 on July 25, 2025, 03:02:45 PM

I would still keep both EM and TH passive sensor along with thevres 1 Active.

I can see you have only 1% IFR so probably tons of engineering modules, maybe you can get some space from there?

If you need more MSP you may be able to use MSP storage sections.

Should I replace some of engineering with more lasers?

You may need some sort of passive sensors unless you planning to keep the AS on all times which gives away your position from further away.

Also, if you are using this out of the DTS range and again you'll have to keep the AS on at all times.

Of course, more lasers are always appreciated.

I am still limiting my answers to basic operational systems as with weapons and such it depends on too many things. I am not a fan of the "perfect" design concepts, it flattens the experience IMO.