hyperion

Overall reasonable but would need quite some polishing. What I don't get are units visible behind trees, the base game has unit silhouettes except maybe for the ARB shaders. Also number garrisoned can usually be inferred from arrow count. To what end? Legitimization only comes from writing the supposed rules down black on white, publishing a CoC for ladder games on the wiki or even better in-game. Some users making up rules on the go definitely lack legitimization. Well, you can't detect it ever, technically outright impossible. It's entirely voluntary to share what mods you use. Atrik earlier in this tread also stated it would be nice to see others mods in the UI and as we are all curious creature I see why people would want it, but bare in mind this can be faked at will with no means of enforcing. In AoE it mostly works because there is a healthy e-sport scene and no one will want to train with mods that can't be used in tournaments, 0ad is far from there. The barrier isn't that high but I concur it exists. But a tutorial is written fast and we have seen quite a few proof of concept mods for such. I think I remember a mod that allows you to read enemy chat was posted not long ago Maybe ChatGPT can also tell you how to

I somewhat doubt it as the python 3.12 porting only really started with SM120, if you want me to try on a different distro feel free to share your patch. I also realized we could just pre apply the binary patches as we repackage the tarball anyway, so blatantly updating bundled virtualenv to a recent version via binary patch (18M) could be avoided. @Stan` I played a match with SM91 vs SM102 and no OOS occurred, my guess the same would be the case for some more esr branches in both directions as we are no longer in the age of netscape where javascript was more like a toy. About we heavily patching SM, compared to distros we are close to vanilla . The reason for giving up is more likely that requiring a different SM minor than the one provided by the distro leads to "slot conflicts", ie a user needs two versions of SM with the same major which can't be installed at the same time. For a packager it's hard to tell if the header check for minor is meaningful, so if in doubt do as upstream insists.

The major we ensure with pkgconfig already. So the the check in the header is redundant. I tried fixing sm91 for python 3.12, that one looks really tricky, needs more than linked patch in the bug and I ended up with binary patches for virtualenv before stopping for now. If we can't add git to the build deps I fear we won't add support for python 3.12 either.

That incident with 78 affected at least a few distributions, so they must have used system spidermonkey at that time. Also that we are aware that some distros package sm wrt ICU in a way that causes issues is due to them using (or trying to use) system sm. Looking at the spec file linked by Norse we also see support for system sm. So if they can they really would prefer that option any day, but the rigid check makes this somewhat tricky for packagers.

Happy new year!

It's a python-3.12 issue, I created a trac ticket with a link to the upstream patch, no need for more info or experiments, it's easy enough to reproduce. Gentoo did for the longest time, then stopped because the restrictive header check became annoying for packaging, not because it could lead to OOS. Pretty sure once upon a time Ubuntu did the system mozjs thingy as well. The header test I consider a remnant of the sm-1.8 days. The pc file already ensures same major version.

Apparently Fedora also uses devel packages so you'd need https://packages.fedoraproject.org/pkgs/mozjs91/mozjs91-devel/fedora-39.html, not mozjs91.

Nah, if it builds it should be fine, quite a few distribution actually do this for the package 0ad. The last time runtime changes to the language happened should be well over a decade ago, tho don't take that as the ultimate truth, it's just what I remember. What we see more often is breakage in how we interface with the engine from C++, therefore we stick to EOL LTS releases. Ofc a distribution can patch it so it wont work but that is exceedingly unlikely.

Not sure which package manager you use, there seems to be rpm yum and dnf for fedora, each having there own way to list installed files for packages. If https://packages.fedoraproject.org/pkgs/mozjs91/mozjs91/fedora-rawhide.html#files is correct then it doesn't install a pkgconfig file which I consider a packaging bug. Maybe file a bug against mozjs on the fedora bugtracker to get this rectified. Also looking at the same page it looks like you are using python3.12, is that correct?

If it's not Fedora specific it might be related to python version. Could you post the version, so maybe others can try to reproduce it. As for the system mozjs91 package, do you have it actually installed? I'm asking as the configure step (premake) can't find it in the first place and as a result the build error is fully expected. Premake / uptdate-workspace.sh not aborting early and creating broken makefiles seems a bug on it's own. If mozjs91 is installed, does it also install a pkgconfig file or just the shared library?

Guess you know what vanilla refers to code wise, so in this context I define it as the shared vision of the game while modifications as approximation of an individuals vision of the game. By review I mean a patch reviewed by the formal process on phab and finally committed to svn. Generally I'd say it's not a big deal but lets assume I host a tournament with a prize pool significantly larger than a bar of chocolate for the winner, then in the spirit of e-sport some measures need be taken to ensure the rules I set. Ofc a lan tournament would be ideal but often unrealistic. So next best is to require a screen recording of the game and optionally a face cam to be analyzed. You can also run heuristics on the replay (network commands). The latter is possible for random ladder games as well. Still you can only assume no one is cheating if you don't catch anyone. I can't stress enough that any and all attempts to prevent users from cheating by code on the users machine I deem utterly futile. So the question of what prevents people dumping stuff into public I can only answer with nothing and nothing ever will. We still haven't established what fair even means, more to that further down. But if there are no downsides to be honest about your modifications why would you hide it. So the environment needs to be pretty bad already for this to be a concern. Perfectly normal, that's why I called imaginary evil. We know there is cheating but don't know what it is. We only know It's something out there that threatens us, which could jump us any moment and has the potential to utterly threaten our existence. So it's imperative that we start gear up with stage props and ostracize people we suspect have fallen to the dark side of force. I guess you can smell some cynicism here. If you want to entitle a group of people to define what cheating is then their first task would be to write it down, not in terms of named mods but what type of modification they don't want to see on the ladder, then we can see if we can develop heuristic to scan game data transmitted during the game for suspicious activity. But before we have such an approved list cheating simply doesn't exist as far as I'm concerned.

Let's assume it's desirable that people can play together without being required to run with the exact same mods in the exact same order so you can find players to play against even if you play with a couple mods. There is fundamentally no issue with this as long as those mods don't affect the result of the simulation. This was done through code in the mod and later a metadata key was introduced to simplify this. So a player using a mod outside of mod.io doesn't deserve to find players to play against or has to convince everyone else to also load that mod in the exact same order as everyone else. I'm thinking about my mute sound on pause patch I carry for a few years (1), which would make me a cheater if I read the intent of your suggestion correctly. What we need is a formal definition of cheating, not some trick in the code that as we have established above is trivial to sidestep for anyone wanting to cheat. Worse impacts conceivably legitimate uses left and right. We could define it as everything goes and there is no cheating. Or what I suggested, everything in vanilla was reviewed by our formal process and as such by definition corresponds to our vision of the game, you can mod the game and as long as you don't hide it it's fine for rated games in the official lobby, we won't get involved into discussions of what modifications are appropriate and which not as every individual has a different take anyway (2). For me it currently looks like there is the imaginary evil of cheating and a group with a mission to fight it. Let's call that group The Committee. Then I at least expect The Committee to publish, let's say on the wiki, a list of modifications that they deem harmful and don't wish to be seen used on ladder in the official lobby. The Committee shall not come up with anything that needs recurring involvement of devs and shall not hinder what is considered a legitimate use case for the last decade and one of the aspects that makes this game charming. (1) Very simple, just download my patch, fetch the sources, apply the patch and build the game, then I'm allowed to play with you again . (2) It would be a good thing in my book if we had pure AI player competing on the ladder as long as they don't lag and are visible as AI players.

I simply can't be bothered to discuss what means not much. I will play with mods and I don't care what mods you use. If I play you and had fun I'll play you again otherwise I'll doge you in future, simple as that. Many mods I don't know what they do and then we have the "user mod" which by design isn't a "mod". If my signature means anything but checked for nasty bugs and malicious code I simply couldn't be bothered to sign anything at all. For me to dip my fingers into this it have to be part of a payed job description.

Doesn't help at all, the engine needs to read that zip file, so the "cheater" can as well.

Against accidental edits (1) of public you could do something, against deliberate edits with the goal of showing a vanilla badge without playing vanilla nothing can be done. I repeat any and all technical solutions suggested to "prevent cheating" are utter garbage conceived by people which don't know any better. Such a thing simply doesn't exist and wont ever exist for 0ad. If you fully control the hardware the user runs 0ad on you'd have some means. The badge is a compromise, a concession to people who want to hunt others for playing some definition of unfair. Protecting devs and other staffers is far more important than anything else. There must be no room for discussion what is cheating and what not. So if you use any mods you have no ground to accuse others of cheating. This auto-sniping was even suggested by wraitii in some form for the base game before, so excuses like my mod should be in the base game, is standard for an RTS or similar, therefore is okay but yours is not are sort of ridiculous. So either you play vanilla or you don't. Pretending to play vanilla when you are not is cheating, anything else is not. Enforcing is impossible but occasionally catching someone is possible (2). Sure you can go for other definitions of cheating but that means an extra burden (to mental health) and we have a recent example of a dev saying it's enough to prove my point There was also a thread maybe a year ago where some user was asked to share their pov on a conflict which they then did. Sure that position wasn't great but what shocked me were an awful lot of justice knights that jumped out using language far beyond what is acceptable and feeling smug about what great they did for the community for lynching an individual. An other example is Norse, sure sometimes unconventional how he does moderation but I have seen nothing so far that would be make doubt his integrity, still there seems to be an awful high level of acceptance for attacks against him. Basically I feel anything but a simple rule as I propose for what constitutes cheating is simply creating a breeding ground for further misconduct, unfortunately. (1) It's reasonable for someone to assume to mod the game is to extract public and work away on it whiteout realizing that this sidesteps some vanilla badge you don't know exists. (2) For example someone uploading a video to youtube while forgetting to disable their mod.

Does this mean the authority to decide doesn't lie with the dev signing? So how should it work then, some user claiming the mods I use are fine but the one you use is not gets to make the call? I struggle to see why WFG should even try to get involved in this mess (a social problem with not technical solution at all). Why not simply add a vanilla badge to user in lobby that don't use any mods and make the only form of cheating recognized by WFG modifications to show said badge when not appropriate. If hosts of games or even tournaments want random mods rules then it's their business.

So instead of a dev just checking if there is no malicious code you want to put him into the crossfire of the vocal and abusive community for signing the wrong mod? Given that it's outright impossible to implement so that it can't be sidestepped I suggest to give up the notion of this being a good idea.

Mh, probably Ubuntu 22.04. python-is-python3 sounds like a package installing a symlink python pointing to python3 and the the package python-is-python3 just so depends on a package python3 which in turn depends on a package python3.10 for example. My guess the package python3 if it exists would be what you want. Not sure what the canonical way to install python 3 on Ubuntu is but looking at the results of "apt search python" should probably make it obvious.

Is correct but might be incomplete. Edit: tested to be complete, builds with 2.11.5, 2.12.1, 2.12.2 and git HEAD. Don't think this improves readability over your first suggestion. It's not complexity that is the issue just that people aren't used to it in this context so it takes an extra one or two seconds to mentally parse, at least for me. The greater than char in the greater than equal token doesn't help Whether or not the tradeoff vs. not using the preprocessor is worth it I don't know.

As long as it's not the cast variant of solving this I'd be fine with either. Looking at the linked ticket a future 2.12.3 should no longer have any issue, still technically it's a downstream bug, just that the fallout was unexpectedly large and the missing headers where injected back upstream. So I'd add the parser header regardless as this also allows the use of all 2.12.x releases.

Well, some of the changes you posted look valid at a glance, not so the use of an internal type of libxml2 tho.

A more recent version than mine, looking at my distros bugracker there are lots of similar bugs to this one for various packages with 2.12 and so it's still hard masked.

Obviously this is just an opinion due to lack of a definitive metric

What version of libxml2 are you using and is it an install from your package manager and with no local build in path?