BarbsPlus for ExtraModMod Preview and Discussion Thread

you are right.. I hesitated a lot between "odds and chances"... but you said there was a fixed odds of big bad monster spawning whatever the odds... so ... so having
"extremely good exploration odds and still having huge spawn" will still be shocking.
maybe : "exploration luck" ? "expected profit" ? "profit chances" ?
 
Hm, maybe just a short descriptive text:

"Strength of enemies depends solely on lair level.
Other events depend on lair level in strength and on exploration odds in kind (good or bad)."

or

"[There is a fixed chance that enemies spawn.] (<- maybe)
Strength of enemies and other events depends on lair level.
Exploration odds determine whether an event is good or bad."

Currently only the exploration odds text is colored (green-yellow-orange-red), the lair level probably should be colored, too.
 
I'm somewhat surprised that those wood golems spawned right next to a capital ... was it due to being late-game perhaps?


Edit: As far as having some text description about how dungeon exploration goes ... I think it should be in the Civilopedia (instead you risk over-complicating the help text popup)

Having Exploration Odds, Exploration Skill, and Dungeon Level is a good thing :)

and I think keeping to those three values in the helptext would be nice.


However for more in depth descriptions, it should be in the civilopedia ... perhaps under the 'New Concepts' section. There you could have a brief description of Dungeon Exploration and roughly how it works ... and you could mention a bit more explicitly that Unit Spawns are not determined by explo odds or explo skill, but instead on Lair (level/ difficulty rating), alone.

Maybe instead of "Lair level" on the help text of a dungeon's difficulty, you could put 'Challenge rating'?

Things like Weak, Moderate, Strong, Extreme ... and perhaps Legendary as well. (with green, yellow, orange, and red/purple/gold lettering)



In this way, the relative danger of the lair is still understood, even if it says "good" exploration odds. its still a dangerous lair. That plus having a descriptive section in the Civilopedia would likely go a long way.

((I briefly thought of having a unit's exploration skill determine the number of 'minions' that are spawned (while having no effect on the boss itself) ... but I'm not sure. The argument would be that a high level unit is more subtle, thereby disrupting less enemies, but this is not always the case))
 
you have a knack with words.
I follow tasunke on this
 
Exploration Skill (Unit lair level) -> Novice, Moderate, Advanced (lv6-ish?), Expert
(no color assignment)

Exploration odds (chance to get a good option for non-spawn options) -> Very Bad, Bad, Neutral, Good, Very Good (dark red, pale red, white, pale green, bright/dark green)

Challenge Rating (strength of potential spawns) -> Weak, Moderate, Strong, Extreme, Legendary, Godlike (green -> yellow -> orange -> red -> purple -> Gold)


Having Godlike and gold are optional imho, especially since gold might get confused with yellow. If flashing colors or striped colors or multi-colors were possible I'd have gold, silver, and purple all in one ... with maybe a dark-red border. Perhaps what is best is just the brightest and most obnoxious form of Yellow, White, or Silver ... that way it'll stand out against the 'regular' yellow. Technically tho u could ignore Godlike and just put all high end under legendary ... stuff like Dragons, elder gods, etc xD

@LFGR
Spoiler :
I'd like to incorporate .5 into my mod I believe ... although I have changed CivEventsManager, so not sure I could just fully merge into it. Perhaps I'll need to just copy and paste the bits of code you've added ... although I haven't changed the DLL so I could merge your new DLL at least (assuming that has been changed). What do you think about incorporation potential?
 
I'm somewhat surprised that those wood golems spawned right next to a capital ... was it due to being late-game perhaps?
A gargoyle and some wood golems? Spawned from Exploration, not just from lair or randomly? Then it's intended if barbs had construction.
Edit: As far as having some text description about how dungeon exploration goes ... I think it should be in the Civilopedia (instead you risk over-complicating the help text popup)

Having Exploration Odds, Exploration Skill, and Dungeon Level is a good thing :)

and I think keeping to those three values in the helptext would be nice.

However for more in depth descriptions, it should be in the civilopedia ... perhaps under the 'New Concepts' section. There you could have a brief description of Dungeon Exploration and roughly how it works ... and you could mention a bit more explicitly that Unit Spawns are not determined by explo odds or explo skill, but instead on Lair (level/ difficulty rating), alone.

Yeah, probably a good idea.

Maybe instead of "Lair level" on the help text of a dungeon's difficulty, you could put 'Challenge rating'?

Things like Weak, Moderate, Strong, Extreme ... and perhaps Legendary as well. (with green, yellow, orange, and red/purple/gold lettering)

In this way, the relative danger of the lair is still understood, even if it says "good" exploration odds. its still a dangerous lair. That plus having a descriptive section in the Civilopedia would likely go a long way.

I'm still sort of missing the indication of higher reward. This is why I favored "Lair Level" over something with "Challenge" (although the latter sounds better). I think with "Exploration Odds: Very Good, Challenge rating: Low" and "Exploration Odds: Good, Challenge rating: High" you don't get that the second gives you better things (if you actually get a good outcome).

((I briefly thought of having a unit's exploration skill determine the number of 'minions' that are spawned (while having no effect on the boss itself) ... but I'm not sure. The argument would be that a high level unit is more subtle, thereby disrupting less enemies, but this is not always the case))

Hm, I consider the bosses and minion part of a "guard" of the lair. You get in, but the way is blocked by a boss (who will of course call all its minions). This is why the spawns all have zero percent chance to destroy the lair. You can explore the lair another time after defeating the boss.
You could say an experienced unit would have the choice not to disrupt the boss and make a popup like "The entrance of the lair is blocked by a big ogre. Do you want to leave or attack it?", but this would make the whole mechanic more complex, and, more important, it would be illogical if the next time someone explores the lair the boss is not there anymore.
Also, you could say an experienced unit could have at least a better chance to sneak past the guard. Well, I think making high-experienced units able to do this would make high-wilderness lairs too easy to farm. But this (X% chance to avoid enemies from lair exploration) could maybe added as a special thing for certain units or promotion (thinking of sidar, svartalfar, panther trophy).

As you said, I don't consider higher experienced unit to be more "subtle", but just more experienced and smart to f.e. find a treasure/prisoner if it's there, to avoid poisoning themselves etc. (non-spawn outcomes). The ability to kill the enemies is measured automatically :).

Exploration Skill (Unit lair level) -> Novice, Moderate, Advanced (lv6-ish?), Expert
(no color assignment)
These all sound really good, thanks!
I think I'll only display even "Novice" only for units with a certain minimum lair level (firstly, because these words sound a bit RPG, which shouldn't be for every unit, secondly just to make the displayed text smaller in average).
Exploration odds (chance to get a good option for non-spawn options) -> Very Bad, Bad, Neutral, Good, Very Good (dark red, pale red, white, pale green, bright/dark green)
Hm, maybe yellow is better than white, since the rest of the text is white.

"chance to get a good option for non-spawn options" -> Your formulation lead me to the idea to really give the percentual odds of getting a good result. If not, at least they should be used to determine the worded level. For example, it makes no sense to distinguish between "Good" and "Very Good", if "Good" already has a 100% chance for a good outcome (It is possible in the current implementation to get such a "threshold" lair level).

Challenge Rating (strength of potential spawns) -> Weak, Moderate, Strong, Extreme, Legendary, Godlike (green -> yellow -> orange -> red -> purple -> Gold)

We'll see if it even makes sense to have that many levels up to godlike (I'll group the SpawnInfos accordingly).

I'd like to incorporate .5 into my mod I believe ... although I have changed CivEventsManager, so not sure I could just fully merge into it. Perhaps I'll need to just copy and paste the bits of code you've added ... although I haven't changed the DLL so I could merge your new DLL at least (assuming that has been changed). What do you think about incorporation potential?

Try WinMerge for the CvEventManager.
The DLL has changed quite a lot. You can just use it (if you merge all of BarbsPlus).
If you based your work on Extramodmod, the only files I can think of, that are maybe tough to merge, are CIV4UnitInfos.xml and I think another XML file I can't recall at the moment. In these files, I removed all XML tags with default values to make the files smaller and easier to edit (like in RifE), so WinMerge will mark nearly the whole document and be useless. However, I have a tool (which I was to lazy to release yet) to do this with any XML file, so if you want you can send me the file and I'll run that for you; then you can easily merge it with the BarbsPlus file and work with that from then on.
Other XML changes should be easy to merge, I think I mostly worked in my own XML files (like CIV4BarbarianCultures.xml).

I'd really appreciate if you based your mod on mine, but still be warned this is probably pretty unbalanced (you should play at least a game or two with few players on a large map. I think the barb pressure with this settings is much higher than normally).
 
Yes, I should probably have a thorough testing of your mod on its own before incorporating it into the mod :)

UnitInfos.xml, UnitClassInfos.xml, CivIV_FFH_GameText.xml, BuildingInfos.xml, TechInfos.xml, and Buildingclassinfos.xml I've all changed quite heavily. CivilizationInfos.xml as well.

My mod heavily changes the melee, mounted, and archer combat lines, and adds four new unitcombats. This is largely taken advantage of by the new 'Military Strategy techs' that branch off of the old Military Strategy tech.

(Its now Warfare -> mil Theory ... and Mil theory branches into Traditions and Strategy)

---------------------------

Hmm, so to get the really good events you need both a high Exploration odds AND a high Challenge Rating? In the Pedia you could briefly mention this.

I agree Legendary and Godlike shouldn't be used unless they are needed ... Weak -> Extreme is fine.

As far as dungeon skill level .... I am not advocating it to be passively displayed at all times upon the unit, but only in the help text of a lair. In this way I feel that all units should have default of 'Novice' ... and then after a certain minlevel become moderate and so forth. But certainly not to be displayed unless hovering over a lair while having that particular unit selected.
 
Yes, I should probably have a thorough testing of your mod on its own before incorporating it into the mod :)

UnitInfos.xml, UnitClassInfos.xml, CivIV_FFH_GameText.xml, BuildingInfos.xml, TechInfos.xml, and Buildingclassinfos.xml I've all changed quite heavily. CivilizationInfos.xml as well.

My mod heavily changes the melee, mounted, and archer combat lines, and adds four new unitcombats. This is largely taken advantage of by the new 'Military Strategy techs' that branch off of the old Military Strategy tech.

(Its now Warfare -> mil Theory ... and Mil theory branches into Traditions and Strategy)
Wow, sounds quite much. But it's based on EMM, no?
Hmm, so to get the really good events you need both a high Exploration odds AND a high Challenge Rating? In the Pedia you could briefly mention this.
Not exactly. You need high challenge rating and (Exploration odds +- random) higher than 0. So with exactly "medium" exploration odds (unit exploration skill = lair level), and high challenge rating, you still get the same good outcomes as with "good" exploration odds. You just have lower chances to get them (-> higher risk).
As far as dungeon skill level .... I am not advocating it to be passively displayed at all times upon the unit, but only in the help text of a lair. In this way I feel that all units should have default of 'Novice' ... and then after a certain minlevel become moderate and so forth. But certainly not to be displayed unless hovering over a lair while having that particular unit selected.

I thought it shouldn't be required to move a unit to a lair to see it's lair level. But thinking about it, higher level means almost always also higher exploration skills, so this is probably not required.
 
Terkhen: Hmm, I tried reinstalling MNAI 2.5 -> EMM 0.3.1 -> BP 0.0.4, and got no such error. Maybe you copied the files over a wrong base version?

I copied the files over my usual "base" version, which I have been using for nearly a year. I must have messed it up somehow, as after creating a new clean one everything worked fine. I'll be back with feedback soon :)

I'd like to incorporate .5 into my mod I believe ... although I have changed CivEventsManager, so not sure I could just fully merge into it. Perhaps I'll need to just copy and paste the bits of code you've added ... although I haven't changed the DLL so I could merge your new DLL at least (assuming that has been changed). What do you think about incorporation potential?

Mercurial does wonders at maintaining modmods as separate branches, and making merges way simpler :)
 
For my new test game I decided to play as the Grigori; since I want to test lair exploration, having powerful explorers will be helpful. As usual, I'm using the MapScriptTools version of the Erebus MapScript that is going to be included in ExtraModMod 0.4.0. I'm playing on a Large map with only 7 civilizations including mine, with the Wildlands, Living World, Compact Enforced, All Unique Features, Flavour Start (I disabled the starting point assignation of the MapScript) and Barbarian Cultures Game Options.

It was great to be able to change my usual exploration tactics. Having to carry a disposable unit to actually explore lairs along with your hero was time consuming and felt wrong, while now it is more like it was meant to be. I got the "nest of scorpions" bad result from a lair, which resulted on me having three scorpions pens without the hassle of going to a desert and capturing so many scorpions... It may be better to produce only two scorpions, but more powerful. Later on I got overconfident by always seeing "very good" as possible exploration outcomes until I got a powerful enemy arising after one exploration and defeated one of my hunter heroes. Lair exploration is still menacing, but it is no longer a russian roulette. It is way better and more entertaining than vanilla :)

The animal mechanics are quite fun too. I was able to cash in some early captures for money (I suggest removing the period from the end of TXT_KEY_MESSAGE_SPELL_SELL_ANIMAL, BTW), and soon I started to hunt prides and packs for having promotions in all of my cities. It was relatively simple for me to get lion trophies in all of my cities, but wolves were more scarce in my part of the map.

I have no bugs to report from this test game and I'm enjoying the changes a lot. With regard to inclusion, I'm planning to reduce the scope of 0.4.0 a bit (it's going slowly enough already) by only fixing the remaining rough edges of the new MapScriptTools maps. An early release would allow me to get feedback and fix any new issues on 0.4.0 before Christmas, which is when I will actually have time to code more complex stuff that could go into 0.5.0.

If I follow this plan, I reckon that 0.4.0 will be released in one or two weeks. Since I plan an early 0.5.0, it may be better to just include all of BarbsPlus branches into 0.4.0 (as long as they are ready) to get more testing and fix any possible issues for 0.5.0. What do you think?
 
How exactly does mercurial work?

I have heavily edited UnitClassInfos, CivIV_FFH2GameText, UnitInfos, BuildingInfos, TechInfos, BuildingClassInfos ....

and a bit of CivEventsManager too

Does the mercurial just save the changes I specifically made? B/c I don't believe that our changes would have necessarily overlapped, unless you tied certain events to techs that I changed, but I never deleted or renamed any techs so hopefully that wouldn't matter.
 
How exactly does mercurial work?

I'm going to try to give you a small summary. It may be somewhat confusing (Mercurial is not simple at first) so I suggest that if you are interested you follow these resources that will explain it better than I. The first one is a short introduction, while the second is a complete book that thoroughly explains what you can do with Mercurial. Although these resources are centered in the console version of Mercurial, you can also use TortoiseHG which provides you with a nice GUI for all of Mercurial operations.

http://hginit.com/01.html
http://hgbook.red-bean.com/read/

Mercurial is a version control system (VCS). These systems are created specifically to store different versions of source code while it is being developed, and to allow to easily check changes between different versions of the source code. The place where your code is stored is called a repository. You start working with a VCS by adding a base version of your source code to your repository and committing it (this would be commit 0). After that, whenever you make a small change that you want to store, you make a commit to the repository. The commit stores the change in the repository along with a small descriptive message you include with it.

I have a small repository in which I store maps and text files only (because the original More Naval AI repository does not include these folders and the ExtraModMod repository is based on it) called ExtraModModAddon, which can serve as a simple example of what you can do with Mercurial. You can check the commit log here: https://bitbucket.org/Terkhen/extramodmodaddon/commits/all

As you can see, each commit is stored in time order, and it includes the user who made it, a short description and the changes to source code that commit included.

There are many VCS systems; for example, More Naval AI uses Subversion (http://sourceforge.net/p/tholalsffhaimod/code/commit_browser). I chose Mercurial because along with other modern VCS such as Git, it allows to create and merge branches easily. Branches are created when you decide to "branch" a specific commit of your repository. After creating a branch, the source code history after that commit follows two different paths.

This is useful when you want to develop something separately from other changes. For example, since this time I plan to follow a more reasonable release scheme with ExtraModMod, 0.4.x versions will only include fixes to 0.4.0 and will be (as long as it's possible) savegame compatible with each other. To develop this, I will create a 0.4 branch just after releasing 0.4.0. The default branch will be for the development of the future 0.5.0 version (including commits for both fixes and new features), while the 0.4 branch will only include the fix commits from the default branch.

Another reason for creating branches (and the reason why I suggested using mercurial) is that they allow to develop new stuff or even complete forks on parallel easily. For example, while developing BarbsPlus, lfgr started by creating a branch from ExtraModMod's default repository (I'm simplifying a lot for the sake of clarity as lfgr actually created many different branches to develop each BarbsPlus feature separately). By doing that, BarbsPlus already contained all of ExtraModMod changes in its repository without having to do anything else.

After the branch, lfgr made commits in his branch while I made commits in the default branch. Whenever lfgr wanted to incorporate changes from ExtraModMod into his branch (for example, when I committed the new Unique Features for ExtraModMod, lfgr needed them for making the exploration changes to them too), it is only needed to do a merge of the default branch into the barbsplus branch. While merging, Mercurial will automatically apply all changes in the default branch to the barbsplus branch, prompting the user only to solve conflicts, allowing to choose what to do with a tool similar to WinMerge.

In your case, since the BarbsPlus repository will be merged in the future intro ExtraModMod's default branch, you could branch ExtraModMod's default branch, pull the BarbsPlus repository into yours (at this point you would already have all of ExtraModMod and BarbsPlus changes) and then start committing your own changes into your branch. Whenever you want to update the ExtraModMod or BarbsPlus version included in your branch, you only need to pull from them.
 
Hmm, so I'd have to recode only once (through the mercurial commits) but then after that it should be able to update w/o me having to recode (ie start over) muliple times, over multiple upgrades of the EMM and Barb+ code.
 
I got the "nest of scorpions" bad result from a lair, which resulted on me having three scorpions pens without the hassle of going to a desert and capturing so many scorpions... It may be better to produce only two scorpions, but more powerful.
Agreed.
Later on I got overconfident by always seeing "very good" as possible exploration outcomes until I got a powerful enemy arising after one exploration and defeated one of my hunter heroes. Lair exploration is still menacing, but it is no longer a russian roulette. It is way better and more entertaining than vanilla :)
Good to hear that!
The animal mechanics are quite fun too. I was able to cash in some early captures for money (I suggest removing the period from the end of TXT_KEY_MESSAGE_SPELL_SELL_ANIMAL, BTW), and soon I started to hunt prides and packs for having promotions in all of my cities. It was relatively simple for me to get lion trophies in all of my cities, but wolves were more scarce in my part of the map.
Changed the TXT, thanks.
Just checked the wolf spawn, it should spawn in forests up to wilderness 65. I think that's enough to have at least some spawning areas for wolves on a map (It's still meant that you normally have to explore a bit to get all animals and the Great Menagerie. I try to make the animals somewhat balanced, but still different).
I have no bugs to report from this test game and I'm enjoying the changes a lot. With regard to inclusion, I'm planning to reduce the scope of 0.4.0 a bit (it's going slowly enough already) by only fixing the remaining rough edges of the new MapScriptTools maps. An early release would allow me to get feedback and fix any new issues on 0.4.0 before Christmas, which is when I will actually have time to code more complex stuff that could go into 0.5.0.

If I follow this plan, I reckon that 0.4.0 will be released in one or two weeks. Since I plan an early 0.5.0, it may be better to just include all of BarbsPlus branches into 0.4.0 (as long as they are ready) to get more testing and fix any possible issues for 0.5.0. What do you think?

I didn't experienced (or was reported) any crash for a while, so I don't think that's still a problem.
As for balance issues, I think the barbarian pressure without the raging barbs gameoption should be tested a bit more to make sure it is not much higher than in vanilla FfH. I just tested the leashed feature from RifE to make raging barbs more balanced, but that will take some time, so raging barbs will probably be a bit experimental in the next few versions of BarbsPlus. I'll play without raging barbs the next few times.
The merge itself: I think the only technical issue is the different makefiles we use (I also removed the python24 and boost folders at the beginning to save space, but added them back in now, because I think they are stored in the each local repository either way). I tried removing your make file, adding mine, adding the Makefile to the ignore list, and commit then, but mercurial overwrote my makefile with yours when I merged EMM the next time.

...
Could you explain how you'll include barbsplus into EMM? I thought of merging it in all the time, but since barbsplus already includes (or will include) the latest version of EMM, is that even necessary?
 
The merge itself: I think the only technical issue is the different makefiles we use (I also removed the python24 and boost folders at the beginning to save space, but added them back in now, because I think they are stored in the each local repository either way). I tried removing your make file, adding mine, adding the Makefile to the ignore list, and commit then, but mercurial overwrote my makefile with yours when I merged EMM the next time.

The python24 and boost folders are included because I'm accustomed to just clone and compile the project without any additional hassle. You are right; if you clone from ExtraModMod all of those files are stored in the metadata anyways so there is no space gain in removing them. I'm open to changes to the makefile, if that is needed. What are the differences between the one you use and mine? I think we can reach a solution that is good for us both.

Could you explain how you'll include barbsplus into EMM? I thought of merging it in all the time, but since barbsplus already includes (or will include) the latest version of EMM, is that even necessary?

I was thinking on just pulling any branches deemed as ready to be merged into the ExtraModMod default branch, in the same way I did with events_enhanced (I learned how to do it without messing up the merges). Otherwise, it would be hellish for you to do the first merge against EMM in your other branches if the BarbsPlus-EMM merge is not done via Mercurial.

Depending on what you prefer to continue development of merged branches, I would either give you manager access to the ExtraModmod repository and tracker so that you can continue development on top of ExtraModMod directly, or just pull from your repositories as needed to get any new stuff into ExtraModMod, as I periodically do with events_enhanced.

I would need to have those changes in my own repository, otherwise to really test ExtraModMod I would need to clone BarbsPlus, pull from ExtraModMod into BarbsPlus and test with that instead of with my own repository.
 
I was thinking on just pulling any branches deemed as ready to be merged into the ExtraModMod default branch, in the same way I did with events_enhanced (I learned how to do it without messing up the merges).

OK, I think I understood now (and I'm perfectly fine with that).

The Makefile I'm using is this one. It's a bit faster than DannyDaemonic's, and, more important, includes a new "Assert" target, which is like release but obviously enables assert messages. I think having that features and the outsourced Makefile-Vars would be best.

EDIT: And, to clarify, I'd prefer to work with my own branches.
 
Hmm, so I'd have to recode only once (through the mercurial commits) but then after that it should be able to update w/o me having to recode (ie start over) muliple times, over multiple upgrades of the EMM and Barb+ code.

Exactly. Besides punctual conflicts caused by either EMM or BarbsPlus modifying exactly the same places your mod would touch, you would never need to recode anything. Even in this case, you would only need to check the specific point which was changed.

OK, I think I understood now (and I'm perfectly fine with that).

The Makefile I'm using is this one. It's a bit faster than DannyDaemonic's, and, more important, includes a new "Assert" target, which is like release but obviously enables assert messages. I think having that features and the outsourced Makefile-Vars would be best.

EDIT: And, to clarify, I'd prefer to work with my own branches.

I'm actually using Asaf's Makefile which includes its own improvements to compilation speed (although certainly I don't remember it taking advantage of multiple processors). That makefile seems superior to my own (I specially like that it would allow to compile beta versions with asserts enabled for testing), so I created task #178 to update my Makefile.

I have no problems with keeping your branches separate and pulling from them periodically. I'll clone any reported issues you still don't have on both your repository and mine, and close mine when I pull the related fix from your branches. With regard to which branches to merge, I'm guessing that we'll go along with the original plan of merging only the wilderness and terrain_flavour branches for 0.4.0. I'm giving priority to #178 to make both your life and mine easier, and I'm aiming for a release somewhen in the next week.
 
I'm actually using Asaf's Makefile which includes its own improvements to compilation speed (although certainly I don't remember it taking advantage of multiple processors). That makefile seems superior to my own (I specially like that it would allow to compile beta versions with asserts enabled for testing), so I created task #178 to update my Makefile.

I'm sorry about the delay, but yesterday I finally had a free day to switch makefiles and test all targets. The targets are going to be useful, and I must say that the speed increase when you have many cores is awesome :)

In order to take advantage of the assert target in the future, I created this task: https://bitbucket.org/Terkhen/extramodmod/issue/185/assert-cleanup

Since More Naval AI issue with OOS logs seems to be fixed, I decided that the 0.4.x releases of ExtraModMod are going to aim for fixing OOS issues. Before releasing 0.4.0 I'm going to play a multiplayer game including both the recent changes to ExtraModMod and the wilderness and terrain_flavour branches of BarbsPlus with my "testing team" to test if it introduces any desyncs. In case they don't, both branches will be included in 0.4.0. If they do introduce new desyncs, I'll drop them from inclusion in 0.4.0 but keep with the test games anyways to get many oos logs to help on fixing them. What do you think about this? Are there any pending issue on any of these branches that would make unadvisable to merge at the moment?
 
We played a test game with wilderness merged on top of a development version of ExtraModMod. After 268 turns we had no desyncs at all :)

The game was on archipielago with tiny islands, so the map was mostly sea. Somehow the barbarians closely matched our own naval technology, attacking us with ship types we had discovered just 10 or 20 turns before. They already had Man'O'Wars on turn 240.

Given the nature of this game we did not explore many lairs, although the unique ones were working as expected :)
 
Top Bottom