Caveman 2 Cosmos (ideas/discussions thread)

[Dancing Hoskuld]

If I changed bFeature to 0 then it would be same as removal of this FeatureBoolean, since its default is 0.

Not necessarily. In the builds file it (0) means can't build the improvement on the feature, not mentioned means you can, and 1 means you can but only after a tech has been researched. I thought that it meant similar on the spawn for map bonuses. Maybe you have to list all the ones that it can instead so as to exclude tar pits.

 

[raxo2222]

Not necessarily. In the builds file it (0) means can't build the improvement on the feature, not mentioned means you can, and 1 means you can but only after a tech has been researched. I thought that it meant similar on the spawn for map bonuses. Maybe you have to list all the ones that it can instead so as to exclude tar pits.

Well in that case tag being 0 is same as tag not existing in entry, if tag being 0 is default - that's how booleans work.

In Builds Info if something was 0, then it would be same as tag didn't exist here if 0 is default.
That is you could explicitly add all default values everywhere and it would be same thing.

That is lets say bTag of 0 is default.
Both entries are exactly same.

<Item>
 <bTag>0</bTag>
 ......................
</Item>

<Item>
 ......................
</Item>

Booleans here have two values (0, 1, one of those is default value for boolean tag if not present), not three: 0, 1 and NULL for when not present in entry.

 

[Dancing Hoskuld]

Well in that case tag being 0 is same as tag not existing in entry, if tag being 0 is default - that's how booleans work.
..

Booleans here have two values (0, 1, one of those is default value for boolean tag if not present), not three: 0, 1 and NULL for when not present in entry.

Not true for all files in vanilla. That is because they don't use them as booleans What I was thinking of was in the BuildInfos file but is based on tech not a tag

 

[raxo2222]

Not true for all files in vanilla. That is because they don't use them as booleans What I was thinking of was in the BuildInfos file but is based on tech not a tag

Tech requirement is normal tag.

<BuildInfo>
            <Type>BUILD_GRAIN_GATHERER</Type>
            <Description>TXT_KEY_BUILD_GRAIN_GATHERER</Description>
            <PrereqTech>TECH_GATHERING</PrereqTech>
            <ObsoleteTech>TECH_SEDENTARY_LIFESTYLE</ObsoleteTech>
            <iTime>200</iTime>
            <iCost>0</iCost>
            <bKill>1</bKill>
            <ImprovementType>IMPROVEMENT_GRAIN_GATHERER</ImprovementType>
            <EntityEvent>ENTITY_EVENT_BUILD</EntityEvent>
            <FeatureStructs>
                <FeatureStruct>
                    <!-- This improvement 'CANNOT' be built on this feature -->
                    <FeatureType>FEATURE_TARPIT</FeatureType>
                    <PrereqTech>TECH_FUTURE_TECH</PrereqTech>
                    <iTime>200</iTime>
                    <iProduction>0</iProduction>
                    <bRemove>1</bRemove>
                </FeatureStruct>
                <FeatureStruct>
                    <!-- This improvement 'CANNOT' be built on this feature -->
                    <FeatureType>FEATURE_CRATER</FeatureType>
                    <PrereqTech>TECH_FUTURE_TECH</PrereqTech>
                    <iTime>200</iTime>
                    <iProduction>0</iProduction>
                    <bRemove>1</bRemove>
                </FeatureStruct>
            </FeatureStructs>
            <HotKey>KB_S</HotKey>
            <iHotKeyPriority>0</iHotKeyPriority>
            <Button>Art/Interface/Buttons/Builds/Button_GrainGather.dds</Button>
        </BuildInfo>

There is FeatureStruct, so boolean tag is part of "configuration" here.
In those cases <bRemove>0</bRemove> could be used as well, as you can't build improvement on this feature until FUTURE_TECH (effectively never).

This is one of very few exceptions.

 

[Thunderbrd]

Not true for all files in vanilla. That is because they don't use them as boolean

This is a deeply false statement. They used this on nearly every nested tag to help them with their initial game design in progress to turn off the nested tag use or to turn it on. If it is 0 in these cases, it simply means its not an active tag. This was used repeatedly by them and I could show you in the vanilla code if you'd like. We have often moved away from using arrays and towards vectors, which they apparently didn't use at all, and in the process, we've been doing our best to eliminate these useless activation confirmation booleans. Nobody who has worked on C2C would go through the effort and data waste of establishing these extra unnecessary bools. We've all seen them as a royal pain in the ass because that's really all they are. They have never meant more when you include a game object and the bool is 0, because these are arrays, and all possible called game objects in these cases are already recorded with a 0 in all possible cases - one of the really data inefficient things about vanilla to begin with.

 

[raxo2222]

@Thunderbrd

XML validator says that bGlobal and bNational tags aren't declared in C2C_CIV4TerrainSchema:

Spoiler :

\Assets\XML\Terrain\CIV4BonusClassInfos.xml:849,3: The 'bNational' element is not declared.
\Assets\XML\Terrain\CIV4BonusClassInfos.xml:849,3: The 'bGlobal' element is not declared.
\Assets\XML\Terrain\CIV4BonusClassInfos.xml:0,0: No validation occurred.

It repeats for all files in Terrain

Are commas fine here?

,m_bPeakMakesValid(false)
,m_iHealthPercent(0)
,m_bDepletedMine(false)
,m_iDepletionRand(0)
,m_iPrereqTech(NO_TECH)
//,m_ppiTraitYieldChanges(NULL)
/************************************************************************************************/
/* Afforess                        END                                                            */
/************************************************************************************************/
,m_PropertyManipulators()
//TB Improvements
,m_bCanMoveSeaUnits(true)
,m_bChangeRemove(false)
,m_bNotOnAnyBonus(false)
,m_bNational(false)
,m_bGlobal(false)
,m_eHighestCostBuild(NO_BUILD)
,m_iHighestCost(0)
,m_iBonusChange(NO_BONUS)

its in cvinfos.cpp

 

[Thunderbrd]

XML validator says that bGlobal and bNational tags aren't declared in C2C_CIV4TerrainSchema:

k... I've fixed it on my end and will commit soon.

Yes, the commas aren't fine, they are required. C++ allows a lot of different expression methods since whitespace doesn't matter there. There's a reason some prefer to put the commas first and others prefer it after, but there must be one between each line in that section.

 

[raxo2222]

k... I've fixed it on my end and will commit soon.

Yes, the commas aren't fine, they are required. C++ allows a lot of different expression methods since whitespace doesn't matter there. There's a reason some prefer to put the commas first and others prefer it after, but there must be one between each line in that section.

Well commas weren't used just above this place where I copied this code.

 

[Thunderbrd]

Well commas weren't used just above this place where I copied this code.

Where the commas are placed can switch to the end or the front, either way.

If it's not right it won't compile.

 

[raxo2222]

Where the commas are placed can switch to the end or the front, either way.

If it's not right it won't compile.

I looked at this file again and it looks like commas switched place right before comment.
So it just looked bit randomly.

 

[Thunderbrd]

I looked at this file again and it looks like commas switched place right before comment.
So it just looked bit randomly.

Yeah, that happens in those lists thanks to the different programmers who have all contributed over the years.

 

[Dancing Hoskuld]

This is a deeply false statement. They used this on nearly every nested tag to help them with their initial game design in progress to turn off the nested tag use or to turn it on. If it is 0 in these cases, it simply means its not an active tag. This was used repeatedly by them and I could show you in the vanilla code if you'd like. We have often moved away from using arrays and towards vectors, which they apparently didn't use at all, and in the process, we've been doing our best to eliminate these useless activation confirmation booleans. Nobody who has worked on C2C would go through the effort and data waste of establishing these extra unnecessary bools. We've all seen them as a royal pain in the ass because that's really all they are. They have never meant more when you include a game object and the bool is 0, because these are arrays, and all possible called game objects in these cases are already recorded with a 0 in all possible cases - one of the really data inefficient things about vanilla to begin with.

Wrong.
In buildings infos

            <BuildingClassNeededs>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_A</BuildingClassType>
                    <bNeededInCity>1</bNeededInCity>
                </BuildingClassNeeded>
            </BuildingClassNeededs>

Is the null case. There is no requirement for building B.

            <BuildingClassNeededs>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_A</BuildingClassType>
                    <bNeededInCity>1</bNeededInCity>
                </BuildingClassNeeded>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_B</BuildingClassType>
                    <bNeededInCity>1</bNeededInCity>
                </BuildingClassNeeded>
            </BuildingClassNeededs>

Is the case where B is required in the city.

            <BuildingClassNeededs>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_A</BuildingClassType>
                    <bNeededInCity>1</bNeededInCity>
                </BuildingClassNeeded>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_B</BuildingClassType>
                    <bNeededInCity>0</bNeededInCity>
                </BuildingClassNeeded>
            </BuildingClassNeededs>

Is the case where building B is required somewhere in the nation not necessarily in the city.

The null and not cases are not equivalent. The loss of this in C2C is, in part, why my projects have stalled.

 

[Thunderbrd]

I don't know who taught you this incorrectly but the first block and the third block are code equivalent. As soon as you place the 0 in bNeededInCity, you make the second BuildingClassNeeded entry invisible in the code. It worked like this in Vanilla as well. Would you like me to walk you through the Vanilla coding to prove it? Because I have worked through every line of it to ensure this is the way it was originally.

 

[Toffer90]

@ DH : Just because you want it to work like that doesn't mean it ever did work like that, wishful thinking can only get you so far...

 

[raxo2222]

Wrong.
In buildings infos

            <BuildingClassNeededs>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_A</BuildingClassType>
                    <bNeededInCity>1</bNeededInCity>
                </BuildingClassNeeded>
            </BuildingClassNeededs>

Is the null case. There is no requirement for building B.

             <BuildingClassNeededs>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_A</BuildingClassType>
                    <bNeededInCity>1</bNeededInCity>
                </BuildingClassNeeded>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_B</BuildingClassType>
                    <bNeededInCity>1</bNeededInCity>
                </BuildingClassNeeded>
            </BuildingClassNeededs>

Is the case where B is required in the city.

            <BuildingClassNeededs>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_A</BuildingClassType>
                    <bNeededInCity>1</bNeededInCity>
                </BuildingClassNeeded>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_B</BuildingClassType>
                    <bNeededInCity>0</bNeededInCity>
                </BuildingClassNeeded>
            </BuildingClassNeededs>

Is the case where building B is required somewhere in the nation not necessarily in the city.

The null and not cases are not equivalent. The loss of this in C2C is, in part, why my projects have stalled.

First and third example are EXACTLY same.
That is your projects stalled because you got confused at some point.
No wonder mod has problems here and there, and some stuff is confusing both for AIs and players.

There is different tag for building required anywhere:

<PrereqBuildingClasses>
                <PrereqBuildingClass>
                    <BuildingClassType>BUILDINGCLASS_B</BuildingClassType>
                    <iNumBuildingNeeded>1</iNumBuildingNeeded>
                </PrereqBuildingClass>
            </PrereqBuildingClasses>

It was a thing since vanilla.
This example means you need one building B anywhere.

That your third example would be this:

             <BuildingClassNeededs>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_A</BuildingClassType>
                    <bNeededInCity>1</bNeededInCity>
                </BuildingClassNeeded>
             <BuildingClassNeededs>  
             <PrereqBuildingClasses>
                <PrereqBuildingClass>
                    <BuildingClassType>BUILDINGCLASS_B</BuildingClassType>
                    <iNumBuildingNeeded>1</iNumBuildingNeeded>
                </PrereqBuildingClass>
            </PrereqBuildingClasses>

......................................................................................................................................
Back in SVN 10241 there were 10 buildings, that had

 <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_B</BuildingClassType>
                    <bNeededInCity>0</bNeededInCity>
                </BuildingClassNeeded>
            </BuildingClassNeededs>

instead of

<PrereqBuildingClasses>
                <PrereqBuildingClass>
                    <BuildingClassType>BUILDINGCLASS_B</BuildingClassType>
                    <iNumBuildingNeeded>1</iNumBuildingNeeded>
                </PrereqBuildingClass>
            </PrereqBuildingClasses>

I changed these errors, so buildings would be actually required by building.
You can recognize them by "Own 1 ..."
One building was bit weird as it had correct and wrong uses of tag on same requirement, something like that:

 <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_B</BuildingClassType>
                    <bNeededInCity>0</bNeededInCity>
                </BuildingClassNeeded>
            </BuildingClassNeededs>
           <PrereqBuildingClasses>
                <PrereqBuildingClass>
                    <BuildingClassType>BUILDINGCLASS_B</BuildingClassType>
                    <iNumBuildingNeeded>1</iNumBuildingNeeded>
                </PrereqBuildingClass>
            </PrereqBuildingClasses>

Spoiler :

For example Animated Movie Featuring Natural Wonder didn't require Wonder of Nature before that change.

This thing never worked:

<BuildingClassNeededs>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_ANIMATION_STUDIO</BuildingClassType>
                    <bNeededInCity>1</bNeededInCity>
                </BuildingClassNeeded>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_NATURAL_WONDER_AUYANTEPUI</BuildingClassType>
                    <bNeededInCity>0</bNeededInCity>
                </BuildingClassNeeded>
            </BuildingClassNeededs>

Spoiler :

As you see there is no NATURAL_WONDER_AUYANTEPUI here.

 

[Dancing Hoskuld]

@ DH : Just because you want it to work like that doesn't mean it ever did work like that, wishful thinking can only get you so far...

That is the way it works in vanilla.

You can't use theiNumBuildingNeeded tag because that changes by map size. If you set it to 1 then it will be 2 on large or huge maps which means you can't build it is every city.

And yes NATURAL_WONDER_AUYANTEPUI was when I discovered it was not working in C2C.

 

[raxo2222]

That is the way it works in vanilla.

You can't use theiNumBuildingNeeded tag because that changes by map size. If you set it to 1 then it will be 2 on large or huge maps which means you can't build it is every city.

It never worked like that in vanilla - test it yourself in vanilla game.
I searched for <bNeededInCity>0 in all xml files in Civilization 4 folder, and there were no such things.

Also there is separate tag to lock iNumBuildingNeeded from scaling when it comes to map size.
<bForceNoPrereqScaling>1</bForceNoPrereqScaling>

One of vanilla buildings - Great Palace - has building requirement set like this:

<PrereqBuildingClasses>
                <PrereqBuildingClass>
                    <BuildingClassType>BUILDINGCLASS_COURTHOUSE</BuildingClassType>
                    <iNumBuildingNeeded>4</iNumBuildingNeeded>
                </PrereqBuildingClass>
            </PrereqBuildingClasses>
            <BuildingClassNeededs>
                <BuildingClassNeeded>
                    <BuildingClassType>BUILDINGCLASS_COURTHOUSE</BuildingClassType>
                    <bNeededInCity>1</bNeededInCity>
                </BuildingClassNeeded>
            </BuildingClassNeededs>

Requires 4 Courthouses anywhere including one in same city.
If you changed bNeededInCity to 0 then you would effectively remove BuildingClassNeededs entry, and it would be just 4 Courthouses anywhere.

 

[Thunderbrd]

That is the way it works in vanilla.

Please test that for yourself before you continue to insist that what has been conclusively proven untrue was somehow true. I'm dead serious - I've read the code on this. What happens is all of the building classes are being recorded a boolean value. 0 is the default and only if a buildingclass is loaded with this boolean set to one will the buildingclass be given a true response on that record. When the 'get' function is called for this in the code, it's really only a boolean call. It only ever asks, was it included or not? Is it true (that this buildingclass is needed) or not? That is the only manner in which this tag is ever accessed. We have not changed or re-established that process. It exists exactly as it did in Vanilla.

Please, do this for yourself. I'm not frustrated with you because I know how it can get when I get something in my head about something and feel like I KNOW I'm right, and how hard it is to get past that. But the code doesn't lie and you should know we have access to the vanilla coding at all times so we can look back and refer to it when we wonder if something went horribly wrong and should be remapped from its original state. Since you insisted on this I dug into it and researched it in full and what I've explained is all there is to it. These bools do nothing but activate the entry being assigned and were, I assume, created to allow for a form of 'commenting out' any entry for ease of testing it. It's not that unlike MLF controls.

It's horrifically memory inefficient of course and they should all be slain at some point to give us a lot more room. I mean, it's a lot cheaper to have the game store a list of 1 or 2 type references in a vector than it is to have an array of ALL buildingclass types, each one maintaining a boolean value in RAM, where nearly all of them are zero anyhow. It was almost like the programmers didn't know that vectors existed, or maybe they didn't exist when the program was written, or they were trying to make things as simple for modders as possible and figured they had limitless memory space.

 

[Toffer90]

That is the way it works in vanilla.

The dll code for that is the same in C2C as in vanilla, identical.
It cannot be different in C2C than in vanilla, period.

 

[raxo2222]

The dll code for that is the same in C2C as in vanilla, identical.
It cannot be different in C2C than in vanilla, period.

I think you should paste code from C2C and vanilla so he actually believes