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: {
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
}