How to Restrict Improvements to Not Be Adjacent to the Same Improvement?

[Bleser]

I'd like to implement a restriction on a number of improvements that already exists for a number of improvements in the game.

I find a number of improvements to be too "spammable", like fisheries, the new offshore wind farms in GS, and others.

What I want to do is change their parameters so that they cannot be built next to another of the same kind, so if you build a fishery on one tile you can't build it on any adjacent tiles.

I tried this:

UPDATE Improvements SET SameAdjacentValid = 0 WHERE ImprovementType IN
('IMPROVEMENT_FISHERY','IMPROVEMENT_OFFSHORE_WIND_FARM','IMPROVEMENT_SEASTEAD');

...but it didn't seem to work; I built a fishery and it let me build another one next to it.

Does anyone know the parameters that need to be changed for this?

 

[Cosmic Fox]

Why on earth would you want this? Farms for example gives more food side by side then alone later in the game. Improvements are just that, improving tiles is what the game is all about. Good luck..

 

[Bleser]

I'm only wanting to do this to a few of them - all water based - as they seem far too powerful to be put on every applicable water tile. I've seen the AI just carpet the water with the wind farms and seasteds, and at least visually it wrecks the game for me. So, I know the mechanic exists, and I just want to see how to tap into it.

 

[Infixo]

There are unique improvements that cannot be place adjacent to one another e.g. Alcazar, monastery, etc. Check them.

 

[isau]

Your code should work. There may be some other issue with your mod.

Load up SQLite Studio or a similar tool and run a query like:

select ImprovementType, SameAdjacentValid from improvements

See if the update is actually being applied. If it isn't your issue is somewhere other than the code.

Check Database.log as well to be sure you don't have an error somewhere else.

 

[LeeS]

check the action's LoadOrder setting. The update may be occuring before GS even loads: if so, there would be nothing for the "Where" clause of the update to match-to. Database.log will not be sent an error in such a case because no syntax or unique constraint or missing reference error is occuring.

Seems like 9 times out of 10 with the Xpacs the underlying issue is a LoadOrder problem.

 

[Bleser]

Your code should work. There may be some other issue with your mod.

Load up SQLite Studio or a similar tool and run a query like:

select ImprovementType, SameAdjacentValid from improvements

See if the update is actually being applied. If it isn't your issue is somewhere other than the code.

Check Database.log as well to be sure you don't have an error somewhere else.

check the action's LoadOrder setting. The update may be occuring before GS even loads: if so, there would be nothing for the "Where" clause of the update to match-to. Database.log will not be sent an error in such a case because no syntax or unique constraint or missing reference error is occuring.

Seems like 9 times out of 10 with the Xpacs the underlying issue is a LoadOrder problem.

@isau is correct - I opened SQLLiteStudio while the game was running and sure enough none of the SamAdjacentValid fields were changed like my modification had requested them to be.

What I don't understand is how to fix it. One of the ones I'm modifying is part of the base game (fishery), so it has nothing to do with GS, and it also didn't change. My mod's load order is 100 - I changed it to 1000 and that didn't make a difference. Maybe it doesn't like my IN clause? I don't get it because when I test in SQLLiteStudio offline it works (affects three rows, all go to zero).

 

[LeeS]

Works fine for me with an action LoadOrder of 150 so far as altering the Column in the Database goes.

LoadOrder must be stated as part of an individual action's properties. If you were doing LoadOrder as part of the mod's properties, this will be the reason for the LoadOrder failure.

 

[Bleser]

Works fine for me with an action LoadOrder of 150 so far as altering the Column in the Database goes.

LoadOrder must be stated as part of an individual action's properties. If you were doing LoadOrder as part of the mod's properties, this will be the reason for the LoadOrder failure.

Yes, this is exactly what I've been doing - setting LoadOrder in the mod properties field.

I found you post here that explains it and I'll try that - thanks!

 

[Bleser]

...and I can confirm after making changes in my .modinfo file with your suggestion that the adjacency improvement values are updated! Thank you!