Advanced Civ

That religion screen is terrible compared to BUG. It's pretty, but the functionality is missing.
Sorting by religion is important.

Another UI one. It would be nice if the city list didn't return to the default sorting all the time. Make it retain the last state every time it opens?

 

Thank you, f1rpo! It looks good.

 

noticeably better on the AI constantly breaking trades.

 

I haven't played with either version. On the BtS screen, moving the mouse pointer on and off a religion icon repeatedly works OK for me. (Screenshots attached; though comparing the upper and lower screenshot is more awkward than moving the cursor in the game.) In any case, I wouldn't remove the BUG version.

This seems to be difficult to implement. Apparently, the sortable table is encapsulated by Python code in the EXE and I see no way to find out the column by which the table is sorted at a given time nor to sort it by a given column. So, unless I'm missing something or some mod has reimplemented the sortable table, I can't do it.

Thanks for testing the AI change (also @Bestban). I hope the AI will still ask for more gold or offer less in some circumstances.

 

Got another one.
BUG GP bar isn't showing the right percentages.
City shows 71% GM, 17% GP
BUG bar shows 71% GP, 17%GM

Nevermind...

 

Try it with 60 cities...

 

No, thanks.
Point taken though. It could be a slight improvement for the BtS/Platy Advisor to sort the cities by the currently selected religion (but not when only hovering over a religion button). I suppose it still won't cut the mustard on Huge maps.

 

I'm seeing resource deal cancellation by AI that the exact same deal is immediately accepted if I try Care to negotiate, within the same popup window. If the AI knew that it would accept, then no need to come to the door at all. It seems cancellation formula is disjoint from acceptance? Thought: Or perhaps, instead of some cancellation formula, an existing deal needs to simply be evaluated against acceptance, assuming that such a deal had not existed, as a way to meaningfully evaluate cancellation or not. Perhaps, the formula just needs to be a chance to evaluate acceptance or not to evaluate it, from time to time.

 

There is no simple way to assume that a deal doesn't exist. There is not, say, a sandbox game state for such hypotheticals.

How it currently works, for example, when the AI trades for a happiness resource: Both for acceptance and cancellation, the trade value of the resource is computed. Ultimately, the bulk of the work is done by a function
int CvPlayerAI::AI_getHappinessWeight(int iHappy, int iExtraPop, /* ... */)
that goes through all cities of a player and computes a percentage that somehow expresses how close the cities are to the happiness cap. This function isn't very well suited for trade evaluation. For starters, iHappy can't be negative; instead my trade evaluation code has to assume extra population when considering to cancel a trade. So that function could probably be improved. However, since the cancellation check is more lenient than the acceptance check, slight inconsistencies in the happiness evaluation shouldn't really hurt. If the evaluation is way off, then it's probably due to some programming error (like this one; fixed since v0.96c). So, if you happen to have a savegame, I'd like to take a look in the debugger.

The other possible cause is that deals are canceled on an AI turn but aren't renegotiated until the human turn; circumstances can change in between turns. I've a plan to address that problem, but I'm not yet sure how much of a problem it is.

 

Sure. Bismarck wants to cancel his Wheat-for-Fur trade. Try 'Care to negotiate?' >> 'Would you accept this deal?'. Use the DLL with revised formula.

 

Hi f1rpo ,
as you might recall, I use AdvCiv as a base for my personal mod. I run into some issues when trying to add natural wonders. Basically, natural wonders are terrain features that are placed during map creation and add additional yield on a plot. The latter is done onGameStart (in my implementation) using setPlotExtraYield() to allow cities working impassable tiles. Whereas this works fine in BTS, impassable tiles are never workable in AdvCiv, regardless of whether the yields are defined in the xml files or added with setPlotExtraYield(). So I guess you made some changes that result in impassable tiles never being workable (which is actually a reasonable assumption given BTS mechanics).
Another issue is that doing so makes the "regenerate map" button (on game start) never appear, probably because adding yields makes BTS think the map has been changed (or something like that). If you happen to have an idea how to circumvent this, I'd be happy for any pointer.

 

Thanks. I don't think Bismarck should've canceled that trade. So I'd need a save from the previous turn; in the save you've uploaded, the trade is already canceled. (He cancels it on his turn and offers to renegotiate on yours.)

I had another idea for avoiding such situations (hopefully won't be needed): Have the AI remember recently canceled resources and adjust trade values based on that memory. This would force the AI to ask for more after canceling a deal. One could look at this as learning through trial and error. Actually, such memory could also make sense for trades canceled by another player (especially human): Pay less to players who appear to be unreliable suppliers.

The problem appears to be this function:

Code:

int CvPlot::calculateNatureYield(YieldTypes eYield, TeamTypes eTeam, bool bIgnoreFeature) const
{
   if (isImpassable())
       return 0;

   // ...

   // advc.016: Cut from calculateYield
   iYield += GC.getGame().getPlotExtraYield(m_iX, m_iY, eYield);
   return std::max(0, iYield);
}

That is, nature yields, including feature yields, are disregarded on peaks (as in BtS) and AdvCiv counts extra yields as nature yields. I've made this change to address the counterintuitive outcome described in this thread.

It's a little illogical to me to allow a city to work an impassable tile, but it's complicated to sort this out, so I'll just move the getPlotExtraYield line to the start of the function; DLL attached. I hope this solves the problem (can't easily test it).

 

Thank you, using the modified dll it works as intended.

Sort of. I think of "passable" with regard to (military) units. And it depends on the specific yields; I just added some commerce to such tiles reflecting something along the lines of tourism. A city has no need to actually "work" the Mount Everest, but obtains some revenue anyway.

 

hey f1rpo,
whats up?

in this regards - how this affects the passable mountains i use?

mind posting your implemented fix?

 

With your passable-mountains option, CvPlot::isImpassable should return false for peaks, so all nature yields are counted.

I've pushed it on GitHub: link

It looks like extra yields aren't reset when the map is regenerated. But I don't see how that stops the "Regenerate" button from appearing. Here's the DLL code:

Spoiler :

Code:

bool CvDLLButtonPopup::launchMainMenuPopup(CvPopup* pPopup, CvPopupInfo &info)
{
   // ...

   if (GC.getGame().getElapsedGameTurns() == 0 &&
           !GC.getGame().isGameMultiPlayer() && !GC.getInitCore().getWBMapScript())
   {
       // Don't allow if there has already been diplomacy
       bool bShow = true;
       for (int i = 0; bShow && i < MAX_CIV_TEAMS; i++)
       {
           for (int j = i+1; bShow && j < MAX_CIV_TEAMS; j++)
           {
               if (GET_TEAM((TeamTypes)i).isHasMet((TeamTypes)j))
               {
                   bShow = false;
               }
           }
       }
       /* <advc.004j> Commented out.
          After ending the initial turn, some script data seems to
          be set by the EXE. Not sure what data that is and whether
          CvGame::regenerateMap can handle it; experimental for now.
          Fwiw, I'm resetting all script data in regenerateMap. */
       /*if (bShow) {
           if (!GC.getGame().getScriptData().empty())
               bShow = false;
       }
       if (bShow) {
           for (int i = 0; i < GC.getMap().numPlots(); ++i) {
               CvPlot* pPlot = GC.getMap().plotByIndex(i);
               if (!pPlot->getScriptData().empty()) {
                   bShow = false;
                   break;
               }
           }
       }*/ // </advc.004j>
       if (bShow)
       {
           gDLL->getInterfaceIFace()->popupAddGenericButton(pPopup, gDLL->getText("TXT_KEY_POPUP_REGENERATE_MAP").c_str(), NULL, MM_REGENERATE_MAP, WIDGET_GENERAL, MM_REGENERATE_MAP, 0, true, POPUP_LAYOUT_STRETCH, DLL_FONT_CENTER_JUSTIFY);
       }
   }

   // ...
}

So: only on the initial turn, not in MP or scenarios (I guess that's what getWBMapScript checks) and civs mustn't have met. The script data condition I've disabled a few versions back and I don't think the extra yields are stored as script data anyway.

 

hey again,

off topic (thanks for the fixes )
had an oos, almost to the end of the game - i was in open diplo screen and my friend passed the turn quick.
ill pack the save and everything for you.
i dont know wheres the logger for it.
from what i see, maybe bombard has something to do with it.
i have some observations - report tomorrow.

 

Sorry, my fault, the disappearing button is not related to applying extra yields, but must be due to something else. I can't see how anything other than GC.getInitCore().getWBMapScript() could cause this, but I don't understand what's done there. Anyway, thanks for your help.

 

Just for the record: The Regenerate button mysteriously reappeared. Whatever.

 

Is it reproducible from a save? I don't really want to set up debug tools for that old Doto version.

The OOSLog is only created if MessageLog and RandLog are enabled in CivilizationIV.ini. And then one needs the logs from both players in order to compare them. (And even then, the info may not be sufficient.) Come to think of it, I'll probably remove the RandLog check because that's a very busy log that I, for one, wouldn't want to keep permanently enabled.

On a somewhat crowded map, the button tends to not show up randomly due to civs starting close enough to be in contact from the beginning. Be that as it may, it would be good to clear any extra yields when regenerating. That'll be just one line in CvGame::regenerateMap; I'll add that in v0.97 (unless you need it earlier).

I'm pretty sure that getWBMapScript checks whether the map file is a scenario file. It calls isDescFileName, which is implemented in the EXE. Curious function name. I think "Desc" is used in reference to the language that scenario files are written in. Wondering about this has made me take a closer look at CvWBDesc.py. That file writes and reads WBSaves; I had always assumed that this was done by the EXE. So one could probably fix the compatibility problems between BtS scenarios and DLLs allowing more than 18 civs. That would be one step toward deploying just one version of the DLL. (end of tangent)

 

heya,
ok here we go:

firstly,
the oos was gone after i closed civ4 and reloaded. so theres that. atleast 50 turns after first happened.
after the first oos appeared, we loaded an auto save, a regular save and a save during the oos.
sometimes it came back after 1 turn and sometimes after 5 or so.
the first one occurred while my friend passed the turn fast while i was in diplo screen and there was a delay in the response to the deal i made, like cpu was loading.

from the "naked" observation,
there were allot of enemy bombardments on my cities, air mostly and naval. the alerts for them come in a delay as you know.
perhaps the overload of alerts has anything to do with.

logs,
yes i turned the logs on , though u didnt see they were created. maybe steam related.

i think, for now, ill wait for our next session, ill try to reproduce, and have some logs.
maybe its just the game reload that was required. for now, ill just report this all to you.

do you have ideas about a possible cause?
the bombard alerts?

the doto version is a few back from the last hotfix with some parts from it.
in the game options, i didnt turn on any of my stuff.

so let me know if you want to check the game saves anyway.


----
game went on pretty cool. aggression was pretty good, wars and good ai decisions .some deals were, worth to human, but not that often.
we ended up loosing, to guess who...space king ghandi.
one weird dont know if intended, when conquering a city, from china, despite i held some turns, cuture was never beyond the city it self, it was always engulfed with china's.
it happened else where, but i guess thats fine. i remember after conquering some parts were moved to the conquerer border, but. i like it as it is.

all an all, great game exp.
thank you for this , as always.

let me know what you need and if you want for some tests.