ViterboKnight
King
- Joined
- Feb 6, 2006
- Messages
- 796
So, ONE line of code of MINE is now in the (un)official patch???
COOL!!!!
Solver's unofficial BtS 3.17 patch
- Thread starter Solver
- Start date
So, ONE line of code of MINE is now in the (un)official patch???
COOL!!!!
Overall ability to do damage there raises as the unit's strength raises. I do see your point, though. Another option that just occurred to me is iCollateralStrength = baseCombatStr() and then iModifier = extra coll. damage, need to run the numbers through that, too.
DanF5771
Emperor
- Joined
- Feb 21, 2008
- Messages
- 1,194
Cool, because that's my code, so I will definitely refrain from presenting contrived counter-examples.
Roland Johansen
Deity
Thanks for looking that up. This will be fun
Heh, I already linked that same post 150 posts ago. Hmm, this thread is moving too fast for you Solver...
However, you don't need just that post. The following discussion in Bhruics unofficial patch thread seems very useful. So, you can find the starting point of that discussion in post 1304 of Bhruics unofficial patch thread. It's better to read that discussion (post 1304-1321) than having to rethink everything.
The way I understood the starting point normalisation code:
The code tries to make the various starting points somewhat equal by improving the poor ones to equal the better ones. It can do that in various ways, by adding food resources, forests and maybe hills or luxury resources. The bug in the code is that it starts with adding forests. Because some starting points need a lot of improvement to get somewhat equal to the best starting points, a lot of forests are added and then there is no room for adding food resources on land tiles. And this of course results in the quite boring all-forest starting positions. The improvement was to start adding some forest, then add some food resources and then add more forest (or something like that).
About the glance screen: It's the easiest way to find out the inter-civilisation relations. I can't think of an easier way to show these relations. I have never experienced a bug in this screen, but I'm using the BUG-mod which comes with its own improved Glance Screen.
deanej
Deity
The glance screen doesn't really offer anything that you can't get without it. If you need to see which AIs hate each other you can use the relations screen. Just click on a leader and you will find out what the other leaders think of them.
Yeah, the Glance screen doesn't provide any information you can't see in the main window. But, it does provide everything on one screen without needing to click around.
I like it, so I reenabled it for 3.17. Still, no big deal if it's included or not in Solver's patch. The only thing I'm using from Solver's patch right now is removing the barrage promotions from tanks. (I'll wait until the other changes get a better testing before trying them out myself.)
I like it, so I reenabled it for 3.17. Still, no big deal if it's included or not in Solver's patch. The only thing I'm using from Solver's patch right now is removing the barrage promotions from tanks. (I'll wait until the other changes get a better testing before trying them out myself.)
Roland Johansen
Deity
The advantage of the Glance screen is that you do not need to click on a leader. Everything can be seen at a glance.
That's the spirit Solver, thanks.
On starting locations:
There are two separate functions called. CvGame::normalizeAddFoodBonuses() is called first to make sure each start location has "enough food". The basic test is "one if by land, two if by sea" (at least one landfood, or at least two seafood). As SevenSpirits points out, the intention is to include an additional clause: "if there is just one food resource, there must also be a tile with 3 native food (e.g. floodplains) or a resource tile with at least 2 native food (e.g. grassland Copper)." The problem is that one landfood is always a resource tile with at least 2 native food. So the additional clause never triggered, and you could be stuck with one plains Cow considered as "enough food". The fix he describes in the first quoted post solves this.
In a second step, CvGame::normalizeAddExtras() is called. The aim here is to balance the starting locations by improving those which need it in several steps:
1, add forests
2, add resources
The "add forests" step loops through all tiles in the BFC. There's a line that's an "if" test based on the number of forests that have been added so far (tracked by the variable iCount). THIS LINE HAS BEEN COMMENTED OUT. Then it checks whether a forest can be added (non-water non-desert and not a resource), adds one and increments iCount.
Because that "if" test is commented out, every single non-resource tile that can support a forest gets a forest. SevenSpirits believes that this was intentional -- his objection is that doing this before step 2 (add resources) interferes with the ability to add resources because forested tiles generally can't accept a resource. So his proposed resolution is to rearrage the code such that universal forestation happens after resources are added, not before.
I disagree that universal forestation was intentional -- why leave the line there, and the variable iCount which is not otherwise used? More importantly, I strongly feel that universal forestation is bad for gameplay -- by forcing early BW, it reduces the variability of the early game. So I would advocate simply de-commenting the "if" clause. If I understand the code right, this would result in typically 3-5 forests being added to those starting positions undergoing improvement.
Then, there are a few more bugs regarding iWaterCount and bLandBias. This was a little more complex than I initially thought it, but I think SevenSpirits has correctly identified the fixes in the second quoted post.
There are two separate functions called. CvGame::normalizeAddFoodBonuses() is called first to make sure each start location has "enough food". The basic test is "one if by land, two if by sea" (at least one landfood, or at least two seafood). As SevenSpirits points out, the intention is to include an additional clause: "if there is just one food resource, there must also be a tile with 3 native food (e.g. floodplains) or a resource tile with at least 2 native food (e.g. grassland Copper)." The problem is that one landfood is always a resource tile with at least 2 native food. So the additional clause never triggered, and you could be stuck with one plains Cow considered as "enough food". The fix he describes in the first quoted post solves this.
In a second step, CvGame::normalizeAddExtras() is called. The aim here is to balance the starting locations by improving those which need it in several steps:
1, add forests
2, add resources
The "add forests" step loops through all tiles in the BFC. There's a line that's an "if" test based on the number of forests that have been added so far (tracked by the variable iCount). THIS LINE HAS BEEN COMMENTED OUT. Then it checks whether a forest can be added (non-water non-desert and not a resource), adds one and increments iCount.
Because that "if" test is commented out, every single non-resource tile that can support a forest gets a forest. SevenSpirits believes that this was intentional -- his objection is that doing this before step 2 (add resources) interferes with the ability to add resources because forested tiles generally can't accept a resource. So his proposed resolution is to rearrage the code such that universal forestation happens after resources are added, not before.
I disagree that universal forestation was intentional -- why leave the line there, and the variable iCount which is not otherwise used? More importantly, I strongly feel that universal forestation is bad for gameplay -- by forcing early BW, it reduces the variability of the early game. So I would advocate simply de-commenting the "if" clause. If I understand the code right, this would result in typically 3-5 forests being added to those starting positions undergoing improvement.
Then, there are a few more bugs regarding iWaterCount and bLandBias. This was a little more complex than I initially thought it, but I think SevenSpirits has correctly identified the fixes in the second quoted post.
Quick note: the bug with iWaterCount resulting in a wrong bLandBias has already been fixed in version 0.17.
As for the rest, I'll try to get some good stuff together for the next version. Will take some time, though, can't produce a new build every day
As for the rest, I'll try to get some good stuff together for the next version. Will take some time, though, can't produce a new build every day
Exactly, civ is about diversity over any other thing, a tough start should be seldomly welcome. That's why I never liked too much that #7 starting location issued above to be included without thorough analisis and consideration from someone who shares this basic point of view.
Keep it up Solver, you are doing a tremendous work here.. wish I could help with more than just my opinion.
Balderstrom
Emperor
*chuckle* that was the whole intent behind the code I presented, though it may not of worked out in practice. That was the general idea.
iColl = Strength, and damage *= extraColl / 100.
Xenomorph
King
- Joined
- Oct 7, 2007
- Messages
- 972
Here you go, then.
[Edit]Added 3.13 python code
You know what would be GREAT? A button you could click on that makes you able to say to your workers: "Don't build any improvements on this tile."
Right now I have to turn off worker automation because they're ruining my future national park. Not removing trees, but building improvements where the trees can grow =(
If this could be done:
Button should be available when you have a worker selected and should count for all workers. Selection should be very similar to "bombing selection", if you know what I mean.
If you were able to do such a thing, I would bow down in awe.
Right now I have to turn off worker automation because they're ruining my future national park. Not removing trees, but building improvements where the trees can grow =(
If this could be done:
Button should be available when you have a worker selected and should count for all workers. Selection should be very similar to "bombing selection", if you know what I mean.
If you were able to do such a thing, I would bow down in awe.
On games with Espionage turned off, when the AI gets the event of an escaped criminal, is it geared to not choose the option of 'interrogate the prisoner'? The Espionage points gained through that event would be fairly useless. A better choice would to either get the relationship boost of returning the prisoner, or deciding it is none of that AI's business.
comatosedragon
Emperor
I assume this means The AI will only change civs during a golden age if the change is beneficial? Not just change for the sake of change, right? And will the AI know, say 5 turns ahead of time that the Taj Mahal (or a great person) will be built, and thus delay a civ change until this time? If so, how far ahead does (can) the AI plan?
Well, of course, it will change if it's beneficial. No planning ahead is involved. It's just that previously the AI had a hard rule to never change civics during Golden Ages and I've removed that rule.
Refar
Deity
- Joined
- Apr 10, 2005
- Messages
- 4,608
Do you know what reason there was for this rule ? It's possible that it was not just
on the dev side...While in GA the economy data is somewhat "falsified" by the effects. If the AI only does concider current state of the economy, without planing ahead or clearing the data from the effects of the GA, the Civic choice might be suboptimal once the GA is over...
No, it's just a mistake from the old rules. Previously, you would get anarchy during GAs. Therefore, changing civics in a GA would be a bad idea, you would thus be wasting some of your GA turns in anarchy, which isn't good. Then golden ages were changed so that no anarchy would be possible during GAs but the AI wasn't informed of that.
