Fall 2017 Start Position Fix 3

[CowGoMoo]

I didn't get much chance to look at this last night, as I actually had a stint playing the game. But the more I look at it the worse it gets. I haven't even started on the fertility function yet!

If the minimum distance has increased then it tallies with what I have been seeing. After getting a few "too close" starts I tried moving the minimum Civ distance up the priority chain of the fall back code. Which only increased "too close" starts and made them closer and more clustered so I assumed it was failing more often and reverted. I should have checked the minimum distance parameter d'oh.

I will hopefully get a good run at this tonight. If it goes well and I continue tweaking then I will have to decide at what point this is just fixes and at what point it becomes a separate mod with improvements.

The FallBack code is clearly causing issues. If you see my above post, when I reverted the functions to return nill instead of pFallBack civs began spawning in a similar fashion to how they have in previous release versions. This is after I reordered and change the fallback score priorities and had spawning too close to another minor and major civ as the first checks after impassable and water.

Feel free to keep messing with this, as I would like to see you made the fallback code work. Once you start looking at fertility, let me know if you can find where bonus resource fertility values are stored. I would really like to tweak those values but I have no idea where those values come from.

 

[beezany]

@UglyBoy Yeah, I was thinking kind of the same thing. I am getting over a cold & jet lag so I haven’t had the time or energy to really dig into this like I’d like. But I had some thoughts of how I would ideally implement this:

First, if the plot is totally undesirable (impassable, in the water), then don’t allow it at all. Second, if the plot has an acceptable distance-to-civs and it passes all of the game-balance checks, then return the plot immediately. Otherwise, determine the “best” plot according to these three metrics:

• distance to other civs (if less than the minimum)
• number of game-balance checks passed
• fertility score

Use distance as the main metric, then game balance and fertility as tie-breakers. If you wanted to be more sophisticated, you could weight the factors instead of just setting up tie-breakers.

 

[beezany]

@CowGoMoo Changing the function to return nil instead of pFallBack essentially changes the behavior back to the pre-patch version (by making the game ignore the extra fallback calculations). Reordering the checks won’t make a significant difference here, because the distance check is all-or-nothing. The root cause of the problem is that, if the game cannot find room for a civ, it ignores the distance entirely, as well as any checks after the distance check. That means that the game is pretty much pulling plots out of a hat once it runs out of room. Worse really, because the most “fertile” plots are probably clustered together after the sort.

 

[CowGoMoo]

@BWS Thanks for the info. If you know the answer, why does the pFallBack code cause this "running out of room" issue to occur while it doesn't normally?

Hopefully someone here can fix FIraxis code, but until then I am just going to play the game without the fallback behavior.

 

[beezany]

@CowGoMoo I haven’t had a chance to dig in & fully understand it yet. However, when I inspected the code the other day, it seemed that the pre-patch code already had some kind of fallback system. I think they tried to improve it with this patch, but instead they made a couple of mistakes that 1. end up throwing civs into wastelands and 2. does a worse job of enforcing minimum civ distances. I’m jetlagged and getting over a cold right now, but hopefully I’ll have some time soon to get to the bottom of how this stuff works and maybe work on some improvements.

 

[UglyBoy]

@UglyBoy Yeah, I was thinking kind of the same thing. I am getting over a cold & jet lag so I haven’t had the time or energy to really dig into this like I’d like. But I had some thoughts of how I would ideally implement this:

First, if the plot is totally undesirable (impassable, in the water), then don’t allow it at all. Second, if the plot has an acceptable distance-to-civs and it passes all of the game-balance checks, then return the plot immediately. Otherwise, determine the “best” plot according to these three metrics:

• distance to other civs (if less than the minimum)
• number of game-balance checks passed
• fertility score

Use distance as the main metric, then game balance and fertility as tie-breakers. If you wanted to be more sophisticated, you could weight the factors instead of just setting up tie-breakers.

I implemented something like this but with: impassable, water, distance less than 5 = instant fail. Then run the remaining fallbacks as before to get a least worst. This looked good for several runs but then I started getting cramped starts again: a few less than 4 and one start with 2 civs side by side. This shouldn't be possible given that I am discarding anything less than 4 tiles apart. So I get the suspicion that some regions/groups of plots are just totally uninhabitable.

I am trying to go one step up the chain now to look at how it gets the list of Plots to check. This is done by StartPositioner.GetMajorCivStartPlots and StartPositioner.DivideMapIntoMajorRegions, but I haven't tracked down the StartPositioner functions anywhere. Does anyone know where these are located? Or are they unmoddable and therefore may have been opaquely changed by Firaxis between patches?

 

[beezany]

@UglyBoy The function starts by setting pFallBack to the first plot on the list, so if the main loop ends up rejecting all plots, then it will resort to that first guess. You could try initializing pFallBack to nil instead of to the top plot. Also, I guess just put in a lot of logging code to see exactly what is going on? Hopefully I will get a chance to dig into this myself soon.

 

[Gedemon]

The startpositioner is not accessible.

He may have changed, but it's not the main issue (else ynamp and the fix using the previous assignstartingplot would be broken too.)

 

[UglyBoy]

He may have changed, but it's not the main issue (else ynamp and the fix using the previous assignstartingplot would be broken too.)

Mostly I agree with you, but it is strange to me. The changes in SetStartMajor and SetStartMinor should make them more likely to return a plot not less and therefore more likely that the number of regions used stays small and less likely that the second loop for failed placements runs.

@UglyBoy The function starts by setting pFallBack to the first plot on the list, so if the main loop ends up rejecting all plots, then it will resort to that first guess. You could try initializing pFallBack to nil instead of to the top plot. Also, I guess just put in a lot of logging code to see exactly what is going on? Hopefully I will get a chance to dig into this myself soon.

You might be right. I assumed that the number of times it completely fails is very low. But that could well be a bad assumption. Depending how the regions are created there could be ones that are entirely water and therefore are doomed to fail. I will try initialising that as nil tonight. And if that fails then start logging like crazy.

 

[UglyBoy]

After a bit of playing I think I have something that fixes Firaxis bugs. Not initialising pFallBack to nil was part of the problem, which then led me to find another problem I had created. When the script finds a plot that passes all criteria it executes
TryToRemoveBonusResource and AddBonusFoodProduction on that plot. For consistency I had added these in for the fallback plot, but these definitely do not like accepting a nil plot. Which led to a lot of unplaced city states.

I have run it a few times and it looks pretty good. I will get a bit of variation in the test runs and then expect an update for the rest of you to test/feedback/play.

 

[UglyBoy]

UglyBoy updated Fall 2017 Start Position Fix with a new update entry:

More fixes added

Based on the discussion thread I added some more fixes.

Read the rest of this update entry...

 

[CowGoMoo]

After looking at this even more and talking to RippedPanda, I think I have it figured out now. Well, he figured it out more so than I, but I contributed a little.
@UglyBoy you fixed it so civs won't spawn on top of each other anymore, but arctic spawns and undesirables are still possible, albeit less common than in the base game currently. See attached image.

The function AssignStartingPlots:__SetStartMajor(plots) looks through the possible starting plots and runs through the list of checks to determine if the plot is good enough for a civ to spawn at. If the current plot being looked at, pTempPlot, passes all of the checks, then it is returned and this plot will be a start location. With the pFallBack code, when a plot is being looked at and it fails any of the checks, it is still returned and that plot, despite failing the checks, will be used as a start location. In previous versions of the game, if a plot failed checks, the return value was nil and that plot was not used. This is the root of the problem.

UglyBoys latest version sets pFallBack to 0 initially, and this value is only increased after passing the check for being near minor/major civs which means the function still returns nil when a plot is too close to other civs, but you still get an undesirable plot returned when the plot fails the other checks after being sufficiently far from other civs since that plot will be returned as long as pFallBack is > 0 while still failing at least 1 other check.

If an insufficient number of plots pass the AssignStartingPlots:__SetStartMajor(plots) function checks then pFallBack should be used, but not prior.



In the image, the start location clearly fails AssignStartingPlots:__GetValidAdjacent(plot, minor) which does not allow that many snow tiles, but the tile is used as a start location (Despite other better locations on the map) since it was checked prior to those tiles and has a pFallBack > 0.

 

[UglyBoy]

Yes, this is my understanding. Like I said previously this was never about improving their code, only about fixing the bugs that were left in. There are a whole series of improvements that could be made over their base code, and I have no desire to defend it. I am actually interested in the communities opinion of whether the Fall changes are an improvement. From the limited testing I have done comparing between my fixes for Fall 2017 and Summer 2017 civs and city states are a little more evenly spread out (I guess because a region is more likely to be used than skipped) but this comes at the expense of a lowering of average quality of starting plot, especially for some city states.

It is subjective enough whether the changes Firaxis tried to make are an improvement. It seems worse on the face of it because plots which are not "perfect" ie pass all their checks can be assigned to civs. But if a plot fails to pass then new plots have to be found for each failure. I am unsure what will happen if all of the regions have been exhausted before all civs and city states are placed. There is a function in SetDefaultAssignedStartingPlots.lua that is described as "A fallback script to assign starting plots if the map generator or World Builder map did not assign a player a starting location" but it only calls a new AssignStartingPlots with different parameters. Without knowing exactly how the arrays of plots are generated by StartPositioner or from where these 2 scripts are called I cannot say for certain if handing out some "least worst" spots is better than only "perfect" spots. My gut thinks this should be better, but it isn't backed up with much evidence.

I totally agree that the way of selecting least worst plots could be improved in a lot of different ways. But it depends what your goal is? Do you want every civ to hit a minimum standard? Do you want each civ to be within a range eg no start too powerful no start too weak? How do you compare relative merit? It is hard enough creating something which satisfies everyone and is balanced and fair, it only gets harder if you get too picky about finding a perfect algorithm where all civs are created equal. This is where my thoughts are going now. With lots of help from the community I have tidied up the mess Firaxis left (the jury is still out on that). But I'm not satisfied with what I have found along the way.

 

[beezany]

One minor suggestion: You might want to configure the mod to turn off AffectsSavedGames, since it does not affect game behavior beyond turn 1 creation. Otherwise, the game will earmark the mod in the saved game & require its presence, even though the game doesn’t really need it after start. This is mostly a hypothetical situation, but it means that all saved games that started with this mod will break if something happens to the mod (e.g., if you take it off Steam Workshop).

 

[beezany]

Also, many thanks for all of your work getting this fix put together and tested and available. I have been pointing folks to this when I notice the topic come up on r/civ.

 

[CowGoMoo]

@UglyBoy Okay, I get where you are coming from then. The one thing I did notice is that previously--mostly just on a crowded map with max civs and max CS--you could have a game with fewer than the specified # of City States if not enough valid plots were found. I think this might be the issue Firaxis was trying to resolve, and with your corrections I believe it has been fixed, however, it can sometimes result in terrible starts for players.

 

[Atlas627]

@UglyBoy Okay, I get where you are coming from then. The one thing I did notice is that previously--mostly just on a crowded map with max civs and max CS--you could have a game with fewer than the specified # of City States if not enough valid plots were found. I think this might be the issue Firaxis was trying to resolve, and with your corrections I believe it has been fixed, however, it can sometimes result in terrible starts for players.

This could happen to Civs too, actually. Sometimes I would check the World Rankings panel and go "wait how were 4 civs already eliminated, its 2500 BC"

 

[UglyBoy]

UglyBoy updated Fall 2017 Start Position Fix with a new update entry:

Disable AffectsSavedGames

Disable AffectsSavedGames

Read the rest of this update entry...

 

[UglyBoy]

@UglyBoy Okay, I get where you are coming from then. The one thing I did notice is that previously--mostly just on a crowded map with max civs and max CS--you could have a game with fewer than the specified # of City States if not enough valid plots were found. I think this might be the issue Firaxis was trying to resolve, and with your corrections I believe it has been fixed, however, it can sometimes result in terrible starts for players.

I have never played a cramped map by increasing the number of civs and city states before. I just ran a test using this mod and on a standard continents map with civs and city states at max they were all placed nicely apart. I have only run one test, and I never played like this on previous patches, but you may want to give this a try if that is how you like to play.

 

[mhIdA01]

I only have the Start Position Fix. I would like to have the complete mod. Can you provide to me