artoo

That's where the git submodules or git subtree, or 3rd party solution, comes in.

Sure. I'd put the public mod in a repo, the source dir in a repo. Details to solve, art, specifically images may go in a repo too. Optionally, maybe mod gui specific stuff to be separated. I would place a bet on devs getting frustrated over time if images go in the source code repo.

I'd think that too from the file sizes of the images. A dedicated art/image repo might do, included with a submodule even. It takes probably 3-4 submodules given the current source tree, maybe more, depending on preferences.

It is in fact totally up to the reviewers/upstream to merge, ie nothing gets in the upstream repo from a fork without explicitly merging it. Besides the technical decision what vcs to use, if the decision goes git, it is more or less a decision what self hosted server to use that suits best. Gitlab is little monster, builtin Ci, lots of features, same for github server, but there are also lighter ones providing the basics, really depends what is required. The main point of git, besides technical specs is considerable, that vast pool of devs and easy collaboration. No problem to include git repos hosted on another platform.

I can try to break it down. Co authoring commits, there is an upstream repo, and there is a fork of that repo. Anyone can fork a repo with git, which is easy to keep uptodate with the upstream repo that is forked, the remotes. You can author a patch in a branch, and send a request to the upstream repo, chose a target branch, master or some feature whatever. Then the merge or pull request can be reviewed, and merged according a selected merge strategy. Or the review determines the PR requires some more changes in order to merge. This also works from a branch of the upstream repo, same concept, you can merge that branch into master branch or any other branch. What all these git servers provide is more or less just a web UI to git. It can all be done locally too and then pushed, ie merge branch 'super_feature' into master, or merge branch 'hotfix-123' into master. submodules are git's native way to include another git repo. Many people, including myself find these a PITA, but there are different ways, including a native git only solution of just using branches. In summary, it is a way to make from more than one repo one unified source tree.

That's what I find one worrying aspect. The other would be you depend on 3rd party services, GL or GH, if its down, its bad for the project, and there is nothing you can do about it, but wait.

That's a decision I can't help with. But I can give my experience with git, having used svn as default project vcs many years ago. The big pro of git is the remotes in my opinion, the fork concept merging branches.

You don't work in the mirror repos. The problems would stack if you used git with current structure, would work, but you might come to the conclusion in 3 years time and 1000s commits later "if we had only split it when we migrated"

Looking just from outside at the current project structure, if you migrate to git, reorganizing the project in git should be chosen wisely in my view in respect to the future repo sizes, commit history etc. I think it would be no fun to put the current source tree in git as is, accumulating tiny problems over time. I would probably consider an image repo for skins, textures, icons, portraits. If you wanted these included in source tree, probably git-subrepo would be the most painless solution. But even submodules might work for the purpose.

If you go git, I would probably use (a) dedicated art repo(s), ie separate art from code. Keeps the code repo small in terms of history compared to art repos containing images. Git has two builtin options to handle possible external repo inclusion, subtree and submodules, but in my view, both are a PITA. There is also a 3rd party solution that works, git-subrepo.

I am all for self hosting. Full agreement on that. We are using atm gitea instance & jenkins, but considerations to have gitlab are there. But gitlab eats so much more hardware resources. Its more like, if you stay with svn, maybe still try to use the vast GH or growing GL too for easy collaboration. Would be naturally easier if you moved to git though, that trying to glue git to svn. Btw, I like the engine has no steam depends or strange tar that may or may not work on linux.

Another in feature in my view, that's nowadays quite important and missing from the "package" sofar, control sharing for teams. Just comparing some spring engine and features they have in eg zero-k. While at it, I think it would be beneficial to tap in the pretty big GH infrastructure and dev pool. Not a fan of GH since MS took over, but the PR workflow is rather uncomplicated in git. Maybe its worth considering how to get PR from your GH mirror back in the svn? As dev , you may have no strings attached to a project, but you may have right now time for a patch and send a PR.

Yes, indeed. I see the crucial missing thing atm mass and some physics, eg ballistics.

Like morale is a given percentage of strength? Or like wounded decreases efficiency? Atm, I am evaluating the engine, what's doable ...

I was under the impression one of those towers would be scaled down and replace the bixies. Might got that wrong. But those towers look pretty cool.