Jump to content
  1. Welcome

    1. Announcements / News

      The latest. What is happening with 0 A.D. Stay tuned...

    2. Introductions & Off-Topic Discussion

      Want to discuss something that isn't related to 0 A.D. or Wildfire Games? This is the place. Come on in and introduce yourself. Get to know others who are using 0 A.D.

    3. Help & Feedback

      Here is where you can get help with your questions. Also be sure to tell us how we are doing. What can we improve? What do you wish we could do better? Your opinion matters to us!

  2. 0 A.D.

    1. General Discussion

      This is the place to post general stuff concerning the game. Want to express your love for hoplites or find people to play the game with? Want to share your stories about matches you have played or discuss historical connections to the game? These and any other topics which are related to the game, but don't have their own forums belong in this forum.

    2. Gameplay Discussion

      Discuss the game play of 0 A.D. Want to know why the game plays the way it does or offer suggestions for how to improve the game play experience? Then this is the forum.

    3. Game Development & Technical Discussion

      A forum for technical discussion about the development of 0 A.D. Feel free to ask questions of the developers and among yourselves.

    4. Art Development

      Open development for the game's art. Submissions, comments, and suggestions now open.

    5. Game Modification

      Do you have any questions about modifying the game? What will you need to do what you want to? What are the best techniques? Discuss Modifications, Map Making, AI scripting and Random Map Scripting here.

    6. Project Governance

      Forums for decision-making on issues where a consensus can't be reached or isn't sufficient. The committees are chosen from among the official team members, but to ensure an open and transparent decision process it's publically viewable.

    7. 512
  • Latest updates

  • Newest Posts

    • Интересно: айфон 15 голубой или где купить моноблок Может быть полезным: https://alikson.ru/smartfony-1003/tag-kupit-smartfon-poco-x6-pro-5g/ или купить смартфон онлайн интернет-магазин кнопочных телефонов Ещё можно узнать: labora citoИнтересно: игровой ноутбук купить дешево мощный или HDD накопители купить Может быть полезным: https://alikson.ru/smartfony-1003/tag-kupit-samsung-z-flip/ или компактные планшеты купить моноблок Ещё можно узнать: кровь на цито что это значит
    • Интересно: самсунг галакси s24 ultra цена или недорогие ноутбуки Может быть полезным: https://alikson.ru/smartfony-1003/tag-kupit-samsung-z-fold/ или где купить ноутбук легкие ноутбуки Ещё можно узнать: как набрать е на клавиатуре
    • Интересно: маленький самсунг или лучшие смартфоны 2024 Может быть полезным: https://alikson.ru/noutbuki-1001/tag-igrovye-noutbuki/ или лучшие смартфоны 2024 магазин электроники Ещё можно узнать: брокер герчик и ко
    • Okay, how do we get our grass sprites to look like that?
    • Can you upload your logs ? System info and hw userreport Do you get any warning when changing sample number ? And 0 A.D. supports 4K no problem so it's something else.  
    • If the exported translations are not committed, that feedback does not actually happen... Do you think it could create actual issues? Yes, the first one isn't possible. The second one I hadn't considered but maybe it would be nice. I am thinking this "translations" repository could even allow us to store the translations of official/semi-official mods. Those would not be pulled into the git and the nightly-build of 0ad, but they could be synced with Transifex, allowing our translator community to translate them. The modders would then pull translations into their mods when they release them, and push pot files to the repository whenever they wish. For the third one, I answer you further below. Well it wouldn't be possible to review changes to the libraries themselves, but changes to the 0 A.D. code would still be reviewed and even tested by CI. This is indeed problematic but it is the same situation as today. Take for instance D5002: the contributor cannot publish the SM upgrade itself inside that diff, the diff only consists of the changes in the game. Right now that situation is too complicated for our CI pipelines to handle it (arc patch doesn't work well with binaries) thus the build for those diffs always fail and make much noise. With git, it would be possible for a contributor to send big binaries in their PR for initial review of the whole. Then we could commit the update to source-libs and have a final round of CI on the final PR that would just update the SVN revision in libraries/ scripts, before committing. So that addresses your concern. windows-libs changes are currently unreviewable, as they are just me or Stan sending new binaries on SVN. At least with the new system we could send the new binaries, then create a PR that just updates the SVN revision in libraries/ scripts, so that CI can run on it. So it's still a bit unreviewable, but it will actually go through CI before commit. ah that's right! Well, it is arbitrary, or at least based on feelings (but I think it's important to consider those). One of my issues is: those commits would lack justification. The history of the repo would contain a lot of commits that do not address an issue. Those would just be commits happening because "translations are updated all Mondays and Fridays". Moreover, those commits have the big downside of highlighting low development activity. It feels very bad to see that autobuild commits more than the team in times of reduced activity. This is awful for morale. My proposal allows us to have daily updated translations, which is better for testing, but if we keep translations in the git repo, having daily updates would dwarf actual human contributions. Hence, if my current system really irks you, your second proposal above is the only one I would find acceptable. Basically I think that the issue with spir-v and with translations is the same: we have files that are needed for the end user (including nightly testers) but which cannot be committed to the git repo (for translations, replace "cannot be" by "I would rather have not"). I figured that if I generated shaders in the nightly and provided a way to export them into the git repo if developers needed them, I could just have the translations follow suit, and fix two problems with the same consistent solution. You can contribute PRs to the private dev-migration repo on Gitea. But I agree it's a difficult project to collaborate on Your thoughtful feedback is much appreciated though By "large" I was thinking about translations (and "very" with shaders on top) but you're right that going from 100MiB to 700MiB would probably not bother users too much (I, on the other hand, would be sad to miss that opportunity to reduce the size by such a factor!) and I hadn't indeed realized that increasing the frequency of translation commits would not increase size that much. Thanks again for your feedback   I'll try and think about the idea of a cleaner, separate repo for the translations.
  • Create New...