hyperion

It's m/s, never ever km/h. As alre correctly pointed out, there is some ridiculous scaling involved, like a sea having a width of 200m. The only thing that is somewhat realistically scaled wrt in-game meters are buildings. No surprise a 4m tall spear man walking at 7m/s or a ship crossing the Atlantic in less than a minute.

So you are saying CS are to cheap for their economic/military value => adjust price/economic value/military value. There are plenty of possibilities to add new unit types, so question to answer are: Are more and more unit types a good thing for gameplay Do specialized economic unit types add anything to gameplay Do they fit the game lore For point 2 I only see more micro intensive eco management, whether to treat this as a good thing(tm) is up to each and everyone.

We don't need dozens of pseudo features possibly all with own options in vanilla. Map creators already have the tools necessary to do whatever they please. Where pyrogenesis is lacking is ease of sharing such content. Maybe support download from host, maybe support fetching from github repo will do. If you want exciting content for single player start creating campaigns!

1st half of the first book? How about the other books, will they be left out?

We just saw an example of considerably less skill beating the strategy, well, in a healthy environment we would see a thread discussing possible strategies beating those merc sword cav instead.

So you won 1 out of 3 while based on rating difference you should only have won 1 out of 5? We need an emergency thread discussing how UP Carthage is

As this time OOM can be pretty much ruled out, so what do you see in kernel log / session log? Also do you run 0ad from a terminal?

It's not a matter of taste, the 3 damage types are insufficient by themselves. Somewhere around A18-A20 0ad dropped hard counters once, the experiment failed. Those counters are equivalent to having another, let's call it anonymous damage type. There is also poison and fire damage currently. Sword damage and such are only semi serious suggestions to spur thinking for alternatives. Btw. "mixed" is already in use. Link pretty please?

Indeed, instead a sword could do sword damage, an axe axe damage, and arrow arrow damage ... That they kind of work is kind of wrong tho, besides the shortcomings you mentioned we wouldn't need hard counter modifiers either.

Not a big deal for me Let me see if I can cherry pick a few easier ones.

So my cristal ball tells me 0ad got indeed terminated (oom killed) and mate/X therefor hangs. If you are lucky you can send those child processes with unsaved work a sigterm and they gracefully save your work upon closing but that depends on the app obviously. Some apps also save changes to disk and in case of a crash allow you to restore your work upon restart. Maybe ask in the Debian forum as people there are actually familiar with your setup.

Well, some of my own patches already conflict / require rebase if order changes. Basically I have to split the mingw branch into up to 70 branches if I go along with this. The patch I submitted in the meantime already needs rebasing, should I do it and retrigger CI and hope it gets committed before needing another rebase or leave it be for instance? Also having dozens of open differentials doesn't sound that enticing either.

In htop you can also sort processes by mem usage, so what is eating your ram? Might be oom killer terminated 0ad and mate simply bugged out.

Can the CI handle it? Do I have to rebase any patch onto master first? Does the committer have to rebase them again when committing? Do I have to manually list any dependencies? What happens if there are changes to master, do I have to rebase them and manually extract and update them again? Well, of course emulating series support is possible to some degree but that doesn't mean it's helpful. If it were arcanist wouldn't be eager to squash commits and 0ad devs wouldn't add semi random changes to existing patches just because the file was already touched or similar. If series support were a first class citizen of the workflow probably 90% of the commits would be split. For example the valgrind patch you mentioned has an "and" in the subject line, acknowledging that it's at least two logical changes squashed. Then look at the corresponding differential in phab and you will notice it could have become a couple more "and" as well. Phab is great for multiple people collaborating on a single change but for a simple reject/accept review it's barely adequate/ the overhead unreasonable. In my perception feeding them one by one or in small batches (they are mostly logically independent) isn't fast but causes the least work for me and reviewers alike over all.

Might be a lengthy vacation, will ping at some point, so even if not fixed anytime soon we can at least know what would need to be done on our side if we choose compressonator. This doesn't sound like much of an improvement. Fixing it to fetch a tarball and apply patches as is done for spidermonkey might be desirable but low priority as long as getting away from it is seriously considered. Moving tinygettext and properly build as external dep with option as system dep sounds like time better invested. If there are other alternatives to nvtt I don't mind looking into them either, but to be clear, I'm still under the impression compressionator to be a good choice for 0ad. Clean api, quality kernels and a whole slew of extras for artists is probably hard to get elsewhere.

I'm currently ahead of trunk by roughly 70 patches. 40-50 are mostly trivial to review and reject/apply, who does it isn't relevant for me. As there is no patch series support in phab this won't be particularly fast anyway. Also I'm not in a hurry either. There are also upstreams to wait for to some degree, so it taking time isn't necessarily bad as long as there is some progress.

@asterix I'm fond of both patches, the valgrind one I used prior to it being committed. The pkg-config one was useless for this task. Beside using cmake in the meantime, there is the issue of the pkg-config premake module needing halve a dozen patches to support cross compiling and being made compatible with pkgconf (an alternate implementation) in combination with a cross root and finally compiling for windows using pkg-config isn't foreseen by the external library search logic either. Further the current premake setup feeds flags to the resource compiler which it doesn't understand and so further adjustments would need to be made. What I did since last update: cherry picked patch for mingw runtime 9.0.0 to support gcc 11 (openal build) switched to gcc 11.2 updated binutils to 2.37 boost updated to 1.77 curl updated to 7.79 After talking with @Stan` I also looked into clang status, cross compiling to windows still can't be considered mature. There is initial pdb support in llvm which probably is desirable and I guess gcc will never have. There is also a very immature resource compiler which would be needed as well. So in a year or two clang is probably a good alternative. He also told me that antivirus doesn't like 0ad and if built with mingw even less, I thought about it and think the injection of startup code into crt before standard program entry might be a possible reason for this. To be honest this is a first seeing this trick. Might giving changing the startup procedure a try. I already started feeding changes back to 0ad, but with @wraitii having barely any time for 0ad currently this might be a lengthy process. So don't expect it being available for general consumption anytime soon.

If taking this as a fact we should conclude any mention of OP is either to have an excuse when loosing or an attempt to hamper any play that doesn't fit into the narrow scheme of what should be legit in the individuals view. If imbalance were an issue we would have mirror matchup settings (civ/map) seen implemented long ago. Also usually cries of imbalance start the day after a release, making it clear there can hardly be any substance to such claims. If balancing was taken serious, ranked games (and maybe others) should be collected and the data evaluated properly. I'm sure statistics will show a different picture in many cases than what people expect. I also second @vv221 claim that all civs playing the same reduces the replayability of the game. This should be obvious to anyone. I would even go as far as to claim imbalance may be desirable for you can easier find an interesting matchup if you can have civ selection slightly favor the weaker player. Well, ofc, if there are millions of players this point becomes moot.

user.cfg is a generated file, based on default.cfg and overrides in local.cfg and later in-game changes of those properties. You may edit user.cfg but honestly backing up or deleting for a reset are the only actions I'd take on it.

The square ones look like rice fields to me, the eyecandy version to me looks more like fish farming ponds designed by Botta. And gravity will always be an issue, maybe restrict rice fields to flat terrain as a malus?

Well, #1554 is marked fixed and #1553 not reproducible, either by @Itms as stated on the bug nor can I. My distribution installs ActorEditor as 0ad-ActorEditor alongside pyrogenesis as 0ad. That line, wherever you came across it, should be deleted me thinks and the bug closed as no longer reproducible.

Hm? Blender and Gimp? Or are you talking about ActorEditor which is part of pyrogenesis and runs on Linux as well? Anyway if it's Linux all you ever need is a text editor.

Of course contributors are more of an investment than getting things done quickly. Experienced opensource coders are not the norm. But there is no need for hand holding either, which you tend to fall into all to quickly.

Just watched the video doing the testing, the obvious result if you throw a one pound stone it will best guns and slings. So we can conclude NO weapon is most powerful. Science the American John Doe way... Anyway, ancient slings were seriously dangerous, just needs quite some practice.

Trusting people to try their best is certainly good. Trusting people are born fully fledged coders and knowledgeable of the ins and outs of the project is bound to not work. The first thing about git is branches are very cheap, commits are very cheap. To test or review I don't need anything committed to master to reduce workload, so there is no need to commit anything to master either. At one point you will have to look at what was done either way, so commits to master can't reduce your workload only increase it unless you don't care about the master branch in the first place. Anyway good to run into such issues now, so you can ponder a workflow for in case of migration.