Disabling Properties

[Lyrrix]

I'd like to play a few games without worrying about the Air/Water Pollution properties.... could someone explain for me how I can disable the two properties?

 

[Dancing Hoskuld]

Unfortunately properties are not WoC compatible so modding them is more difficult than usual. As far as I know the only way to disable them is to remove them from all units, buildings and terrain features etc.

 

[Thunderbrd]

You'd have to be a fairly skilled modder to work out how to remove these effectively at the moment.

A game option using replacements could do it but it'd still be a tremendous effort to setup. Even moreso if any semblance of game balance was to be retained. I'd say it's an eventual goal of the mod team to accomplish this though.

 

[Lyrrix]

Okay. Thanks for the feedback. It was more of a "I just don't want to have to deal with this for a few games" thing. I understand it definitely affects the balance, but I'm fine with that in the pursuit of amusement and enjoyment. As in people, so in games... unbalanced can be fun once in a while.

Okay... a little more specific then, can I remove (or zero out the chance for) global warming?

 

[Faustmouse]

Okay. Thanks for the feedback. It was more of a "I just don't want to have to deal with this for a few games" thing. I understand it definitely affects the balance, but I'm fine with that in the pursuit of amusement and enjoyment. As in people, so in games... unbalanced can be fun once in a while.

Okay... a little more specific then, can I remove (or zero out the chance for) global warming?

I think you should be fine to just turn off Hydro's Crime and Disease Folder. And Pollution maybe. This will atleast remove the effects of properties, so you don't have any bad consequences from them. Might lead to a few non-critical XML errors but that's not too bad.

 

[Hydromancerx]

I think you should be fine to just turn off Hydro's Crime and Disease Folder. And Pollution maybe. This will atleast remove the effects of properties, so you don't have any bad consequences from them. Might lead to a few non-critical XML errors but that's not too bad.

But they are more interconnected than those. Those mods have links to my other mods and even stuff outside my mod. That's one reason why they are not an optional setting.

 

[AIAndy]

The easiest way to remove most of the effects of a property is to go to CIV4PropertyInfos.xml, remove all the diffusions and increase the decays to something close to close to 100% (using 100% might cause some problems so it is probably better to use something like 95%). At the same time AI weight of the property should be set to 0 so the AI ignores it.
Note: This does not work on Flammability.

 

[Athmos]

The largest part of the properties code is bugged and no one knows how to fix it. The only properties I have not seen affected by overflow errors is the crime one. It would be sad to deactivate them, but the option would be nice at least until they work.

 

[olduser]

The largest part of the properties code is bugged and no one knows how to fix it. The only properties I have not seen affected by overflow errors is the crime one. It would be sad to deactivate them, but the option would be nice at least until they work.

Why do you think the code is broken? Did you run the game with the debugger attached to see if you get Overflow Exceptions?

 

[Athmos]

No, but I got plus or minus several thousand values at the strangest times for air and water pollution, from v32 onward, once the game gets well advanced, value shifting randomly from turn to turn. After bug reporting and some discussion about it, the most probable cause was narrowed to overflow errors, and TB (I think) got to work on a fix, but the code ramifications are deep and he wasn't able to produce a fix.

Since then, such bugs sometimes happen with disease too, (usually only upward), and in v34 flammability got set to very negative values (minus several thousand) in some conquered cities, while I didn't witness such issues in v32 and v33 with flammability. There might of course be different bugs, this is indeed quite probable. In the end, the properties code is very buggy and behaves as random values each turn in many cases in advanced games (I believe the code start to act "random" when the negative or positive variation becomes too large but I have no proof of that).

This has been reported and discussed in the bug forum several times.

 

[Thunderbrd]

It's interesting to note that apparently taking out trade propagators for properties hasn't stopped those overflows...

 

[olduser]

I still don't see how overflows are possible here because of the low values properties reach. The int datatype has a range from –2,147,483,648 to 2,147,483,647 and those properties reach maybe +-5000. Even without trade they are affected by alot of things like buildings, units, auto-buildings..... Did you run a game with the debugger attached to see if you get any Integer Overflow Exceptions?
Or maybe the bbai.log could help to find the changes in a city causing those fluctuations.

 

[Thunderbrd]

No... I've pretty much decided to step back from it all for a bit. Maybe soon I will. I do want to be able to help them get the Electricity property setup and there's a few adjustments to the property mechanism that'll be necessary for that so some further familiarity might help there.

 

[Athmos]

I still don't see how overflows are possible here because of the low values properties reach. The int datatype has a range from –2,147,483,648 to 2,147,483,647 and those properties reach maybe +-5000. Even without trade they are affected by alot of things like buildings, units, auto-buildings..... Did you run a game with the debugger attached to see if you get any Integer Overflow Exceptions?
Or maybe the bbai.log could help to find the changes in a city causing those fluctuations.

By just looking at the end value, you are being deceived by the deviousness of most overflow errors. This is common, this is probably because of the way the storing ability of a variable type is usually illustrated (-n to +n ), as the really important thing is the number of digits used, and not the value itself.
So, the decimals or other insignificant amounts, and the value of the exponent placing the points are also important. We start and end up with int values, but in the meantime everything has been multiplied, divided, squared, and all that as float values...


I have no proof whatsoever of what I'm going to say, but my personal hypothesis is that the formula computing the changes in the properties from turn to turn probably has a few multiplications and divisions, and the number of digits in the intermediate calculations quickly gets out of hand for an int. This is the first cause of overflow errors everywhere.

I'll try to exemplify the phenomenon, but keep in mind that I don't know the formulas used so I will just invent some possible scenarios where this kind of problems may arise :


Let's say the variation par turn is the addition of the pollution produced by buildings, plus the pollution produced by population, plus a diffused value from the surrounding tiles.

Let's say we have a medium city : 31 populations; as an example, if there is a computation of the square of half the population, with a 31 pop city you get a 240.25 number.

The important thing to notice is instead of having a number with two digits, you get a number with 5 digits. This is the important thing here; multiplications (in particular squaring) often doubles the number of digits needed. 31 could theoretically be stored in a 5 bits variable, you require upward of 16 bits (depending on the precision you use on the exponent to place the floating point) to store 240.25. A double precision float as implemented in C is considered to be able to hold a number with a precision of 16 digits.

Additions and subtractions don't do much to the size of a number (in digits), but any multiplication will likely double it. So when we add our different sources of pollution, even if they all have such kind of relatively simple computations, we'll have a 5 or 6 digits number. If then a second layer of computation is performed on it, for example to implement an "elastic band" effect on it, which is something quite common in video games and often implies some elevation to a power (=multiplications !), this amount easily doubles again.

If there is a third layer applied, whatever the reason (difficulty /game speed adjustment, modification by other overall effects), we can easily imagine another doubling of the number of digits required to keep full precision. For example, if you square a number that looks like the square of 240.25, the results already requires 20 digits to store (5*2*2 = 20) and breaks a double precision floating point storing capabilities, and probably even that of an "extended precision" double float.

This is all imagined of course, and there are in all programming languages fail-safes implemented in all the conversions from one type to another, but if the computations employed doesn't actively curtail its own precision (like discarding decimal numbers after most squaring, multiplications, and divisions operations), it is possible to get overflow errors and "apparently random" values creeping out of seemingly simple computations.

So, the problem probably arises in the intermediate operations that are performed to compute the values used to determine properties variations from turn to turn. If there are several "layers" of computations performed without intermediate conversions to int or similar measure (= rounding down and discarding of the decimal digits), this is in fact a very frequent problem.

Usually a careful look at the formulas used and their implementations to cut down on the precision, discarding negligible bits after multiplications of all kinds (squaring/ elevation to a power and divisions included) is enough to prevent such errors, but apparently the code involved is very convoluted and the modders team hasn't been able to fix it yet.

And I guess, sorry for the wall of of text, but I am starting to suspect that you are not alone in knowing what an overflow error is in principle, but not how they come to happen...

 

[olduser]

I have to look at the code again to see if there are possible spots for overflows. We had some overflows in other areas with much higher values e.g. Culture. Properties just don't reach a very high rate or level. If you have a example save that could also help.

I don't know if i'am completely wrong here, but normally in case of an overflow a exception is thrown. That was at least how i found a few Integer Overflows.


Edit:

I extend the logging to log the rates for those properties every turn.

 

[Harrier]

I have no proof whatsoever of what I'm going to say, but my personal hypothesis is that the formula computing the changes in the properties from turn to turn probably has a few multiplications and divisions, and the number of digits in the intermediate calculations quickly gets out of hand for an int. This is the first cause of overflow errors everywhere.

My programming experience is over 20 years old. But what you just said was valid then, and is probably valid now, despite any improvements in programming compilers .

 

[Thunderbrd]

I know exactly how they happen. What I cannot follow is the madness that is AIAndy's programming methodology. I don't believe there are so many calculations on those figures but he does use math that is about 4 years of schooling higher than my understanding.