Can this be unified with the simulation civ file function? (I know that one just loads a single file, so maybe we should look at how that is used, since in most cases we end up loading more than one anyway.

Fix the config change I apparently didn't test.

Note that this also changes some parts of the API compared to the previous iteration (no, the v1 part didn't change, we are this early in development that v1 isn't yet finalized, it will be soon according to upstream). (For those interested nameid -> name_id and a few similar ones, and my suggestion about having a better filehash structure was also merged.)

[WIP] mod.io support PoC.

In D754#41878, @temple wrote:

I'm trying to digest the discussion, but in the meantime I'll say a couple things:

• Testing for OOS and other problems I played against myself on two clients, tried rejoining as player and as an observer, and also did replays and saved games. There were some OOS with the territory manager component, that's why I have the changes there. There were problems with the minimap colors, first having to remove them from serialization to avoid OOS errors, but then also on rejoins having to update them (because setting the colors isn't included in the deserialization anymore).

Well, if you make everything non-serialized it is quite likely that those changes don't cause any OOS now. That doesn't mean that a future change relying on any of those value (well, why wouldn't the player colour be serialized? And more importantly why would any other JS component have to care about that?) does not cause that. Simulation code should be robust and trying to avoid possible sources for OOS as much as possible. In case you don't see the reason for that you might want to ask a few of the other devs about OOS war stories.

As requested.

As requested.

I'd be happy with an en_US, which would basically only touch the time/date formats (so that we don't cause headaches for the translators). But right now in the language selection it already says language = English (United States) and locale = en_US, at least for me. How does one go about adding en_US to Transifex and making the default language = English (International) and locale = en_something-else (or just en)?

Should probably just be en, might need a few changes (source/i18n, possibly some scripts, maybe some change on transifex) in a few places.

In rP20492#25048, @Imarok wrote:

Is it fixed now, if yes care to accept this?

Putting the US time/date default formats into a separate patch.

One could also declare the default US-international or something with US spelling and sane units. (Case in point being distances and such using meters in the game.)

"English (United Kingdom)" is one of the languages on Transifex, that's why it's "meters" and not "metres".

Which is why some sort of US-international would make sense. Note that it is meters not yards or something similarly strange.

In D795#41658, @temple wrote:

Putting the US time/date default formats into a separate patch.

One could also declare the default US-international or something with US spelling and sane units. (Case in point being distances and such using meters in the game.)

Code looks fine to me. Didn't do any testing though.

(Also passing components around is something you should try to avoid, since then someone might decide to store that somewhere which will end in pain since once that function returned the unit the component belongs to might stop existing, which also causes the component to do that.)

I don't understand this. Who would destroy the unit created for the projectile (or hit animation) while the projectile exists.

Not the Unit, but rather the unit (or to be more specific entity) that the component belongs to, in that case it was a system component, but not having code that does slightly questionable things helps with not having any examples that could cause issues if people follow what current code does.

Is there anything we can do except making sure to use utf8? Since upstream documents that everything should be utf8 it's unlikely there is an easy patch to this problem.

Well, unless you see something that makes rP20493 not be utf8, then I'm not sure if that is everything that is needed.

I guess we can at least call the "Agree that it is nice" part of the test plan done.

Uhm, if that also wasn't the issue... @Itms Phabricator is stupid, trac works though.

In rP20489#25038, @Stan wrote:

Well apparently, even by setting the property (mime:type plain/text), Phabricator doesn't recognize it as at a text file https://stackoverflow.com/questions/2634043/svn-diff-file-marked-as-binary-type

Because the ñs in there are in some codepage and not in utf8. The file uses the wrong text encoding and according to https://secure.phabricator.com/book/phabricator/article/utf8/ that is most likely causing this.

No, there is no need to check for existence of system components in JS (unless you have a use-case where some mod might not have one, and we want to support that).

@Itms Why does this not get built? That would at the very least point out one unused parameter. (Also passing components around is something you should try to avoid, since then someone might decide to store that somewhere which will end in pain since once that function returned the unit the component belongs to might stop existing, which also causes the component to do that.)

Thanks. rP20489.

Any clue why the license file shows up as a binary file?

The references you included don't seem like we can actually distribute them. Which is what should be the case for everything in art_source.

In D341#41422, @bb wrote:

Was actually thinking more the other way around in #252: merge the code handling damage and capture. The problem of having an own capture component is that units then will be able to capture and damage at the same time (and making the components work together to avoid that will lead to bugs as #4000 in other components). And I guess that is not what we want to happen. One could better use cmpAttack.CanAttack() to handle attacking non-health units.

The issue with making capture an attack (as has been done) is that it is not really one. Attacks deal damage, capture does not. It does share quite a few things, which I guess why it was made one, yet there is still that issue with lots of code assuming that a target needs health and (possibly armour). So we already have a situation similar to #4000 where we also have two similar but not equal things done in one place becaused it seemed like an easy way. However this here doesn't seem as bad as #4000.

The recommended way also lists an alternative, though that one has some caveat. For something like the listed example I do agree with it being preferable, for a big codebase that did get some C++11 updates where needed adding a few such features is not that nice, especially since one would not expect them to be there. Since a quick grep of the codebase grep "^\s[A-Za-z0-9_]\+\sm_" source -r | grep = and some manual weeding out of the few results we notice that there exist a total of two such occurences in the current code base, both being introduced by rP19031...

(In case it wasn't obvious I didn't actually check if my guess was correct, in case someone is bored enough to just run the specific test and that still fails, then it wasn't.)

I have

SortEntitiesByPriority

I actually have a TODO comment about that being mostly unneeded, and too complicated for that one use, given that it could be done in linear time (finding the best target) locally. (There's also a comment about AttackEntitiesByPreference doing too much work for what it is used for, in case you are looking for more things to do.)

Given the function name I would expect the parameters to be ordered differently.

In rP20462#24904, @elexis wrote:

In rP20462#24890, @leper wrote:

what's the short syntax for wiki links on here?

None yet. Looks like we need a short phabricator php file called Remark Extension https://secure.phabricator.com/T11980

@Itms: Care to look into adding that?

In D1042#41032, @elexis wrote:

If you upload a script that changes the capitalization and replaces space with underscore that would be quicker to confirm for me.

The _2.sh files I uploaded yesterday do exactly that. I've already run them a few times to spot and correct all typos. I suppose there must be many other ways to do the same file moved in a much shorter script, but my programming skills are rather limited, and the longer but straightforward .sh files I uploaded work.

That's why I mentioned all the needed (well, except for xargs in case you want to be sure) tools above. As always man toolname does provide useful information.

I'm open to other solutions.

Remove Health and related things that make them attackable, see what breaks and why, fix those things.

Units are invulnerable for a few moments while they cheer after being promoted, so attacking units will now stop attacking them during that period, either finding a new target or going idle.

That sounds a lot like it will break in ways that are annoying to the player.

Wiki update https://trac.wildfiregames.com/wiki/TechModifications? (Also what's the short syntax for wiki links on here?)

Ah, also this will not prevent any further files with that format from being added.

In D1042#40914, @elexis wrote:

All lowercase filenames comes unexpected. Would be consistent with all other files though.

Given that the title is just about replacing " " with "_" that seems unfortunate.

In D1029#40393, @elexis wrote:

Having the URL in the config sounds like a mod or map with GUI script access (#4838) could replace it. But it should really be in the config and the issue should be solved by the GUI asking for user confirmation before downloading from an URL maybe.

Excellent catch! I guess having an explicit URL should be done in any case. That does not fix the issue of a malicious mod just changing the GUI to not display that.
But since we are just reading those config variables in the engine we can just use the config namespaces and ignore the user namespace (which is what the GUI can write to). This still allows a user to change things by specifying them in local.cfg, or on the command line (the command namespace always overwrites the others).

In D863#40395, @bb wrote:

What about the ones in GameSetup/GameSetup.cpp?

Those end up in that one function that takes a pointer after some long and slightly confusing code. And that function needs to be able to take a nullptr in one case IIRC, which makes the whole thing somewhat ugly.

Infrastructure for getting the required data from the GUI.

In rP20438#24720, @temple wrote:

Sorry, leper. I actually thought about it but 200 updates seemed overwhelming. But maybe I can do some and give you a break (or maybe I'll do them wrong and it'll just make more work for you? :) ). We'll see what happens...

Given that I just updated that page since elexis seemed busy, and I wanted to document a few modding related changes, and that has now been done and the next such change ran into some obstacle I don't see me doing that anytime soon.

In D8#40273, @wraitii wrote:

I'll commit this shortly unless somebody complains.

$complaint

In rP20438#24715, @elexis wrote:

It's not making it harder while the "page includes all relevant changes until commit X" entry remains unchanged.

Until someone updates up to that and there are suddenly two similar but different entries for a single revision.

So something like that must be running`./update-workspaces.sh --without-pch` prior.

Uh, someone else actually using that.

In rP20438#24697, @elexis wrote:

(@temple also feel free to add a performance category in wiki:Alpha23 with an entry of this commit. See also wiki:Alpha22.)

wiki:GamePerfomance which stopped being updated a while ago. And if someone updates the detailed changelog at least update the whole thing instead of cherry-picking a few revisions making it harder for everone updating later.

Would be better to actually package that separately. Downloading things during a build phase is ugly and will most likely break a few downstream build scripts (or should, since actual building should work without network access).

In rP19703#24603, @elexis wrote:

(Compiling is the non-quick part) SpiderMonkey build fails with a clean working copy after running clean-workspaces.sh, export CC=clang CXX=clang++ and update-workspaces.sh. Maybe I installed a wrong version.

You can also just compile the game and not the libs with clang. (At least that's what I did, because well D953 and SpiderMonkey's build system is a mess of scripts and autotools.)

Clang has warnings, warnings are nice. @Itms clang builds for things would be nice.

It would also be nice if we would have the same kind of replacement in all cases where we have {civ}.

I don't really get your point: we either replace {civ} by its value or remove _{civ}. Do you see a problem with removing _{civ} ?

We only ever changed {civ} to something else, that the current template naming scheme uses _ is not connected to that in any way. So it is the same as having foo{civ}bar and if we don't have that for the current value of the civ, we end up with fobar. Replacing {civ} by an empty string, or if that is considered somewhat ugly by eg default or generic that would most likely be easier to understand than changing anything apart from {civ}.

#4589 and #4588 seem related. I actually thought there was a diff for exactly this somewhere around, but I can't seem to find it, so maybe I'm just thinking of D707.

Very nice!

Basically what elexis said. There was some hwdetect work done back then (just checked the logs, no specific mention of that). As to why that should be as small as possible is because that is on the stack, and stack sizes are small, and if we end up running into some ENSURE or similar in a deep callstack we might be short on available stack. That and nobody needed more. Yes crashing in that case is wrong, we should truncate, though I seem to recall a diff (or commit?) that attempted to limit the length of things passed to one of the debug functions.

I guess having some explicit message in case something fails during that step might be nice (|| echo nope).

Ok, so this basically adds a bunch of complex code to replace some slightly complex code for some reason that's not very obvious.

In D1009#39578, @Nescio wrote:

NB It appears the sed script can't read map files which contain spaces (" ") in their name. Any suggestions on how to solve this?

Will need a slight change to how sed is invoked, as whitespace is a parameter seperator (one can change that by setting the IFS variable, but for this case it would be slightly more complicated, or rather somewhat uncommon).
We'll first invoke find, make it use \0 as the separator, then use xargs to split that and pass it to sed.

In D1007#39547, @Nescio wrote:

In D1007#39540, @leper wrote:

Check if everything works.

You are at least missing the cheat data file.

Sorry, I'm unaware of its existence. Which file?

I suspect you don't know about grep(1) either.

Check if everything works.

You are at least missing the cheat data file.

In D274#39425, @wraitii wrote:

I believe priority should be used sparingly too, in fact I believe it should be used for replace. In vanilla 0 A.D., that's pretty much the only obvious use case. For mods or custom maps though, you may want to have lower-priority "replace" that then have technologies applied on top: for example a trigger could replace the HP of some building silently without the need for a mod (by making default replace something like 1, you could use 0 for "root" modifications.

Why not use a different template? Not that the proposed solution couldn't also work, but it is presented here as "the only way to do this and really needed", so why not avoid all that complexity, add one single file with about 5 lines when nicely formatted, and achieve the same?

In D274#39423, @wraitii wrote:

In D274#39421, @leper wrote:

And the "new" approach does not have any at best unexpected behaviours?

Well you can specify priorities, so it's up to the template creator to an extent. Admittedly, the "rest" (being what you're talking about below) would go in a different patch.

And what happens if someone uses the same priority for different modifications? I'm just going to assume that the next template creator will just copy something existing and only modify what "needs" to be modified. Nobody will actually change the priority. So the new code has logic to handle something that is unlikely to be used correctly, while still having the "drawbacks" of the current code.

In D274#39420, @wraitii wrote:

I exaggerated "completely random" alright, but I maintain "at best unexpected".

And the "new" approach does not have any at best unexpected behaviours?

In D274#39407, @wraitii wrote:

In D274#39405, @elexis wrote:

(Did someone speak of duplication removal? Simulation code being able to add or remove modifiers doesn't sound bad. Just one had to be careful not to break things in case multiple effects are applied)

Duplication removal would be possible after moving the aura code to also use this modifier manager, but IIRC that proved slightly complicated at the time because the architecture wasn't obvious. Auras being top-level citizens atm and this patch would "just" make them local modifiers of sort. In general I think we should go there though.

If not even the tests pass I'm quite certain that no care was taken in not breaking things.

The other approach seems really hard. @leper had you some vague ideas when writing the TODO?

Probably, else I wouldn't have written the TODO. Then again it has been 2 years, so dunno.

Given that there is no division there, dunno.

tell me if you also have a GitLab account and want the access there

Not yet, and, not yet.

Get one, the repos being out of sync would be bad (especially if someone does not pull from both before updating).

In D994#39127, @elexis wrote:

About git svn, I'm unable to import svn with git svn to my existing repository. Importing all commits fails all 1000 commits with too many objects that need to be pruned. Importing only the head revision fails with some tens of thousands objects that need to be pruned. Never finishes and I need to keep my branches. Perhaps I could do a second repository and set this a remote though.

By existing I presume cloned from the official git clone on github/gitlab. In that case you will have to do more work to get the same state as that repo, check one of the staff forum topics started by k776, I outlined the steps needed to get a repo that is compatible with that. Also check if you have access to the official clone, if not ask someone to give you that, then you can actually update that when needed (or get @Itms to allow you to trigger an update via a jenkins job or something). Then possibly add your current repo as a new remote, but then you will have to take extra care to not push your work to the official one. So better have one repo (or the job mentioned above) to update the repo, and your current repo to work on things.

Not that I actually tested this, or formally accepted that revision.

(I never understand how I can preserve the file history by applying the patch. Neither svn patch with the downloaded patch nor arc patch seem to do that)

You could do the moves manually, then edit the diff (if needed), then apply that. (Or use a git-svn clone.)

Our engine uses SpiderMonkey 38 currently, (https://trac.wildfiregames.com/wiki/SpiderMonkey) that will be switched to 45 hopefully soon,

I wouldn't hold my breath, and I haven't seen anyone working on that for quite a while.

Check maps/scripts/CaptureTheRelic.js. Sometimes only grepping for a part of the full name is helpful.

In D989#38817, @Nescio wrote:

Many thanks for your explanation! So the item separator is the character directly after s, and it can be anything? (I've tried out the comma in a single find-and-replace expression, and it worked.)

Yes, using something that is unlikely to occur in either the regex or the replacement does help though.

And if you want to keep using / as the separator you can escape occurrences in s/regexp/replacement/ by replacing it with \. There are a few other things that need to be escaped (eg ()), but for this ticket there should be no use for this.

In D989#38806, @Nescio wrote:

Basically this does the replacement for you which is a lot easier than having to do that manually.

Thanks! This could have saved me hours yesterday.

Being lazy has its perks, one does have to know the tools for that though.

In D989#38800, @Nescio wrote:

Given the specific nature of this ticket it might be worth just including the file moves, non-map changes and providing eg a sed script that changes all the map files.

What is a sed script?

sed(1) is the stream editor, a *nix program.

Bar architectural concerns, I think we can commit this.

Wishful thinking

It is nice to be in such complete agreement with elexis again. (Apart from also considering the random maps to be a mess I seem to have to play the adversarial role recently.)