Just so I understand... in brief, what's the cause for concern? Is it slower to utilize somehow?
Slower and more memory.
Just so I understand... in brief, what's the cause for concern? Is it slower to utilize somehow?
I don't think it's true that it takes up more memory since a single precision float is the size of a 32-bit integer, unless you would use 16-bit "short" integers instead. It also seems to me that throwing in the occasional floating point calculation could be faster rather than slower. Any CPU made in the last several years (newer being better at it) has a good chance of being able to process some integer instructions simultaneously with the floating point instructions which could, in an ideal situation, get you a few floating point operations essentially for free - they might actually add near 0 processing time if the operation is pretty simple since they are using the otherwise unused floating point units in the core as the integer units keep processing any available independent integer instructions.
Interestingly, on any recent Intel CPU it looks like a 32-bit floating point divide is actually faster than a 32-bit integer divide (this info is seems to be hard to come by - I looked at the "Intel® 64 and IA-32 Architectures Optimization Reference Manual", in appendix C); on any Intel processor back at least a couple of generations doing one divide for a pair of 32-bit integers (assuming they are already in registers) generally takes somewhere in the 14-25 clock cycle range (with a series of them you might get them through as fast as 8 cycles each) but it is apparently only about 6 clock cycles for 32-bit floating point numbers (or one every 5 cycles for a series of them) - it used to be slower for a floating point divide but it looks like that is no longer the case (apparently since the "Enhanced Core Architecture", Family 6 Model 17h, which may or may not be the "Core 2" CPU generation; before that it was 32 cycles rather than 6 for the floating point divide), although there may be latencies in other stages of the processing that this does not account for. Floating point adds are 3 clock cycles (and you can push another one into the multiplier every clock cycle) and multiplies are 5 (a series of them gets one started every 2 clock cycles), but with integers it is 1 for an add (and you can apparently start 3 at a time) and a multiply is 3 clock cycles (and you can start 1 per cycle). So in general the integer math is not all that much faster than the floating point math, especially if there is much division involved. And, of course, the CPU can do both at the same time.
All assuming there really is nothing else going on at the time that is already using the floating point units.
Could I have an ObsoleteTech tag on the buildsinfos in the unit folder. There is at least one urgent one, the plant new forest is a poor cousin to the terraform builds.
Do we have a tag on buildings that lets us change the happiness by religion eg -1 for Zoro and +1 for both Druid and MesoAmenrian? I thought we did but I can't see it in the building schema
<FreeBonus>BONUS_ALCOHOL</FreeBonus>
<iNumFreeBonuses>1</iNumFreeBonuses>
<TechCommerceChanges>
<TechCommerceChange>
<PrereqTech>TECH_ASSEMBLY_LINE</PrereqTech>
<TechCommerce>
<iCommerce>3</iCommerce>
<iCommerce>0</iCommerce>
<iCommerce>0</iCommerce>
<iCommerce>0</iCommerce>
</TechCommerce>
</TechCommerceChange>
</TechCommerceChanges>
I finally found this, about 6 pages back, anyways i need a NEW tag for FeaturesInfos:
Code:<[U]FeatureUpgrade[/U]>FEATURE_FOREST_NEW</[U]FeatureUpgrade[/U]>
Schema info:
Code:<ElementType name="FeatureUpgrade" content="textOnly"/> <element type="FeatureUpgrade"/> <element type="FeatureUpgrade"/>
FeatureUpgrade- If this improvement has a chance to turn into a feature.
Source Code in FfH2 from Kael here: http://forums.civfanatics.com/showpost.php?p=5817028&postcount=1 (about 1/3 of the page down)
(This is what was proposed?)from DH ???
The only solution I thought of was having a burnt forests (burnt_forest_n ... burnt_forest_0) where n was the number of turns on the slowest speed. Then put the correct burnt_forest_k for the game speed on the plot. Then every turn go throw every plot and if it has burnt_forest_i on it change it to burnt_forest_(i-1) and replace it with forest if it was burnt_forest_0.
Way to complicated for me, sorry, its better to have just 1 tag. . .
It's certainly feasible, but if the improvement is on a plot that ALREADY has a feature what should happen? I assume just replace the existing feature? It could add a second one I guess, if the multi-feature stuff is active, but I don't think it is by default (is it?)
It's certainly feasible, but if the improvement is on a plot that ALREADY has a feature what should happen? I assume just replace the existing feature? It could add a second one I guess, if the multi-feature stuff is active, but I don't think it is by default (is it?)
No we have the coding possible for it NOT to have 2 features on the same plot, ie" Great Farmer. This code above is needed for CHOPPING of the forest(burnt) and to have that area then be re-placed by a NEW forest. (At least in theory)
Anyone willing to add a tag to techs for yield changes to types of terrain?
That's usually handled through improvements. If you could justify how this should NOT be handled with an adjustment to or further development on improvements, I'd be interested in hearing what you have in mind.