capturing and razing city does not decrease culture cost?

omiman

Chieftain
Joined
Jan 23, 2016
Messages
23
I have captured a city and razed to the ground but the cost is does not change?
Can some one expelling this to me?
 
Razing a city will not increase the cost of the next policy(ie the one you're about to get), but will increase the cost of any subsequent ones if the city is still there. The only way to not increase cost(s) is to puppet, but that increase your tech costs.
 
Incorrect.
The Policy cost is based on the highest number of annexed/founded/razing cities you have ever had. So the first time you capture and raze, your policy cost will go up. But after the razing is done, you get to found/annex one more city 'for free'.

The tech cost is based on all your cities (annexed founded and puppets) at that time (so razing will reduce your costs as soon finished)
 
No that's tech cost. Policy cost is dynamic, tech cost uses the ratchet method.

Policy uses the ratchet method because its exploitable (you can build up culture) [it was exploited in early builds when the per city cost was higher and # of policies was how you won cultural]

It is possible tech uses the ratchet method as well, but tech applies to both puppets and annex... policy only applies to annexed. (and self founded cities for both)
 
national wonders cost ratchets too

Policy uses the ratchet method because its exploitable (you can build up culture) [it was exploited in early builds when the per city cost was higher and # of policies was how you won cultural]

yeah players would sell their cities just before hitting a threshold. per-city increase was also much higher.

this damn ratchet is one of the most annoying things in civ5.
 
The science/culture-penalty per city is lower on huge/giant maps and can almost be neglected compared with the science/culture-output of your cities. I think on huge maps science goes up by only 2% per city, which means that a 50-cities-empire just has double science costs compared to one city only.
 
You know I find it interesting that five years after this game was released people are still debating how the basic mechanics of it works.
 
You know I find it interesting that five years after this game was released people are still debating how the basic mechanics of it works.

Well it's a big game and only some of this can be gleaned from lua files etc. A lot of it you'd have to decompile the code to assembly language which would be a pain to go through trying to find something. So you're stuck with detailed observation of what happens in games and not everyone wants to do that, a lot probably see something happen once or twice and base assumptions on that, I've done it though I don't post about them ;). And of course there have been changes as mentioned above which no doubt adds to the confusion.
 
Well it's a big game and only some of this can be gleaned from lua files etc. A lot of it you'd have to decompile the code to assembly language which would be a pain to go through trying to find something. So you're stuck with detailed observation of what happens in games and not everyone wants to do that, a lot probably see something happen once or twice and base assumptions on that, I've done it though I don't post about them ;). And of course there have been changes as mentioned above which no doubt adds to the confusion.

Anything that isn't exposed in the XML layer is exposed in the DLL code written in C, so knowledge of assembly not needed. However to get this you have to either download the DLL or alternatively download a mod that included DLL changes.
Note that the main things in lua are map scripts and user interface, but in at least one case it is known that logic that should have been in the back end was instead written in the user interface.
For more details, most of the knowledge is in Creation & Customization.
 
Anything that isn't exposed in the XML layer is exposed in the DLL code written in C, so knowledge of assembly not needed. However to get this you have to either download the DLL or alternatively download a mod that included DLL changes.
Note that the main things in lua are map scripts and user interface, but in at least one case it is known that logic that should have been in the back end was instead written in the user interface.
For more details, most of the knowledge is in Creation & Customization.

If it was written in C/C++ then it should have been compiled into machine code and hence would decompile into assembly language. If it was written in .net then it can be decompiled to a higher level, but that still is going to leave you with a lot of undocumented code to sort through.
 
Well it's a big game and only some of this can be gleaned from lua files etc. A lot of it you'd have to decompile the code to assembly language which would be a pain to go through trying to find something. So you're stuck with detailed observation of what happens in games and not everyone wants to do that, a lot probably see something happen once or twice and base assumptions on that, I've done it though I don't post about them ;). And of course there have been changes as mentioned above which no doubt adds to the confusion.

I think the issue is that the basic mechanics are not clearly made available to the players (in part of the civilopedia)... not talking about things like AI behavior but basic game rules.
 
From what I've read, razing immediately after capture (in the dialogue box, "what would you like to do to this city?") Has no affect on policy cost and golden age. Razing from the city-screen will do what everyone has said: acquiring a new city will increase it, but razing a building a new one will keep it at the same level. The game counts total cities you have ever had.

But I play vanilla, without expansions. I may be out of date.

I think the issue is that the basic mechanics are not clearly made available to the players (in part of the civilopedia)... not talking about things like AI behavior but basic game rules.

Oh yeah, the civelopedia is horrible. It insults my intelligence. It doesn't even tell me the movement cost of roads, it just says "faster".
 
If it was written in C/C++ then it should have been compiled into machine code and hence would decompile into assembly language. If it was written in .net then it can be decompiled to a higher level, but that still is going to leave you with a lot of undocumented code to sort through.

Firaxis has provided the DLL as C/C++ source code as a separate download, you don't need to decompile the exe file.
 
Firaxis has provided the DLL as C/C++ source code as a separate download, you don't need to decompile the exe file.

In which case these arguments should not be happening. Just post a reference to the relevant code. But I've yet to see that happen. I think for the same reason (even if you don't have do a decompile): you have a big bunch of C++ etc. code to wade through and figure out the relevant formulas etc. If it's as "well" documented as many coding projects I've looked into that's a problem too.

But still interesting. I'm tempted to look into it and see if I might change some of my major annoyances like city-states asking for you to get rid of a Barbarian camp and then doing it themselves in the next turn or two.

Edit: Well looks like typical C++ code to me. Little documentation, but at least the variable names seem to be fairly explicit. At least now I have a vague idea of how random numbers are being generated anyway. But unless someone who's been working with the specific code for a question that's been asked happens by, my premise still stands--there is a lot of code to wade through to figure out a specific answer and most people aren't going to either be able to do it or have the time to do it, which leads back to my original premise as too why so many differences of opinion: because most of what people know is based on observation.
 
If you are interested in viewing the source, it's a free download from Steam -- in the software tools section of the Library, look for Sid Meier's Civilization 5 SDK.
 
Top Bottom