Development Thread

Okay, one more question. If the tile has no improvement but it does have a not-all-bad feature (Forest), should I show it as improvable if the best build is an improvement that removes it, say a Mine or Cottage? Right now I only show it as improvable if the feature is only bad.

Hmm, no that won't work. This will block Plantations on Silk in a Forest. How about making an exception if the improvement unlocks the bonus on the tile; that should probably flow through first in all cases.

Show as improvable if the build will

1. provide access to a resource,
2. increase a tile yield without losing a good feature or other improvement, or
3. remove a bad feature.

This is like a game of whack-a-mole!

 

You must have misunderstood me, or at least we still aren't on the same page.

If the build adds an improvement to an unimproved tile then that tile is improvable, no matter what happens to any feature.
If the build does not add an improvement but only removes the feature, that tile should be shown as improvable too - no matter if that feature is all bad or all good or something inbetween (though I guess you could limit this case to isOnlyBad() features) - unless the tile already has an improvement which needs that feature.
I'd only ever use isOnlyBad() for the Oasis vs Fallout scenario, where the good feature with isNoImprovement would not be shown as unimprovable.

No further whackign required as far as I can see.

 

The latter.

The reason I am not showing a forest tile that can receive a cottage as improvable is to avoid the case where two forest tiles that can receive the same improvement but only one is circled because only one has a best build for whatever reason (usually riverside).

I figure if you want to clear forest to build improvements, you will. A forest stands out quite well on the map, and my preference is for consistency. Another option would be to ignore best build entirely and do the calculation myself, but I was hoping to avoid that for several reasons.

This case is more clear cut (no pun intended) to me: if clearing the feature doesn't improve a tile's yield, it's not improving the tile. Clearing jungles and fallout improves the tile's yield and will be shown as improvable.

 

I see absolutely no problem with that case. Riverside means -1 +2, whereas non-riverside is only -1 +1

I think an unimproved tile stands out as well, which is why I even suggested not circling unworked improvable tiles.

If there is a best build, then that means there is a value in doing that build, even if it's only the +20 for the next city.

Also I was under the impression that chopping a forest and then building a cottage there does improve the yield at least in the long run, but the best build might be forest chopping in some cases, not the cottage build - because the cottage build (which includes the forest removal) takes longer and thus has less value per build turns because the cottage isn't worth much. Only once the forest is cleared, the best build will be cottage.
For that case alone I'd show forest chopping as improvable, but of course I can see your point.

So, if the best build only removes the featue and the feature isOnlyGood, ignore. I could live with that, I just don't think it's necessary to make that exception.
But please don't ignore any builds that add an improvement to an unimproved tile.

edit: if someone really doesn't want to see any improvement suggestions that would include the removal of a forest, this person can simply use PLAYEROPTION_LEAVE_FORESTS, which will prevent any such build from being considered for best plot build.

 

Ahh, I thought I had that turned on all this time but apparently it got reset a ways back (I never automate workers). No wonder it's recommending builds on my forests! Okay, now I'm fine to remove some of these special cases I have.

Strangely, however, it doesn't seem to honor the option to leave old improvements in the best build. I definitely have that turned on (just checked), and it's recommending a farm for a tile with a cottage (I added the best build display to the plot hover to be sure).

I'm still tempted to add a sub-option for these: Ignore Unworked Tiles. However, an unimproved stone/marble can be tough to spot for me as my vision is quite bad; other bonuses as well. I may highlight improvable bonuses tiles even with that option checked.

The primary use case for this feature is "Help the player avoid unintentionally working unimproved tiles." This is not about gaining from chopping which I think is easy to do without highlighting. "I want to chop. Do I have forests? Yes. Okay, chop!" If I were to have the game point out forests that could be cleared for , I'd want to make sure it did it consistently for all forests--not just those the AI decides are worth it.

 

Yes, leaving old improvements is a different option which is not considered on the bestPlotBuild level.
And a "forest" is defined as a feature that adds to the tile, so PLAYEROPTION_LEAVE_FORESTS will not protect all good features at all times. It does reliably protect the build against gaining value from FeatureProduction (the +20) though.

Ignore unworked tiles (improveable & improved) option is definitely worth the space for another checkbox.

Ok, you convinced me: Ignore forest chopping / OnlyGood feature removal if that's all the build does, for unworked tiles at least. I'm still not sure if a worked forest should show "unimprovable" as well if you can chop it down ..
I guess we can try it your way and see how it goes. If all fails you can make it another option

 

CvMainInterface.py adjustment for AIAutoplay: (scroll to the right ->)

Code:

[COLOR="Green"]# BUG - Attitude Icons - start[/COLOR]
												if (ScoreOpt.isShowAttitude()):
													if (not gc.getPlayer(ePlayer).isHuman() [B]and ePlayer != gc.getGame().getActivePlayer()[/B]):
														iAtt = gc.getPlayer(ePlayer).AI_getAttitude(gc.getGame().getActivePlayer())
														cAtt =  unichr(ord(unichr(CyGame().getSymbolID(FontSymbols.POWER_CHAR) + 4)) + iAtt)
														szBuffer += cAtt
														if (bAlignIcons):
															scores.setAttitude(cAtt)
[COLOR="Green"]# BUG - Attitude Icons - end[/COLOR]

So, are you ever going to commit? Just ignore the forst chops, it really doesn't matter that much.

 

Just rejoining the party here after a couple months off from CIV. I was ecstatic to see the City Tile Status description. Excellent idea if I say so myself:

I agree with Fuyu on this since my first impression of your original implementation was: "there's too many circles." Sounds like you're working that out.

Looking at the SVN logs (and the fact there's no option in my game - unless I really screwed up the merge), I'm thinking you haven't released this yet?

 

Patience is a virtue, my friends. This feature took a lot more play-testing than any of the other BUG features, and I've been very busy IRL. It seems to be in a very good state now: forests are mostly unhighlighted, no more recommendations to road seafood tiles, and now the plot hover text shows which city controls the tile (and in cyan if it's being worked) in addition to any recommended build.

I hope to place it into SVN today.

 

I understand you want to test your new features thoroughly and there is nothing wrong and everything right with that, and I'm not saying you should release the next BULL version to the world this instant. But I'd like to include that new feature in the next Better BUG AI, and since starting monday free time will become very scarce for me, I'd like to try to release that new version before then.

 

I'm away this weekend and didn't have enough time last week to release. That means it will be at least a week before I can do a proper release--but not likely to be more. Luckily the feature is fairly solid.

 

pXML->GetChildXmlValByName(&m_bFemale, "bFemale");
Does that work without an updated schema file?

 

Hrm, when I put in the #ifdefs to guard the <EventImage> tags, you guys said it wasn't necessary. Are you saying now that it is necessary to make them conditional? Or can I just update the schemas for both and it'll work for people without those extra tags in their XMLs?

 

If I remember correctly then defining the tags in the schema with minOccurs = 0 makes it work whether the tags are present or not. Reading a tag from the xml without anything in the schema file should fail with an xml loading error.. but I'm not really sure there
At least in the case of EventImages I ended up with EventArt in the schema..

 

I'll dig into the code for GetChildXmlValByName() to see if it handles a missing tag. I can say that I haven't touched my schema or XML files and am able to load up the game and play. I haven't had a great person pop yet, but the XML is read just fine. I would probably have to add it to the schema if I added <bFemale> to a unit.

I may add it to the schema anyway as long as it doesn't hurt using minOccurs = 0 as you said. That means the least amount of work for a modder to add the tag.

 

Yes, it handles missing tags. It uses the default value of 0, unless you specify a different default. (Or "" for strings, '' for Chars, 0.0f for floats... you get the idea)

 

Thanks for saving me the effort. What would you suggest, then, about the schema? My only hesitation is that I prefer to modify the minimum number of files in BULL because every file I touch makes a file a modder will have to merge to modify it. You're a consumer of BULL so you've been through it.

 

So the answer to my question

.. is yes. As long as there is no bFemale tag in any xml, there's no need for the schema update. Sorry for the confusion.

 

No worries, I'm very happy to know that you're putting that much care into checking my work.

That still leaves the question: should I modify the schema anyway? Would that make it easier or harder on modders?