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.

Why would footprint change? Its roman siege wall footprint. The dubbed rammed earth wall would need wall towers and a small gate plus wall segments, its just swapping dae and then decide if they should/have turret slots?

That's a nice idea, I wouldn't mind. Seeing these cool towers, atm, I have the roman siege wall models for the palisades. I was thinking there could be a smaller sized wall, where some of these towers could be reused? http://www.chaz.org/Arch/China/City/Changan_through_time_large.png

Yes, I know, just thinking it may come in useful in terms of coding, but this works fine too, sure.

I'd make the scale multiplier configurable in some template, and to be on absolute safe side, no hardcoded defaults for atlas. Doc might read on scale multiplier: "Do not touch unless you know what you are doing."

With patched cmpUnitMotion?

I haven't had enough time to go in greater detail with atlas code, but if no template value is found, it uses the hardcoded defaults. Would be odd in a differently scaled project? You are the master artist to say. I could find out when precisely the default is used, but I think its more of an issue for artists if the default is used by Atlas, their walk and run animations would not fit set scaling? Another use case of a scale multiplier, Atlas, could come from template too. Right, its a little patch with great effect that should be upstream, addressing little hurdles that may or may not prevent adoption of the engine for other projects. In return, if the engine gets more adopted, you probably get more patches enhancing the engine.

I am just saying, if you develop the engine further, and you add mass to the equation for example, you probably want to have the scaling multiplier stored somewhere, and not calculate it over and over again from the speed or so, apart from bad coding practice it would be. You very likely gonna need it the more complex the engine gets. Would already be interesting to test some formation stuff with accurate speeds, unscaled, just for some fun testing to have a real values based reference point to compare against. Same for pathfinding etc. Point being, if my super secret realism aimed project used a different scaling, the artists would probably pull their hair out why the walk and run animations seem 0AD public mod scaled in Atlas.

A scale multiplier becomes ever more important if you implement more physics, like eg mass.

Look at the ActorViewer.cpp, you will find a hardcoded default walk and run speed of 7 and 12 respectively. Set it to unscaled default and have a scale multiplier. Nothing changes, just the default for walkspeed in the templates, ie 1.9 to 2.5 m/s for 0AD. Look, I am long enough in the open source development, this is neither trashing nor somehow picking on the great work of an engine. This is about improvement, about customization of the engine, but it seems you are set to oppose this. Such little improvement could decide a teams choice for an RTS engine, just saying.

My thought is, that is amazing to witness some comments here, documenting they don't get the simple mathematical concept of factorization. I am saying, the engine can and is being configured with default values. So far so good. But actually using a scaled speed as default value is in my view uhm suboptimal. Hence any project using the engine will have to use the hardcoded 3.6 scale, hard coded in atlas for defaults, the rest comes from templates. So if my project used a different scaling, my team would run into problems, apart that I would want my team work against real defaults. Its easier to eg research the avg walk speed of a horse and put the value in the template, instead of working with scaled speed. Ideally, you scale everything at a certain ratio, atm, afaik, the engine uses different scaling multipliers for different things, some is scaled, some is not or differently scaled. It is an approach the devs took, which is fine, but the engine is not really customization in terms of default settings with this appraoch. This would be a non issue, if real values were used, and the scaling multiplier gives you the speed you need in scale. I was just thinking, there is also competition in open source RTS engines, and this may sound like trivial issue, but a tendency would be atm to recommend say spring engine. Example. 0AD sets walk speed at 7 m/s, I doubt all balancers are aware this is actually a scaled speed at a factor 3.6, ie m/s to km/h. So a default avg walk speed is 1.9 m/s x 3.6 = ~7 m/s Difference is, walk speed is based on a real life reference point, no guessing required. Balancing team would simply not have to care for scaling, they look up real measured values and put it in the template. Can then be fine tuned as desired.