hyperion

Guess there are many, one with questionable wrapping is fc5518a22b15827c7f4d4410c27dad4c628af8a4 and on that got worse with rev to sha is 9f85b097e11ffac38df23815a62b14bd25925d2d you can't change human nature Needs to be made public before the actual migration so others can verify the migration, but can wait.

I don't really mind but @ShadowOfHassen above was puzzled with the outcome of "git pull --tags origin main", so it's safe to assume there is a certain expectation. Ok, but then maybe using Ghost like github or similar would be better to indicate the intent of it being a removed/invalid user. Could also be used in future for deleted users without awkwardness. It helps distinguishing metadata from commit message, the linux kernel and many other projects do this as well, guess it would also be good to follow this convention in the future. Is the source of the whole migration available somewhere? Anyway a first simple solution from the top of my head :set textwidth=72 :normal gggqG :wq save the above as rewrap.vim and run as vim -es -S rewrap.vim message.txt Maybe wrapping the first line (subject) is undesirable though. Anyway looking at the result should shed some light on what to improve. Coreutils has commands to similar effect IIRC, would have to dig through man pages tho. But they might fit better into the migration pipeline in the end.

Fine, let me add some random findings in short form: default branch name trunk -> main maybe Pascal case generates a link on trac, maybe camel case as well. The migration script ideally filters such broken links. Example: https://gitea.itms.ovh/wfg/0ad/issues/6796 https://gitea.itms.ovh/TracUser should probably be renamed, at least if it's used in future for automation in commit messages patch by, comments by, reviewed by, svn commit id probably should be a block, ie. no empty lines in between might want to rewrap commit messages at width 72, some weren't wrapped at all and some are wrapped poorly after changing svn rev with the much longer commit hash If the underling file system allows sharing extends this should be even less.

The technical issue is fairly well summed up by Sam James from Gentoo at https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 A rather good video by Theo discussing the human component of the exploit:

@Itms Glad to see progress was made and we might have an improved workflow in the not so distant future. Appreciated. I wonder if it would make sense to create a subforum for the git migration and keep this topic as a means for informing the community about the general progress. I already see me bringing up various issues which each might warrant a discussion. Putting them into separate threads would help keep some order at least and help avoid duplicate reports to some extent. Or maybe we simply should use trac?

If Redhat trust the people they have given commit access to flathub they can just put the trusted label on it and users can chose to trust Redhat or not, done. Upstream endorsing downstream is backward, why should upstream endorse Canonical and Redhat but not all the other distributors? Maybe you realize there is as much politics in this as other reasons. If upstreams aren't serious about it and just randomly hand out dozens of endorsements then it's a disservice to the end user and being serious means work, no way around it.

Those distribution builds are done by distribution maintainers and not wfg. Sure sometimes they run into issues and might ask a quetion or two but more often than not they provide patches and it can be considered a net win for the project. From the viewpoint of wfg flatpack is just yet another binary repo. That reminds me of https://xkcd.com/927/ I'm a Linux user for 30 years and still not yet a fundamentalist. What I expect from binaries is that I could build them myself and that they are from a trusted source, also I want to get notified of security issues and them being taken care of in a professional and timely manner. Lastly it should be functional. This is what a distribution maintainer is for and if you want to take care of flatpack you will have to take up the same role. Whether the binary format is PE, ELF or Mach-O I don't care and don't see why I should. So the really bad I really don't understand. Wine is a recursive acronym for wine is not an emulator. Sometimes a software actually runs faster in wine than on Windows. I remember getting about twice the FPS for Diablo II. Ofc an Linux package is preferable all else equal. Debian builds for 4 different archs https://packages.debian.org/stable/0ad, so no single binary to rule them all. There are more archs than that running Linux, some somewhat recent patches suggest people also want to run 0ad on risc-v and e2k. Not money but man-hours. Half a day would be not unusual I'd estimate. Add to that that bugs with that package would be come our bugs instead of theirs. If you want to help I guess you'd have to be familiar with building from source, packaging software, willing to commit for several years, live in a country were law can reach you and possibly meet a current developer IRL for exchanging keys.

Why would you mind the unverified label for flatpack? Also what does native mean? After all the exe is a native x86 binary and flatpack isn't a native distribution package. Using wine gets you a 0-day trusted binary path at basically no cost for wfg. The cost for a release I'd argue is already in the unhealthy territory. I fully understand that this might not be the most favorite solution for a small set of users but my standpoint is providing the sources is good enough and beyond that is adding bells and whistles.

Few years ago I tried and hwdetect triggered an error due to numa not being implemented in wine, the error dialog offered a continue button and so I continued and from there the game ran just fine. If this is still the case just dropping numa detection which we don't make use of in the the first place would allow us to have a viable alternative to offer a "trusted" binary for the impatient beside the just build it yourself (tm). While it is true that a distro might lag a lot, those listed as the most popular were all reasonably fast to offer the latest version in the past as far as I remember.

Have you ever tried running the Windows version available on play0ad in wine?

No, that is really only a mirror. @Vantha just ask an admin to manually activate the phab account. Spam bots are just to common this days and the hurdles placed for them might occasionally affect legitimate attempts at registering.

Created a pull request

We don't strictly need 8 names, I mean I can play against 3 or maybe 4 before I get badly beaten. So in most games a single name per civ would be already enough. Using made up names would undermine the point made by @Stan` which I quite like. So requiring 8 names doesn't sound that great.

Adding more names is an option, removing names ending in a roman number is an option. Not generation an endless list I consider a regression (the engine already supports more than 8 players), tho changing how the list is generated might make a lot of sense. What do you have in mind for how it should work, replace roman numbers with a suffix like (2)?

They are undocumented at https://trac.wildfiregames.com/wiki/ParticleFormat. I just tried to do so but after trying to pass the the captcha about 20 times without success I give up

You might have a much easier time using blender python api, there is also an importer for pyrogenesis https://github.com/stanleysweet/blender_pyrogenesis_importer If you want to write an app based on pyrogenesis I'd say dig into premake and study the ActorEditor for being a lot simpler than Atlas/ScenarioEditor

You can also ask a moderator to split this thread or even submit a patch to phab if you think you have better implementation.

The code needs to generate an endless list of names, could be bot1, bot2 and so on. The improved names here are only for role-playing purpose. If you don't provide an endless list you might break mods or add another thing that breaks should you increase max players. Tweaking the generator is an option but discussing this I consider off-topic (like most in this thread) so I stop here.

As you are a single-player you can just delete the map if you dislike it that much. Or not that hard either, create a mod with an empty file maps/random/pompeii.json.DELETED

Auto queue is just a hook to add stuff to the queue should it be empty, what is shown is basically just the pattern used for adding, not units already in the queue. Filling the queue based on the pattern binds the resources. The AI has already decided to spend the resources this way so binding doesn't matter either. You can also just calculate each round what the AI should do with their res and only queue a single batch if currently empty. In essence you would just run the same calculations over and over as the result wouldn't change. Sure you can mod the AI to be smarter but the autoqueue feature is pretty much useless for anybody but humans.

If the name itself was "Themistocles II" ... Anyway not a bug a as you can't reasonably require sufficient names for any case.

What you show as bot auto queue is just a regular queue. Basically the same you get if you queue up 6 batches a 2 manually. Auto queue for humans only makes sense because we forget sometimes to queue units but that is an issue the AI doesn't have. In light of that your question doesn't seem to make sense to me. Could you elaborate a bit more on what exactly you want.

That's about page size (continuous blocks of memory similar to blocksize for hard disks), paging (or swapping in unix speak) moves pages between ram and hdd. Page size is about efficiency, to small means to much overhead and to large means waste of space. I can't find good docs either, but an article talking about it would be https://www.tomshardware.com/news/how-to-manage-virtual-memory-pagefile-windows-10,36929.html Unfortunately, the use of the term virtual memory in that article is again different than what virtual memory is about (see https://en.wikipedia.org/wiki/Virtual_memory for a somewhat decent introduction) and the statements about minimum and maximum size are almost certainly not true either but alas ...

But only on a 64bit Windows. The 4GB are also referring to virtual memory and not ram per se. Using my numbers from before only 1.5GB would have to "live" in physical ram. After an arduous journey of convincing the search engine (tm) that I don't want to backup files I found it's called paging on Windows and the "swapfile" is called pagefile.sys and hidden and managed for you by default. While Linux just pretends the extra 5.5GB memory exists until it's used (true overcommit) Windows should be able to "page" it according to my understanding. Ofc the 32bit Windows build doesn't use 7GB virtual memory but it's pretty safe to assume that maximum of 4GB is just barely enough.

Was based on svn before A26, closer to A25 I believe. The binary I deleted in the meantime but could be rebuilt, though might have to work around a certain python - sm issue. From my limited knowledge of Windows memory model, it allows sort of overcommit if backed by hdd, maybe sort of dynamic swap is a better term. For me 0ad typically takes about 7 GB of virtual memory on Linux 64bit and some 1.5 GB residential memory. Therefore I think it's very reasonable to assume that a 32bit builds will have trouble with the limited address space but a 64 bit build would work reasonably well with 4GB physical ram even on Windows. So I have no doubt that 32bit is an issue which people might run into occasionally, was just wondering if the last community mod might have moved the tipping point based on recent noise but according to @chrstgtr that doesn't seem to be the case. I think the last notable rise in requirements was with A24 and earlier version should be much less likely to run into this.