Leaderboard

Person.

@Sun Wukong A new Mauryan palace is coming for A28.

I really want to experiment with p1 champions for spartans. In fact, I have a community mod branch made to implement @borg-'s sparta patch at the ready. I'd like to try this out in the community mod once that is ready for a27. With one or two iterations, we could make it very polished.

Here is the first 'Release Candidate' of Alpha 27 - Agni Downloads - Current bundles are for SVN revision r27645/bbae4080acaf09e2716cde8027c7a3c2cd3eaff4 Linux data and build Windows MacOS Builds currently unavailable due to signing issues. You can only test the installer but the game will not run. macOS (x64) macOS (ARM) Things to note: Mind your mods -> they might introduce issues or Out Of Sync. Save your A26 config file somewhere, ideally. or use -writableRoot. What changed: Alpha27 – Wildfire Games How to port my mod PortA26ToA27 – Wildfire Games What to do if I have an error or notice something weird? Post your commands.txt (replay) and the interestinglog.html file from your folder. You can also reply to this thread. What to do if the game crashes? Upload your crashlog.dmp and crashlog.txt see https://trac.wildfiregames.com/wiki/GameDataPaths What to do if I have an Out Of Sync? You should go in your logs folder, find the replay (commands.txt at least), the mainlog/interestinglog and find the OOS dump folder. Zip all these files and upload them here. We need the reports from two players to compare them: One OOS and one non-OOS players at least should upload their oos_dump files. Things you may want to test (non-exhaustive) Test Vulkan performance. Enable feedback and see if it works (Main menu) See this video Launch a random game Launch a skirmish. Connect to the lobby Play on the lobby with someone Play in LAN Launch Atlas and try things out there Open Unit tests demo (To see if there any breakage in displaying entities) (It's in scenarios) Connect to and use mod.io Test replaying new games Test multiple game modes (e.g. Regicide) Test Atlas terrain previews. Test Screenshots (F2) Test deleting all saved games Test Big Screenshots (Maj+F2) Test hotkeys Test Saving and loading a game. Test Quickload/Quicksave And of course playing games.

A bus stop with a garden!

Units in A26 and A25 can squeeze themselves into tiny singularities which causes many problems. This screenshot is one example (it's not even the worst case, I missed the worst moment). Inside this picture are 76 spearmen, all crowded into this one small area. As you can see, the middle ones are overlapping each other with body parts inside their friends. This is bad. The results of this is 30 or 40 spearman all focusing on one enemy while leaving the rest of your units unattended. It causes very quick death rates and the melees are not doing their job of shielding their ranged units. It is actually less efficient in battles and causes chaos, but hurting both sides. Quick death rate is bad and is the hidden cause of many other problems. I understand that this feature was implemented in A25 for smoother and more efficient pathfinding. However, it is now just ridiculous and unrealistic to cram dozens of units into such a small area. I propose we let units have their own rigid personal space, no entering your friend's bodies. Now, I know it's too late for A27 vanilla, so can someone teach me how to make a mod that disables the squeeze? So that there is a chance that community mod will have this problem fixed. Thanks.

Hi Vlad, here is my userreport: userreport_hwdetect.txt I am not able to record the issue using OBS Studio: indeed, whenever the flickering happens, the frames captured by OBS Studio are blank. The capture shows the screen only when the flickering has stopped. Instead, here is a video of my screen using my phone. VID_20230520_000647.mp4 You can see that a few square parts of the game view are flickering. In this pathological example, a part of the dialog is missing, removing a button. The flickering always stops without intervention after a couple of seconds, then the game looks normal. The flickering doesn't always hit the same parts of the screen. I believe the issue only happens in fullscreen, but I'm not sure. It can be triggered by toggling fullscreen with Alt+Enter, but I found that the most reliable way to reproduce the issue was to enable fullscreen in the options. With this option enabled, flickering will happen at game start in the majority of cases. Hope this will help you.

Could you post your user report with OpenGL enabled? Also is it possible to record it?

Point is, just because one guy has a problem with it doesn't mean an entire building needs redesigned.

On a different PC, I started A27 in OpenGL mode, and I saw huge travelling waves of Mosaic patterns all across my screen. After I changed the rendering backend to OpenGL ARB and Vulkan, the problem disappeared. The configuration of my test bench is as follows: Nvidia GTX1660 with 530 driver Arch Kernel: Linux 6.3.2-zen1-1-zen 4K screen This was a minor issue and can be solved by changing the renderer. OpenGL seems to really fail for more demanding tasks such as driving a 4K screen. I think it would be good if we add a notification on the welcome screen to tell new players how to change settings to fix such problems.

I'm working 2 or 3 changes for each civilization. It's not much, just to give a direction and characteristic for each civilization.

You have to press "c" + right click now. You know, if you only get that sword symbol, your units are just going to (try to) destroy it.

I would refuse to play in your cubic hellscape as well. During regular gameplay I could capture towers and other buildings just fine.

You don't need it anymore. Only when playing the development version.

we should raise the heads of the elephants and make them look a bit more fierce. Right now They look Fat like circus elephants. look these https://yatramantra.com/top-10-famous-elephants-living-in-kerala/ https://youtube.com/shorts/iBwFmF8NkE0?feature=share female elephants are chubby male elephants are are bit strong looking.

I have an idea. You could make it so that as it loses life, it starts to become faster and more destructive.

is that now? Should be good against cavalry.

eles have been redesigned to be more effective fighters, not just a second ram. They still do well vs buildings, but their primary role is now vs infantry.

I'm sticking with this idea. More loyalty from that would make the buildings harder to capture. @real_tabasco_sauce @borg- I mention you because you wanted to keep differentiating the Spartans.

Have you tried the values I suggested in the patch? I think they were a pretty good middle ground, as there are many undesirable behaviors outside of certain ranges. 1. being the "bog down" of pathing units. 2. bulky units can be pushed into interlocked pairs. and a few more. I think it was being considered for committing but people lost interest i guess.

I oppose the idea of giving an archer bonus for Carthaginians. In the wikipedia page about the military of Carthage, archers aren't mentioned once. Carthage should have other qualities than buffed archers. Wikipedia article: https://en.wikipedia.org/wiki/Military_of_Carthage

Worked fine with fmt 10.0.0.

Splash? Eles have area damage??? Eles have been OP since long time ago, never nerfed. More hack, pierce and less crush maybe, so that elephant civs still rely on mainly rams to siege.

Specifically the saying goes that Sparta's men were its walls, and historically, there was no threat to Sparta up until the war with Thebes following the Battle of Leuktra. In theory the game is supposed to represent civilisations at their pinnacle, and thus, Sparta does not have any walls. It is supposed to have better loyalty with its buildings and hardier women to compensate for that fact (at least going off of the original design document).

@Yekaterina Can you make sure you have the same options enabled, just for comparison fairness? E.g arb disable a lot of options. Thanks for testing.

I get the feeling that there is transparency in these bars because none of them fit.

use this to prioritize killing enemy ranged units. This is known as sniping, and I think it uses left click instead of right. Due to the way melee and ranged units are balanced, this is the best micro to do during a fight.

I wanted to share some details about the migration of the lobby we did on Friday and what went problems we encountered while doing so. That'll take a bit to explain so I suggest grab a cup of tea and some cookies before you continue to read. The motivation for migrating the lobby to a new server was to get it into an up-to-date state and to improve its performance. The operating system on the previous server was already getting older and as it got manually updated over the past years, there was lots of stuff on the server, which wasn't really necessary for operating the lobby. Therefore, to start with a clean slate, we decided to set up a new server from scratch. Server in this case means a new virtual machine as part of the infrastructure Wildfire Games has available to host everything related to 0 A.D. Instead of manually configuring the new server, we wrote so called playbooks for a tool called Ansible, which are instructions written as code how to configure such a server. We did so to increase transparency and documentation what's running on the lobby server. Going forward instead of doing manual changes on the live lobby, changes are written in Ansible code and can be reviewed like any other code related to 0.A.D. as well. This also improves the ability to test changes in an isolated environment instead of having to use the live lobby for that, as the written Ansible code makes it easy to configure other computers the same way. With an additional tool called Vagrant, which allows easy creation of virtual machines running on your local computer, it's now easy to get a nearly identical copy of the official lobby running for testing purposes on your own computer. If you're interested in the details regarding that, please check out the git repository where we published all of that: https://github.com/0ad/lobby-infrastructure/. If you're interested in participating and improving the infrastructure behind the lobby, contributions are always welcome there as well. While having the configuration of the lobby available as Ansible playbooks means that configuring a new server is just a matter of running a single command and waiting a few minutes, that's only true for a new lobby without any existing state. State in this context means lobby accounts, ratings and certain logs we wanted to keep. As migrating the state takes additional time and care and because unexpected things might (and in fact did) happen during such a migration, we planned a quite long downtime of 4 hours. However, the actual migration only took roughly one hour and once everything looked good again we made the lobby available for all of you again. Unfortunately, that's when we and some of you started to notice some problems, which took us quite a while to debug and fix. Here is a list of the most critical and interesting problems we encountered: Games becoming invisible Once more and more of you joined the lobby after the migration, eager to play again, we quickly noticed that something wasn't right. Games would become invisible or wouldn't even show up in the first place. After searching for a while, we figured out that this was caused by rate-limiting of messages getting sent through the server. There is rate-limiting in place to avoid spamming of large amounts of messages. That means that each user can only send a certain amount of text per second. During the migration we made a mistake in the configuration and applied the same rate-limiting which applies to all players to the bot managing the games as well. While you don't see many written messages from WFGBot, it's actually a pretty busy bot and sends out a lot of messages which get processed by 0.A.D. to be able to show you the list of games. With WFGBot not being able anymore to send all messages it wanted to send, this meant the list of shown games would be outdated or even completely empty, because your instance of 0.A.D. wouldn't get up-to-date information of the available games. We didn't catch this problem in our testing prior to the migrating, as our test setup had too little volume in terms of online players and hosted games to trigger the rate-limiting. Fortunately the fix for this problem was easy and just required fixing the mistake in the configuration. Lots of stale and outdated games being shown With invisible games not being a problem anymore, the list of games constantly grew and quickly started to show games whose hosts had already left the lobby. That's no new problem, and you've probably seen such stale games in the past already. That happens when WFGBot doesn't get a notification when a player hosting a games leaves the lobby, as WFGBot then doesn't know that that player isn't hosting a games anymore. We don't know why that happens sometimes, but it does and when it does it leaves behind such stale games. To avoid this problem going forward we added a filter to only show hosted games whose host is still online, which fixes this problem. Windows users not able to join anymore with TLS-encrypted connections Another problem which became visible was that Windows users weren't able to join the lobby anymore if they had TLS-encrypted connections enabled in the settings (which is the default and a good idea to have set). To explain why that happened I have to back up a bit. Core of the lobby is a protocol called XMPP. At its core XMPP is an extensible chat protocol. When you connect to the lobby using 0.A.D., it'll establish an XMPP-connection to an XMPP-server running as part of the lobby. Such connections can be unencrypted or encrypted with TLS. TLS is the encryption protocol also used when you visit websites whose protocol is HTTPS, like your beloved https://play0ad.com/. TLS is available in multiple versions. For historical reasons 0.A.D. up to Alpha 26 on Windows only works with TLS v1.0, which is deprecated nowadays and usually already disabled by default. Connecting to the lobby with TLS-encrypted connections didn't work for Windows users right after the migration, because the lobby XMPP-server didn't offer TLS v1.0 anymore, but only more recent TLS versions. However, the configuration of the XMPP-server was fine. What we missed during the migration of the lobby was to enable TLS v1.0 in OpenSSL, the library the XMPP-server uses for all the heavy-duty TLS-related work. Interestingly, even if we hadn't missed that it wouldn't have worked, because the configuration for OpenSSL required slightly different parameters than before thanks to it being a newer OpenSSL version. Nevertheless, this problem should have been surfaced during testing before the migration, but didn't because we simply forgot to test with Windows. The fix was once again straight-forward and just involved setting the correct OpenSSL configuration after we figured out what exactly the culprit was there. Going forward we'd love to disable such old TLS versions, but we'll have to wait with that until all recent 0.A.D. versions support newer TLS versions as well. Some Linux users not able to anymore with TLS-encrypted connections With login for Windows users fixed, we received reports from some Linux users not being able to connect to the lobby with TLS-encrypted connection enabled. Figuring out what was causing this took us a while, as it did work for the majority of Linux users, but not for all of them. The culprit in this case were the TLS-versions supported by the XMPP-server again, but this time not an old version was missing, but a new version causing problems in certain cases. As part of the migration we enabled the most recent TLS version TLS v1.3. This usually works without having to change clients, because only clients supporting such a version will use it. The client which didn't work correctly was gloox, which is the XMPP-client library used by 0.A.D. We don't know yet why it doesn't work, but it apparently doesn't. The interesting piece is why that was so difficult to track down. Contrary to Windows it's common with Linux that application don't contain all of their dependencies, but rely on them being provided by the operating system in one way or the other. The version of gloox adding support for TLS v1.3 got released less than 4 weeks ago and Linux distributions usually don't include software which got just released a few weeks ago. That's why the majority of Linux users had no problem, as the version of gloox they were using didn't support TLS v1.3. The affected users were mainly users which did install 0.A.D. as Flatpak application, as the Flatpak app for 0.A.D. included such a new version of gloox. Our workaround for this problem was to disable support for TLS v1.3 again on the lobby server, as that makes gloox and therefore 0.A.D. happy again. That's of course just a workaround, as we'd like to be able to offer support for TLS v1.3 in future as well, but to enable it again, we have to figure out why it's currently not working with gloox and get that fixed first. Conclusion As you can see preparing and carrying out the migration of the lobby was quite some effort and not without challenges. While most of the problems which appeared during the migration could've been avoided, that's always easy to say in hindsight. I'm personally very satisfied with the result of the migration though, as it's a great base for further improvements and the performance of the lobby is even better than before as well.

Have you tried renderactors = "false" in your user.cfg?