wraitii

Personally would be fine with IRC, Matrix has been a little annoying every time I've used it - the web clients seems slow-ish, and I haven't taken the time to find a client I liked. I'm also only somewhat semi-active, and for work am now mostly on telegram (+ slack) so not really relevant. If Zulip is more lightweight than Matrix it would have my preference, but I think we aren't big enough that IRC is unworkable.

Massive congrats for getting this through the door @Itms ! And thanks to the efforts of all involved, especially @Stan`

Yeah that's what those are. I guess I just forgot to upload the tarball. I've done that now, should fix the link.

As an eternally sometimes active and sometimes burned out dev, I relate to the struggle. Thanks for all the years of leadership and support, thanks for all the events you attended, all the mods you carried and updated, and all the releases you shipped ! Enjoy the rest

Sure I think ModIO keeps past versions automatically, though from within 0 A.D. you won't get it

(Also noticed a similar error on Jebel Barka, didn't investigate more)

Seems like it's just not running. Presumably because you don't have the Developer role https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html#prerequisites Edit: ran them, looks like it fails 'cause the pipeline is broken. If people are OK with the changes I can merge them regardless

On topic, I do agree that Cappadocian is probably much better than nearestern, yes.

I think flavourful names do a few nice things: They're cooler, which is more memorable They highlight potentially important places in history (depending what we choose), which fits the historical vibe of the game. They make 0 A.D. less like a generic RTS. Contrast 'Arabia' on AoE 2 with 'Highlands' on AoE 1, despite it effectively nowadays having different biomes. Some names are more generic, I'll admit, but I don't see the harm in giving them cooler names. (Not that this is the thread topic...)

Yeah I think that's a good approach. The map selector might by default show specific biomes, or if you force 'random' just default names. I'm not 100% sure on the biome-map availability thing, it's a trickier issue to me. IMO you should be able to pick a map and get an expected RM experience, if the biome can completely change around to map in un-expected ways it's probably bad. However, knowing that there might be slightly less wood or it's configured slightly differently might be good. So it's kind of a case-by-case thing. Deep forest is probably a good example that having a Saharan / steppe option might just not work yes. I'm less sure about e.g. Oasis - conceptually that can work with any kind of biome, sorta.

There's degrees to this, our Corinthian Isthmus isn't a 1-1 match for the real thing either. Think we sorta agree on the 'biome changes map name' approach then. It's just that my default approach would probably be more to show interesting names (and thus maybe default biomes) than generic names in the map selection screen.

I vaguely remember this, but I think my argument was that this just doubles the map count for no real reason, right? And IIRC I disliked switching to generic names for random maps as I thought that was kinda boring. Wouldn't necessarily be against setting a 'default' biome for those maps that can be over-turned by players to 'random' however. Edit: or changing the map name based on biome tbh. I'd rather just avoid all our maps having generic, boring names by default in RM.

Hello everyone, This is an update on the progress of the Alpha 27 release. After extensive deliberation, the team has decided to abort the release process for the foreseeable future. As some of you know, we've been in a "feature freeze" for the past 3 months. This period, during which we halt all new code merging except for crucial bug fixes, is typically a final step before a release. Unfortunately, progress on the release has been slower than anticipated, and Alpha 27 is still several weeks away. Some of the outstanding issues include: Acquiring the necessary macOS certificates for signing the packages Completing the trailer for the announcement, and finishing the announcement itself More testing is potentially needed, and some important bug fixes are not yet merged. The balance of A27 has not been extensively tested and refined. The time it takes to actually release (uploading packages, informing maintainers, etc.) is potentially more than any of the team can commit to right now. Our current pace on these matters is unsustainable. Following a vote, we have chosen to abort the release and refocus. This decision wasn't made lightly, but we believe it's in the best interest of 0 A.D.'s long-term health. We will use this time to: Merge improvements that have been developed during the feature freeze, such as optimizations and further fixes. Identify and address the issues that have hindered the current release process, as we cannot hope to release in the future without fixing them. We will likely come back to the community with more information on this last point and potentially requests for help. We realize that this news may be disappointing. We thank you for your patience, understanding, and ongoing support. On behalf of everyone at Wildfire Games, Wraitii

In my experience, merging things in feature freeze delays the release as it introduces new bugs. I don't want to do it this time. Might make an exception for the password change feature as that seems like it could lift off quite a bit of weight on the lobby mod team & Stan by proxy.

Yeah the reason it's still not implemented is that it's much slower to compute some kind of proper distance than to assume euclidian / spherical cows. The UnitAI part is the part that's the same between the AI and a regular player, but the AI has the same problems. As far as I know the best solution for AI dev is to share things on the forum, and then we can consider actual patches in the future if it proves to be better. -- You should note that nowadays, you can implement your own cheats in the AI by giving it custom modifiers. It doesn't have to be just the resource gathering. You can also use LOS data nowadays, but IIRC that needs to be implemented in entity.js

Most likely these are turns during which a unit dies and all other units go in 'FindingNewTargets' mode, or some other event like that.

0 A.D. currently updates the simulation state every 200ms. This update usually takes 20-40ms, depending on the number of units doing things. This means even if you're running at 60 FPS graphically, when the sim is running, you'll get worse FPS, and worst you might get a lot of 'micro-freezes'. Furthermore, the 200 ms turn length gives high input lag which would be nice to shorten. I ran some quick experiments on Combat Demo Huge to see what changing the turn length would do to performance, and the results are somewhat more promising than I expected. First, what to expect: We should run fewer JS timers each simulation turn, as they will tend to hit on different frames. This should 'smooth' the framerate. Movement might be a little easier and smoother since we're going less far away (in practice, I'd need to update Pushing, it's too smooth) Things like 'range queries' shouldn't change too much, as we still run all of them every turn. Overall the FPS should be lower, as we compute more things, but also smoother, as we don't stop as long. Frames would go "16-16-30-16-16-30ms..." instead of "16-16-16-16-80-16-16-16-16-80ms..." The results are quite interesting. The 'smoothing' effect is rather convincing. I think if we adapted to not run all Range queries on all turns, and perhaps tweaked movement appropriately, it might be worth looking into running turns every 100ms for example. In the profiling runs below, Red is 350ms turns, green is 200ms (normal), dark-blue is 100ms and cyan is 50ms turns. Remember that the red curve is farther ahead in time at any given time.

The largest hurdle is the RangeManager, the LOS code only supports up to 14 players at most right now I believe. Until D3938 is merged, that can't easily be changed. I'm not sure which other components assume 8 players after that, probably territories ?

A few things that I'd say prevent 'beta', though I've argued differently in the past as well: No dedicated servers (and with it stuff like what Dunedan describes) Game Performance woes, and turn-length issues (200ms turns are not so acceptable these days I feel) Graphics performance - though the Vulcan rewrite will probably end up fixing that soon-ish No actual campaigns. AI still isn't great. However, these are only sorta relevant. The reason we're not in 'beta' is because the 'original vision' for 0 A.D. included a lot more features, including things like running units / charging / better formation & naval play which we have not been able to deliver on. We just don't have a good design for these within the current scope of the game. In the end, this isn't a race. This isn't a money-making project. It's a side-hobby for all of us. It moves slowly, it moves surely, and it'll likely get there (or computers will catch up...)

Good news and bad news about the future. As of Firefox 115, which will be the latest ESR soon, I can finally properly profile the game including JIT code. The only thing to do is compile spidermonkey with `enable-perf` and `--enable-jitspew` (I think), then run it form within https://github.com/mstange/samply like so: `IONPERF=func PERF_SPEW_DIR=. samply record -n --rate 10000 binaries/system/pyrogenesis -mod=public -autostart="random/continent" --autostart-ai="1:petra" -autostart-ai="2:petra" -autostart-nonvisual -autostart-seed=150` This gives you a full profile that you can then access on the firefox profiler, like so: https://share.firefox.dev/3IHH7ho (AI 1v1) There are some interesting overall insights: In this AI 1v1 75-80% of the time is spent in C++ code. But a lot of that time is calls from JS. As I have reported in the staff forums in the past, the main cost in the SimUpdate is `Timer Update` (about 15% of total time), split between ResourceGatherer, ProductionQueue, Builder, Attack, DelayedDamage. Most of the code appears to end up properly jitted. But the GCs 'dump' the JIT code regularly, which means we spend more time in baseline than we probably should. I have reported a bug about this, we'll see what happens: https://bugzilla.mozilla.org/show_bug.cgi?id=1834848 There is a fair amount of Spidermonkey overhead, though there are things we could improve. To take the Example of calling `Engine.QueryInterface`, the costs breakdown as follow: ToJSVal<IComponent*> is about 40-45%. This is largely because of D5004. The actual C++ QueryInterface is only 20%, which is slow because of std::map. But it's not the most major cost. Getting the ComponentManager pointer is 7% ScriptRequest enters the realm (for no reason), which accounts for about 10% total So as you can see there are a lot of things we could do to skip some time, but it's also going to be kinda hard. Some obvious things that show up and could probably be improved: Having a `Engine.QueryInterfaces()` function is probably interesting. Identity:Init() is slow because of splitting the identity classes. We can cache that in ParamNode directly I think. There are some regex constructions in loop which are slow, such as in MatchesClassList AI Interface and AI Proxy are fairly slow. The AI in general also seems poorly jitted, and that might have to do with how the objects are structured, hard to say. Modifiers are kinda costly, but we knew that. Now, right now we are still on ESR92, so this is some ways off, but I have compiled it on a local branch, and I think the results are rather interesting, and encouraging for the future.

It should be possible to completely disable by setting the 'radius' in pathfinder.xml to 0. But you'll also want to increase unit obstruction radius in that same file to something like '2' if you want no overlap at all. This will generally make pathfinding terrible though.

I'm fairly certain the range manager already does this in a way. The problem is that you do want to send _only_ the right units to JS, because doing further filtering in JS is super slow.

You should specify that on the merge requests as comments then, maybe we can clean them out

Created with the relevant requests right now. We are also interested by people coming forward to get the rights to merge requests on your own, as a reminder.

It's a bit difficult for me to know what should be merged here since there the forum discussion is long & not many people are voting on gitlab. How about I make a forum Poll with the different merge requests and people vote there directly ?