Merging modmods

[vetiarvind]

Well, it would save a LOT of work if we just put together all things we can agree about.

But as I said, if we had a central project, you would have more time today you could spend on making new things, instead of adding mine.

Makes sense! So what you're proposing is a RAR-extended version where we modders work as a team and produce one mod-mod whose features cannot be toggled? So, to add to this mod-mod is it enough if one\two people thinks it's good enough? Do we get vetos like how R&R members do it?
Personally, I would be in favour of 2 vetos to not include a mod. (if the members are more than 3)

 

[Commander Bello]

I may misunderstand the discussion at the moment, but as far as I see it, the "big modmod" doesn't change anything if there are small parts left, no?

Let's say there are four modmodders A to D, who all made their individual changes 1 to 4.
Then you have A1 - A4, B1 - B4, and so on.

Now, for the "big modmod" these four agree upon A1, A2, B3, C2, C4, D1, D2 and D4.
Still, in the end they are all left with their individual modmods, as each of those holds specific changes.
Sure, for them changing their own modmod may become a bit easier (and as I myself am currently in the process of merging, I know how time consuming this is), but I still miss to see the advantage for the players - they might even get more confused now in finding out where the differences are.

I don't want to say that I reject the idea but the real advantage at the moment still is hidden for me.

 

[agnat86]

Makes sense! So what you're proposing is a RAR-extended version where we modders work as a team and produce one mod-mod whose features cannot be toggled?

I would prefer that, although I personally do not mind if we add customizable features as Game Options. But we should not ask the player to go to XML files to make his or her preferences known. That should be done in-game.

So, to add to this mod-mod is it enough if one\two people thinks it's good enough? Do we get vetos like how R&R members do it?
Personally, I would be in favour of 2 vetos to not include a mod. (if the members are more than 3)

Well, that is one of the first things we would need to discuss.
For example, we could do it like this:

• Anyone who wants to add a feature makes his intentions known to the teammates on the forums (or in PMs). The teammates can then provide feedback if they want to
• When features are ready to be committed, if no one made any objections against them, they are free to do so.
• Before adding anything, the necessary quality checks need to be done (testing, balancing etc.)
• We do not add unfinished features (for example, when you add a unit, you also add the pedia texts associated with it).
• We do not add anything that is vetoed. This can only work, of course, if we only veto things for good reason. Quite often, if anyone doesn't like a feature it just needs to be adapted or balanced.

Of course, as there currently are several finished features available already, I propose that we first decide which of those we are going to include, so we have a first version of our modmod, and something to work from. But for that, everyone needs to post a list of features here that he wants to add.

 

[vetiarvind]

Sure, for them changing their own modmod may become a bit easier (and as I myself am currently in the process of merging, I know how time consuming this is), but I still miss to see the advantage for the players - they might even get more confused now in finding out where the differences are.

I don't want to say that I reject the idea but the real advantage at the moment still is hidden for me.

Exactly, it is hidden because the answer is simply not there. So, to summarize:
1) centralized "push what you want" structure
- where no one is entirely happy because of feature-spam
- balancing issues
+ more features are easy to get
2) centralized toggle-based structure
- hard to implement
- future compatibility
+ flexibility for users
+ access to features
3) centralized veto-based mode (similar to the existing R&R model, where modders will maintain private versions)
- modders will maintain private version on top of common mod-mod
+ better overall mod
4) decentralized structure (more freedom to individual modders, but all mod-modders pledge to update their mod-mod with future R&R releases)
+ more balance
- user will have to spend time to choose

I would prefer that, although I personally do not mind if we add customizable features as Game Options. But we should not ask the player to go to XML files to make his or her preferences known. That should be done in-game.
Of course, as there currently are several finished features available already, I propose that we first decide which of those we are going to include, so we have a first version of our modmod, and something to work from. But for that, everyone needs to post a list of features here that he wants to add.

My personal choice would be 4. Next would be 3 with 2 vetos.
List of features to add:
1)Implement risk-based assessment for automated units to revert to manual mode. (>=50% would halt automation)
2)Trilateral navigation between port screens and if possible, automation.
3)Since no one has volunteered so far, I will add Sea AI to search for wrecks like scouts do. (i am not familiar with the AI code, so it might take me time)

 

[agnat86]

I may misunderstand the discussion at the moment, but as far as I see it, the "big modmod" doesn't change anything if there are small parts left, no?

Well, it does. It can function as a rallying flag for visitors to this forum, and increases the exposure of our work to the public. Small modmods usually end up in lonely, forgotten corners of the forums, but larger projects attract attention.

Now, for the "big modmod" these four agree upon A1, A2, B3, C2, C4, D1, D2 and D4.
Still, in the end they are all left with their individual modmods, as each of those holds specific changes.
Sure, for them changing their own modmod may become a bit easier (and as I myself am currently in the process of merging, I know how time consuming this is), but I still miss to see the advantage for the players - they might even get more confused now in finding out where the differences are.

Well,

• the personal modmods would be much smaller than they are now, which makes comparison easier
• it would save us a lot of work, as you do not have to commited every tiny change time and time again whenever you add another modder's work. The time saved that way can be used to adding features and improve the mod's quality.
• We can link to our own modmods in the main thread of the "main" modmod, and explain the differences between them
• Working together also provides an extra quality check to our work, in the form of feedback of your teammembers.

I don't want to say that I reject the idea but the real advantage at the moment still is hidden for me.

Well, I think this more or less is it. However, whether or not you think those advantages matter much, I do not see a real disadvantage to working together.

 

[Nightinggale]

I'm not sure I like the concept of limited number of vetos. Imagine somebody spamming silly ideas and then we end up with submarines because he proposed that after everybody else ran out of vetos. Besides just throwing a veto is against the idea of cooperation. If there is an idea, which we agree on, we debate it and if we can't agree, we would consider if it makes sense to make it a game option or something.

As for game options, it's not a goal to gain as many as possible. In fact we should keep the number as low as possible without preventing features. It's an option we can use when we have two or more valid solutions and we can't agree on what is best. City radius is so far the only feature, which really makes sense to add as an option.

 

[agnat86]

I'm not sure I like the concept of limited number of vetos. Imagine somebody spamming silly ideas and then we end up with submarines because he proposed that after everybody else ran out of vetos. Besides just throwing a veto is against the idea of cooperation. If there is an idea, which we agree on, we debate it and if we can't agree, we would consider if it makes sense to make it a game option or something.

I agree with that. Although I think that "spamming silly ideas" would not be the cooperative attitude that is required for a team project, so anyone who would feel inclined to do so perhaps shouldn't join.
I hope people can also just use their common sense to determine whether or not a change would be welcome, or need discussion before implementation. And that usually is not complex mathematics or something.

As for game options, it's not a goal to gain as many as possible. In fact we should keep the number as low as possible without preventing features. It's an option we can use when we have two or more valid solutions and we can't agree on what is best. City radius is so far the only feature, which really makes sense to add as an option.

I agree with that as well.

 

[vetiarvind]

I'm not sure I like the concept of limited number of vetos. Imagine somebody spamming silly ideas and then we end up with submarines because he proposed that after everybody else ran out of vetos. Besides just throwing a veto is against the idea of cooperation.

Fair enough. We can simply work on a "culture of honour" basis, where team members are expected to ask for feedback before adding features. You are then to use your judgement based on the feedback whether to add or exclude the feature. There will be no disputes if a member decides to include a feature, but please use your judgement carefully.

There are generally two kinds of mods that I find

1. that are simple to make and are catered to someone's taste - things like production bonuses, small number changes, traits
2. add a new capability to the game - units, code changes, AI, better UI

We need to be careful while adding things pertaining to (1). A feature might seem very good to your taste, but might simply not be the case for everyone.
(2) probably needs less feedback, other than a review from members.

I guess the current active modders would be in the team? That would be agnat86, Commander Bello, nightinggale vetiarvind and Schmiddie (in case he wants to work on experimental ideas that he doesn't want to include in R&R). If someone is keen on working as a partner or contribute, they can simply request the existing team members and be granted access with permission.
I have also sent a msg to ADHansa in case he is interested in being a modder.

Are you guys more comfortable with SVN, Git or TFS? I am fine with any of them although SVN might be the simplest to work with. Git is extremely powerful and make things like switching between branches (one for private mod-mod, one for R&R-ext, one for R&R) a breeze. Although I haven't used it much and I know it has a large learning curve, Git might be the best suited for us.
If someone wants to create a repository, please go ahead. We can simply start with the latest R&R code as a modbase.

 

[Nightinggale]

Are you guys more comfortable with SVN, Git or TFS? I am fine with any of them although SVN might be the simplest to work with. Git is extremely powerful and make things like switching between branches (one for private mod-mod, one for R&R-ext, one for R&R) a breeze. Although I haven't used it much and I know it has a large learning curve, Git might be the best suited for us.
If someone wants to create a repository, please go ahead. We can simply start with the latest R&R code as a modbase.

I really prefer git. Svn might be the simplest one to use if it is just a matter of writing code and commit to the same branch. However once we do more advanced stuff, like reading the commit log , git is far superior and I can do lots of stuff I don't know how to do in svn and I know I can do some stuff, which isn't possible in svn. On top of that I find the git clients to be better and so far the best one I have seen is smartGIT.

Since it turned out that plenty of people haven't tried git before, I ended up writing a git guide for M:C modders. Parts of it could be useful here too: http://sourceforge.net/p/colonizationmodcollection/wiki/GIT/

As for a modbase, we could import the RaR svn server into git, complete with history. The question is if we want to do that. If we use sourceforge to host a git server (free unlimited server space), then it will have public read only access. Considering RaR was committed with the intention that the svn server to be private, we should consider if something should be removed. I have experience in people contacting me saying "I committed 200 MB of files, which shouldn't be there" and then remove those files while keeping the rest of the files, which they were committed with.

Also when I gained svn access, I promised not to publish unpublished files from the server. If we just import the newest version of the server, then that is precisely what we end up doing. Either we get permission to do so, or we go back in the log and import RaR 2.1. Gitsvn will view the original svn server as a branch, which can be merged into other branches. This mean we can merge 2.2 once it's released.

I don't see any technical issues involved in using the svn server as a base. It's all policy and human related issues.

Also I proposed using the mod name Religion and Revolution Extended (RaRE). One person supposed that idea and nobody else said anything. Is this a name everybody support?

 

[Commander Bello]

I guess the current active modders would be in the team? That would be agnat86, Commander Bello, nightinggale vetiarvind and Schmiddie (in case he wants to work on experimental ideas that he doesn't want to include in R&R).

I would be.

But I would just like to say that I think, we are meanwhile talking about a "standalone" mod, which is very much based on the fundament of RaR.
Reason is that RaR is under development, too and may change regardless of what the modmodders group is doing. And as soon as a new version is out, the basis for the "modmod" has changed, making the current development unusable for the players.

 

[vetiarvind]

I don't see any technical issues involved in using the svn server as a base. It's all policy and human related issues.

Also I proposed using the mod name Religion and Revolution Extended (RaRE). One person supposed that idea and nobody else said anything. Is this a name everybody support?

I like it Excellent post btw. Mirrored a lot of thoughts I had.

I would be.

But I would just like to say that I think, we are meanwhile talking about a "standalone" mod, which is very much based on the fundament of RaR.
Reason is that RaR is under development, too and may change regardless of what the modmodders group is doing. And as soon as a new version is out, the basis for the "modmod" has changed, making the current development unusable for the players.

What Nightinggale suggests would remove that concern. By using Git on a SVN server (i'm guessing the same server as R&R) we would be able to treat R&R as a branch and merge any changes there to our branch of RaRE. Do correct me if I'm wrong. (in which case we'd use a git server with a branch for RR and RaRE and manually merge RR SVN updates to RR branch)

 

[Commander Bello]

What Nightinggale suggests would remove that concern. By using Git on a SVN server (i'm guessing the same server as R&R) we would be able to treat R&R as a branch and merge any changes there to our branch of RaRE. Do correct me if I'm wrong.

I think, you are wrong.

As soon as a new version of RaR is released (say, 2.3 and the modmod being based on 2.2), a new player will automatically load 2.3 as the then older version 2.2 is no longer available.
Updating the modmod may take some time, however, since there is quite a chance that old and new coding will interfere with each other. (Not to mention that changing the basis may require new discussion of how to adopt the changes)

A standalone mod will make things much easier for all: us modmodders and the players.

 

[vetiarvind]

As soon as a new version of RaR is released (say, 2.3 and the modmod being based on 2.2), a new player will automatically load 2.3 as the then older version 2.2 is no longer available.
Updating the modmod may take some time, however, since there is quite a chance that old and new coding will interfere with each other. (Not to mention that changing the basis may require new discussion of how to adopt the changes)

Of course. My intention was to have a mod-mod that can be applied to R&R. We will treat R&R changes in one release as "implicit features" for the next version of our mod-mod. When we publish we will release the R&R version this mod-mod belongs to. For eg. we could continue making changes to our 2.2 based extension after 2.3 is released.
Eventually, we will transition to the 2.3 version ASAP. If this is not to your liking, let me know. My assumption was based on the fact that we are calling it RaRE and not something entirely different like how R&R is to it's base - TAC. I believe from Nightinggale's post that this is what he meant by saying we could us a svn server.

A standalone mod will make things much easier for all: us modmodders and the players.

Perhaps us. For the players, they would be forced to stick to one version of R&R and then either branch with either R&R and RaRE forever.

Guys, please give your opinions on this. We will probably take a fork based on a vote. (of course we can always choose to go either way in the future by including\excluding R&R changes)

 

[Nightinggale]

What Nightinggale suggests would remove that concern. By using Git on a SVN server (i'm guessing the same server as R&R) we would be able to treat R&R as a branch and merge any changes there to our branch of RaRE. Do correct me if I'm wrong. (in which case we'd use a git server with a branch for RR and RaRE and manually merge RR SVN updates to RR branch)

That's pretty much what I said.

I think, you are wrong.
...
A standalone mod will make things much easier for all: us modmodders and the players.

Assuming there are no conflicts, an update will be done in a matter of minutes. It's a few clicks with the mouse, write a commit message (merged RaR 2.2 or whatever). Most of the time will actually be just waiting for file transfers.

However you are right that there are issues if there are conflicts. I don't view that as a major problem. If there is a conflict with 2.2, then we fix it. If the same conflict appears in 2.3, then the wonderful magic of branches will make git remember how it was solved and we will not get the same conflict again.

Besides we can make a standalone mod if we want that. If we branch off from the RaR svn server, then we will have all files. That will allow us to make a standalone mod quite easily.

Having said all this, I wonder if it would be easier to just focus on RaR. That would be the logical choice. Why is it that everybody made their own mod instead of just contributing to RaR? If we make RaRE, we will end up with programming power in RaRE and the graphical expertise in RaR.

 

[Commander Bello]

Of course. My intention was to have a mod-mod that can be applied to R&R. We will treat R&R changes in one release as "implicit features" for the next version of our mod-mod. When we publish we will release the R&R version this mod-mod belongs to. For eg. we could continue making changes to our 2.2 based extension after 2.3 is released.
Eventually, we will transition to the 2.3 version ASAP. If this is not to your liking, let me know. My assumption was based on the fact that we are calling it RaRE and not something entirely different like how R&R is to it's base - TAC.

Perhaps us. For the players, they would be forced to stick to one version of R&R and then either branch with either R&R and RaRE forever.

Maybe we are talking about the same thing but just put different meaning into the terms...

I will try to explain my point more clearly:
RaR as a standalone mod comes with its own basis of DLL and assets. It is a complete modification of the vanilla game.

A modmod in my eyes only changes specific items of the main mod and therefore only comes with exactly as much as has to be changed. The modmod cannot be run without the main mod being installed beforehand.

The main mod (RaR) is under development, too, meaning that coding and contents may change at any given point of time.
As soon as the coding changes (or XML tags, or whatever), the basis for the modmod automatically has changed, too, which will likely render the modmod in its current state unplayable. Since with a new version of RaR, the older versions are no longer available, the player cannot play the modmod anymore.

To avoid this, I was proposing to provide the whole package to the player (meaning each and everything - DLL, python, XML, graphics, documentation), which according to my view makes the "big modmod" a standalone mod (whatever name we may give it - personally, I am absolutely fine with RaR_Extended).
It still would be based on RaR, but it would be playable even within the timeframe of releasing a new version being adopted to the assumed RaR changes.

Hope, I could make myself clear.

 

[vetiarvind]

If we make RaRE, we will end up with programming power in RaRE and the graphical expertise in RaR.

Which is why I am for RaRE being based on and updated with RaR changes.

Having said all this, I wonder if it would be easier to just focus on RaR. That would be the logical choice.

You will have to ask Schmiddie's permission to become a member. Or do you mean, we just create mod-mods based on RaR? I thought the whole idea was because we all wanted to create a separate large modmod. If that is the case, we should not be having this discussion and just do what we have been doing so far. Maybe we should close the thread? So long as no one brings up this idea again and let everyone do his own thing and let Schmiddie decide which to let into RaR. The status quo is absolutely fine with me.

Maybe we are talking about the same thing but just put different meaning into the terms...
.
.
Hope, I could make myself clear.

Yup, we were talking about the same thing.

 

[agnat86]

The main mod (RaR) is under development, too, meaning that coding and contents may change at any given point of time.
As soon as the coding changes (or XML tags, or whatever), the basis for the modmod automatically has changed, too, which will likely render the modmod in its current state unplayable. Since with a new version of RaR, the older versions are no longer available, the player cannot play the modmod anymore.

I prefer publishing our work as a standalone mod as well. The question is of course what Schmiddie thinks of this, as he is in charge of the main mod. It would be strange if we would publish content of the main mod before the main mod itself comes out.

However, the main reason we are making a modmod instead of just contributing to the main mod is because the main mod is not expected to change much from this point on. So I suppose that we will not have to do too much work merging stuff of the main mod every time.

 

[vetiarvind]

I prefer publishing our work as a standalone mod as well. The question is of course what Schmiddie thinks of this, as he is in charge of the main mod. It would be strange if we would publish content of the main mod before the main mod itself comes out.

No, we will never publish a R&R feature before it is "officially" published. That would simply be disrespectful. We will only merge R&R changes after they are published.

This is of course depending on if we are doing this at all.

 

[Nightinggale]

I was proposing to provide the whole package to the player (meaning each and everything - DLL, python, XML, graphics, documentation), which according to my view makes the "big modmod" a standalone mod (whatever name we may give it - personally, I am absolutely fine with RaR_Extended).
It still would be based on RaR, but it would be playable even within the timeframe of releasing a new version being adopted to the assumed RaR changes.

That is precisely what we can do if we import the svn server into git. We can release all files if we like.

You will have to ask Schmiddie's permission to become a member.

You will also have to ask for write permission to RaRE. The asking for write permission isn't the main issue here. It is policy of what goes into the server. Modmods started to appear as ray rejected the ideas. However before we start to make a RaR clone, it would be a good idea to see what Schmiddie's point of view is on all this. Maybe he will be more open and would welcome other modders, who can mod stuff he can't (like programming). Also I don't think we should clone the server without his approval.

I wonder if Schmiddie follows this thread.

 

[Commander Bello]

That is precisely what we can do if we import the svn server into git. We can release all files if we like.

And that is exactly what I would prefer, as it would uncouple the development schedule of RaR_E from RaR's own development cycle.

We're all having a private life of our own. Up to now, this was not a problem, as each one was working just on his own behalf. He could check the newest RaR version whenever he wanted and he could develop and release any changes as soon or as late as he wanted.
If working in a combined effort, we should at least give any other team member the chance to test, what a new version of RaR provides. This may take say a fortnight. Then there may be some discussion about what consequences the RaR changes will have. And finally each one may need some time to adjust his "own" portion of RaR_E to the new basis and according to the common discussions.
And then, the whole thing should be playtested, too.

So, the whole process of adopting RaR_E to the newest version of RaR may easily take some weeks. A timeframe in which currently RaR_E wouldn't be available to new players.

Making RaR_E a standalone mod only holds benefits as far as availability, workload of the modders , "time pressure" and independancy from the RaR development cycle are concerned.
The only drawback would be that the player once would have to load the whole mod.