phosit

Hello everyone! We just branched for R28. The nightly-build tracks the state of R28 and can be used to test the new version. It is generated weekly, and you can get it using SVN. Detailed information can be found on the wiki Mock Release Bundles are also generated weekly, from the nightly build. They can be downloaded from our Jenkins build system. Future RCs will be taken directly from here. A higher overview of the release process can be found at [RELEASE PROCESS] Release 28 The contribution work-flow is not stalled during the process. We are still merging the work of devs and contributors into the repository, for inclusion in the future releases. The preparation of Release 28 is made in parallel, and not blocking. That said, most of our energy is dedicated to the release, and you will experience delays in us reviewing contributions. Please make sure no mods are enabled when testing the game. What should I test? While we encourage you to test everything, we expect most regressions to be related to those changes: In the match-setup a player can be removed and might interact badly with joining player or so. The size of Strongholds have been refined. The Germans have been introduced and might not be balanced well. The font rendering changed. Especially non-Latin fonts should be tested. Some parts of the game now use js-modules. We want to know whether it's still easy to mod those. There is now a 64-bit Windows and an AppImage build. What should I report? Not everything. We know about two apparent issues related to sound: #8342 #8426 Apart from that we must fix regressions (stuff that used to work, but doesn't work any-more) and critical issues that would prevent the users from playing. We cannot reasonably fix all the existing bugs in the release. Critical issues include crashes and multi-player OOS. How to report them is detailed in the ReportingErrors wiki page. With the weekly generation of testable game versions, it is absolutely necessary to check you use the same nightly build (version is displayed in the main menu) without any mods when testing for OOS. Happy testing!

Did you instal vulkan-icd-loader and vulkan-radeon?

Sorry if it was already proposed: Asymetric victory conditions For example on "White Cliffs of Dover" the invading units have to build a settlement. Instead of conquesting the Britons they could prove that they have a stable settlement by building a wonder. The condition would then be Team 1: conquest the invadors Team 2: conquest the Britons or build a wonder When "Asymetric victory conditions" would be in place it would be easy to build a tower defence scenario. Team 1: keep the wonder for x time Team 2: destroy the wonder Should something like that be in 0 A.D. or should it only be in mods? Is there already a map which does that?

Wat does that mean? Other continent also existed. Do you mean that there are primarly records from thous regions?

Is this still a problem? I haven't seen such a report in a long time.

Likely there will be another european civ : https://gitea.wildfiregames.com/0ad/0ad/pulls/7104

I'm not working on it.

Could you attach the replay-file?

I forgot about it. I accepted it and will merge it tomorrow.

I'm in favor of XMPP We already have a server. Compared to Matrix it's is wider supported. (more clients) Compared to IRC it supports group chats, it allows async comunication and it doesn't tell everybody when I'm online.

That would have more or less the same effect as halfing the popcap. (The other way around: When doubleing the cost player will just increase the popcap. So there is litle difference in unit count) I think it would be better if there is no hard popcap but a penalty for players having many units.

@phosit ? I can't reproduce it on svn.

The x-axis of the right chart is time. The frames are ordered chronologically. The right chart are the frames ordered by time. No I only tested it with multiplayer with a single client that worked. I also get OOS with multiple clients when entering the command during a game. It worked when entering the command during the loadscreen. In a replay the turnlength is the same as in the game it came from.

What do you mean by that?

For the first part: Yes it would be good to implement that. There is a ticket: #5323 For the second part: There is also a ticket #3752 Most computation isn't executed every turn (or in a constant turn interval), like a builder deciding what to do when a field is placed. Still some computation does that, like the AI deciding what to do. IIRC An AI only executs each 8th turn. With more frequent turns the constant-turn-interval tasks could be spaced out more. So the average computation is roughtly indipendant of the turn length. Engine things (rendering, network...) Isn't done per turn but per frame. In a cpu intensive game there is a turn every frame. So engine things could be seen as constant-turn-interval tasks. (This entirely refutes my previous argument ) There isn't one magical thing which makes the game run fast (in a single thread (multithreading really is magical (that's a joke magic doesn't exist ))) If you only care about game speed (your complain 1) you want do as few constant-turn-interval tasks. Thus longer turns. If you only care about a responsive UI (your complain 3) you want to do as few sim-things per frame as possible. Thus shorter turns. About your 2. complain: I think in such a situation the fast clients repeatetly have to wait for the slowest client. When a fast client ends it's turn it has to wait's for the slow client to finish the turn. In this time the fast client shows an interpolation (IIRC 5 frames) to the user. When the slowest client is really slow thous 5 frames aren't enough. A solution (which just came to my mind, it isn't elaborate) would be to space thous "interpolation-steps" out, like one interpolation-step each second frame. The interpolation-step / frame ratio should be dynamic to the expected speed of the slowent client. Maby also the interpolation-step count could be dynamic. (I'm just thinking loudly at this point) We head in the direction of decreasing turn length even more: Hosts can already specify the turn length by typing `Engine.SetTurnLength(100);` in to the js console. (yes the feature is hidden) I'd like to see the results of your experiments .

There is a fix but there is little activity so i don't think it will be commited soon.

There will be another RC when we are in the release process. The release process from which 0ad-0.0.27-rc1-27645 originates got halted.

An AI was roman.

Indeed, thanks for the ping. It should be fixed with rP27994.

After updating ICU I also had linkage errors. It was fixed by cleaning the workspace.

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. Right i used 2.12.1 Can you upload a patch? (I'm shy of patching libraries) To address the readability issue we could use a temporary/using. using MaybeConstXmlError = std::conditional_t<LIBXML_VERSION >= 21200, const xmlError, xmlError>; void errorHandler(void* UNUSED(userData), MaybeConstXmlError* error)

Thank you for the work. I don't like preprocessor directives. We could go for: void errorHandler(void* UNUSED(userData), std::conditional_t<LIBXML_VERSION >= 21200, const xmlError, xmlError>* error) Also that wouldn't introduce duplication. @hyperion Does Fcollada also have an issue with newer lxbxml2 version? I get this errors: FCollada/FUtils/FUXmlDocument.cpp: In constructor ‘FUXmlDocument::FUXmlDocument(FUFileManager*, const fchar*, bool)’: FCollada/FUtils/FUXmlDocument.cpp:39:39: error: ‘xmlParseMemory’ was not declared in this scope 39 | xmlDocument = xmlParseMemory((const char*) fileData, (int)fileLength); | ^~~~~~~~~~~~~~ FCollada/FUtils/FUXmlDocument.cpp: In constructor ‘FUXmlDocument::FUXmlDocument(const char*, size_t)’: FCollada/FUtils/FUXmlDocument.cpp:67:23: error: ‘xmlParseMemory’ was not declared in this scope 67 | xmlDocument = xmlParseMemory(data, (int)length); | ^~~~~~~~~~~~~~

Indeed. While writing that prompt it also got to my mind: In the winter there aren't that much less animals. Instead there is less gain on the fields.

In days of old, when winter's chill did reign, Meat was a luxury, scarce and plain. The frozen fields lay barren, void of life, Leaving hunger pangs to plague our strife. But fear not, for in those frozen lands, There were still ways to feed our hands. We turned to fields of grain and green, Where other forms of sustenance were seen. The wheat and oats we harvested with care, Baked into bread, our bellies could bear. And from the gardens, vegetables galore, Stews and soups we made, and more. In winter's grip, we found a way, To survive each day, come what may. For though meat was a rarity, Our resourcefulness kept us in unity. So let us cherish these fields of gold, That give us life, both young and old. For in their bounty, we find a way, To thrive, even in winter's gray.

Ok i reinstaled the git repo, but still don't get the xml error. If there is no objection i'll commit it as is.