Once upon a time I discussed with Daggolin how almost all 1.04 mods share common set of features/bugfixes and how it would be great to save time and make the code implementing them easily reusable for new mods.

Let me list few examples:

Multiple duels at the same time

No duplicate names (Padawan, Padawan(1) …)

wk/nk settings

emote animations

all common bug fixes

Daggo threw an idea of using C preprocessor for disabling/enabling these but looking at some real patches I think it would make the code an unmaintainable mess - jk2 sdk isn't modular to begin with.

My idea is to use a VCS like Git as a generic code-reuse solution. This requires a proper workflow and development cycle though. Ideal situation would be having a git repository where you can either merge, cherry-pick features or revert existing ones independently and without conflicts. Is it possible to come even close to this? I have strong doubts about it. I hope we can come to a conclusion in a discussion. Here is what I came up with so far:

If a feature is to be merge/reverted, it would be best to keep all work on it in a single feature-branch. What about single-commit features? There is a strong temptation to put them right on our development branch. What if we need to fix them later? How is a person who wants to merge the feature supposed to know that there is also a fix, possibly many commits later? Keeping EVERYTHING, even single-commits on separate branches seems to be solution, applying fix to it and mergin it back. We may end up with git history looking like this though:

So we should keep feature branches unmerged for a long time and merge them only into rebase-able testing branch. This will unfortunately add a lot of repo maintenance work.

What about feature dependency though? Single dependency is easy - just start off the feature branch you need. What if we need few features as dependencies? I guess it would be possible by starting each feature off a common core and merging each dependency as needed. It would make for an enormous octopus repo and certainly isn't worth the effort.

Is there even a solution to this problem without sacrificing major ammount of dev time for repo maintanence?

Maybe it would be better maintain a riggid base repo, sort of new sdk, with common set of core features/bugfixes like ioq3 and backport popular features from forked projects?

You can see somewhat "branched" result of my experiments here: https://github.com/aufau/SaberMod/network I don't feel like it's reusable right now, more of a dependency hell. I'm almost certainly gonna rebase these repos in the future.

The idea we had about this was to have everything based on a fixed version (mvsdk, which will come out later this century)

mvsdk containing only fixes, cmake support and other improvements which don't change anything noticeable by a user at all etc.
Based on that a fork called SkyscraperMod which has basic Admin functionality, multipile duel features, emotes etc.
And someone deciding to develop his own mod can then decide to either fork the sdk or the Skyscraper mod, whichever makes more sense. If you want to have your own login system it makes more sense to fork mvsdk etc.

I don't think it's a good idea to have branches for all features. If you manage your patch files very well (like how the linux kernel is managed) you can simply extract the patches you want and apply them to your own repository.

A lot of people who made mods for jk2 knew that a mod like theirs already existed and that theirs wouldn't be any advantage.
People make mods just for the fun of doing it, so no idea how well this can work out.
(They enjoy doing the same work to learn how things work)

If i understand (sry is hard to me understand english sometimes), you want to do something like git workflows "features", but using the current jk2 code having a base as "master" branch with the main bugfixes? And using only the jk2sdk to do that, to add new features and etc?

If is that (or something like that) i thougth the same, i was looking for a way to no re-implement all new features in another mod, just calling them from another source, i tried few test with my gameplay changer to no touch the main gameppay functions and get the new features to be "injected" from another source file, so was easy to implement in any mod, but only was a test.

Tr!Force wrote:i was looking for a way to no re-implement all new features in another mod, just calling them from another source, i tried few test with my gameplay changer to no touch the main gameppay functions and get the new features to be "injected" from another source file, so was easy to implement in any mod, but only was a test.

That's what fau was talking about when saying jk2 isn't modular.
You can create some kind of plugin api like Raz0r did with his japp mod on jka: https://github.com/Razish/japp
but that's a lot of work and most likely not very efficient to have a lua vm in a q3vm :lol:

ouned wrote:The idea we had about this was to have everything based on a fixed version (mvsdk, which will come out later this century)

mvsdk containing only fixes, cmake support and other improvements which don't change anything noticeable by a user at all etc.
Based on that a fork called SkyscraperMod which has basic Admin functionality, multipile duel features, emotes etc.
And someone deciding to develop his own mod can then decide to either fork the sdk or the Skyscraper mod, whichever makes more sense. If you want to have your own login system it makes more sense to fork mvsdk etc.

Haven't seen it yet so I can't give you my opinion. I'm sceptical about the multiversion idea.

ouned wrote:I don't think it's a good idea to have branches for all features. If you manage your patch files very well (like how the linux kernel is managed) you can simply extract the patches you want and apply them to your own repository.

Can you elaborate? Afaik linux kernel development heavily depends on feature branches.

ouned wrote:A lot of people who made mods for jk2 knew that a mod like theirs already existed and that theirs wouldn't be any advantage.
People make mods just for the fun of doing it, so no idea how well this can work out.
(They enjoy doing the same work to learn how things work)

That's part of the problem I have with existing 1.04 mods. They are not really made for players. Believe me or not but I don't enjoy implementing features I've used or fixing bugs that have been fixed since 2004, I'd rather concentrate on new ideas. We're making a mod that hopefully will be advantageous.

As I said, full reusability is too optimistic. Also I don't believe there will be many new mods anytime soon. As I open-source my mod, I'd like to make changes reusable. Not that there should be no merge conflicts or that no thinking needs to be involved in transplating them to your mod, but it should be made clear which commits constitute full body of a feature, fixes and dependencies. I think that's the best you can get without sacrificing major part of dev time for repo maintanence.

fau wrote:Haven't seen it yet so I can't give you my opinion. I'm sceptical about the multiversion idea.

it's already working^^

I'm sceptical about the resulting code quality, readability, relative (to the original) ease of introducing changes and how is it going to be better for me, as a 1.04 modder. Performance may also be an issue, vm is a big part of it on the server side any many 1.04 servers have performance issues already (i.e.: run on underpowered servers).
Haven't seen it though. I wanted to start my mod few months ago and mvsdk sounded as close to release as it sounds today. We're almost ready for public testing and I'm happy we didn't wait.

They do it for easier review process and bisecting (God, I wish someone reviewed my jk2 patches btw :P). Actual linux git workflow can be previewed here: https://git-scm.com/book/en/v2/Distribu ... A3I3cPTbum
Also linux is highly modular at it's core, so it's a different world. They don't need to look for patches and fixes for a specific feature they want to unmerge – they just remove relevant driver files and config.

My question is basically a slightly unusual software engineering problem. What I wanted to convey is that branching model I'm trying to find must be different than common models I've seen/used so far. Usually you either fork a repository to make your changes and push it upstream, or to maintain it as separate fork and merge back upstream changes from time to time. Here it's different, you've got multiple forks of the same 'base' repo, and the aim is to help them share code between them, leaving out the origin repo.

fau wrote:Here it's different, you've got multiple forks of the same 'base' repo, and the aim is to help them share code between them, leaving out the origin repo.

hmmmm, I think that's not possible. At least not automatically.

fau wrote:(…) Not that there should be no merge conflicts or that no thinking needs to be involved in transplating them to your mod, but it should be made clear which commits constitute full body of a feature, fixes and dependencies.