[RaRE] RaR Extended: a combined modmod for the RaR modification

Commander Bello

Say No 2 Net Validations
Joined
Sep 3, 2003
Messages
3,858
Location
near Koblenz, Germany
Starting with Nightingale's RaRE (upto RaR 1.6), several modders now have released their own modmods for the Religion and Revolution modification, as there are (in no particular order):

As many or at least some of the individual changes were and are of interest for the other modmodders, too, we have come to the agreement to combine the commonly accepted features into one "big modmod" which we will call "Religion and Revolution Extended" (RaRE).

This thread shall serve the purpose to discuss things, propose changes and adoptions, and to have a place where we can organize ourselves.
As it is likely that later on other threads may be needed or wanted, I propose to have a tag [RaRE] in the name of such new threads, just to make identification easier.

RaRE will be based on the RaR modification like the individual modmods were, yet enhance it where we think it is necessary or desirable, so it may enhance the playing experience of RaR-players.
 
To make a start, let my say some things related to my own modmod :blush:

The discussion of the past days showed that the feature "limited combat rounds" which originally was introduced to the RaR environment by my modmod seems to be generally accepted, yet some people are unhappy with the currently hardcoded value of just 7 internal combat rounds (reasons and backgrounds for this change I have explained here and in the following postings).

Although personally I am fine with that value, I understand the point of view of the others and as I already did, I once again propose to enhance it by a XML-based value for the number of internal rounds (in the GlobalDefinesAlt.xml). That way, everybody can set the number to the desired value and even go back to the "death or glory" principle of vanilla Col (by just inserting a "99" which under all circumstances should be sufficient).

Another point being critically observed was the strength of the starting army which I have given the colonial players.
I admit that under current rules, this army may have been too strong (was 1 Seasoned Scout, 2 Conquistadors, 3 cannon regiments and 5 cannon garrisons).
Here I propose a change to 1 Seasoned Scout (exploration), 1 Conquistador (counter attack) and 4 cannon garrisons (defense).
I still would like to give the player a chance to survive an eventual early native attack, yet not to enable him to massacre surrounding natives.

Another point was the question if natives and scouts should again be enabled to cross mountains (peaks).
I would prefer to keep it the way it was in my modmod: that only units in the profession "Pioneer" can enter mountains and other units only after a route has been created there (the following points of course just reflect my point of view).
1) in the vanilla game, mountains were just like forests or jungles, yet even gave you a better view of the surroundings, as your field of view was increased. That always irritated me
2) the limitation makes exploration much more interesting
3) you may make use of bottleneck situations now, both in warfare as by placing cities in suitable locations
4) native units placed on mountains were a nuisance, as they couldn't be attacked by own troops, yet caused the game to constantly notify you about "enemies around"

The contribution of sales to crosses I would like to keep, too.
The reason is that currently we have a strange situation: due to the low early limit of crosses needed (and chapels available on the spot) immigration during the early game is high and significantly decreases in the middle game. It may increase in the later game again, if the right Founding Fathers are achieved and enought churches built (and some events, too), but in total the way immigration works in vanilla/RaR is just ahistorical.
By giving the players crosses (which don't contribute to the crosses generated for FF's) for sales, at least to a certain degree the attraction of a flourishing economy in the New World to Europeans is simulated and helps limiting the aforementioned effects of having almost no immigration in the middle game.
Once again, about the percentages we can discuss and here we might offer XML settings, too.
 
Another point being critically observed was the strength of the starting army which I have given the colonial players.
I admit that under current rules, this army may have been too strong (was 1 Seasoned Scout, 2 Conquistadors, 3 cannon regiments and 5 cannon garrisons).
Here I propose a change to 1 Seasoned Scout (exploration), 1 Conquistador (counter attack) and 4 cannon garrisons (defense).
I still would like to give the player a chance to survive an eventual early native attack, yet not to enable him to massacre surrounding natives.

Maybe we could give starting players some additional starting colonists as well. It would seem strange to send 4 cannon garrisons to protect two colonists.

Some more colonists at the start could also speed up the early game a little.

Another point was the question if natives and scouts should again be enabled to cross mountains (peaks).
I would prefer to keep it the way it was in my modmod: that only units in the profession "Pioneer" can enter mountains and other units only after a route has been created there (the following points of course just reflect my point of view).
1) in the vanilla game, mountains were just like forests or jungles, yet even gave you a better view of the surroundings, as your field of view was increased. That always irritated me
2) the limitation makes exploration much more interesting
3) you may make use of bottleneck situations now, both in warfare as by placing cities in suitable locations

Those are good points.

4) native units placed on mountains were a nuisance, as they couldn't be attacked by own troops, yet caused the game to constantly notify you about "enemies around"

I never had much problems with that. They usually will enter a plot that can be attacked in one or two turns.:dunno:

The main thing that seems very strange to me is that natives cannot enter peaks, unless a colonial power builds a road first. I think one of the things we need to keep realistic, is that natives are better at travelling and fighting in the wilderness.

Also, they can use every military advantage they can get. So if they gain the ability to move in terrain European players can't enter, it seems like a realistic advantage for them to have. Also, the bottleneck strategy (which I think gives the human player a big advantage, as the AI is not very smart) would not work on natives, but it would work on Europeans and the REF. That also seems rather realistic to me.

That's why I still think natives should be excepted from the new system.

BTW, will Ancient Ruins and Burial Grounds still appear on peaks? If so, does that mean only pioneers can explore them?

The contribution of sales to crosses I would like to keep, too.
The reason is that currently we have a strange situation: due to the low early limit of crosses needed (and chapels available on the spot) immigration during the early game is high and significantly decreases in the middle game. It may increase in the later game again, if the right Founding Fathers are achieved and enought churches built (and some events, too), but in total the way immigration works in vanilla/RaR is just ahistorical.
By giving the players crosses (which don't contribute to the crosses generated for FF's) for sales, at least to a certain degree the attraction of a flourishing economy in the New World to Europeans is simulated and helps limiting the aforementioned effects of having almost no immigration in the middle game.
Once again, about the percentages we can discuss and here we might offer XML settings, too.

I agree with that. I always found it unrealistic that immigration was solely driven by religious freedom in your colonies.

I personally wouldn't mind if there were even more different ways of boosting immigration. For example, what about wars and famines in Europe? These usually were the driving factors.
Also, maybe discovering valuable resources, such as gold and gems, could also increase immigration a bit.

The only thing that we need to be careful of is that preachers do not become useless.
 
4) native units placed on mountains were a nuisance, as they couldn't be attacked by own troops, yet caused the game to constantly notify you about "enemies around"
I never had much problems with that. They usually will enter a plot that can be attacked in one or two turns.:dunno:

The main thing that seems very strange to me is that natives cannot enter peaks, unless a colonial power builds a road first. I think one of the things we need to keep realistic, is that natives are better at travelling and fighting in the wilderness.

Also, they can use every military advantage they can get. So if they gain the ability to move in terrain European players can't enter, it seems like a realistic advantage for them to have. Also, the bottleneck strategy (which I think gives the human player a big advantage, as the AI is not very smart) would not work on natives, but it would work on Europeans and the REF. That also seems rather realistic to me.

That's why I still think natives should be excepted from the new system.
It's a very thin line.
I understand your points, but if natives are allowed to enter peaks then you don't have a counter unit for them. Which would make you create a counter unit, but that will benefit you even more when fighting with other colonial powers or the REF.
The problem may be both, the single mountain next to your settlement (because of the reasons mentioned above) and even more, the mountain chain prohibiting you to attack the natives while they are flooding into your area.

What might be done, though, is to give certain natives the ability to build roads on peaks. Might be worth a try. :think:

BTW, will Ancient Ruins and Burial Grounds still appear on peaks? If so, does that mean only pioneers can explore them?
No, since the last version of my modmod peaks can be entered if there's a goody hut.

Actually, I am thinking about adding a road to that peak as soon as the goody has been entered. One could say that it was an old burial site to which a path was leading.
That way, one could create mountain passes which may be an advantage or disadvantage to you.

The only thing that we need to be careful of is that preachers do not become useless.
Well, preachers already are pretty much useless :)
They are eating your food and except for the early game don't really benefit you. As I already pointed out here, I am currently thinking of giving additional benefits to them.
 
BTW, will Ancient Ruins and Burial Grounds still appear on peaks? If so, does that mean only pioneers can explore them?
Seasoned scouts are able to enter peaks, just like hardy pioneers can.

Well, preachers already are pretty much useless :)
I would say that problem is mainly a question of the required number of crosses to gain the next colonist. I recall the formula as some exponential calculation. Say it says cost of last unit + 20%. 10 + 20% is 12 and no big raise. However at some point a colonist cost say 1000 and then 20% would be an additional 200. The next one again would increase cost by another 240 (to 1440).

I think the proper solution to this issue is to make cross requirements be calculated in a more balanced way. I don't know what would be best, but we could introduce new numbers into the calculation, such as how many human units you have, average number of units for European players, peace factor (number of turns since last combat/last war), your wealth etc. We could even add some randomness.

My guess for a decent system would be one where increases for each unit aren't that much, but it starts higher and then you get a discount for every unit you have under some set amount. That way it will still be fairly easy to get plenty of units early, but it will be followed by a reasonable flow later on, which will not raise to insane levels. We might also consider putting a cap on unit cost meaning at late game, twice the number of crosses will produce twice the number of immigrants.


I have asked Schmiddie if he is ok with copying the svn server with the log. I will do something about setting up git once he replies.
 
In that case I will set up git shortly. I plan on removing the DLL file as it takes up a whole lot of server space. When it was removed from M:C, it freed 200 MB and I think RaR uses even more in this regard. While sourceforge gives us unlimited server space, we do need to transfer the data and a difference of hundreds of MB does make a difference when people clone (download for the first time).

Would it be a problem for anybody if the DLL is missing? If it is, would it be ok to delete the DLL files in history and just keep the new ones?
 
In that case I will set up git shortly. I plan on removing the DLL file as it takes up a whole lot of server space. When it was removed from M:C, it freed 200 MB and I think RaR uses even more in this regard. While sourceforge gives us unlimited server space, we do need to transfer the data and a difference of hundreds of MB does make a difference when people clone (download for the first time).

Would it be a problem for anybody if the DLL is missing? If it is, would it be ok to delete the DLL files in history and just keep the new ones?

You're confusing me.
What do you mean by the DLL file taking up to 200 MB?
The CvGameCoreDLL.dll just takes 4 MB (RaR) for the release version.

Regarding the source files (as in DLL_Sources) I think we only need the files from 2.2, as anybody wanting to change the DLL should have all previous versions in his RaR installation.
 
You're confusing me.
Missing accomplished :trophy:

What do you mean by the DLL file taking up to 200 MB?
The CvGameCoreDLL.dll just takes 4 MB (RaR) for the release version.
That is 4 MB multiplied with the number of revisions where the DLL file is updated. Remember that svn and git will remember all versions of the files, not just the newest.

Regarding the source files (as in DLL_Sources) I think we only need the files from 2.2, as anybody wanting to change the DLL should have all previous versions in his RaR installation.
Being able to track changes in the log can help a lot when hunting bugs. Besides those are PLAIN TEXT files, which mean git store changes line by line rather than replacing the files like they do with binary files (like DLL files). We would likely save less than an MB (presumably much less) if we remove text file history. That would make no sense.
 
It's a very thin line.
I understand your points, but if natives are allowed to enter peaks then you don't have a counter unit for them. Which would make you create a counter unit, but that will benefit you even more when fighting with other colonial powers or the REF.
The problem may be both, the single mountain next to your settlement (because of the reasons mentioned above) and even more, the mountain chain prohibiting you to attack the natives while they are flooding into your area.

What might be done, though, is to give certain natives the ability to build roads on peaks. Might be worth a try. :think:

That makes sense. However, natives usually only have braves. Having natives with the mountaineer promotion enter would not be an option, as that would only help some nations.

Actually, I am thinking about adding a road to that peak as soon as the goody has been entered. One could say that it was an old burial site to which a path was leading.
That way, one could create mountain passes which may be an advantage or disadvantage to you.

Wouldn't it be easier to just add the roads at the beginning of the game, when the goodies are placed?

Well, preachers already are pretty much useless :)
They are eating your food and except for the early game don't really benefit you. As I already pointed out here, I am currently thinking of giving additional benefits to them.

Additional benefits could help, but I agree with Nightingale. The increase of the immigration threshold becomes way too big after the early game. If we find a way to balance that out, then perhaps we wouldn't need to give crosses extra effects.
 
Yes, you can copy the SVN as far as nothing will be published until the main mod has been published as Release 2.2.

Alright!:thumbsup:

Do you have any indication at the moment when 2.2 will be released?

Would it be a problem for anybody if the DLL is missing? If it is, would it be ok to delete the DLL files in history and just keep the new ones?

I would prefer it if there is always a recently updated DLL available. Testing could become really exhausting if you would have to compile a new one every time.:dunno:

BTW, about the project in GIT, is it possible to organize the folders in such a way, that the Mod can be started immediately from the game's main menu without first having to copy everything into a new folder?

I ask this because that is how the core mod is structured at the moment. Currently, there are two folders in the main category there, "Religion_and_Revolution," containing the mod, and the Workfolder. I cannot test the latest revision without first copy-pasting the entire mod into my Mods folder, which is time-consuming.

If the contents of the mod (Assets, PublicMaps, etc) were moved up one level to the main folder, everyone can keep their version of the mod in their Mods folder, and test it immediately after updating.
 
Wouldn't it be easier to just add the roads at the beginning of the game, when the goodies are placed?
We could make the DLL place a road whenever a plot has a goodie added. I don't think that will be hard to do. We could also modify CvUnit::canMoveInto() into ignoring peak restriction if there is a goodie on the plot.

Do you have any indication at the moment when 2.2 will be released?
My plan is to make a local svn branch and pull 2.1 out of that one and use it as a base. When 2.2 is released I can easily merge the branches. That should work ok unless somebody causes conflicts by adding the same feature to svn and git.


I would prefer it if there is always a recently updated DLL available. Testing could become really exhausting if you would have to compile a new one every time.:dunno:
Good point. We can leave it as it is. Speaking of waiting for the compiler, I intend to add makefile 2.3 + project files. That way all CPU cores will be used instead of just one. Also I might clean up header includes like I did in M:C. Right now there are plenty of unneeded includes and if a header is modified, all cpp files including it will be recompiled. After the cleanup most headers will only force half the files to recompile and quite a lot less than that.

Wouldn't it be easier to just add the roads at the beginning of the game, when the goodies are placed?
We could make the DLL place a road whenever a plot has a goodie added. I don't think that will be hard to do. We could also modify CvUnit::canMoveInto() into ignoring peak restriction if there is a goodie on the plot.

Do you have any indication at the moment when 2.2 will be released?
My plan is to make a local svn branch and pull 2.1 out of that one and use it as a base. When 2.2 is released I can easily merge the branches. That should work ok unless somebody causes conflicts by adding the same feature to svn and git.


BTW, about the project in GIT, is it possible to organize the folders in such a way, that the Mod can be started immediately from the game's main menu without first having to copy everything into a new folder?
I have done so locally and intend keep it that way. In fact I didn't even consider doing it any other way. The trick is to NOT check out the entire svn server, but select a folder inside the server. We will lose Workfolder that way, but the ability to just place the working directory inside MODS is way more important.

Also you can check out a folder in svn if you like. While colonization will not work on an alias in MODS, it will work if you place a symbolic link to the folder you intend to place there. While it works (I have done it), it is easier to just keep the git file layout MODS compatible.
how-to-create-symbolic-link-in-windows-7
 
We could make the DLL place a road whenever a plot has a goodie added. I don't think that will be hard to do. We could also modify CvUnit::canMoveInto() into ignoring peak restriction if there is a goodie on the plot.

I think it is easiest, and most realistic, to make the DLL add a road.

My plan is to make a local svn branch and pull 2.1 out of that one and use it as a base. When 2.2 is released I can easily merge the branches. That should work ok unless somebody causes conflicts by adding the same feature to svn and git.

Okay, I understand that.
I don't understand, though, why it would cause conflicts if stuff was added to both svn and git. If you merge those, wouldn't git just interpret those particular parts as being unmodified like all other parts where both branches are the same?

This might be important, as maybe there are things in our submod that Schmiddie wants to add to the core mod.
 
I don't understand, though, why it would cause conflicts if stuff was added to both svn and git. If you merge those, wouldn't git just interpret those particular parts as being unmodified like all other parts where both branches are the same?
It will cause a conflict if both branches are modified. Git will then look at the conflict and auto resolve it if both modifications are 100% identical. Here lies the problem. They have to be 100% identical.

Code:
///  ModTech start
Code:
/// ModTech start
Code:
///  ModTech - start
That's 3 ways to write the very same and not picking the same will cause a conflict, which requires human interaction. It is very likely to cause conflicts even if you think you added the very same code to both sources.
 
From a merging perspective, who is checking in their modmod as a base? CB has already included my modmod's changes as part of his modmod, so his or agnat86's modmods might be a good start. I suppose merging our modmods and testing will take a day's work at the most, so whoever feels their modmod has more changes should use theirs as a base.
 
I have managed to import the svn server from RaR into git and hope to have that online this weekend. It just needs a few finishing touches and then a long upload.

While we could use another mod as base, I think it's best to use RaR itself and then apply each modmod into it due to file history. It will make it easier to track down who did what and why later, something which could be worth quite a lot if the game becomes buggy.
 
I have managed to import the svn server from RaR into git and hope to have that online this weekend. It just needs a few finishing touches and then a long upload.

While we could use another mod as base, I think it's best to use RaR itself and then apply each modmod into it due to file history. It will make it easier to track down who did what and why later, something which could be worth quite a lot if the game becomes buggy.

Sure. It's basically the same thing. The first modmod is always trivial (just an archive extract :D) Thanks for uploading btw.
 
I have managed to import the svn server from RaR into git and hope to have that online this weekend. It just needs a few finishing touches and then a long upload.

While we could use another mod as base, I think it's best to use RaR itself and then apply each modmod into it due to file history. It will make it easier to track down who did what and why later, something which could be worth quite a lot if the game becomes buggy.

How do you think we should import our modmods. Every modmod in its entirety, or feature by feature?

I would greatly prefer the first option, as the second would, at least in my case, be very time-consuming.:dunno:

Also, Schmiddie recently said that he expected to release RaR 2.2 within a week or three. If we do not plan to release RaRE before that, then it would not be a problem to just add all features of the current SVN to git, would it?

I'm asking this because I have kept my modmod updated with the svn of RaR, and it would be quite some work to separate my features from Schmiddie's changes. If we do not release our modmod before RaR2.2, then we can just keep Schmiddie's changes.
 
How do you think we should import our modmods. Every modmod in its entirety, or feature by feature?

I'm asking this because I have kept my modmod updated with the svn of RaR, and it would be quite some work to separate my features from Schmiddie's changes. If we do not release our modmod before RaR2.2, then we can just keep Schmiddie's changes.

I don't know if the reply was for Nightinggale alone, but I think entirety makes more sense. Of course we will have to modify the features that we decided to omit\tweak (based on the discussion in the merging mod-mod section), such as CB's modmod starting army size.
It makes more sense to wait for Schmiddie to release RaR2.2, we can merge and test in the meanwhile.
 
Top Bottom