Leaderboard

From https://trac.wildfiregames.com/roadmap *Due date is for feature freeze, actual release might happen a month later. (Hopefully not) I did my best to advertise it a bit (on Discord mostly), but I can't post it on social media, because it's highly experimental.

I would assume they are much smarter about collision detection They probably have much more persistent data structures for collision detection in such a manner, because otherwise the game just wouldn't work. For example, they can probably first consider all formations (of which there are very few) to decide a new target to pick, where we must consider all individual units. Or another example: for the most part, they don't have to consider new units joining the battle (I think this may be somewhat different in TW WarHammer but it remains limited). That probably enables them to use some clever hacks that we can't so easily use. There is a lot of stuff happening in combat. If the target dies, UnitAI needs to choose a new target, which is by itself rather slow -> range query + filtering for preferred targets, sorting, etc. That's not even mentioning the fact that yes, dying by itself could be a bit slow. This is indeed an area of possible improvements, and some work has been done (e.g. rP25102) To be honest, the arrows range query could perhaps be improved by having some in-turn caching or some other logic to batch missile hits (so that multiple missiles landing in the same area don't do multiple range queries or something), but that doesn't sound entirely trivial to do without breaking in some edge-cases. It's always a question of code complexity, accuracy, edge-cases with these kind of optimisations. --- Edit: Also, while such "in a vacuum" performance profiling is useful when you're working to optimise a specific function, be careful about generalising. In an actual MP replay, you'll most likely see a much more nuanced picture.

You’re statements on attack group aren’t true. If you select a large area, attack group just makes you shoot father projectiles that are less likely to hit. If it also acts as a tower that randomly selects then that means that it will attack random units walking through the area that you probably don’t mean to target and are less likely to be hit because they’re moving. If attack group selects random units that you aim at until dead or at units that are nearest in that area then You will have to regularly re micro as that area will have units disappear and range units will go back to default attacks if nearest unit. Plus if you do attack group then new arriving units will need to be microed to attack group or they will just default to nearest units. This provides the benefit of being able to target ranged units in the back which is why this whole discussion exists so idk why you don’t think it provides player benefit and as I describe above it also requires regular micro and skill. I described these pros/cons in my initial comments on this thread. I believe those possibilities should be re-examined. The only person who spoke in opposition to that said they thought my proposal would be OP (despite no reason given for that) and that they preferred attack ground bc it would hit the footprint, which is obviously true but equally obvious that that would make attack ground only useful in the very limited situation where extreme chock points exist (which also probably creates balance issues that something like attack group with target of nearest unit doesn’t have a problem with) Not trying to say I told you so here, but attack ground has some very obvious deficiencies that makes it use extremely limited. And these deficiencies are severe enough to mean in the vast majority of situations on the vast majority of maps attack-ground won't address anyone's original concerns that led to this discussion, namely that range units overkill meat shields. If you want it, fine. But it is not something that excites me at all.

Obviously attack group is better than attack ground, i never doubted that. But do you really want to take away such skill/interaction from the game? It seems like you do, but honestly i don't and there are people on both sides. You say attack group requires micro and skill but i honestly doubt that in realtime, it would pretty much be a simple repaint of an area once in a while. There is pretty much no risk involved with attack group. There is no misusing attack group other than letting your ranged get eaten by swordsmen for example, which would be bad in all occassions, even without attack ground/group. Micro should give you an edge over your opponent, and attack group takes too much from it. You might aswell make it their standard attack behavior unless manually commanded otherwise. People who don't like micro will get balanced by elo tbh. Besides, units are clustered on the battlefield all the time, not just on choke points. A one time volley on a resizable circle attack ground would be a pretty useful thing to have imo, with the choice of a continious one with a combination of a hotkey (for all ranged units, just to be clear, not just archers). But with risk of misusing / poor judgement and without it being the new standard way to play. Attack ground will also give usefulness to formations whereas it wouldn't with attack group. Also attack group needs a heavier rebalance than attack ground but whether that's a problem or not depends on the balancing team.

FreeBSD provides alsoft, but without pulseaudio support. I have rebuilt alsoft from sources with pulseaudio support and 0ad runs now as expected. Thanks a lot. Best regards, JB

Hello everyone, We're happy to release the first testing bundle of 0 A.D. Alpha 26 (name to come). Keep in mind, this is not a 'Release Candidate' yet, and so some bugs are to be expected. We provide this in the hope of finding and squashing them efficiently. If you choose to test, please keep that in mind. Downloads - Current bundles are for SVN revision r26108 (See below for updated bundles) Linux data and build macOS Windows Snap build is available at latest/edge Things to note: Translations are not complete & may be buggy -> Play in English for now. Mind your mods -> they might introduce issues or Out Of Sync. Save your A25 config file somewhere, ideally. Changes: https://trac.wildfiregames.com/wiki/Alpha26 Points of attention: Acceleration Currently known issues: AI is slower to attack https://code.wildfiregames.com/D4391 Maurya palace triggers errors https://code.wildfiregames.com/D4392 Gui scale popup might close quickly https://code.wildfiregames.com/D4318 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 Update 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. Ideally, you should coordinate with the OOS players so that they upload their own OOS dump, so we can compare them. Things you may want to test (non-exhaustive) Launch a random game Launch a skirmish. Connect to the lobby Play on the lobby with someone Launch Atlas and try things out there Open Unit tests demo (To see if there any breakage in displaying entity's) (It's in scenarios) Enable feedback and see if it works (Main menu) Example video Connect to and use mod.io ( Try to download and install the linux libertine font) Test replaying new games Test Screenshots (F2) Test Big Screenshots (Maj+F2) Test hotkeys Test Saving and loading a game. Test Quickload/Quicksave And of course playing games.

Didn't know. Doesn't seem like too many people have played it. Honestly, I didn't realize we were so close to a26.

After acceleration/turn times. That is a major change that will be hard to assess if you add this too. Borg’s comment has merit. Otherwise, I would 100% say now.

Same

That's ok. No hard feelings or disrespect meant or anything.

Didn't say this at all. I said i doubt it. Attack group reduces the basic micro that's already there is what i'm saying. You honestly can't disagree with this. How is painting an area to target units more micro than invdividually selecting unit per unit with alt? If that's how you feel we might aswell stop discussing this further with eachother. Which is pretty much what i said. I said the thought process you discribed will come more naturally the better you get at the game.

I think it's an interesting feature but it's not the ideal time to implement it in my opinion.

@chrstgtrYou call it a simplification, i call what you do an overcomplication. Pretty much all elements you name are standard elements you need to take into account when playing the game and will come more naturally the better you get at the game. It's only made much easier because now you can attack groups. We don't have to agree though.

Zeus or Zarathustra would be my favorites.

The problem with the death part is the number of messages it generates. And all those messages need and are copied for the AI. Sometimes sending those messages can take more than 500ms per frame. See yesterday's discussion on #0ad-dev. https://irclogs.wildfiregames.com/%230ad-dev/2022-01-11-QuakeNet-%230ad-dev.log

Hello today, Today I've spotted a funny bug. If you assign a blacksmith and temple to a hotket (group), UI presents to you 2 trainable unit (while you have only 1 temple). Good news is when you click on Druid unit to be trained, it gets trained only from temple (1 unit)

Do individuals specifically get hit and die by arrows in total war? Never looked that closely to it. Otherwise it's probably just calculating the entire battalion as 1 hitbox and lets random soldiers die when the health drops of the battalion entity.

Question. So, in a Total War battle, you can also have 100s of arrows in a volley, but have less lag. What are they doing differently?

@wackyserious Here, another depictions of the same author more close to our timeline. Evidently they are about north-eastern Iberian warriors: "Battle between Iberian warriors and Roman legionaries (3rd century BC)"

Thanks, yeah, I figured I was just exploiting a bug The code example helped, I now know how to use modifiers directly from code, it's pretty cool.

Did you enable cheats?

Version 2.1 Giving all houses a garrison flag. Adding some camera options. Requires a restart Adding a sound when switching to the loading screen. @ffffffff audio_interface_ui_switchToLoadingPage.ogg @ISlan fixed it for version 2.1

Just had this idea, and I think it's good, so I wanted to share this... Current situation As you may know, the AI is currently designed to ultimately be run in an asynchronous manner, in the background, over possibly n turns. A reference is this interview of @quantumstate for example, but it's also quite obvious from the architecture. The Idea was that thus the AI wouldn't be blocking for the simulation even if it was slow. Based on the fact it currently runs once per 8 in-game turn (about 1.5 seconds in SP, about 4 seconds in MP), we can assume that this is a reasonable time-frame for such a threaded AI. To support this, the AI receives a copy of the simulation state, through AI Proxy components on most entities and AI Interface. Consequences This is nice in theory - I've never questioned it and I don't think anyone questioned it in the past few years. However it has several significant drawbacks: The AI wouldn't be able to be run more than once every n turns (n=8 right now). That makes it basically impossible-by-design to micro efficiently, for example. Note that our synchronous AI can, but that's not how it should work (and it doesn't leverage that). Copying the simulation state is slow. AIProxy listens to most messages, all entities have one. It can easily take up several ms per turn (in fact I had a diff for that which I didn't keep as it was kinda broken.). Copying the simulation state is error prone. We have to do it manually. Techs in particular were a real pain to handle. Mitigations for multiple AIs (the common-API) are a mess. Copying the simulation state is greedy and custom. If the AI wants new information, we have to add it to its state. If it doesn't care about some information that we've added, we've payed the price anyways. The above flaws are all fundamental to the design. The second and first can be mitigated, but at great cost, and only up to a point. Proposed Change The biggest change is simple conceptually: we run the AI synchronously. It fixes all the fundamental design flaws above: we can run it every turn if we want to. This fixes point 1. we no longer need a copy of the whole simulation state. This fixes points 2/3/4. The AI can call into the Engine directly (using QueryInterface or something similar) - in a read-only manner. This can be by setting a flag or by copying only that relevant bit of data it's asking for. If the AI remains in its own context, we can use structured clones. The problem of this design is that if the AI wants to do something slow (and it does sometimes), it will lag. There is a solution. We let the AI run specific computations asynchronously, over a specific number of turns, using an interface similar to worker threads. Then if the computation isn't done, we block, otherwise we return the result and process it synchronously and deterministically. For these computations only, we copy whatever state is necessary. What I hope this achieves A speed-up of several ms per turn on both SP and MP. A much simpler AI interface (basically no interface). Still the ability to run longer computations asynchronously.

hi, do you have this in game or in atlas? I remember props not being synchronized in atlas but would work in game.

Even simpler: don't show the civ in the diplomacy panel :p