Realism Invictus

[Walter Hawkwood]

Indeed, while I absolutely love the work f1rpo did on AdvCiv, and I was able to adopt some of the simpler changes, in general this is way beyond my coding skills. I will take a look at that one and see if I feel confident enough to implement it.

BTW, @f1rpo, since you popped into here, perhaps you with your skills could have some insight into the changing flags thing? The crux of the issue is this: when one changes a civ's flag during the game, the flag displayed in the interface updates instantly 100% of the time, while the flags of the units that were on screen at that moment get stuck with the old one, and may or may not change when the unit is moved. A save/load cures this issue, so I guess it's not some fundamental flaw that can't be solved. There is a number of commands dealing with unit flag entities, but they feed into the exe file and aren't documented as far as I could find - and I went semi-crazy trying for hours to make something work there. Everyone attempting dynamic flag changing before ran into the same issue, or so googling that shows.

 

[coinflip]

It seems that ai never tends to build improvement on island(separated from city land), even there are resources on it. When playing large world map, I find Greece(ai) never builds winery for wine resource on Crete Island. Is this a ai problem hard to fix?

Personally, I just edit the map to connect up islands and island chains to be a size that allows/justifies building a city there.

The AI won't build cities on one or two space islands, and neither would I, generally. That creates a lot of dead space on the Earth maps, and leaves a lot of resources undeveloped.

 

[Zap0]

Description issue:
The Warehouse says it becomes obsolete quickly with Metal Casting, which it doesn't do anymore.

Edit: Not sure about that decision, Dr. Sun Yat-Sen

 

[f1rpo]

[...] the flags of the units that were on screen at that moment get stuck with the old one, and may or may not change when the unit is moved. [...]

OK. I've given it a try in AdvCiv. Haven't really gotten it to work. If I set

GC.getInitCore().setFlagDecal(GC.getGame().getActivePlayer(),
        GET_PLAYER((PlayerTypes)1).getFlagDecal());

i.e. assign the flag of player 1 to player 0, and then call

CvFlagEntity* pTmpFlag = kFlagEntity.create(BARBARIAN_PLAYER);
CvFlagEntity* pOldFlag = kPlot.getFlagSymbol();
kFlagEntity.setPlot(pTmpFlag, &kPlot, false);
kFlagEntity.destroy(pOldFlag);
kPlot.setFlagDirty(true);

on all plots where player 0 has units, then the flags get immediately updated correctly (showing the flag of player 1, not the Barbarian flag). However, on subsequent moves, the flags sometimes revert to the original flag of player 0. I'll take another look at it tomorrow. I haven't tried to track down the RI code that changes the flag; not sure if you've committed it already.

 

[Sathar]

Just some feedback after having two games.... "disrupted" by the current Revolution mechanics.

These are on the Huge World Map. I play on Emperor so I tend to play defensively -- I rarely start wars as the ai usually will pick fights often and seemingly randomly so I usually find it safer to respond than to send my armies crusading.

Previous game, I struggled to get enough land in the early game and had fewer cities than usual. By mid-game, several of my neighbors were dying off and I picked up some good land, but various leaders were declaring war on me nonstop (I swear the ai is much more aggressive now that the scoreboard is generating dislike). I was able to keep most of them at bay while I consolidated, but even with my suing for peace with each old war a new one was popping up just as fast. My Separatism (there, I said it right ) War Weariness modifier kept ticking up to crazy values like +140% and up, and it was getting harder and harder to keep every place under that magic 10% cap. I could get no relief, either, as my primary opponent at that point would not even let me negotiate a truce. Eventually, a city somewhere failed its check (I'm fairly sure without rioting first) and flipped --- taking several of my (not rioting) core cities with them. I tried taking them back, but with half of my civ gone, as well as most of my military traditions and Great Wonders, it just wasn't feasible and I abandoned the game.

My last/current game saw the opposite problem. By mid game I was managing the war weariness better, and fighting a few standoffs with ai's hellbent on sending suicide stacks halfway around the map at me. Then out of the blue after centuries of polite trade India, ahead of my score and with a 0.7 power ratio, decided to throw his stack of doom at me, about 40 units deep and mostly cutting edge stuff superior to what I could muster. I did my best to attrit the stack down and get some defenders in place, when it turned and took my #3 city, losing about half of his units in the process. I took to the hills and considered my options. Often I'd abandon a game after such a setback, or save-scum an autosave far enough back (I doubt there was one), but I decided to tough it out and started planning a counterattack. Suddenly, only two or three turns later (five tops, pretty sure it was while the city was still in revolt), the city flipped back to my control, peace was automatically declared, and I was even awarded about half a dozen cutting edge techs I didn't even realize I was behind on. It was literally quite a coup, but it didn't feel earned and just left me unsatisfied.

I really like that Revolutions have come so far along, and I understand the programming limitations that have pretty much restricted them to near-instantaneous cause/effect calculations rather than conditions that evolve over time. However, these sudden seismic, game-altering shifts that often come with little or no warning, and little recourse, are a bit tough to swallow. This is made worse by the intense increase in micro-management, as all cities <9% Separatism is Everything's Fine, and one city at 11% means game over some time in the next ten turns. Oh, wait, you moved one garrison unit out to stop a peasant revolt and didn't recheck your Separatism? You lose.

Post-script: If situations where Separatism is allowed to climb into the 50% 100% 150%+ range are considered "acceptable", maybe there should be additional, more severe curbs that should be offered at those higher levels before a city flips. E.g. riots first break out above 10% and you can give Tax Breaks for -x (I forget the #), and riots intensify at >50% and you can do something harsher for a bigger decrease. Maybe even separate (no pun intended) it into two or more checks, first to see if riots worsen, and if so then to see if the city Separates.

 

[Walter Hawkwood]

OK. I've given it a try in AdvCiv. Haven't really gotten it to work. If I set

GC.getInitCore().setFlagDecal(GC.getGame().getActivePlayer(),
GET_PLAYER((PlayerTypes)1).getFlagDecal());

Yes, that is more or less what I've been doing. I've exposed the function to python and call it from there with a variety of strings as inputs instead of other players' flags, but otherwise that's what I'm using. As I am more confident in python (and the component cannibalizes a lot from Platy's dynamic names), the actual decision process happens in python in DynamicCivNaming.py, and only calls the setFlagDecal function when it's done.

.e. assign the flag of player 1 to player 0, and then call

CvFlagEntity* pTmpFlag = kFlagEntity.create(BARBARIAN_PLAYER);
CvFlagEntity* pOldFlag = kPlot.getFlagSymbol();
kFlagEntity.setPlot(pTmpFlag, &kPlot, false);
kFlagEntity.destroy(pOldFlag);
kPlot.setFlagDirty(true);

on all plots where player 0 has units, then the flags get immediately updated correctly (showing the flag of player 1, not the Barbarian flag). However, on subsequent moves, the flags sometimes revert to the original flag of player 0. I'll take another look at it tomorrow. I haven't tried to track down the RI code that changes the flag; not sure if you've committed it already.

Yes, that's one of the things I was trying as well. It seems to me that the flag data for plots where units were doesn't get deleted properly or something along those lines.

Just some feedback after having two games.... "disrupted" by the current Revolution mechanics.

Thanks for the feedback! I'll see if there are some tweaks I can squeeze in. One question - what revisions were both of these games? I've implemented additional checks to prevent flips without rioting rather recently and I'd be very annoyed if they don't work.

Also, the "peace out" and techs were only supposed to be happening to civs being brought back from the dead. So I will make checks for that.

 

[Sinaherib]

I try to launch RI 3.5 after installation, but I get "GFC Error: failed to initialize the primary control theme" every time.
Any ideas what can be the reason? I never got such message while playing previous versions (including pretty recent SVN builds).
Upd. I get it during "[Realism Invictus] Init Engine" and "[Realism Invictus] Init Fonts".
Upd2. Made some tests. RI 3.4. works fine. Build 5227 works fine. 3.5 refuses to launch.
Upd.3 I updated SVN Build to the latest version and it worked, but only as a Build. It still doesn't work through actual installer.

 

[Walter Hawkwood]

I try to launch RI 3.5 after installation, but I get "GFC Error: failed to initialize the primary control theme" every time.
Any ideas what can be the reason? I never got such message while playing previous versions (including pretty recent SVN builds).
Upd. I get it during "[Realism Invictus] Init Engine" and "[Realism Invictus] Init Fonts".
Upd2. Made some tests. RI 3.4. works fine. Build 5227 works fine. 3.5 refuses to launch.
Upd.3 I updated SVN Build to the latest version and it worked, but only as a Build. It still doesn't work through actual installer.

Are you by any chance trying to put it elsewhere than "Realism Invictus" folder?

 

[arievillo]

I try to launch RI 3.5 after installation, but I get "GFC Error: failed to initialize the primary control theme" every time.
Any ideas what can be the reason? I never got such message while playing previous versions (including pretty recent SVN builds).
Upd. I get it during "[Realism Invictus] Init Engine" and "[Realism Invictus] Init Fonts".
Upd2. Made some tests. RI 3.4. works fine. Build 5227 works fine. 3.5 refuses to launch.
Upd.3 I updated SVN Build to the latest version and it worked, but only as a Build. It still doesn't work through actual installer.

I got this issue to. Try put the Realism folder in c/Programs../BTS/mods (something like that) and not on Documents/BTS... works like a charm to me.

PS: This beta version is great. More dynamic, faster (unity movements). I just started now and I really like the revolution thing.

 

[Walter Hawkwood]

Mods should never go into Documents folder, at least bigger ones, with modified dlls and stuff.

 

[Sinaherib]

Are you by any chance trying to put it elsewhere than "Realism Invictus" folder?

No, in the correct folder. I installed RI3.4 in the same folder and it worked (I uninstalled it after that, so RI3.4. wasn't causing this problem). Reinstalled the game and the mod several times, but it kept on crashing for the same reason.

Have just tried to launch it once again (without reinstallation) and it suddenly worked, even though I didn't change anything. Honestly, I'm a little confused about why all this was happening.
Sorry for bothering then!

On a side note, I noticed that several minor civs became playable in Huge Earth Scenarion?

 

[Sathar]

Thanks for the feedback! I'll see if there are some tweaks I can squeeze in. One question - what revisions were both of these games? I've implemented additional checks to prevent flips without rioting rather recently and I'd be very annoyed if they don't work.

Also, the "peace out" and techs were only supposed to be happening to civs being brought back from the dead. So I will make checks for that.

I'm typically using the latest SVN. I do occasionally break the "Don't update the SVN mid game" rule, and usually keep it to myself if the game behaves oddly as a result. As several of the recent SVN updates have been mainly art assets, I may have updated during the game. If I had a guess, the first game I descibed would have been roughly 5265 and the second game 5268.

I see you just uploaded 5273, I'll give that a try "soon".

 

[Brant_Flir]

I try to launch RI 3.5 after installation, but I get "GFC Error: failed to initialize the primary control theme" every time.
Any ideas what can be the reason? I never got such message while playing previous versions (including pretty recent SVN builds).
Upd. I get it during "[Realism Invictus] Init Engine" and "[Realism Invictus] Init Fonts".

I got this issue to. Try put the Realism folder in c/Programs../BTS/mods (something like that) and not on Documents/BTS... works like a charm to me.

Arievillo, would you mind elaborating on what exactly you did to fix this? I have the exact same problem.

Originally, I had my Civ IV install in a 'User/MySavedGames', and so based on your post I switched this to "C/ProgramFiles" but I still get the same GFC error.

UPDATE: I reinstalled RI 3.4, used the new ProgramFiles, and 3.4 works just fine. I just cannot get 3.5 to work.

 

[f1rpo]

Yes, that's one of the things I was trying as well. It seems to me that the flag data for plots where units were doesn't get deleted properly or something along those lines.

Giving the Barbarian treatment to all plots indeed seems to do the trick. Actually, it seems to be enough to do it for all plots with m_pFlagSymbol!=NULL – that excludes the (empty) plots on which I had seen the original flag resurface. My best bet is that the EXE uses some sort of cache or object pool, but I don't really see how my code clears that data.

Oh, and I've remembered that the Change Player component (CvPlayer::changeCiv) temporarily changes the player's era in order to update the flags. That seems to work too. Change Player suppresses the new-era popup by briefly enabling AI Auto Play; I don't remember if that part worked correctly. In any case, a while ago, I've added a bGraphicsOnly parameter to CvPlayer::setCurrentEra in order to fix some temporary graphical artifact caused by the changeCiv function.

The crucial call triggered by setCurrentEra appears to be

if(m_pFlagSymbol != NULL)

gDLL->getFlagEntityIFace()->updateGraphicEra(m_pFlagSymbol);​

for every plot's flag – but the flag owner's era needs to have changed for this to have an effect.

I've now put my new flag update code into a new function CvPlayer::setFlagDecal and removed (commented out) the era-change code: Git commit

 

[arievillo]

Arievillo, would you mind elaborating on what exactly you did to fix this? I have the exact same problem.

Originally, I had my Civ IV install in a 'User/MySavedGames', and so based on your post I switched this to "C/ProgramFiles" but I still get the same GFC error.

UPDATE: I reinstalled RI 3.4, used the new ProgramFiles, and 3.4 works just fine. I just cannot get 3.5 to work.

I sent you a private message.

 

[Walter Hawkwood]

Arievillo, would you mind elaborating on what exactly you did to fix this? I have the exact same problem.

Originally, I had my Civ IV install in a 'User/MySavedGames', and so based on your post I switched this to "C/ProgramFiles" but I still get the same GFC error.

UPDATE: I reinstalled RI 3.4, used the new ProgramFiles, and 3.4 works just fine. I just cannot get 3.5 to work.

Current installer has a bug and will NOT work for people without an SVN version installed as well. We will hopefully get a new and working installer tomorrow.

Giving the Barbarian treatment to all plots indeed seems to do the trick. Actually, it seems to be enough to do it for all plots with m_pFlagSymbol!=NULL – that excludes the (empty) plots on which I had seen the original flag resurface. My best bet is that the EXE uses some sort of cache or object pool, but I don't really see how my code clears that data.

Oh, and I've remembered that the Change Player component (CvPlayer::changeCiv) temporarily changes the player's era in order to update the flags. That seems to work too. Change Player suppresses the new-era popup by briefly enabling AI Auto Play; I don't remember if that part worked correctly. In any case, a while ago, I've added a bGraphicsOnly parameter to CvPlayer::setCurrentEra in order to fix some temporary graphical artifact caused by the changeCiv function.

The crucial call triggered by setCurrentEra appears to be
if(m_pFlagSymbol != NULL)
gDLL->getFlagEntityIFace()->updateGraphicEra(m_pFlagSymbol);for every plot's flag – but the flag owner's era needs to have changed for this to have an effect.

I've now put my new flag update code into a new function CvPlayer::setFlagDecal and removed (commented out) the era-change code: Git commit

Thank you very much man! You're the best! Since RI already had CvPlayer::setFlagDecal function, implementing that was as easy as updating it. Since that was the major unsolved bug for 3.5, that's a great load off my shoulders.

 

[keldath]

Thank you very much man! You're the best!

told you his great.

 

[f1rpo]

Thank you very much man! You're the best! Since RI already had CvPlayer::setFlagDecal function, implementing that was as easy as updating it. Since that was the major unsolved bug for 3.5, that's a great load off my shoulders.

Well, in that case, I very much hope that it'll actually work reliably. I've only tested it with one savegame ...

told you his great.

Sometimes you remind me of my mother.

 

[Walter Hawkwood]

Well, in that case, I very much hope that it'll actually work reliably. I've only tested it with one savegame ...

I've run (and still am running) several hands-off test games, and so far it works flawlessly.

 

[keldath]

Sometimes you remind me of my mother.

well,

im a father my self ,
so, encouragement, is lodged in me

Walter Hawkwood, glad you made progress.