vv221

No a lot. I would not be surprised if more than 90% of GOG customers were Windows users.

I don’t think there is any such version of the source code (A26 + OpenAL 1.24 fix), nor that it would be planned.

A fix is now included for Debian sid, and will be part of the next upload. This bug report will be automatically closed when this upload is sent.

I can confirm that on a system that uses ALSA, without PipeWire nor PulseAudio.

A basic 64-bit (x86_64) build using dynamically linked libraries is what would be expected, as well as a list of libraries that should be installed by the end user. The target should be an "old enough but not too old" system, like the current (or previous) Ubuntu LTS. GOG does not provide official support for any Linux distribution besides Ubuntu, so users of other distributions are expected to find out by themselves how to get games to work (like translating the list of dependencies to the package names provided by their system). Anyway, for Linux users installing from their distribution is always going to be the best option, providing a Linux build of 0 A.D. through GOG would be more about visibility than usability.

GOG uses their own installers, that are based on InnoSetup for Windows and on MojoSetup (+ Makeself) on Linux. I don’t know what is used for the MacOS installers. I don’t know the exact process, but I strongly suspect these installers are done by GOG, not by the game developers. That would be surprising, as there is not a single game page doing that on GOG for now. Customers of this store already know about 0 A.D. and talked about it positively on their forums over the years. But according to the low popularity of this wishlist entry, it is not (yet) a game that many people would expect to see distributed on GOG: https://www.gog.com/wishlist/games/0_ad It would be much better not bothering with that and not trying to support it in any way. The goal is to get more visibility, not a source of extra work Whatever we do, if 0 A.D. is added to GOG it would automatically be downloadable/runnable through Galaxy, but we should not waste time and energy working on Galaxy integrations with things like cloud saves or achievements.

I can’t say how easy or hard it would be to pass through their curation process, but I think 0 A.D. would be a great fit for GOG, if distributed there as a free game. It would no even need an "early access" label (it is already in a much better state than many *released* commercial games). Many GOG customers are starved for RTS games, and multiplayer games that can be played without going through a store launcher/DRM. Many of them joined the store for "old" games and are still waiting for Age of Empires, so having access to 0 A.D. could scratch their itch. I expect launching the game on GOG would have a bigger effect on 0 A.D. popularity than what itch.io did, if only because of the small catalogue leading to each game getting more (relative) exposure. To get an idea, here is their full list of so-called real-time strategy games (most of these are not even what we would call RTS): https://www.gog.com/en/games?genres=strategy&tags=real-time&hideDLCs=true It would be very easy for 0 A.D. to shine when compared to most of these games. --- On the topic of the alpha version, I too am in the opinion that it does no longer help. I would suggest dropping alpha, beta or whatever and stick to the 0.0.27 naming scheme (0.1.0 would be first beta, 1.0.0 first "complete" release). Alpha/beta could stay in internal discussions, but no longer has an useful meaning for distribution.

For the discussions we currently have on #0ad-dev (I do not follow #0ad), I think IRC is already the best option. So we would only need to switch to a server with support for TLS encryption, my preference here would be OFTC (already used by Debian). I would be happy with XMPP too, even if I think it has too many features for our needs (and unused features are bugs lying in ambush). From an user point of view, it would be very similar to IRC with better support for private messages. I think it can be used without an account, but I don’t remember having tried that. The ability to link the discussion channels with the game lobby would be a very big upside, if it were considered that would make XMPP my favourite option. My experiences with Matrix have all been really bad, so this is not an option I would support. The clients especially seem to mostly be either awful (Element) or incomplete. I do not know anything about Zulip yet, so I won’t comment about this one. --- TL;DR: 1 vote for IRC, and 1 vote for XMPP.

This is a very apt description, and having no problem at all wrapping my head around pointers might explain why I do not see submodules as really confusing.

It looks like I have been a bit too slow with my EDIT

I do indeed think that per-dependencies repositories would be easier to work with than a common repository for all libs. Then the way we include these, be it with curl+tar+patch or submodules, is in my opinion not of a big importance. I think the best option is the one the people who will actually maintain the build tools would rather work with.

The difference would have been the ability to patch the source more easily, but Stan` wrote above that we use OS-specific patches, something that submodules could not help with. --- EDIT: Actually the OS specificities could still be handled as per-OS git branches, so applying the patches in these repositories instead of doing the patching at build time is an improvement that could still be done. Improvement that could be done no matter if we chose to go with submodules or tarballs, so this is not really an argument in favour of submodules themselves.

I think they do bring another upside: we need to patch the source of some dependencies, like SpiderMonkey. If we used submodules instead of the curl+tar+patch dance, we could provide an already patched source instead of maintaining patches in the 0ad repository. I am assuming here that the repository fetched by the submodules is not the upstream one, but something we would host ourselves. --- To avoid confusion: I am not advocating that we *should* use git submodules. What I mean here is that *if* we decide that they could help us, I am willing to work on them to make their use as painless as possible.

That’s right, and I plan to abstract that by providing scripts so the people who want to build 0 A.D. locally will not have to worry about submodules at all.

I think our situation of depending on third-party sources using fixed releases is one of these few situations where they make sense. Not having these sources included in the main repository will make 0 A.D. easier to package for distributions that un-vendor such dependencies, like Debian.

One week from now, I should finally have time to join this migration effort. @Itms, my initial plan was to focus on the SpiderMonkey update, but it seems you already have that on you TODO-list? I have to admit it’s good news for me, because I know nothing about SpiderMonkey and would have to learn everything from scratch. My goal was to ensure 0 A.D. relies on the current ESR release, or at least the previous one, I guess yours is similar? Would you agree that the best way I could help would be to experiment with git submodules ? I have some experience with them, and more generally see myself as a skilled git user (I used it daily for more than 10 years, including in very tricky ways) so that might be the best way to spend my time on this migration. I have been maintaining git forges for a long time too (mostly self-hosted GitLab), so if you need support on this front feel free to ping me.

It’s sad to see you go, but not unexpected. No one can bear so many things by themselves for so long. I hope your replacement will be a team instead of an individual, to prevent people getting burnt out. Anyway, it’s good to see you have other projects now, I hope we will soon find some time to discuss these with a cold beer

I think an automatic slideshow would be a bit distracting. On the other hand I would love to get a random background on each game launch.

Tested on a Debian Bookworm/Sid with Python 3.11, the full mozjs build went smoothly.

Well done, it did the trick on my Debian Bookworm/Sid with Python 3.11.

The process is much easier than what I expected, so I plan to import all patches from the community mod in the coming days.

This is the main reason I’m all in favour of GitLab, because this is the one I can help with. Including for long term maintenance. I think that for equivalent features, volunteers for administration/maintenance is what should drive the choice of tools. So if other people feel ready to dedicate some of their time for the maintenance of the development environment, it might be a good idea to make these intentions known

I think this is should be the focus. We don’t want to "burn" people with the administration of the tools that will be adopted. This is the main reason I’m mostly advocating in favour of Gitlab, because as a Gitlab administrator and maintainer myself this is something I could help with both in the short term (helping in the setup and migration) and long term (helping in the maintenance and administration). I don’t think it is a perfect solution, I actually have more than a couple issues with Gitlab, but I have been working with it long enough to know of its shortcomings and can help working around them. I would still be willing to help if another solution is chosen, of course, but I would be much less efficient with other tools if I need to learn how to use/maintain them from scratch.

In my experience, GitHub ability to bring valuable contributions is overrated. I even took down the GitHub mirrors of the software I maintain a couple months ago, after years with no contributions coming this way (while we still get contributions on our dedicated GitLab instance).

Training otherwise unavailable units from captured buildings, with some limitations, sounds like a really fun idea. I would love seeing that in game