Poll: Worst Unit Of The (time interval) Award (IV)

[keith.lamothe]

I realize it is just a debugging log, but on Line 57: reinforcementStrength = max(35,reinforcementStrength) = 2.67
Shouldn't that read: reinforcementStrength = min(35,reinforcementStrength) = 2.67

Quite correct, just fixed it, thank you

Ah, I see now. If the AI overspent to get that last low cap ship, its debt was being "forgiven" when it got around to budgeting the next pulse. Now, it won't be forgiven. It can still get low ship cap ships when it doesn't have enough for it, but the next thing it gets around to will have that much less.

Exactly   Actually, at this point, 1 planet getting a blade spawner can consume all of that planet's reinforcements AND all of the next planet's reinforcements (aside from the buy-a-guardian step, which is free but only gives 1, and only if there's a guard-post/command-station on the planet with fewer than the maximum number of guarding guardians per each), and possibly more than that.  And it's still getting its money's worth, but not a lot more.

Fair enough. I'll let you know if low-ship cap ships start getting to uncounterable numbers in long lived games.

I have the utmost confidence in y'all to do just that

Just read your summary and did not look at the actual logs, but this sounds like it's cleaning up a lot of stuff behind the scenes.

Definitely cleaning up a lot of stuff, I'm really glad I went ahead and did the logging for it, it turns up a lot of stuff.  A year and a half ago or so when I did this for wave calculations there was a ton of stuff there too that was really dodgy but works really well now.

Will have to try another diff 10/10 game once these changes go through, sounds like some of the odd/extreme wave compositions are no longer possible.

This won't impact the wave mechanic, really, though they do use some of the same code and I'll need to check on that, as the intent isn't to nerf waves or whatever (or really change anything that isn't demonstrably a bug), but I think it'll be fine.

[Wanderer]

Thank you, Keith.  In particular in regards to AIs with Maws.  My sanity had wondered how much it had drank with my wits and deductive capability in Mexico.  It's nice to know it didn't swallow the worm.

I'll be very interested, when it's not 3AM, in making sure I understand what you've managed to unearth there.  I get the gist but not the detail right now.

[Wanderer]

If I'm reading this right:

valuating planet 7 (Confederation ) (alerted)  reinforce priority = 0
valuating planet 17 (Shawshank) (alerted)  reinforce priority = 0

Means that an alerted planet doesn't get a higher priority, unless:
valuating planet 43 (Craps) (alerted) (outnumbered, +2000)  reinforce priority = 2000

You've got overwhelming force nearby.

That goes counter to the strategy of 'alert random world somewhere and let it super-alert the boonies'.

This might explain some of the heavier reinforcing we've seen core worlds and homeworlds do when we've never been near them.

Minposts vs. Central Add Count means that the higher your AIP, the less raiding any guardposts will count.  In the first example for Craps, They're getting 7 guardposts worth of reinforcements.  They'd have gotten the full 11 if I had removed the wormhole guardposts in that system.  Raiding IS useless, but only after a certain AIP (110+)

In the second section, the reinforcement decisions, what does this line do:
reinforcementStrength += rand(4,AIDifficulty+3) = 25.4

I'm not familiar with that syntax for the random function.

I'm assuming reinforcementStrength += ((AIP/10) * (AIDiff/10)) = 42.49 takes into account the AI Diff of the owner of the planet being reinforced?

This randomness here seems odd:
reinforcementStrength *= 0.07 = 2.67

Where does .07 come from?  Thin air or some antique design decision?  It almost seems something like
reinforcementStrength *= ( .1 - ( (10 - AI Diff)/100)) = x
would make more sense.  Yes that's a horrible calculation but my brain's not awake enough yet for balancing that.   You get the drift.

This:
reinforcementStrength *= centralAddCount = 18.69

Since there's no significant calculations later for the wormhole posts, this calculation almost appears counterproductive to the resulting strength of the system.  Since the wormhole posts later were only getting +1 strength after all this was done for the command center, yikes.

on the second reinforce in the AI Thread wave, there's no indicator to us which planet it was workign against.  I figured out the first one was Craps, but I'm not sure which the second one is, just that it belonged to the Mine Enthusiast.  Or was that a second reinforcement for Craps?  The next one down seems like it's calling for Confederation to get a reinforcement, even though it had lower priority than the hw/coreworlds.

Code: [Select]

******calling SendGuardPostReinforcements
Dood! Neutered! *mutter*

Bwahahahahah.

This is going to take a few iterations for me to grok entirely, I fear.

[TechSY730]

So, if I am reading this right, minposts is NOT the minimum number of posts that is used to determine how many ships are gotten, but rather the number of posts that once the number of guard posts goes down, the AI will start recieving a buff to how many ships it gets at the other guard posts. However, min posts seems to grow to fast IMO,

Code: [Select]

minPosts = (AIProgressionLevel / 10) = 17

Thankfully, minPosts seems to be clamped at a minimum of 3 and a maximum of 11. But, games will very quickly reach 110 AIP, meaning that very quickly, Guard post rading becomes cheapened.

Also, as min posts - current posts is multiplied straight back in, once you fall below minposts, the AI will not get any reduction in the total budget it will get, happening as soon as 110 AIP. Too low.

So two things, can the denominator of minPosts be increased some (like, AIP / 30 or something)? That way you can get much higher in AIP before guard post raiding is assured to become cheapened.

Two, can the "bonus due to lost guard posts" be made such that it is not enough to completely undo the effect of blowing up guard posts?
Like change it to

Code: [Select]

reinforcementStrength *= max(1, centralAddCount * .75)
or something?



Also, alerted worlds do not get any reinforcement priority bonus? That seems pretty counter to what the wiki states.
Can they get some reinforcement priority bonus? (though maybe not as great as being adjacent to a human or being outnumbered)

[Hearteater]

Yeah, the reinforcement priority seems somewhat odd.  I'll assume there are some other factors that didn't turn up in this example, or that worlds are chosen by treating their priority value as "tickets" in a raffle, and X raffle tickets are drawn (with duplicates ignored).  As opposed to a straight sort on priority, take the top X.

[Wanderer]

Also, alerted worlds do not get any reinforcement priority bonus? That seems pretty counter to what the wiki states.
Can they get some reinforement priority bonus? (though maybe not as great as being adjacent to a human or being outnumbered)

Confederation in that game was adjacent to a human (it sat next to the turretball on Cyborg).  It had no effect.  That wasn't a Dyson alerted world.  That was when I had the Dyson ball on Macross/Twycross/Sushi, and the Dyson was completely covered by friendlies.

[keith.lamothe]

Alerted doesn't increase reinforce priority, it just puts the planet in a separate list which is checked before the all-reinforceable-planets list   Each of those lists is then randomized and then sorted by reinforcement priority.

I'll probably change the planet list to display the order in which they'll actually be reinforced (until it runs out of reinforcements), rather than displaying the scoring as it happens.

Minposts vs. Central Add Count means that the higher your AIP, the less raiding any guardposts will count.  In the first example for Craps, They're getting 7 guardposts worth of reinforcements.  They'd have gotten the full 11 if I had removed the wormhole guardposts in that system.  Raiding IS useless, but only after a certain AIP (110+)

As far as actual strength, that's probably right.  But there are two other consequences:

1) If all the ships get dumped on the command station, they're probably easier to deal with.
2) The fewer guard posts, the lower the population cap on the planet.  Once a planet is over its cap, it is no longer eligible for reinforcement.

In the second section, the reinforcement decisions, what does this line do:
reinforcementStrength += rand(4,AIDifficulty+3) = 25.4

If AIDiff is >= 9 and < 10, this causes reinforcementStrength to be increased by a random number between 4 and 12 (inclusive).  It's just psuedocode (the actual code is a lot more characters), so the syntax being unfamilar does not surprise me

I'm assuming reinforcementStrength += ((AIP/10) * (AIDiff/10)) = 42.49 takes into account the AI Diff of the owner of the planet being reinforced?

No, the player who's doing the reinforcing.  Each AI can reinforce planets owned by the other.

This randomness here seems odd:
reinforcementStrength *= 0.07 = 2.67

Where does .07 come from?  Thin air or some antique design decision?

When I first saw it, it was literally *= 0.07   Why?  That's just the size scale that seemed right, I assume.  Presumably it could be worked into some other step, but the point of the algorithm isn't to have the minimum number of statements, etc.

This:
reinforcementStrength *= centralAddCount = 18.69

Since there's no significant calculations later for the wormhole posts, this calculation almost appears counterproductive to the resulting strength of the system.  Since the wormhole posts later were only getting +1 strength after all this was done for the command center, yikes.

Another rule that's (probably) not apparent here is that after all the normal reinforcements, if the human has a significant military presence on an AI planet that was not just reinforced, then all the wormhole guardposts on that planet get some reinforcement.  I'm not sure how often it is true that the human presence is high enough and the planet is not high enough in the reinforcement list to get a normal reinforcement, however.

Anyway, yes, it does appear that reducing a planet to fewer than min(11,(AIP-10)/10) guard posts actually increases the total strength of the reinforcement spawn.  Right now I'm not really interested in changing the intended function of reinforcements (which this evidently is, Chris wrote all this originally), but I apologize for providing misleading information in the past that indicated differently about this.  I didn't know until doing the logging   And the actual bugs being found I'm certainly happy to fix.  Once we see what it's like actually working properly, we may consider actual deliberate changes.

As a side note, honestly I don't consider it a bad thing if there's not a powerful motive to go around killing every guard post in range: how fun is it to do that, really?  As it stands, I think the population-cap reduction may still be a pretty powerful motive, but we'll see.

on the second reinforce in the AI Thread wave, there's no indicator to us which planet it was workign against.

Which line, specifically?

These are the lines that marked transition to a new call to SendReinforcementsToPlanet, the number of which is determined in the main thread (numberOfReinforcements, 4 in this case) :

***calling SendReinforcementsToPlanet on planet 43 (Craps) reinforce priority : 2000, (overall) strengthBudget = 0
***due to reinforce priority >= 2000, calling SendReinforcementsToPlanet on planet again 43 (Craps)
***calling SendReinforcementsToPlanet on planet 7 (Confederation ) reinforce priority : 0, (overall) strengthBudget = -1.14
***calling SendReinforcementsToPlanet on planet 17 (Shawshank) reinforce priority : 0, (overall) strengthBudget = -0.71

This is going to take a few iterations for me to grok entirely, I fear.

Yep, this one is harder to really explain in a straightforward fashion like wave calculations, and I'm still grokking it myself, so the feedback is appreciated

However, min posts seems to grow to fast IMO

You wouldn't even know it existed apart from these logs, all you see is the much-later end product (and you haven't even seen it since this isn't what's in the public 5.031), so your opinion on a particular step in a long algorithm doesn't really even start a case for changing how reinforcements have been intended to work for over 2 years   Not saying it won't ever be changed, but it's gonna take a lot more empirical trials and such.

[Wanderer]

Alerted doesn't increase reinforce priority, it just puts the planet in a separate list which is checked before the all-reinforceable-planets list   Each of those lists is then randomized and then sorted by reinforcement priority.

I'll probably change the planet list to display the order in which they'll actually be reinforced (until it runs out of reinforcements), rather than displaying the scoring as it happens.

Ah, wait, wut?  You split the lists.  Okay, got that.  Alerted planets are always checked first, cool, good so far.  Then they're randomized?  Oookay, not sure why but okay... and then you re-sort.  Why the final piece if you're going through all that work to randomize, or is it just to randomize the different priority sections?

Out of confusion, how would a coreworld ever get reinforced then in satellite world games?  I don't think it can.

If reinforcements are # of non AI planets / 2, and your average world connects to 1 AI world (I realize you can lockdown a sector, but ignoring that for the moment) then it should be roughly impossible for reinforcements to ever go to HW/Core until you're annoying it and it gets on the alerted list.

As far as actual strength, that's probably right.  But there are two other consequences:

1) If all the ships get dumped on the command station, they're probably easier to deal with.
2) The fewer guard posts, the lower the population cap on the planet.  Once a planet is over its cap, it is no longer eligible for reinforcement.

#1 is a 50/50 proposition, since you can't bait the defenders in pieces, but you're not getting flanked either.  I'd say it ends up about equivalent.  #2 however is a definate component and one of the reasons I neuter/nerf.  However, if it does cap, have you been able to determine if a capped planet hands its reinforcement off to another planet, or does it fizzle?

If AIDiff is >= 9 and < 10, this causes reinforcementStrength to be increased by a random number between 4 and 12 (inclusive).  It's just psuedocode (the actual code is a lot more characters), so the syntax being unfamilar does not surprise me

Ah!  Makes a lot more sense.  And brings the AI Diff into the equation in a way I hadn't realized.  Cool, thanks.

No, the player who's doing the reinforcing.  Each AI can reinforce planets owned by the other.

Hrm, I swear on mega-split AI Diff (2/9) games I saw a different reinforcement volume depending on owner.  I may be misremembering though, I was just getting a handle on the game at the time and it's been a while.

When I first saw it, it was literally *= 0.07   Why?  That's just the size scale that seemed right, I assume.  Presumably it could be worked into some other step, but the point of the algorithm isn't to have the minimum number of statements, etc.

Aye, just seems like after all the other calculation work it really chews into the final value.  Well, it's worked so far, just seemed odd.

Another rule that's (probably) not apparent here is that after all the normal reinforcements, if the human has a significant military presence on an AI planet that was not just reinforced, then all the wormhole guardposts on that planet get some reinforcement.  I'm not sure how often it is true that the human presence is high enough and the planet is not high enough in the reinforcement list to get a normal reinforcement, however.

For me?  Quite often.  I'm usually working 2/3 planets off the nearest friendly planet, so I see these quite often.  Depending on enemy ship composition (snipers, blade spawners, anything with mega-range) it can be quite the hassle.  Thus: Working as Designed.

Anyway, yes, it does appear that reducing a planet to fewer than min(11,(AIP-10)/10) guard posts actually increases the total strength of the reinforcement spawn.  Right now I'm not really interested in changing the intended function of reinforcements (which this evidently is, Chris wrote all this originally), but I apologize for providing misleading information in the past that indicated differently about this.  I didn't know until doing the logging

That's fair, I only knew what I read in the wiki and could see.  But even then the wiki's still a bit wrong, as the cmd center actually appears to reinforce stronger than any guardpost, and will get a stronger reinforcement than the missing guardposts.  I can go edit that eventually once you're able to determine exactly what's happening here, but the comment there about the ratios being better for killing posts is actually inverted.

And the actual bugs being found I'm certainly happy to fix.  Once we see what it's like actually working properly, we may consider actual deliberate changes.

I'm perfectly content with the current reinforcement volumes, I just wanted to be able to better understand them.  However, this knowledge may actually help with the entire stalemate conversation more than some new toy.

As a side note, honestly I don't consider it a bad thing if there's not a powerful motive to go around killing every guard post in range: how fun is it to do that, really?  As it stands, I think the population-cap reduction may still be a pretty powerful motive, but we'll see.

It's always been the only motive for me, the pop-cap.  Aggression removal is necessary if you want to be able to ignore your satellite systems until you can sweep through and do garbage collection.

Which line, specifically?

These are the lines that marked transition to a new call to SendReinforcementsToPlanet, the number of which is determined in the main thread (numberOfReinforcements, 4 in this case) :

***calling SendReinforcementsToPlanet on planet 43 (Craps) reinforce priority : 2000, (overall) strengthBudget = 0
***due to reinforce priority >= 2000, calling SendReinforcementsToPlanet on planet again 43 (Craps)
***calling SendReinforcementsToPlanet on planet 7 (Confederation ) reinforce priority : 0, (overall) strengthBudget = -1.14
***calling SendReinforcementsToPlanet on planet 17 (Shawshank) reinforce priority : 0, (overall) strengthBudget = -0.71

Yeah, I misunderstood something, I didn't realize that world was getting a double reinforcement from the same player.  It might be helpful if the reinforcement choices were spelled out at the beginning of the decision tree so it's more apparent when a double reinforcement occurs.

[keith.lamothe]

Then they're randomized?  Oookay, not sure why but okay... and then you re-sort.  Why the final piece if you're going through all that work to randomize, or is it just to randomize the different priority sections?

Exactly: there are very few distinct values for priority, so the randomize happens before the sort in order to have a sorted sequence of groups, but randomized order within those groups.  Without randomization it would be possible to achieve some very odd "direction" of where reinforcements go based on a planet's actual index in the main planet list.

Out of confusion, how would a coreworld ever get reinforced then in satellite world games?  I don't think it can.

If reinforcements are # of non AI planets / 2, and your average world connects to 1 AI world (I realize you can lockdown a sector, but ignoring that for the moment) then it should be roughly impossible for reinforcements to ever go to HW/Core until you're annoying it and it gets on the alerted list.

If 30 planets are non-AI, it will try 15 reinforcements (16 above diff 8, 17 at diff 10), so unless you have 15 planets alerted some of the non-alerted planets will get reinforced.

But with fewer planets taken, and a larger "surface area" of alerted planets (which is what you mean by "sattelite world games", I imagine), then you're probably not getting any HW reinforcements until it has been directly alerted.

#2 however is a definate component and one of the reasons I neuter/nerf.  However, if it does cap, have you been able to determine if a capped planet hands its reinforcement off to another planet, or does it fizzle?

It simply doesn't reinforce that planet.  It tries, but the function returns false and the number-of-planets-to-reinforce is not decremented, so the AI doesn't lose anything in the deal.

Hrm, I swear on mega-split AI Diff (2/9) games I saw a different reinforcement volume depending on owner.  I may be misremembering though, I was just getting a handle on the game at the time and it's been a while.

Just checked the code again, and it's the player-sending-the-reinforcement's AIDiff.  And it makes sense in the general case: if the AI still has a reinforcement-gate on a planet but the command station has been popped, there is no owning player, but it can still (and will probably, being permanently alerted) get reinforced.

For me?  Quite often.  I'm usually working 2/3 planets off the nearest friendly planet, so I see these quite often.  Depending on enemy ship composition (snipers, blade spawners, anything with mega-range) it can be quite the hassle.  Thus: Working as Designed.

Ah, good to know.  The wormohle guardposts deserve their high marks in the "Player Harassment" category in their annual performance reviews

I'm perfectly content with the current reinforcement volumes, I just wanted to be able to better understand them.  However, this knowledge may actually help with the entire stalemate conversation more than some new toy.

It does certainly warrant dealing with this stuff before adding on new stuff intended to alter the stalemate factor, yes.  Periodic appearance of shiny new toys to blow things up is kind of an occupational hazard, however.

It's always been the only motive for me, the pop-cap.  Aggression removal is necessary if you want to be able to ignore your satellite systems until you can sweep through and do garbage collection.

Another thing I should make clear in the logs; when it says:

GetCanReinforce: pop = 13, cap = (1 * 100) min|max:200,700 = 200, can reinforce

That is:

cap =
(number of non-wormhole guard posts + (1 if command station present))
* (UnitCapScale.AIShipCapPerPost, which is 100 on normal),
min UnitCapScale.AIShipCapMinimum (always 200),
max UnitCapScale.AIShipCapMaxNormal (700 on normal) or UnitCapScale.AIShipCapMaxCoreOrHome (1000 on normal)

The key there being "non-wormhole guard posts".  So killing wormhole guardposts doesn't lower pop-cap.  I did not know that before logging this, but I suspect I should be glad I'm not within your striking distance

It might be helpful if the reinforcement choices were spelled out at the beginning of the decision tree so it's more apparent when a double reinforcement occurs.

I think displaying the sorted list(s) before starting the actual reinforcement loop would be good, yea.

[Wanderer]

But with fewer planets taken, and a larger "surface area" of alerted planets (which is what you mean by "sattelite world games", I imagine), then you're probably not getting any HW reinforcements until it has been directly alerted.

Yeah, where you're just taking 'stepping stone' systems and they get 2/3 alerted neighbors because you're not building that area up for easier defense.  I call them satellite systems because they're just off on their own, praying the AI doesn't see 'em.

It simply doesn't reinforce that planet.  It tries, but the function returns false and the number-of-planets-to-reinforce is not decremented, so the AI doesn't lose anything in the deal.

That's how I'm getting reinforcements on Coreworlds then.  Interesting.  I need to scour more often.

Just checked the code again, and it's the player-sending-the-reinforcement's AIDiff.  And it makes sense in the general case: if the AI still has a reinforcement-gate on a planet but the command station has been popped, there is no owning player, but it can still (and will probably, being permanently alerted) get reinforced.

So, Troop Accellerators and the like?  I think there's a stop on that somewhere.  I had a world for a while with a Troop Accellerator on it that I never popped because of the AIP gain.  I think those reinforce but I don't see one in my current games.  i guess SF posts and the like still do that though.

Ah, good to know.  The wormohle guardposts deserve their high marks in the "Player Harassment" category in their annual performance reviews

Oh, they're gonna get theirs!

It does certainly warrant dealing with this stuff before adding on new stuff intended to alter the stalemate factor, yes.  Periodic appearance of shiny new toys to blow things up is kind of an occupational hazard, however.

That's a different reason.  Shiny toys to blow things up = joyous fun.

Another thing I should make clear in the logs; when it says:
GetCanReinforce: pop = 13, cap = (1 * 100) min|max:200,700 = 200, can reinforce

That is:
cap =
(number of non-wormhole guard posts + (1 if command station present))
* (UnitCapScale.AIShipCapPerPost, which is 100 on normal),
min UnitCapScale.AIShipCapMinimum (always 200),
max UnitCapScale.AIShipCapMaxNormal (700 on normal) or UnitCapScale.AIShipCapMaxCoreOrHome (1000 on normal)

I'm not sure I understand that.  Going to try to rephrase it.

pop = # of ships currently in system.
cap = # posts * 100.  If that value is less than 700/1000, it'll reinforce?  I'm not grokking this explanation.  How does min/max get involved?  I'm quite sure I've seen a lot more than 700 ships on planets.

The key there being "non-wormhole guard posts".  So killing wormhole guardposts doesn't lower pop-cap.  I did not know that before logging this, but I suspect I should be glad I'm not within your striking distance

... 

   Well, that'll make it a bit easier later.

[Wanderer]

Additional question: Is population/cap determined by particular AI player, or is their combined strength evaluated?

[keith.lamothe]

It simply doesn't reinforce that planet.  It tries, but the function returns false and the number-of-planets-to-reinforce is not decremented, so the AI doesn't lose anything in the deal.

That's how I'm getting reinforcements on Coreworlds then.  Interesting.  I need to scour more often.

Ah, right, that does make sense in how it's getting through all the alerted ones to the non-alerted ones.   And the homeworlds/coreworlds get a 500/300 (respsectively) priority bonus and so are sitting right on top of the non-alerted pile, fat and happy.

Just checked the code again, and it's the player-sending-the-reinforcement's AIDiff.  And it makes sense in the general case: if the AI still has a reinforcement-gate on a planet but the command station has been popped, there is no owning player, but it can still (and will probably, being permanently alerted) get reinforced.

So, Troop Accellerators and the like?  I think there's a stop on that somewhere.  I had a world for a while with a Troop Accellerator on it that I never popped because of the AIP gain.  I think those reinforce but I don't see one in my current games.  i guess SF posts and the like still do that though.

Barracks, Troop Accelerator, Mothership, Eye, Alarm Post, Special Forces Alarm Post, Raid Engine, AI Command Station (I-III and Home), Special Forces Guard Post, Warp Gate Guardian, Warp Gate.

Another thing I should make clear in the logs; when it says:
GetCanReinforce: pop = 13, cap = (1 * 100) min|max:200,700 = 200, can reinforce

That is:
cap =
(number of non-wormhole guard posts + (1 if command station present))
* (UnitCapScale.AIShipCapPerPost, which is 100 on normal),
min UnitCapScale.AIShipCapMinimum (always 200),
max UnitCapScale.AIShipCapMaxNormal (700 on normal) or UnitCapScale.AIShipCapMaxCoreOrHome (1000 on normal)

I'm not sure I understand that.  Going to try to rephrase it.

pop = # of ships currently in system.

In this case, pop = # of ships on the planet with player-number = the player doing the reinforcing.  This actually includes minor faction ships which happen to have the same player-number (these are all AI-Ally or Ally-to-All, and all assigned the first AI-player's number, I believe).

cap = # posts * 100.  If that value is less than 700/1000, it'll reinforce?  I'm not grokking this explanation.  How does min/max get involved? 

cap = # non-wormhole-posts
if AI command station is present, cap += 1
if(cap < 200), cap = 200
if(is home or coreworld) { if( cap > 1000) cap = 1000 }
else if (cap > 700) cap = 700

I'm quite sure I've seen a lot more than 700 ships on planets.

As you asked in the later post: the cap is per-player.  So the real cap is 1400 or 2000 (if core/homeworld).  And more ships can wander in or otherwise spawn, of course, just no further reinforcements if it's over that.

... 

   Well, that'll make it a bit easier later.

I'm sure your fire-control officer corps will suffer much lower attrition from terminal boredom

[Eternaly_Lost]

cap = # non-wormhole-posts
if AI command station is present, cap += 1
if(cap < 200), cap = 200
if(is home or coreworld) { if( cap < 1000) cap = 1000 }
else if (cap < 700) cap = 700

Please tell me that last line is a typo, and you meant if( cap > 700 ) cap = 700... Otherwise everything 200-700 gets set to 700 and everything over 700+ is left as is.

[keith.lamothe]

Please tell me that last line is a typo, and you meant if( cap > 700 ) cap = 700... Otherwise everything 200-700 gets set to 700 and everything over 700+ is left as is.

You're correct   I seem to make a lot of typos when trying to explain something...

[Wanderer]

I'm quite sure I've seen a lot more than 700 ships on planets.

As you asked in the later post: the cap is per-player.  So the real cap is 1400 or 2000 (if core/homeworld).  And more ships can wander in or otherwise spawn, of course, just no further reinforcements if it's over that.

No, I'm sure I've seen it MUCH higher, in the 3000 ship range.  I'm going to have to pay more attention.  Maybe boot up a 5/5 game and let it spin on a short reinforcement list.  A mere 1400 ships is very low for a standard world to my mind once I've let it get silly for a while.