Fall 2017 Start Position Fix 3

[UglyBoy]

UglyBoy submitted a new resource:

Fall 2017 Start Position Fix - Fixes AssignStartingPlots.lua from the Fall 2017 update.

Fixes AssignStartingPlots.lua from the Fall 2017 update. This should fix it to work as the developers intended, rather than reverting to the Summer 2017 version.

Read more about this resource...

 

[UglyBoy]

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

Apparently I am an idiot

First time making a mod and copied in the wrong .modinfo

Read the rest of this update entry...

 

[Stilgar08]

so what does it improve apart from what has been improved by the Sommer-patch -Lua?
And furthermore: How should I use this? Just copy the AssignStartingPlots.lua into the Base folder of the game?

 

[Atlas627]

1) This is attempting to fix what Firaxis did by making it *work*, not by undoing it. They seem to be trying to fix a bug where some civs would simply not get placed at all because there were no viable spots.

2) Never ever copy a file onto the base game files. Instead, unzip this mod into your Mods folder (which is by default in Documents -> My Games -> Civ6 -> Mods on Windows)

In addition, I'm reporting that I still got other spawns directly adjacent to me. This happened on 2/2 starts, whereas with the vanilla bug I got it on about 1/12 starts. However, I have yet to start in the arctic, so that is a plus.

 

[BWS]

I wonder if there is some subtle bug with how they determine proximity now? That would make the proximity check always fail, and so the fallback code would always ignore it (and later checks). It would also mean that you frequently get arctic/wasteland starts with the unmodded code.

 

[UglyBoy]

In addition, I'm reporting that I still got other spawns directly adjacent to me. This happened on 2/2 starts, whereas with the vanilla bug I got it on about 1/12 starts. However, I have yet to start in the arctic, so that is a plus.

Did you download the mod before or after I posted the update? The original upload was broken because I put in the wrong .modinfo

I haven't had any instances of starting too close. I ran a few test starts before posting this and was been generally impressed with how spread out civs had been.

If there are issues then either I have messed something else up or the improvements Firaxis were trying to make were no good anyway.

 

[BWS]

I was planning to run some tests once I'm done with my current game, to figure out exactly how the script works and how often fallbacks crop up. If you run into any good seeds for reproducing problems, could you please post them?

 

[Stilgar08]

2) Never ever copy a file onto the base game files. Instead, unzip this mod into your Mods folder (which is by default in Documents -> My Games -> Civ6 -> Mods on Windows).

I saved the original file before, of course Furthermore, the quickfix with the AssignStartingPlots.lua was originally exactly that. Thanks anyways!

 

[BWS]

@UglyBoy, if you changed the <= comparisons to < but did not update the fallback scores, there will be one small change in behavior: the game will never choose the fallback with a score of 0. I don't think that's really a problem in practice though, as a score of 0 indicates that the plot passed the "impassible" check but failed the "in water" check, and such a plot is not really playable anyway.

On a tangential note, these validity functions are pretty poorly written. They run all of the checks even after one of them fails, which is pointless and inefficient. The inner loop really should work something like this instead:

local fallback:number = nil
if not test-one then
    fallback = 0
elseif not test-two then
    fallback = 1
elseif not test-three then
    fallback = 2
...
else
    self:__TryToRemoveBonusResource(pTempPlot);
    self:__AddBonusFoodProduction(pTempPlot);
    return pTempPlot
end
if fallback and fallback > iFallBackScore then
    iFallBackScore = fallback
    pFallBack = pTempPlot
end

I guess they did it that way because Lua doesn't support loop continuation, and not all of their checks fit into a simple "if not test" syntax.

 

[Atlas627]

Did you download the mod before or after I posted the update? The original upload was broken because I put in the wrong .modinfo

I haven't had any instances of starting too close. I ran a few test starts before posting this and was been generally impressed with how spread out civs had been.

If there are issues then either I have messed something else up or the improvements Firaxis were trying to make were no good anyway.

After. My third start is playable, but it seems like things are *too* spread out. That is probably indicative of other areas of the world being too cramped, so *somebody* got adjacent starts, just not me.

 

[blackbutterfly]

EDIT: So yes, I see improvement. Maybe not as balanced as previous game starts IMO but better than the clusterf*$% that is the Fall 2017 starts

FYI it seems to me the Fall 2017 patch starts don't impact island maps so much. E.g: Island Plates or Scrambled Southeast Asia. But it totally fails on land maps. Does that help?

 

[UglyBoy]

EDIT: So yes, I see improvement. Maybe not as balanced as previous game starts IMO but better than the clusterf*$% that is the Fall 2017 starts

So in your opinion the changes are worse than the Summer 2017 starts? As I didn't make the changes (only fix Firaxis work) I am trying to gauge whether they were heading in a good direction.

@UglyBoy, if you changed the <= comparisons to < but did not update the fallback scores, there will be one small change in behavior: the game will never choose the fallback with a score of 0. I don't think that's really a problem in practice though, as a score of 0 indicates that the plot passed the "impassible" check but failed the "in water" check, and such a plot is not really playable anyway.

On a tangential note, these validity functions are pretty poorly written. They run all of the checks even after one of them fails, which is pointless and inefficient.

Thanks. I had noticed the 0 check myself but as you point out it makes no real difference as an impassible start is still undesirable.

The way they have structured it makes me think they were trying to build something more, possibly with weightings for passing different criteria, but ran out of time and didn't finish it. I may well try looking into improving it in a similar manner this week. But not as part of this mod.

 

[UglyBoy]

As requested I have uploaded this to Steam Workshop. http://steamcommunity.com/sharedfiles/filedetails/?id=1178781732
I will be updating this one in a minute to match. There are no material changes, but I am slowly figuring out ModBuddy so I put an actual version number on it.

I have also ran a bunch of test runs and had some starts right next to city states. I am going to attempt to fix this ... wish me luck.

 

[CanuckSoldier]

Thanks @UglyBoy I will have my staff at Civplayers do some testing with this, and give feedback. I will monitor this thread for your improvements. Thanks for the hard work.

CS

 

[blackbutterfly]

So in your opinion the changes are worse than the Summer 2017 starts? As I didn't make the changes (only fix Firaxis work) I am trying to gauge whether they were heading in a good direction

No, it's better than Fall '17 Patch but I cannot say for sure RN if it's better than the Summer '17 Patch. They've added more distance between civ spawns as was popularly requested. But o/w the starts previously were pretty balanced IMO.

I will play test a few more maps and let you know. I do want to play a full game as Indonesia first

 

[BWS]

Did the minimum distance between civs increase? That would explain why the fallback code is getting triggered (and why they needed it in the first place). I was thinking this morning of ways to improve this, because right now the distance check is all-or-nothing, and if you fail it you can start at any distance from another civ. It would be better if the fallback included a metric to keep the distance as large as possible when it isn’t possible to uphold the standard value.

 

[blackbutterfly]

Did the minimum distance between civs increase?

Why not revert the spawn algorithm and just use the default to increase the distance between civs? My head hurts just thinking about this

 

[CowGoMoo]

I used this mod as a baseline and made some additional changes which looks to have resolved the issue. I didn't pinpoint the issue (I continually made adjustments until the problem went away, and didn't remove any adjustments to see if they were necessary or not) but civilizations won't spawn on top of each other anymore. You also shouldn't get ridiculous arctic spawns either.

http://steamcommunity.com/sharedfiles/filedetails/?id=1179231808

The final changes I made before civs stopped stacking were in:
AssignStartingPlots:__SetStartMinor(plots)
and
AssignStartingPlots:__SetStartMajor(plots)

I changed the final Return value from "return pFallback;" to "return nill;" for both functions which was the case the previous versions of the game before this Fallback script was added.

I also made a couple minor balance changes to increase the desired production value of the start location and reduced the fertility even further for tundra, snow and ice.

 

[Gedemon]

Did the minimum distance between civs increase? That would explain why the fallback code is getting triggered (and why they needed it in the first place). I was thinking this morning of ways to improve this, because right now the distance check is all-or-nothing, and if you fail it you can start at any distance from another civ. It would be better if the fallback included a metric to keep the distance as large as possible when it isn’t possible to uphold the standard value.

YnAMP's fallback function use a minimal distance scaled on the map size and number of civs selected, and use the smaller value between that calculated distance and what's been set in global parameters. That way it only place civilization at a closer distance than desired if there are too many civs on the map.

It also use a simplified version of fertility calculation to still place civs near fresh water and on the best plossible plots first.

All that's for fallback, if the original game's positioner found a position, it use that one (wich should be fine, it's the game's fallback function that is failing AFAIK)

 

[UglyBoy]

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.