Caveman 2 Cosmos (ideas/discussions thread)

I have small suggestion: Since we have unit/building upgrade chains in civpedia, can we have improvement upgrade chains too?

Edit: I have suggestion for soft obsoloteness:
Instead of shutting down buildings instantly when tech get researched, make them just unbuildable and lose only some of its benefits.
Such obsolete buildings for example completly lose all benefits after lets say 50 turns.
Some buildings could make use of this.
 
Last edited:
Could there be some way to specify the group size of units before you build them? The delay between clicks in the queue is starting to throw me off and I often end up producing the wrong number without realizing until it's time to group them up on the field. It's not game-killing, but it's pretty annoying. Maybe a set of toggle "buildings" that automatically give the promotions to applicable units in exchange for slowing unit production down?
 
Could there be some way to specify the group size of units before you build them? The delay between clicks in the queue is starting to throw me off and I often end up producing the wrong number without realizing until it's time to group them up on the field. It's not game-killing, but it's pretty annoying. Maybe a set of toggle "buildings" that automatically give the promotions to applicable units in exchange for slowing unit production down?
Interesting idea... I'll have to give that some consideration.
 
I have 2 sanity minor detail suggestions:
First one: for Uranium change enabling tech for Uranium to Quantum Mechanics (same as reveal tech) - mining plain doesn't make sense, as you researched
that tech 5 milennia ago >.>

<BonusInfo>
<Type>BONUS_URANIUM</Type>
<Description>TXT_KEY_BONUS_URANIUM</Description>
<Civilopedia>TXT_KEY_BONUS_URANIUM_PEDIA</Civilopedia>
<BonusClassType>BONUSCLASS_FUEL</BonusClassType>
<ArtDefineTag>ART_DEF_BONUS_URANIUM</ArtDefineTag>
<TechReveal>TECH_QUANTUM_PHYSICS</TechReveal>
<TechCityTrade>TECH_MINING</TechCityTrade> <- should be QuantumPhysics

Second one: (text tech file in xml/text folder)
Description of arrometer engineering is bit wrong:
<TEXT>
<Tag>TXT_KEY_TECH_ATTOMETER_ENGINEERING_PEDIA</Tag>
<English>Attometer Engineering is engineering at the atomic level, no need to waste precious metal for thickness or sturdiness since the structures that will require this type of technology will never get close enough to any gravity field to need a backbone. This differs from nanotechnology as nanites are roughly the size of cells.</English>
</TEXT>
It should be changed to: Maniulating with strong nuclear forces/elementary particles, as this is below quark scale (protons are size of 10^-15m - that is femtometer, attometer is 1000 times tinier)
 
Last edited:
below quark scale
Not really, since quarks are (today believed to be) elementary particles. If that is true, you cannot really assign them a "size". But at 10^-18m you would certainly have to deal with color forces, sea quarks, etc.
 
Not really, since quarks are (today believed to be) elementary particles. If that is true, you cannot really assign them a "size". But at 10^-18m you would certainly have to deal with color forces, sea quarks, etc.
Well by that I just meant really tiny scales, not that quarks are composed of something.
Basically heavy duty quantum magics :mishief:
 
I think that there is currently some misconception: a resources enabled by the same technology (Y) that reveals them.
A the same there are earlier technologies (X) that allow for buildings that absolutely require the resources (i.e. the resources cannot be substituted by other resources , already enabled at time of X) AND an achieving a technology Y requires an achieving a technology X.

Example is Bricks and Governor's Menagerie. Bricks is enabled and revealed by Masonry, Governor's Menagerie may be theoretically build after achieving Chiefdom. There is no way to know Masonry without knowing a Chiefdom.
Civilization that knows Chiefdom and does not know Masonry may import Bricks, but because Bricks is not enabled for it, it is useless.
If Governor's Menagerie would be available with Masonry there would not be practical difference.
 
I think that there is currently some misconception: a resources enabled by the same technology (Y) that reveals them.
A the same there are earlier technologies (X) that allow for buildings that absolutely require the resources (i.e. the resources cannot be substituted by other resources , already enabled at time of X) AND an achieving a technology Y requires an achieving a technology X.

Example is Bricks and Governor's Menagerie. Bricks is enabled and revealed by Masonry, Governor's Menagerie may be theoretically build after achieving Chiefdom. There is no way to know Masonry without knowing a Chiefdom.
Civilization that knows Chiefdom and does not know Masonry may import Bricks, but because Bricks is not enabled for it, it is useless.
If Governor's Menagerie would be available with Masonry there would not be practical difference.
The same can be said for many buildings. They show when the idea of the building becomes obvious but can't be built until a later technology. Quite realistic if you ask me.
 
If really the intention was a technologies that give theoretical possibility of constructing a buildings but under conditions that cannot be fulfilled in any way (until new technologies that require the former), then I apologize for bothering.
 
If really the intention was a technologies that give theoretical possibility of constructing a buildings but under conditions that cannot be fulfilled in any way (until new technologies that require the former), then I apologize for bothering.
It's no bother. It's good to get the impression the player gets from this. There are multiple design theories in use in C2C. I try to keep units, at least, showing up at their most stringent requirement if they have multiple ones.
 
It's no bother. It's good to get the impression the player gets from this. There are multiple design theories in use in C2C. I try to keep units, at least, showing up at their most stringent requirement if they have multiple ones.

Thanks.
Personally I prefer a clear distinction between decorations and things that have actual impact on game.
Currently a "possibility of building" of Governor's Menagerie that Chiefdom gives has such impact on game as citation associated with Chiefdom has impact on game.
The same for Market Scales and Standardization.
Both are actually possible to build respectively, with Masonry (that requires Chiefdom), and with Metal Casting (that requires Standardization).

Enabling a resource (or at least one of resources, if there are alternatives) necessary to construct a building, along with technology that gives the building or earlier, would make the possibility of constructing the building to have a actual impact on game.
Strait consequence of above would be that an importing of such resource from more advanced civilization would make a sense. I do not expect from Civilization IV to be a simulator, but it is quite realistic that a less advanced civilization is importing a things necessary for it, that only more advanced civilization is able to produce.
 
Enabling a resource (or at least one of resources, if there are alternatives) necessary to construct a building, along with technology that gives the building or earlier, would make the possibility of constructing the building to have a actual impact on game.
Strait consequence of above would be that an importing of such resource from more advanced civilization would make a sense. I do not expect from Civilization IV to be a simulator, but it is quite realistic that a less advanced civilization is importing a things necessary for it, that only more advanced civilization is able to produce.
I did try this but it did not work. I can't remember why it did not work. You may want to try it again to see if any of the changes since my try have changed the situation.

There are two tags
  • TechReveal that shows the resource on the map.
  • TechCityTrade that enables the resource to be used.
For manufactured resources I set both to NONE. That should allow them to be traded to and used by players that don't have the tech necessary to build the buildings that produce the bonus.

For map bonuses such as horses or copper having the TechCityTrade occur earlier than the TechReveal tech just meant that both were the TechReveal tech if I remember correctly.
 
Code:
<Define>
       <!-- Set to non-0 value to enable dynamic activation of unit graphics entities (reduced memory usage and growth) -->
       <DefineName>ENABLE_DYNAMIC_UNIT_ENTITIES</DefineName>
       <iDefineIntVal>0</iDefineIntVal>
   </Define>

From A_New_Dawn_GlobalDefines, does this actually work?
 
Code:
<Define>
       <!-- Set to non-0 value to enable dynamic activation of unit graphics entities (reduced memory usage and growth) -->
       <DefineName>ENABLE_DYNAMIC_UNIT_ENTITIES</DefineName>
       <iDefineIntVal>0</iDefineIntVal>
   </Define>

From A_New_Dawn_GlobalDefines, does this actually work?
I can't say for sure if it works, but I saw in the code that viewports activate what ENABLE_DYNAMIC_UNIT_ENTITIES does regardless of what that option is if units leaves the viewport.

TB might want to elaborate here.
 
It should work but I wouldn't suspect it would have a very dramatic effect. It could also mislead a player that relies on thinking what he's attacking is what he's seeing - it may in-fact be a different unit in the stack rather than the one you're able to see on that plot. Small little ways like this that it can tweak the game in the effort to save a dime of processing time - not really much in actual current ram would be saved.
 
I'm still working on the XML editor (it's almost complete), but now I might make a significant change (see quote). This brings up an important question: do you guys have Colonization?
And if you have such an "external" editor, will you still be interested in getting the editor inside your DLL?

It's a good question and it got me thinking. My plan is to finish for M:C and then make a modcomp for BTS, but if more versions are still in use, then what?

Thinking about a proper answer to this question made me realize something really important. Right now the editor is hardcoded to read the path of the DLL and then use that one for reading and writing files. What if it is possible to add an XML file, which tells the path of the mod? This would allow making an editor mod, which can be used on all mods even without modifying the code in those mods. If exe paths are set as well in that new XML file, then editor and mod will not even have to use the same exe file.

The result from this approach is that I can make a standalone editor as a colonization mod and it can be used by everybody regardless of which version of civ4 they mod. It shouldn't be hard to make an editor mod for BTS as well, but using the Colonization version is highly recommended because only the Colonization exe supports drag-n-drop and the editor use that. This means the BTS version will be a worse editor and there is nothing I can do about that.

The only issue I can see with editing a "remote" mod is the button preview. However this can be solved by just copying the Art folder. Most likely a symbolic link will be a better solution, though it takes more skill to set up. Either approach should work.

This requires some thinking and some testing, but I think I'm on to something really interesting here. Making this standalone setup will not prevent mods from including the editor in their own source code. This is just added flexibility.
 
I don't personally have Colonization. But I'm sure such an editor would be certainly intriguing and potentially incredibly useful if it had enough maleability to work with it properly in this kind of environment!
 
I can't say for sure if it works, but I saw in the code that viewports activate what ENABLE_DYNAMIC_UNIT_ENTITIES does regardless of what that option is if units leaves the viewport.
I can't answer the question itself, but I will point out that if you add an int to xml and keep using getDefineINT() to read it, you will slow down the game. getDefineINT is a map, meaning it has to calculate a hash key from "ENABLE_DYNAMIC_UNIT_ENTITIES" each time it's called and then look up using that key. It's much faster to add this to CvGlobals:
PHP:
bool isDynamicUnitEntitiesEnabled() const {return m_bDynamicUnitEntitiesEnabled;}
This then requires setting bDynamicUnitEntitiesEnabled once during startup and it will then be read much faster at runtime.

I have had good result from caching output of frequently called getDefineINT. In fact I have managed to change one call to reading a cache and it reduced the time the AI used by 1%. 1% might not be much, but if it's 0.2% for the next one, and 0.3% for the next, it suddenly adds up to something where you can tell the difference.
 
This brings up an important question: do you guys have Colonization?

I do and your RaRE too. But I'm not a a coder, that's T-brd's department and Toffer too.
 
I do and your RaRE too. But I'm not a a coder, that's T-brd's department and Toffer too.
The editor is intended to be used to edit the xml files using a simple to use interface. This means it's not aimed at coders. Instead it's intended to be used by people who edit xml files, regardless of programming skills. The editor deals with which tags to add and which order etc, while all the modder has to do is to click on bools to toggle, click on strings to pick the right type from a menu etc. It has been used in M:C for testing purposes and it has revealed that not only is it a lot easier to mod xml this way, it's also significantly faster.
 
Top Bottom