Prerelease 3.158 (Performance+, 2 new forts, AI cmd stations, flak balance)

[superking]

sounds good, quick turnaround as usual  !
except...

   * Flak turret attack power moderately decreased against ships outside its specialty.

ohh nooo   in my current game my wave-receiving planet's defence is MK III flak based, lol

[superking]

oh man, i updated and it ruined my game  

for some reason all AI planets reinforced massively with defences and fortresses spawned on several neutered planets, argh

edit:

infact, fortresses spawned on almost every single AI world.

[Buttons840]

Fortress should be easier to protect inside a turret ball because they no longer need to move, they have the range to hit anything.

[Tusoalsob]

Hy just updatet and a III system witn 600 ships in kills my 1,7K force with level III ships as well at the entery in seconds.

only the starships survive after 10 sec, can it be that there is a mistake by the Flak turrets or the lightning shuttels ? ( the only ships in that system that do AOE damage )

else i can't see why my fleet is riped to piese. ok Lightnigshuttels are bad for frigates but III fighter or III bombers shoud survive more than 10 sec and the flak shoud't kill them in that time.

Ok must i just start a new game ?


edit:

after some more loading and trying the fight ti seems that flack III turrets kill bombers/fighters III in 3-4 shoots ?

[Buttons840]

Ugh!  Game breaking bugs with the new target finding routines.  (I've reported them in bug section.)

My game never slows down on my 2.6 ghz quad core, and every CPU based improvement makes things worse from my experience.

Just this last game I watched a single Z Bomb enter and race past my riot starship, it was never detected by the targeting loop before it hit it's target, no attempt was made to stop it - the riot could have killed it's engines.  For several versions now there have been a few ships which are very slow to respond - example, the FRD blob will send most of it's ships against enemies very quickly, but there are always a few ships which just wait around for another few seconds doing nothing.

The more primitive routines in older versions never had these problems.

[x4000]

Signata -- glad that fixed it and it's working now!

superking -- yeah, a lot of AI planets get the extra Mark I/II fortresses seeded in, but it shouldn't be nearly all of them.  At difficulty 7, it should be roughly a 70% chance of one on each Mark III/IV planet, and none on any other planets.  The lower-level fortresses are about as common as ion cannons with that.

Tusoalsob -- yeah, I had a similar experience the other night, and the flak reductions in this release were meant to counter that.  We're planning another change that should prevent those even more.

Buttons840 -- I haven't seen your post about the target-finding routines.  But, if you think that the older, simpler target-finding routines never had that, you just haven't been around here long enough.  The recent batch of performance-improving stuff post-3.060 has made the time-to-start-killing-stuff way shorter, while also affecting the CPU in hugely desirable ways.  Great that you haven't seen any slowdown, but plenty of others have with various scenarios, so I'm not exactly planning to just go back to raw loops.   Thanks for bearing with us.

[superking]

new forts are brutal  can keep even a neutered IV world empty almost indefinately if you are willing to pay the upkeep

[x4000]

new forts are brutal  can keep even a neutered IV world empty almost indefinately if you are willing to pay the upkeep

That's actually a super-cool use for them that I hadn't thought of.  Keeping travel lanes open via them seems like a superb idea!

[superking]

well, thats the only way I can see them justifying a continous 30k energy cost 

[Signata]

This just started for me, I had four riot ships at a location, and I sent two of them through the wormhole to the beachhead and now those two won't sit still. They are constantly moving around as if trying to find a spot to settle down in a cluster, only there is nothing around them at all. I pulled them back into the defensive side of the wormhole to see if it was something related to being on a non-owned planet, but now those two are behaving the same on this side as well. The original two riot ships that I never gave any movement orders are holding steady, it's just the ones that I gave move orders to today. I believe they haven't been moved since the last round of updates. The shifting tends to end up with them eventually far away from where they are supposed to be.

Update: To test things further, I saved the game and then moved the two, static, riot ships to see if the behaviour would reproduce in a friendly planet with no enemies present and indeed now all four are dancing around as if they really have to pee.

[Buttons840]

This just started for me, I had four riot ships at a location, and I sent two of them through the wormhole to the beachhead and now those two won't sit still. They are constantly moving around as if trying to find a spot to settle down in a cluster, only there is nothing around them at all. I pulled them back into the defensive side of the wormhole to see if it was something related to being on a non-owned planet, but now those two are behaving the same on this side as well. The original two riot ships that I never gave any movement orders are holding steady, it's just the ones that I gave move orders to today. I believe they haven't been moved since the last round of updates. The shifting tends to end up with them eventually far away from where they are supposed to be.

Update: To test things further, I saved the game and then moved the two, static, riot ships to see if the behaviour would reproduce in a friendly planet with no enemies present and indeed now all four are dancing around as if they really have to pee.

This has been fixed.  Or rather, will be fixed in the next update.

Buttons840 -- I haven't seen your post about the target-finding routines.  But, if you think that the older, simpler target-finding routines never had that, you just haven't been around here long enough.  The recent batch of performance-improving stuff post-3.060 has made the time-to-start-killing-stuff way shorter, while also affecting the CPU in hugely desirable ways.  Great that you haven't seen any slowdown, but plenty of others have with various scenarios, so I'm not exactly planning to just go back to raw loops.  Thanks for bearing with us.

I just call em like I see em (as they say) - I've never noticed such problems in older versions.  I remember a time when FRD blobs would all move at the same time, rather than the current behavior where several ships wait around for another few seconds (as I mentioned earlier).  Perhaps my memory fails me?

Please never take my criticism as a lack of appreciation for you hard work and frequent improvements.

[wyvern83]

         o The AI command station variants have 5X more health than their human counterparts

24 out of 46 AI non-core worlds left in my game are mk3 or mk4 and I've recently taken to Raider CC blitzing. With the numbers I was using before I could probably still do it but replacing near max-cap of 3 mk's of raiders takes alot of time. I threw away over 3300 Raiders to snipe a chain of 4 systems, with the very last raiders dying before the killing salvo even landed.

That this is a significant health buff would dampen this tactic considerably to say the least. Given that my objective in this campaign is to glass it all, I think I'll be finishing my current campaign before updating to this beta release.
 

[keith.lamothe]

Please never take my criticism as a lack of appreciation for you hard work and frequent improvements.

Sometimes tone really doesn't come across on the internet, but I've seen enough of your fussing to realize it isn't ungrateful fussing

As for not seeing any slowdown I'm actually very curious what folks consider to be non-slowdown, and what normal usage is really like.  For me even on pretty good machines I see 50% or more slowdown (i.e. 300+ millisecond turns instead of 200ms) in relatively mild battles of 2000 ships kicking down the door into an AI system with roughly as many ships, etc.  If you hit F3 during the game you'll get a variety of performance statistics including the lines "Last Process/Render MS" (sim time and render time for the last cycle, but changes really quick), "Last Turn Avg Process/Render MS" (average of last 4 cycles, iirc, somewhat more stable and useful), and "Last Turn Part/Full MS" (first number total of sim and render for last 4 cycles, second number is that plus any artificial delay to bring it up to 200ms, though I might not be reading it right).

And like Chris said we haven't seen your post in the bug forum; I'd have responded sooner otherwise.

Anyway, the changes I made _should_ not be affecting the rate at which units get their target lists, as I didn't really touch the throttling code or the "is this unit eligible for a new list" code, etc.  I've certainly made changes in the past that caused a lot of problems there, and one point between 3.060 and 3.120 FRD was bordering on uselessness, but I made several changes to prioritize units in certain circumstances and ensure that every unit would eventually be "gotten around to" at some point, etc... and everyone was really happy with FRD and all that again.  Currently there is a hard rule that a unit cannot get a target list if it got one within the last two game-seconds, and perhaps that is causing issues, though I get the impression from what you're saying that it's worse than that.  Anyway, if you could make sure that your bug report is actually in the forum (and give me a link if I'm just being stone blind), and give a save if you've got one, I can take a look and see if anything untoward is going on.

Like I said, the changes shouldn't have been a problem for that, but I did do some pretty major refactoring of some fairly core logic (mostly collision checking, but also the actual computation of a target list, and movement code), so I'd be shocked if I didn't break *something* in that process.  As-is the only reported bug that I've confirmed came from it was the Riot's ants-in-the-pants situation, which was pretty funny.

Anyway, thanks for the testing, hopefully we can get the targeting stuff ironed out.  Actually, considering that this last batch of cpu improvements may well have increased sim performance by 30% in heavy battle situations, we may be able to use some of that in opening up the target-list throttles a bit more (or reducing that hard two-second delay, etc), but first I want to make sure I know what the actual bottleneck is for those ships.  We've got the ants out, now to get the lead out

[x4000]

Buttons840 -- No worries, as Keith said.  I just wanted to make sure that you weren't thinking we were just faffing about with performance for no reason, for kicks or whatever.

wyvern83 -- True, you can't go through and just snipe every command station now, like you could before.  It's a lot harder to bum rush certain planets because of this, and that's by design.  Having to have a certain minimum threshold of firepower on an enemy planet to destroy the AI command station makes the "cap the command station and wait for the influx to my systems" strategy a bit more difficult, but not impossible by any means.

Interesting notes, though, just FYI it's actually worse than just 5X what it was before.  That's for the mark I command stations.  Mark II and III are already something like 2x and 3x more health than the base mark I, so with the AI command stations on the mark III and IV planets (which use higher-tier command stations now), cumulatively that's an increase of 10x and 15x on them, rather than the base 5x of the mark I and II planets.

Not trying to make life difficult, but this should... well, yeah, make things a little more difficult (hopefully in a good way). 

[wyvern83]

Interesting notes, though, just FYI it's actually worse than just 5X what it was before. 

I'd noticed, 1.5 million for a mk3 world, 3 million for a mk4 world if I did the math right.

I understood the intent behind the idea immediately as my tactic alone proves it's necessity. It was inevitable that something like this would be done, if only to further diversify the terrain of the map. So I'm not saying it wasn't the correct thing to do, just that I'm naturally hesitant to update because I know what it's for.   

I may update anyway, but I'll have to think about the other ramifications first. I want to finish up cleaning out those 4 worlds first in any case as a precaution against having 'new' stuff show up in out of supply worlds that would complicate things. I have yet to claim any of the 15 worlds I've glassed recently for the purpose of keeping a unified front and I don't want any unpleasant surprises at this point.