If it is a new version, there is a chance numbers, hexes, ones and zeroes, have gotten shuffled around.
An inch is like a mile.
May need to find out what/where those variables are for the barns.
Funnily enough, I have a theory why 250 was the max.
Probably a hex overflow problem, or something. I dunno, I'm not a coder. But in the before times, 255 was the magic number for a lot of reasons, in that certain code could only count this high.
Or something.
And 250 is just a round number.
When games have a limit like 255, it's because 2 to the power of 8 is 256. Now obviously 255 does not equal 256 but the reason why it'd be 255 instead of 256 is because we count from 0 not from 1. An 8-bit integer can have any value from 0 to 255. Legend of Zelda only let you have 255 rubies and Pacman could only go do 255 rounds because these values were stored as 8 bit integers. It made a lot of sense during the those times because the CPUs for those platforms were 8-bit and therefore the CPU registers, which are the fastest form of memory on a system, can directly do 8-bit adding, subtracting, etc. But if you were to do 16-bit values on an 8-bit system, this can be several times slower because it has to use at the very least two 8-bit registers to handle one value and it gets even worse if you're trying to do stuff like add a 16-bit value to a 16-bit value (as opposed to adding an 8-bit value to a 16-bit value). Small stuff like this is why it was a big deal when not only later generations got more RAM but they also got 16-bit and later 32-bit CPUs because they could directly handle bigger numbers much more easily. And to get really off tangent, fun fact, the Atari Jaguar was not a 64-bit system, it was more like a dual-core 32-bit system that also had a 16-bit CPU as well.
Anyways a bit more back on topic. To this day it is not unusual for modern games like Half-Life 2 which ran on the source engine to have some stuff stored as 16-bit values for example even though the game was meant to run on 32-bit systems. I read that the map coordinates are stored as 16-bit values and that's why you can't have maps as huge as GTA San Andreas's world map running in the source engine without a lot of black magic. This is probably because bigger limits that are stored as 32-bit values might have meant that even more RAM would've been needed and source engine games ALREADY were frequently crashing due to running out of memory (despite being a 32-bit OS, on Windows XP, a program is normally only allowed 2GB of memory).
As for Breeder's Nephelym, you need to realize that even though the number of monsters is an 8-bit number, each monster has several values associated with it such as: the name of the monster, the stats of the monster (which used to be like 6+ values that had strength, speed, etc. but is now only 3 values iirc), the genetics of the monster, who the monster's parents were, and what physical attributes the monster has in terms of boobs and ass and all that. 2 to the power of 8 is 255, but 2 to the power of 16 is 65,536. If each hut had even 10,000 monsters, I don't think anyone would have enough RAM to store all the information, they'd have to keep loading from the SSD or worse the HDD and the save files would be hella huge too. The game dev, Derelict Helmsman is also not exactly the best programmer (maybe he's smart but he's so damn slow at getting anything done) and probably doesn't want to deal with this problem because he doesn't do that much work these days anyways as it is.