[Religion and Revolution]: Bugs and Todos

[HermanHeydt]

Apparently, this is a feature. African slaves are allowed to be scouts, while native slaves are not! This is rather inconsistent and I lean towards this being an oversight.
Until we get the chance to change this, you can copy the tags below <ProfessionsNotAllowed> from the native slave to the african slave entry in CIV4UnitInfos.xml

I also have african slaves founding colonies in my latest game - is that a feature as well?

 

[devolution]

It's tricky to track down all the (corner) cases where units are allowed to change their UNITAI (this is how the game internally decides how a unit should behave). I suppose the AI found a way that I'm not (currently) aware of.

 

[devolution]

Just a general comment regarding bux-fixing and development:

The project is already severly understaffed at the moment. As for myself I have very little time that I can actually spend on this project so I'm encouraging you guys to step up. Feel free to add your own features and to fix the many bugs that are still left. You have the source code, so roll up the sleeves and start coding\debugging. If a random person like me can stroll into the forum and contribute after a couple of weeks of playing, so can you.

 

[devolution]

I have reported this before but apparently the bug is still there.
Similar as Marla I use the Import/Export window to determine that no more than 100 sheep should be present in Boston.
This amount should be filled up by an automated Wagon Train from New Haven.
The SaveGame is saved just after starting a new turn but before all orders from last turn have been executed (some have but that is an unrelated issue of its own).
Boston had 100 sheep at the end of the last turn and consumed 24 of them. These have been filled up to 100 as the automated WT has already run.
However, that WT had taken 24 more sheep from NH and now decided to bring the rest to Trankebar (my founding city). You can find it south of Tap Hus.

This behaviour is repeatable:
Load 24 sheep in Boston onto the WT present.
Assign the transport of sheep from NH to Boston to one of the Treks in NH and run the automated movements.
The Trek dutifully goes to Boston delivers 24 sheep but cannot unload the other 24(!) sheep it had loaded and proceeds towards Trankebar.
I don't think it is by chance that the surplus is exactly the missing number of sheep in Boston. If you load 50 sheep onto the WT the Trek still has a surplus of 24.
So the error is obviously a miscalculation during the uploading of the Trek, maybe counting the missing sheep and adding next turn's consumption.

One thing I like about the mod is the logistical challenge. But it has to be solvable.
Managing the logistics is difficult enough if everything works as expected.

I have determined the cause of this bug and corrected it in my build. Unfortunately, this particular subsystem (CvSelectionGroupAI::AI_tradeRoutes) is one of the most convoluted aspects of the entire game. Hopefully my change is an actual fix and no other issues will be caused by it. Ideally, most of the trade route stuff should be overhauled, which is unlikely to happen unless someone steps up.

 

[devolution]

Has anyone reported the train oil factory bug, wherein you get a notice that a wealthy faction wants to build a train oil factory in a coastal town - in my case my capital. If you agree you get a free train oil factory, but if you refuse you get three turns of unrest. I have had event pop up earlier in the game and I built the train oil factory in my capital, but now I've had this happen three turns in a row now and since I already have a train oil factory in my capital my only option is to refuse and am up to 9 turns of chaos.

Either events like this should only show up once in a game or it should occur at another coastal city.

Thanks

Do you have a save ?

 

[devolution]

Btw. this is the same game my still unanswered culture questions were about.
I attach another savegame which shows the situation in Jan 1671. That is just after the unrest period for the last Swedish city I conquered (Fort Christina, later renamed Göteborg) has ended. Over the next turn I built Taverns, Markets, Newspapers, everything that produces culture in Minquas, FC and Nya Stockholm quickly.
Although I am now, almost 20 years = 40 turns later, producing lots of culture - much more than the remaining Swedish cities in the vicinity - and although some of those Swedish plots are adjacent to not one but even two of my cities but 4-5 plots away from the nearest Swedish town I have gained just the two northernmost plots adjacent to Minquas (the more southern of which just a couple of turns ago).
Furthermore I had temporarily gained control over the jungle plot southwest of FC not adjacent to any of my towns (the one which in 1671 shows 0% Russian and 99% Swedish but belongs to Russia!) but lost that again after a few rounds. I even lost control permanently up to now over the sea plot adjacent to it, which I already owned in 1671!
The percentages shown mot of these cases don't reflect these changes at all (with the exception of the two northern plots).

- I am actually surprised to learn that borders do not reflect the actual owner of the plot. Maybe this is another feature that somehow got broken at some point. I haven't played vanilla or TAC in ages, so could someone confirm that borders are suposed to work like that (they do in Civ4 BTS and I'd like it to be that way to make culture meaningful)

Add this to the information by devolution in a different thread that the combat odds shown previous to a combat are wrong and I am asking myself which info the game gives me is actually accurate.

Mods:
I think we can agree that this is a game of strategy. For strategy you need planning and for planning you need accurate information. It is ok to have a certain amount of uncertainty - this is not chess. But as a player I need to know the most basics of game mechanics. What to do to get tile control, which unit to send into a combat and the like.
And the game needs to work according to that info.
Instead you seem to be concentrating on ever more units (e.g. two new types of coastal ships that the UI builds by the dozens but knows not how to use or the continental guard with an "aura" much too large [try accessing the popup for the info of Ölhab two plots above]) or unnecessarily changing the graphics (artillery that looks like hunchbacks with broken toys on the European pier).

- As far as I know, most (or rather all the remaining) of the documented features should be accurate. These blanket statements are not really fair to modders who are doing their best with what limited time they have (After all, they are using their precious leisure time to create a game that other people can play and complain about). Not sure what you mean by the aura ?

The AI seems as silly as ever: look at all the buildings in formerly French Port-au-Prince 1671 or at the Corvette in Novo Arkhangelsk in the later save which has watched my pirates picking on the Russian ships for like a decade without interfering; the loot of these pirates is mostly raw materials and livestock implicating a poor economy.
The only improvement I have noticed is that they cover their artillery stacks a little better. I still conquered cities killing specialists and even statesmen only to find a population of white shirts (though maybe that is actually clever when overrun).
The Russians had a 38% independence support in 1671, I had 19%. Now, in 1689, I have 41% and they have only 34%. This is without any wars in between and without significant territorial changes. The only way I have interfered with them, albeit strongly, is by pirating like every other ship they sent out in the later decade.
In probably close to 30 games over the years I have yet to see the AI declare independence. That seems not to have changed.

These are real AI problems and I am working on resolving them. For instance, I want the AI to protect and escort their merchant\transport ships and to carry out coastal patrols. The construction of empty buildings in tiny cities is yet another problem that I intend to resolve.
The AI will declare independence by about turn 350 if there is no human player involved in my autoplays. If there is a human player, it is generally too easy to exploit the AI's shortcomings and to prevent it from achieving anything. The goods news is that I am implementing some deteriments to the player declaring war on his\hers European rivals.

Why do we have all the European kings in the Foreign Advisor screen? I have never been able to interact with them. It says somewhere that good relations with them improve the chance of help during the WoI. But what gives if I can't do anything to change these relations?
Same goes for the Pope. He took my money about 5 times and gave me 2 bishops but that's it so far in my present game. I can't even buy favors with the foreign European kings through him which should be easy to implement.

I agree that their presence is not very useful. Hopefully my forthcoming changes will help rectify this.

My king however seems to be overly friendly now. I actually thought about not even producing any guns because I could and still can (at 41% revolutionary support!) buy so many military units they might be enough to kill the REF.
Although the king has been building up his military for some time now we still have positive relations and I can still buy units at ridiculously low prices. All I did to achieve that was paying my dues each time and agreeing to higher taxes most of the time.

I have extended the cap on negative attitude from requesting military help. This exploit will be gone in the next beta. TAC did not have this exploit btw since the demerit was unlimited methinks.

The two times I did not was before I realized that selling boycotted goods through the Custom House gives me less money than shipping the underlying raw materials to Europe or Africa!?

Not sure what you mean with his, this more of a game balance thing. Arguably, the customs house is a bit too generous. IMHO 80% of the export price is too good. I'd like something like 50% and then have the warehouses at something like 25%. These export alternatives actually ruin an important theme of the game and if I had my way I would consider removing it altogether.

Speaking of which: What exactly does Africa add to the game except more micromanagement when shipping out goods? Most goods have the same price in midgame anyways and if they don't I might gain 100 or so gold after taxes on a whole shipload. It would be more interesting if there were other advantages to Africa than just prices and slaves. There could be a bonus on the king's counter for tax hikes, it could be faster to get to from the East coast (might have been true) or the West coast (actually was true). There could be goods only for sale there other than slaves or only to be sold there (sails, cloth, anything that Europe produced at the time).
Or I could gain Exploration Points instead of Trade Points. That would make a lot of sense as I usually have tons of TPs anyway but never get to the higher half of Exploration FFs (playing normal size maps) for lack of EPs. Also it makes some historical sense as going to Africa in those times was definitely more adventurous than going home to good ole Europe.

The african port has generally better export prices for livestock and due to the random price fluctuations, the prices there will be different from the European port. I agree that it would make the game more interesting if there were to be more of a difference. I have some thoughts on this though....

To say something positive at the end: I do like the reconfiguration of the FFs. Costs and benefits are much better balanced than before.
That said, for replayability it would be nice if there were some random changes each game. Make two or three categories (early, mid and late) of FFs and have them randomly assigned to the early, mid and late slots in their respective groups each time a new game is started. With the old configuration I had a clear path which FFs to get which became a bit boring. With the new configuration it will take a few games but then a new clear path will emerge.

I have been thinking about randomizing the FFs (by swapping them by a maximum of 1 or 2 slots) to counteract the game getting "too stale". I've always thought that the idea of having a semi-random tech tree (like Master of Orion 1) was cool since it incentives tech trading\spying\stealing.

Sorry for the rant. I am German so I might come across a bit harsher than it is meant.
I love this game, it is the only longer one I am still playing. What TAC, R&R and now the new team have achieved is truly a great improvement over Vanilla.
But after three weeks of playing one game I get attached to it and would like to bring it to an end.
So I am really pissed off right now with the transportation issue mentioned at the beginning of this post and all the other new bugs (there are more than I mentioned here) and not so much impressed with the new stuff (new for me is not necessarily very new in the mod as I stopped updating once the 2-plot-radius became mandatory).
I really think you should give pause to introducing new stuff and concentrate on ironing out the bugs and inconsistencies. Not as glorious, I know, but more rewarding in the long run.

 

[Sarin]

Not sure what you mean with his, this more of a game balance thing. Arguably, the customs house is a bit too generous. IMHO 80% of the export price is too good. I'd like something like 50% and then have the warehouses at something like 25%. These export alternatives actually ruin an important theme of the game and if I had my way I would consider removing it altogether.

There is a problem with nerfing the custom houses though. In late game, your colonies can produce thousands of units of export goods per turn. Had you have your way, the player would be stuck in late game with 10 minute turns spent entirely on micromanaging ship loading and unloading. I had games on marathon where I had a galleon leaving my main hub every turn fully loaded with goods, and it wasn't enough to keep up with flow of the goods.

You'd need to implement total automation of export in order to be able to nerf custom houses.

 

[stillontheedge]

Do you have a save ?

I have a save of this exact situation, compounded by the fact that my "capital" city is already in disorder because the previous turn I had to decline this same offer. So now my city will be in disorder for 5 turns!!

How should I get the file to the appropriate people?

 

[devolution]

I have a save of this exact situation, compounded by the fact that my "capital" city is already in disorder because the previous turn I had to decline this same offer. So now my city will be in disorder for 5 turns!!

How should I get the file to the appropriate people?

Post a reply to this thread with the save attached, there's a "Upload A File" button" next to the "Post Reply" button for your convenience You should also post your modifed XML files. (if any)

 

[stillontheedge]

Post a reply to this thread with the save attached, there's a "Upload A File" button" next to the "Post Reply" button for your convenience You should also post your modifed XML files. (if any)

I have attached the save. There are no modified XML files included, as the only XML mod is one that increases the fishing yield by level of dock built. Can't see how that yield change would change the randomness of the Train Oil event, especially as someone else is having the same issue.

This is an autosave at the start of the turn where the second Train Oil event is generated.

 

[devolution]

@stillontheedge
I've found the cause of the issue. The event " WHALING" is allowed to repeat, which does not make sense at all since the factory can only be built once.

The simple fix should be to change line 9751 in Assets\XML\Event\CIV4EventTriggerInfos.xml from <bRecurring>1</bRecurring> to <bRecurring>0</bRecurring> . This should prevent the event from triggering more than once.

Note that in the save you've attached, the event has already triggered a second time so I suppose you'll have endure it for now. At least you shouldn't have to suffer this maladay a third time

I will include the fix in the next beta.

 

[stillontheedge]

@stillontheedge
I've found the cause of the issue. The event " WHALING" is allowed to repeat, which does not make sense at all since the factory can only be built once.

The simple fix should be to change line 9751 in Assets\XML\Event\CIV4EventTriggerInfos.xml from <bRecurring>1</bRecurring> to <bRecurring>0</bRecurring> . This should prevent the event from triggering more than once.

Note that in the save you've attached, the event has already triggered a second time so I suppose you'll have endure it for now. At least you shouldn't have to suffer this maladay a third time

I will include the fix in the next beta.

Thank you for the quick response. I will make the change in my XML code and reload my game, so I don't have to see that event any more! Now if we could just stop the Spanish from taking the Founding Fathers I want....

 

[devolution]

@stillontheedge
You're welcome

By the way, it seems that I forgot to mention it explicitly, but you'll have to have the game reload the XML. The only way to do this is to relaunch the game. One more thing though, to be sure that the game actually reloads the XML (which may be cached), keep the shift key pressed while launching.

 

[ShadesOfTime]

Hey guys!

I believe I tracked down the bug that was described here:
https://forums.civfanatics.com/thre...-bugs-and-todos.449958/page-116#post-14964697


The correct code in CvCity.cpp, lines 1015 and 1016 should imo be:

1015       setImportsLimit((YieldTypes) iData1, (iData2 >> 16) & 0xFFFF); //shift and then mask, because never trust that 0s are shifted in from the left
1016       setMaintainLevel((YieldTypes) iData1, iData2 & 0xFFFF);

My reasoning is this:

-) In CvDLLButtonPopup.cpp on lines 3054 and 3056 it is established that the import limit goes to the spinbox with id "NUM_YIELD_TYPES+iYield" and the export limit/maintain level goes to the spinbox with id "iYield".

3054           gDLL->getInterfaceIFace()->popupCreateSpinBox(pPopup, iYield, L"", pCity->getMaintainLevel(eYield), 10, 999, 0);

3056           gDLL->getInterfaceIFace()->popupCreateSpinBox(pPopup, NUM_YIELD_TYPES+iYield, L"", pCity->getImportsLimit(eYield), 10, 999, 0);

-) In CvDLLButtonPopup.cpp on line 823 and lines 831 through 836 the values are concatenated with the import limit in the left 16 bits and the export limit/maintain level in the right 16 bits.

823                       int iLevel = pPopupReturn->getSpinnerWidgetValue(iYield);

831                       int iMaxLevel = pPopupReturn->getSpinnerWidgetValue(NUM_YIELD_TYPES + iYield);
832                       bool bImportsLimitChanged = iMaxLevel != pCity->getImportsLimit(eYield);
833                     
834                       int iBuffer = (iMaxLevel << 16);
835                       iBuffer |= iLevel & 0xFFFF;
836                       iLevel = iBuffer;

I have seen Erik Sandbraaten made this commit:
https://sourceforge.net/p/religion-.../ci/add7113453a6af836042e761b286033d0174e61c/

which, as far as I can tell from looking at the code, introduced this behavior.

I am pretty confident I got this one right. I did not build and test it, but because as of how the code is, the workaround for this bug, when I want to change import/exp limits, is to open the import/exp dialog, close it again (then the values are switched) then open it again, make my changes - to the spinbox of the other value - and then close it again. And this workaround works perfectly.


Can I wish for something as a bug finding and solution providing reward?

1) Please fix at least the bug and make a 2.7.1beta3 for download asap. Because I have no means to compile this for the next time. And I would like to keep playing without that workaround.

2) If you want to give me even more, make the value for the import limit go to the left spinbox and the export limit to the right one. Because this is far more intuitive. Left spinbox below checkbox "Import" and right spinbox below checkbox "Export". I did not check all the code, but I believe it should be along simply switching the IDs of the spinboxes ("NUM_YIELD_TYPES + iYield" and "iYield") in all function calls.

And/Or even better: Add lables. "Import up to" and "Export down to". When I played my first time 2 years ago or so, it took me quite some time to figure out what the spinboxes are for and what value should go where.


Thanks a bunch!

 

[ederl]

I'm not really sure, but it could be, that the point "2 times as likely chance to get treasure from Ancient Ruins" from the founding father "Jacques Marquette" doesn't work correctly, because I made the experience, that I get really often treasures without him and when i get this founding father, Treasures get very rare... It could also be a big coincidence, but I tried a lot and always made this experience. Maybe take a look if this really works as intended...

 

[Randomsheep]

Hey guys!

I believe I tracked down the bug that was described here:
https://forums.civfanatics.com/thre...-bugs-and-todos.449958/page-116#post-14964697


The correct code in CvCity.cpp, lines 1015 and 1016 should imo be:

1015       setImportsLimit((YieldTypes) iData1, (iData2 >> 16) & 0xFFFF); //shift and then mask, because never trust that 0s are shifted in from the left
1016       setMaintainLevel((YieldTypes) iData1, iData2 & 0xFFFF);

My reasoning is this:

-) In CvDLLButtonPopup.cpp on lines 3054 and 3056 it is established that the import limit goes to the spinbox with id "NUM_YIELD_TYPES+iYield" and the export limit/maintain level goes to the spinbox with id "iYield".

3054           gDLL->getInterfaceIFace()->popupCreateSpinBox(pPopup, iYield, L"", pCity->getMaintainLevel(eYield), 10, 999, 0);

3056           gDLL->getInterfaceIFace()->popupCreateSpinBox(pPopup, NUM_YIELD_TYPES+iYield, L"", pCity->getImportsLimit(eYield), 10, 999, 0);

-) In CvDLLButtonPopup.cpp on line 823 and lines 831 through 836 the values are concatenated with the import limit in the left 16 bits and the export limit/maintain level in the right 16 bits.

823                       int iLevel = pPopupReturn->getSpinnerWidgetValue(iYield);

831                       int iMaxLevel = pPopupReturn->getSpinnerWidgetValue(NUM_YIELD_TYPES + iYield);
832                       bool bImportsLimitChanged = iMaxLevel != pCity->getImportsLimit(eYield);
833                    
834                       int iBuffer = (iMaxLevel << 16);
835                       iBuffer |= iLevel & 0xFFFF;
836                       iLevel = iBuffer;

I have seen Erik Sandbraaten made this commit:
https://sourceforge.net/p/religion-.../ci/add7113453a6af836042e761b286033d0174e61c/

which, as far as I can tell from looking at the code, introduced this behavior.

I am pretty confident I got this one right. I did not build and test it, but because as of how the code is, the workaround for this bug, when I want to change import/exp limits, is to open the import/exp dialog, close it again (then the values are switched) then open it again, make my changes - to the spinbox of the other value - and then close it again. And this workaround works perfectly.


Can I wish for something as a bug finding and solution providing reward?

1) Please fix at least the bug and make a 2.7.1beta3 for download asap. Because I have no means to compile this for the next time. And I would like to keep playing without that workaround.

2) If you want to give me even more, make the value for the import limit go to the left spinbox and the export limit to the right one. Because this is far more intuitive. Left spinbox below checkbox "Import" and right spinbox below checkbox "Export". I did not check all the code, but I believe it should be along simply switching the IDs of the spinboxes ("NUM_YIELD_TYPES + iYield" and "iYield") in all function calls.

And/Or even better: Add lables. "Import up to" and "Export down to". When I played my first time 2 years ago or so, it took me quite some time to figure out what the spinboxes are for and what value should go where.


Thanks a bunch!

I congratulate you on your deduction.

It is indeed the most annoying bug remaining in version 7 and still repeatable in beta 2.

Please fix this bug.

 

[Sarin]

Two things about a map, RaR Americas Huge-random.

One is very minor, the description says gigantic. Second, the European players spawn points are rather unbalanced. Three are on tundra/permafrost level, while South America has only one spawn. Moving at least the Pacific and northernmost Atlantic spawns to locations at SA coast would make the map more fun and balanced. It's not exactly realistic, I know...but there's non-random version for that.

Now, I've never actually edited maps in CIV or Colonization, but I'd be willing to fix the second thing, if only I knew how...from the start, since my editing attempts through WorldBuilder ended up...weird.

 

[Schmiddie]

Hey guys!

I believe I tracked down the bug that was described here:
https://forums.civfanatics.com/thre...-bugs-and-todos.449958/page-116#post-14964697


The correct code in CvCity.cpp, lines 1015 and 1016 should imo be:

1015       setImportsLimit((YieldTypes) iData1, (iData2 >> 16) & 0xFFFF); //shift and then mask, because never trust that 0s are shifted in from the left
1016       setMaintainLevel((YieldTypes) iData1, iData2 & 0xFFFF);

My reasoning is this:

-) In CvDLLButtonPopup.cpp on lines 3054 and 3056 it is established that the import limit goes to the spinbox with id "NUM_YIELD_TYPES+iYield" and the export limit/maintain level goes to the spinbox with id "iYield".

3054           gDLL->getInterfaceIFace()->popupCreateSpinBox(pPopup, iYield, L"", pCity->getMaintainLevel(eYield), 10, 999, 0);

3056           gDLL->getInterfaceIFace()->popupCreateSpinBox(pPopup, NUM_YIELD_TYPES+iYield, L"", pCity->getImportsLimit(eYield), 10, 999, 0);

-) In CvDLLButtonPopup.cpp on line 823 and lines 831 through 836 the values are concatenated with the import limit in the left 16 bits and the export limit/maintain level in the right 16 bits.

823                       int iLevel = pPopupReturn->getSpinnerWidgetValue(iYield);

831                       int iMaxLevel = pPopupReturn->getSpinnerWidgetValue(NUM_YIELD_TYPES + iYield);
832                       bool bImportsLimitChanged = iMaxLevel != pCity->getImportsLimit(eYield);
833                    
834                       int iBuffer = (iMaxLevel << 16);
835                       iBuffer |= iLevel & 0xFFFF;
836                       iLevel = iBuffer;

I have seen Erik Sandbraaten made this commit:
https://sourceforge.net/p/religion-.../ci/add7113453a6af836042e761b286033d0174e61c/

which, as far as I can tell from looking at the code, introduced this behavior.

I am pretty confident I got this one right. I did not build and test it, but because as of how the code is, the workaround for this bug, when I want to change import/exp limits, is to open the import/exp dialog, close it again (then the values are switched) then open it again, make my changes - to the spinbox of the other value - and then close it again. And this workaround works perfectly.


Can I wish for something as a bug finding and solution providing reward?

1) Please fix at least the bug and make a 2.7.1beta3 for download asap. Because I have no means to compile this for the next time. And I would like to keep playing without that workaround.

2) If you want to give me even more, make the value for the import limit go to the left spinbox and the export limit to the right one. Because this is far more intuitive. Left spinbox below checkbox "Import" and right spinbox below checkbox "Export". I did not check all the code, but I believe it should be along simply switching the IDs of the spinboxes ("NUM_YIELD_TYPES + iYield" and "iYield") in all function calls.

And/Or even better: Add lables. "Import up to" and "Export down to". When I played my first time 2 years ago or so, it took me quite some time to figure out what the spinboxes are for and what value should go where.


Thanks a bunch!

Please post the file you changed here. I will see after it when starting modding again.

 

[devolution]

All,

Could I get an accurate description of the import/export bug, I can only fix issues that I'm aware of.

 

[devolution]

For reference, this is a brief recap of the history of bugginess of this feature.

2.5 and earlier: I don't have source code prior to 2.6 so I dunno
2.6: The columns seemed to be swapped.
2.7 beta1: I swapped the import/export columns, but forgot about how the buttons was supposed to work
2.7 beta2: As far as I know, the columns and buttons work correctly now. I'll be happy to be provided with a counterexample

Btw, I am taking this from memory since it's been a while and I don't have access to my dev setup atm