Idea for Speeding Up Aurora

[Zenrer]

. . . I am so glad I have not encountered these kind of speeds anymore since my second game. ^^ It was always less than a minute for 5 day intervals since then, but after I recently discovered the manual processor assignment trick, I have it down to about 10 seconds for one production turn at year around 2280.

Could you elaborate a little more on this? The eventual slowdown of the game is starting to get to me 

[MarcAFK]

Could you elaborate a little more on this? The eventual slowdown of the game is starting to get to me 

you can use task manager to change processor assignment too.

[Vandermeer]

test - I wonder how many signs I can put in here before I get an error message. Zenrer, sorry, I cannot reply right now, because the Aurora forums had some problems, and currently it is bugging again. I tried to post stuff without extras - no thick or cursive text, no links, no quotes, just text, but it seems after just a small amount it wouldn't get accepted anymore. I could maybe make like 100 little replies to circumvent, but I'd rather wait.
Can we make it to 500 characters? Yes we can! -500-
And 600? That would be like birthday on christmas, with the easter bunny handing out shots --600---
Now the real achievement: 700. The well is twice as deep as in 300, and more spit on camera -700--

Ok, the other post down proved that 978 is possible, so new goal is 1000. Who bids higher? Do I hear 1001?

Hmm, I am just gonna fill this with nothing: abcdefghijklmnopqrstuvwxyz1234567890ß?*+~.;:-_#'´`\/()&%$§"!²³{[]}F1F2F3F4F5F6F7F8F9F10F11F12jackQueenKingAce god does this not end?!?!?!-999here-1008here-

New theory: This is all completely random, because at around 999 I could at first not post without error. Then I removed brackets, and it worked. Then I could go over 1000 even. I added those brackets again, but they aren't the culprit: ())(()(
So? Gremlins!
Still cannot post my original reply though, no matter how often I try.

[JacenHan]

Could you elaborate a little more on this? The eventual slowdown of the game is starting to get to me 

If you have multiple cores, you can assign Aurora to use one and let other functions use the rest. I think Vandermeer posted about it somewhere else, but I can't seem to remember where.

[Vandermeer]

If you have multiple cores, you can assign Aurora to use one and let other functions use the rest. I think Vandermeer posted about it somewhere else, but I can't seem to remember where.

The post was swallowed with the 1 week rollback of the forum it seems.
Well, there was not much more to it. I personally assign some cores further down, like 5 and 6, and then it flies. Aurora always seems to select the first one, even if that one is already busy with whatever runs in your background. I figured that out, because I like to watch movies or something on the side whenever running Aurora, because even though that has been proven to enlarge loading times, I'd rather be entertained through inevitable waiting periods rather than stare at the screen for some minutes.
However, manual assignment takes care of that, and it goes freely as if you were doing nothing else than focusing on Aurora.

[Vandermeer]

Hopefully this gets through now. The forum sometimes doesn't accept certain words, but only when they come after other certain words. There is no way to identify the rule behind this, so I will just black out words that the forum does not accept, so you will have to guess sometimes what should be there. See it as a game.

Could you elaborate a little more on this? The eventual slowdown of the game is starting to get to me  

Well, aside *black* the only recently discovered processor trick, I've gotten my speeds by making sensible cuts to the game, which probably a lot of people wouldn't go with, since it might take away too much from their play-style. I've tested multiple theories for this to figure out what actually causes slowdown in later game stages, because it could be many things: Count of moving objects (ships, planets etc.), Count of total systems (there might be a calculation routine for every one of the, causing degrading the more you have), Count of officers, number of active sensors in the galaxy (seemed likely to be a calculation maelstrom), amount of accumulated resources (incl. fuel), Count of outpost(/colonized) worlds (again, seems likely to demand an extra calculation each).

By rigorous testing through my long past 2nd and 3rd Aurora game, I could rule out the following as being basically of no influence for production turn speed:
Resource amount, thankfully the count of found star systems, and surprisingly also the count of outposts. -Maybe that gets worse if you really overdo it, but I never experienced any frowning problems up to 30 settlements or what not, including around 8 1billion+ inhabited worlds. The only thing that happens is actually that big, not many colonies slow down the loading when selecting such a colony in the production window. This is however not due to bare size, but because of a surprise guest on the list of possible factors: ground units. Having more ground units on a colony significantly slows down the load-on-selection time. It starts to get annoying around 6 divisions, and with 10 it is becoming a problem.
...Can be avoided by putting them in cryo-modules until they are needed though, and suddenly the biggest colonies run nearly at 100% speed again. This is of course of utmost importance for your main colony to have (the others not too much), because the biggest one sits on top, and gets thus loaded when you summon up either production, research or economics windows, slowing that down by a lot. If you herd your ground forces adequately, you may load almost as on day one though.

So what stayed as factors are: officer count, sensor count, count of moving objects.

Officer count you will only notice at two moments: Whenever an assignment cycle is through (happens normally once a year or so, unless you change it), because then elaborate calculations determine where every officer goes on for the next assignment cycle, who is fired, and then some promotions happen too. Of course this becomes more demanding the more officers you have, but it is only once in a what time, and even then not as bad.
What I found is more of a problem is that the officer menu slows down quite a lot once you have around 500 in naval only, and that may become a problem. I've learned through this to not go over 20 naval academies if possible, because on that stage it already needs a few seconds on every window summoning.(this already gives potential for over 1000 naval officers, so unless one sports expansive fighter fleets, it should be enough for a long time)
This isn't really necessary though if one doesn't bother with selection loading time. I may break my own limitation in my most recent game later one for example, if I really go into megaton carriers and need lots of fighters.

Sensor Count I could not fully nail down to determine just how much it does, because you basically need a hostile NPR to test this out. I can confirm general slowdown for sure (does not extra influence production turns however), but if it may become really crippling if you let the NPR around,..I could not sort out individually. This is because I deal with any NPR I encounter quickly, and do not let them leave their system for exploration, because of the last and most important factor:

Moving objects. The one and only absolutely deciding factor in any game's pace are the amount of objects that fly through your game. This does not only include your and any possible NPR or whatever ships, but also most notably the civil fleets, and the orbiting bodies in systems.
- Orbiting bodies can be avoided by turning that option of in the game menu, though I must confess I am not sure on how strong it actually influences, because I never tested it separately (difficult to do), and had it turned of ever since after my 2nd game. Some people might find it breaks some important atmosphere with the realistic body motion turned off, and I can understand that. I just saw the potential that this may slow down the game with pretty much every newly discovered system, even if there is not much living in it, so a game would naturally slow down through exploration alone, and I didn't want to take the risk. I always play usability before presentation.

- Your own ships you can of course easily have under control, but NPR might spawn fast after being discovered. In one older thread here I presented that I played as  the Warhammer 40k human empire, because I noticed that the only sensible philosophy towards aliens is to violently exterminate them before they can spread. Even small NPR start spawning ships fast very soon, and then they start flying through jump points and discover worlds you have not seen yet (including even more NPR possibly about which you can do nothing - exponential slowdown trap). This might then cause the feared 'distant battle' slowdown, where you really cannot do much but watch 5 second intervals for some hours, because your master yoghurt senses a disturbance in the force. This is so threatening, because you never know if the game didn't possibly bug out, and those turns will never end. No joking, I once in my second game had a period of those slowdowns that lasted more than 10 hours. I watched the entire alien trilogy, then reviews on every movie of the trilogy, then parodies, all in that time, and it wasn't even nearly finished. They ended, but I decided I would never deal with this ever again, turned NPR on new games off by default, so that I can only find them, and if I do... Exterminatus!
Well, I have relativized that decision a bit since, and allow them to live in controlled environment peacefully with me, but I prepare measures to hinder them from leaving their origin, or grow too fast. ("..uhhh, no, this ship was infested by some ancient long extinct empire's AI virus, switched sides, and now goes rampage destroying your fresh jump fleet. Well, we couldn't have known.")
Once they are allies, and one can see all their ships and position, one might let them roam around even more freely, but always beware of letting them discover new systems still, because in the end they are just armed civil fleets with the same problems...

- Keeping you civil fleet under control is an absolute must. Many good things happened to the civil fleet management since 6.3, so it might now be feasible to have one without completely breaking your game on year 100, but you must always be knowing how to treat those to prevent disastrous multiplication. (for example you do not move infrastructure to venus, or else your civils will at first go filthily rich with that, becoming too many easily, and then also only ever to those jobs and not help you out with whatever you really need. All in all it is pretty easy to mess up your game with some AI trap or miscalculation, and it definitely costs you some processor resources in any case for those hundreds of ships to individually figure out where to go on every increment)
The most problematic thing about civils is that they can get out of control still, because there is no way to restrict their growth or even scrap them by empire decisions. In 6.4 they update their design efficiently, and scrap ships after some intended life time by themselves, so that does help out preventing this terrible exponential explosion. There is no guarantee though if you overlook something, and so you still often see threads on the forum where people got their games crippled to backwards time compression because of civil fleets with hundreds of ships in eternal meaningless transit.
A side problem is of course too that these ships might also get intercepted again, so there is potential for a lesser case of the 'distant-battle' slow down. You see them, but it will be a long encounter (a whole freighter trail), about which you can do nothing.

In 6.3 I had concluded civil is impossible to bear, and yes, it turned out to be basically the only most responsible factor of game slowdowns for later years, as when

[Erik L]

Could you elaborate a little more on this? The eventual slowdown of the game is starting to get to me 

Well aside from Vandemeer not being able to use "from" in this post.

[Vandermeer]

Well aside from Vandemeer not being able to use "from" in this post.

Now it is the letter "I". But only at that position where my post just ended. (sign number 9187...) (/edit: Correction, I cannot write anything more in the post above. That it ended on not being able to write "I" was strange coincidence. I am not at the sign limit though, so it is still shady, and still goes to the same error page)

I will continue here:

...I started to blow up the first ships of freshly created shipping lines (/preventing them ever making profit, and thus instantly bankrupt them at the root) , I suddenly had a fluent running game with my 3rd one and every other after that. I handled all my freight jobs and fuel mining per hand, which is really not that hard to do once you got the procedures down, and know how to intelligently make use of the stored order templates and order copy/+repeat options.
6.4 again is better with civils, and I will try them out again for the idea that I have for my next game in some future. It is always an argument that civils help you automate the game, so it goes faster, but even with the upgrades nobody can really cut out the performance drop that a couple hundred AI handled ships will inevitably bring with them, so one will always have to accept that trade of immersion with processor work. Automated, yes, faster, no, actually the opposite.

So to sum up the measures I took:
- store (most) ground units in some cryo modules if possible to prevent colony menu loading slowdown
- restrict academy count to either 10-16, or then as low as possible to man all your ships (+some extra) to prevent officer window slowdown
- turn orbiting bodies of to prevent mere exploration from gradually interfering with your game, and have huge star maps later on, yet still normal game progression. (not verified and sufficiently tested)
- do not ever generate NPR on game start, because of horrible slowdowns when they go to battle, which might even become eternal in some bugged sensor related AI trap cases.
- control found NPRs in some way, so that at least you know the position of all their ships all the time and do not risk their multiplication or 'distant-battle' slowdowns.
- Most importantly: Keep your civil fleet under control. Either know exactly what you are doing and live with a small performance impair, or just get rid of all of them and do the stuff manually.(requires designer mode password though)

There you have a recipe for a good and cleanly running game. Whether one decides that he can accept all those points, or maybe drop one here or there for the sake of his own game experience, is of course personal decision.

To prove it, here is a slightly older save from my recent game at year 2221, which still runs smoothly.(I think the ground units are not currently in their cryos {/barque ships} though, so beware )
http://www62.zippyshare.com/v/79549364/file.html

I've played other games to well beyond year 300 with the same results, and can safely extrapolate that this is how Aurora stays running and smooth.

[Barkhorn]

I've had an idea for awhile now on how to deal with the civilian fleet problem.

Just stop simulating them perfectly 100% of the time.  Switch to a trade route system instead, abstract the whole system 90% of the time.  The routes would have a density, i.e. number-of-ships / length of route.  Trade and installation shipment rate should be computable without calculating exactly where every cargo ship is all the time.

Then, if a hostile ship's sensors are within range of the route, you roll some dice and decide based on the density of the route if one or more civilian ships are there.  If yes, spawn them and then its business as usual.  If no, sorry alien raider, no juicy freighters for you.  Any civilian ships that survive an encounter get despawned and put back in the abstraction once the alien leaves.

This idea would cut the civilian shipping CPU cost down from O(s) per increment where s is the number of ships, to O(r) where r is the number of trade routes.

[rcj33]

Vandermeer, do you mean that the GU should be loaded into cryo drop modules only? Or will troop transports/PDC barracks work as well?

(Still haven't started my 15B pop game due to deleting and recreating 500ish GU being something i only feel like doing incrementally)

[Vandermeer]

Normal troop transports would work as well, though I just prefer cryo modules because there the troops don't lose morale while being in it. I don't know if morale loss applies when a normal transporter is in planetary orbit though, so it could be ok.(always skipped the tech right for cryogenic transporters)

I am not sure if PDC barracks would work either, because I never had them bigger than for 1 division so far, so the difference wasn't apparent. I see this as risky, because the troops never really get unassigned from their colony here, as they are found just under a dropdown-menu in the troop tab still. Maybe that doesn't factor into the loadup calculations though, so it could be fine.
There is a 13 division fortress PDC currently in the production line of my recent game, so maybe I can report later if it does help or not. Having fortresses is still useful either way, because you can just station your troops there in case of assault then.

[rcj33]

Afaik, troop transport modules don't cause GU to lose morale, only normal drop modules. I wonder if they prevent morale gain? Anyway, I tested and neither orbiting troop transports nor PDC barracks seem to work for reducing the lag. Seems the troops are still counted as being on planet. Do you think something would change with a multi-division PDC? That could be my problem (two divisions each in nine transports, one each in 19 PDCs).

[Vandermeer]

The orbiting ones should work definitely. Do I get that right that you have 18 divisions (not brigades, but full scale divisions)? I was going to bet that you had too few troops to notice the effect, but 18 would be guaranteed to be enough.
Just to confirm this again, I went into my game, where there are currently 7 divisions and 5 brigades stationed on my home planet, and one 5 division transporter to lift most of them away. With ~8 divisions lag is not too bad, but I could stop the clock and found to gain 1-2 seconds easily here.(before 3-5, now 2) To hold against that I went into SM mode and changed all other possible factors gradually, first population to 100b - nothing, then 100mt+ of every mineral + millions of MSP and 100b fuel - no difference again, then thirdly about 20k of every building there is, including naval academies again - a second of drop maybe here, but could be wrong and is nowhere close to the up to 10 seconds you could wait when having well over 10 divisions stationed.

So my best bet is that in fact the troop transports do not work here for some reason. There is a tab under the ground units that lets you display troops from ships in orbit, but that also displays troops in cryo bays... . I think I have two theories for this now.
1. The lesser theory is that the slow-down has to do with morale calculation, because since those stop with cryo bays, that could explain the difference.
2. Much stronger, this all is probably just about the calculation that Aurora needs to make to sort the long list of troops. The way sub-groups like the brigade and divisions get sorted is probably complex, flawed and thus too demanding, meaning the longer the list, the longer (exponentially) the drag. Having troops in PDC or ships can reduce this problem as long as they are partially in there, because that would give you two partial list (and 2x1²<1x2² in matters of loading time). The impact is however gone if you assign all the troops to one of the list, no matter if ground, ships, or maybe even PDC (double unsure here though), because then a single list is just as long again.

Would you mind testing that theory 2 in your game? Easy disprove would be to carry away filled troop transporters a bit from the planet, so they cannot be listed anymore. If that does however work good for the loading times (check the load-up multiple times please, because the first is often always longer), then as second testing stage assign only half the divisions to the transporters, and see if that makes a difference then still.
If it doesn't, then either 2. is wrong or troop bays do indeed not work out the same way, since cryos definitely made a difference here.(even in orbit)

[rcj33]

Yes, the 18 (now 19) divisions were fully manned. I think they are gone now though

I decided to make things a bit easier on myself and built something to hold a few more troops than normal:

Code: [Select]

ARMYWIDGET class Troop Transport    793,600 tons     5110 Crew     27089 BP      TCS 15872  TH 32000  EM 0
2016 km/s     Armour 1-763     Shields 0-0     Sensors 1/1/0/0     Damage Control Rating 1     PPV 0
MSP 21    Max Repair 100 MSP
Intended Deployment Time: 3 months    Spare Berths 0    
Troop Capacity: 210 Battalions    Cargo Handling Multiplier 4000    

AARC 500320 VASIMR-E+ (100)    Power 320    Fuel Use 2.53%    Signature 320    Exp 4%
Fuel Capacity 250,000 Litres    Range 2.2 billion km   (12 days at full power)

This design is classed as a Commercial Vessel for maintenance purposes

Here's what I found in terms of average refresh times:

Nessus (Alpha Centauri B-I, a listening post with no garrison yet): <1s; I counted "one-missi" consistently so probably about one-half. I couldn't measure it accurately with the stopwatch.
Luna with all troops on colony: not timed but seemed like a good while
Luna, troops in TT: 2.6s
Luna, troops in TT with move order but insufficient fuel: 2.5s
Luna, troops in TT at random waypoint: <1s; about the same as Nessus.

Then I put two brigades of each division into a PDC and the other two into the TTs.
Luna, troops split among PDCs and orbiting TTs: 3.4s
Luna, troops split among PDCs and TTs in near space: 2.1s
Luna, troops split among PDCs and TTs at random waypoint: 2.2s

Normal troop transport modules do indeed work for reducing troop lag, as long as they aren't at the colony in question. I shaved off about 2s of load time, which is great news. I'm definitely starting my next campaign with a normal sized pop and adding GU later - 3000 or so operations on the troop management screen killed most of my Sunday evening.

However, the second set of tests didn't prove or disprove your other theory conclusively. To be sure whether distributing storage locations within Stevefire matters, I had to get a control for those tests too, namely a trial where the troops in the TTs didn't exist in the database at all; since I didn't want to disband 210 or so units for 10 minutes, I deleted the TG containing them. So I don't really know the answer to this one, and I don't recommend testing it, either, since I wasn't able to restore from backup for some reason.

Edit: OK. the restore did work, I just wasn't in SM mode. Whew.

[Vandermeer]

Clean examination there. Glad it worked out, but strange that troop transports may not work in orbit like the cryos do. As far as I can see in your data, there is only one test with Luna needed where all the troops you used in the test are neither in PDC or TT, but on the colony itself. If that results in larger loading times than the 3.4s you had for the split, then the problem comes indeed from the list length, and TTs may still help a bit when being in orbit.(as would PDCs)