I noticed that several mapscipts have something wonky going on with how often certain ressources appear on a map. I've recently been plagued by maps that e.g. have only one or two iron deposits while having gold and tin everywhere. This is both unrealistic (iron is the 4th most abundant element in the earths crust while tin and gold are both relatively rare) and a potential gamebreaker, as not having iron pretty much prevents you from building anything usefull after the classical era.
Ressource frequency
- Thread starter force200
- Start date
It's an issue with xml values set for bonuses, and of the fact that we have so darned many map bonuses in C2C.
To get an accurate relative amount of each bonus as they are defined in xml, one should actually choose a big map size and reduce the amount of resources the map script provides, this will ensure that there's plenty of spots to put each bonus; problem is often that bonus A cannot be placed anywhere because there's already too many bonuses on the map that occupy all the plots that are valid placement plots for bonus A.
It can potentially be fixed by reworking XMl a lot, but it would require a lot of trial and error and analytics to get right, alternatively we may perhaps need to rethink the bonus placement code algorithm and logic we currently have established.
Most mapscripts use the same algorithm.
In world mapscript I recommend 50-75% bonus amount regardless of map size to minimize the amount of bonuses that are blocked during placement by other bonuses placed earlier in the priority queue.
Edit: {
To get an accurate relative amount of each bonus as they are defined in xml, one should actually choose a big map size and reduce the amount of resources the map script provides, this will ensure that there's plenty of spots to put each bonus; problem is often that bonus A cannot be placed anywhere because there's already too many bonuses on the map that occupy all the plots that are valid placement plots for bonus A.
It can potentially be fixed by reworking XMl a lot, but it would require a lot of trial and error and analytics to get right, alternatively we may perhaps need to rethink the bonus placement code algorithm and logic we currently have established.
Most mapscripts use the same algorithm.
In world mapscript I recommend 50-75% bonus amount regardless of map size to minimize the amount of bonuses that are blocked during placement by other bonuses placed earlier in the priority queue.
Edit: {
Yeah, the world mapscript adds a lot of info to the pythonDbg.log, and it is obvious that iron has too weak xml values from this log:
Desired amount is the max amount it will attempt to add, based on some numerical XML values from the bonus's XML entry. Density count is derived from and xml value and is relative to the map size chosen. Multiplier at 0.5 is just me who selected 50% resources in game setup options for the mapscript. This log is a very good tool to use when adjusting the bonus XML, it's helped me in the past solving some issues with specific bonuses not being placed well.
later in the code it will inform you of which order bonuses are placed in, how many were placed and how many were desired; also a useful part of the log
}Spoiler log screenshot :
later in the code it will inform you of which order bonuses are placed in, how many were placed and how many were desired; also a useful part of the log
Spoiler log screenshot :
Last edited:
Similar threads
