1. We have added the ability to collapse/expand forum categories and widgets on forum home.
    Dismiss Notice
  2. Photobucket has changed its policy concerning hotlinking images and now requires an account with a $399.00 annual fee to allow hotlink. More information is available at: this link.
    Dismiss Notice
  3. All Civ avatars are brought back and available for selection in the Avatar Gallery! There are 945 avatars total.
    Dismiss Notice
  4. To make the site more secure, we have installed SSL certificates and enabled HTTPS for both the main site and forums.
    Dismiss Notice
  5. Civ6 is released! Order now! (Amazon US | Amazon UK | Amazon CA | Amazon DE | Amazon FR)
    Dismiss Notice
  6. Dismiss Notice
  7. Forum account upgrades are available for ad-free browsing.
    Dismiss Notice

Development Thread

Discussion in 'Civ4 - BTS Unaltered Gameplay (BUG, BAT and BULL)' started by alerum68, Sep 2, 2007.

  1. EmperorFool

    EmperorFool Chieftain

    Joined:
    Mar 2, 2007
    Messages:
    9,633
    Location:
    Mountain View, California
    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! :D
     
  2. Fuyu

    Fuyu Chieftain

    Joined:
    Nov 5, 2009
    Messages:
    1,220
    Location:
    Austria
    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.
     
  3. EmperorFool

    EmperorFool Chieftain

    Joined:
    Mar 2, 2007
    Messages:
    9,633
    Location:
    Mountain View, California
    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.
     
  4. Fuyu

    Fuyu Chieftain

    Joined:
    Nov 5, 2009
    Messages:
    1,220
    Location:
    Austria
    I see absolutely no problem with that case. Riverside means -1:hammers: +2:commerce:, whereas non-riverside is only -1:hammers: +1:commerce:


    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:hammers: 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.
     
  5. EmperorFool

    EmperorFool Chieftain

    Joined:
    Mar 2, 2007
    Messages:
    9,633
    Location:
    Mountain View, California
    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 :hammers: 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 :hammers:, I'd want to make sure it did it consistently for all forests--not just those the AI decides are worth it.
     
  6. Fuyu

    Fuyu Chieftain

    Joined:
    Nov 5, 2009
    Messages:
    1,220
    Location:
    Austria
    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 :hammers: 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:hammers:) 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 ;)
     
  7. Fuyu

    Fuyu Chieftain

    Joined:
    Nov 5, 2009
    Messages:
    1,220
    Location:
    Austria
    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.
     
  8. _alphaBeta_

    _alphaBeta_ Chieftain

    Joined:
    Dec 28, 2005
    Messages:
    976
    Location:
    NJ, USA
    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:
    :lol:

    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?
     
  9. EmperorFool

    EmperorFool Chieftain

    Joined:
    Mar 2, 2007
    Messages:
    9,633
    Location:
    Mountain View, California
    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.
     
  10. Fuyu

    Fuyu Chieftain

    Joined:
    Nov 5, 2009
    Messages:
    1,220
    Location:
    Austria
    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.
     
  11. EmperorFool

    EmperorFool Chieftain

    Joined:
    Mar 2, 2007
    Messages:
    9,633
    Location:
    Mountain View, California
    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.
     
  12. Fuyu

    Fuyu Chieftain

    Joined:
    Nov 5, 2009
    Messages:
    1,220
    Location:
    Austria
    pXML->GetChildXmlValByName(&m_bFemale, "bFemale");
    Does that work without an updated schema file?
     
  13. Lemon Merchant

    Lemon Merchant Smarticus Pantsidae

    Joined:
    Jun 27, 2008
    Messages:
    4,219
    Gender:
    Female
    Location:
    Red Sector A
    I believe that you have to update the schema file.
     
  14. EmperorFool

    EmperorFool Chieftain

    Joined:
    Mar 2, 2007
    Messages:
    9,633
    Location:
    Mountain View, California
    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?
     
  15. Fuyu

    Fuyu Chieftain

    Joined:
    Nov 5, 2009
    Messages:
    1,220
    Location:
    Austria
    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 :p
    At least in the case of EventImages I ended up with EventArt in the schema..
     
  16. EmperorFool

    EmperorFool Chieftain

    Joined:
    Mar 2, 2007
    Messages:
    9,633
    Location:
    Mountain View, California
    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.
     
  17. Afforess

    Afforess The White Wizard

    Joined:
    Jul 31, 2007
    Messages:
    12,239
    Location:
    Austin, Texas
    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)
     
  18. EmperorFool

    EmperorFool Chieftain

    Joined:
    Mar 2, 2007
    Messages:
    9,633
    Location:
    Mountain View, California
    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.
     
  19. Fuyu

    Fuyu Chieftain

    Joined:
    Nov 5, 2009
    Messages:
    1,220
    Location:
    Austria
    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.
     
  20. EmperorFool

    EmperorFool Chieftain

    Joined:
    Mar 2, 2007
    Messages:
    9,633
    Location:
    Mountain View, California
    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?
     

Share This Page