wraitii

The large drawback is that we'll have to rewrite a lot of the code . Other drawbacks include that we'll still pay some 'synchronous' AI cost every turn, where a perfectly asynchronous AI would not. It's micro-vs-speed basically, the there is a large speed disadvantage to copying the sim state, so as I expand on above - could work out. An alternative would be doing something like the gRPC diff on Phabricator, where we allow external AIs to plug-in the sim-state. Same architecture but slightly different realisation.

Agreed. Pikemen and such, when gathering, aren't supposed to be burdened by their heavy armour anyways (since we show them not having it), so their regular walk speed should be basically identical. Only when in special 'formation' mode should they possibly be slower. Champions are a different deal.

At some point we need configuration files to specify what to show directly, what to show in the tooltips, what to show in the Structure Tree.

Yeah we need to rework the tooltips for sure. Adding some grid-like structure would definitely help a ton with readability, but the flexibility of the game's system make that difficult to get right. I think one thing we should do is take more vertical space, so that items are better separated, and then you can find the same info on the same vertical line. You might also note that HP is actually redundant with armour somewhat, since having more armour = having more HP for that attack type. One should find a few different cases for tooltips that are different and try and work something out that works OK for the general case.

I have this idea, that I should flesh out in a mod, of having civilisations "Tiers", and only trying to balance inside intra-tier, not extra-tier. That would allow for more diversity imo, while still allowing balanced gameplay.

With the phenotype system, we could have lefties and righties (probably not the best use of the system though)

To be honest SVN doesn't really work that way right now + we don't really have spear-specific upgrades. This is just a good example of how your mod handles things differently.

Another breaking change: rP22824 See commit message (or diff) for the changes.

I did indeed - have to say I completely forgot to test techs on this diff (see 'missed an edge case' in the OP :p )... Broke all armour/attack techs pretty much I'll fix it tonight or tomorrow depending on time I have.

This SVN or your mod? The incorrect animation based on position is not something I recall seeing in svn but I can't say I've tested this code a huge amount.

Hello everyone, This to inform modders of a breaking change in templates following https://code.wildfiregames.com/rP22754. Capture previously looked: <Capture> <Value>5</Value> ...[Other Stuff]... </Capture> You need to change "Value" into "Capture". The reason for this is that you may now use the "Damage", "Capture", and "GiveStatus" nodes in any place where you could previously use Damage. For example, you can now have capturing splash damage, or both a Capture and a Damage node in the same attack. "Capture" is no longer hardcoded to be the only attack type that can capture. This change also affects many simulation components, so feel free to ask questions about those if needed. Let me know if anything looks odd, as again, this changed many component files and there's a chance I've missed an edge case. Please note that tooltip support is not yet committed, this will be a WIP in the upcoming days.

I'm working on some trigger-bound maps to test performance of some stuffs... Some interesting results. In particular, creating a new entity is somewhat slow (200µs), so creating dozens of entities per turn can be a noticeable slowdown. The main culprits seem to be Identity and ResourceGatherer, which do caching on Init. In general it appears JS components are a bit slower than C++, which is to be expected. Not sure if anything can be done about that though.

OK so it does seem like you are running from the Applications folder. Could you open a Finder window, press "cmd + ctrl + shift" simultaneously, then go to "~/Library/Application Support/0ad/" (see screenshot, in French but ought to be the same interface) Then press "cmd + i" simultaneously, and screenshot the window that opens? It should look something like this: (NB: to screenshot, press "cmd + shift + 4", then press space once, and you just click on the window you want to screenshot).

This sounds vaguely like a permission problem. What folder are you running 0 A.D in?

Those should just be the Idle animation of the "Gather Food" variant. But perhaps Atlas doesn't have great support for that. TBH we're pretty close to hitting some hard limit in the customisability of our actor file there, so we'll probably have to think of a better way to do this soon-ish : /

I believe that's because I changed the actor format in a breaking way but didn't really communicate on it. See https://code.wildfiregames.com/rP22442 You now must use animation variants and the regular Walk/Idle formations instead of walk_testudo_front animations.

@Alexandermb Yes there's been changes recently. That you need to be aware of: Formations now use animation variants, and the regular "Idle", "Walk", "Run" animations. So you need to setup your actors to have a regular variant group with idle/walk/run animations, and a formation-special variant. Also, while remaining in formation units will IDLE in formation-animation, but when that formation breaks (for whatever reason), they will revert to their usual animation. I believe there's still a few issues, but tbh the current code needs some streamlining before we fix these. Check out my changes to the testudo formation actors.

Ah man these look insane

Yeah, I was never quite happy with them There's that and ship trails, and a few related effects that we should have, but I think it needs a rethinking of how we handle the water a bit.

Sounds a lot like https://code.wildfiregames.com/D1955

Quick and dirty screenshot from an MP 4v4 at the 16th minute. This shows: - short requests computation (red) taking 50-90 ms per turn, with the odd peak above - long path requests taking about 20ms - Active queries taking 20-30ms per turn - Sim update (excluding active queries) taking 30-40ms per turn - Motion update taking about 30-40ms per turn. So threading the pathfinder and having unit pushing (which will reduce # of short requests) will help, but it won't be completely smooth sailing.

@gameboy I can't reproduce your errors with the patch either.

Hey ethanray94, welcome to the forums. Work has been started on supporting campaigns (https://code.wildfiregames.com/D11), but so far nothing is actually done. I would not expect it for the next alpha, perhaps the one after that. Rest assured however that it is one of the features the team has in mind for the game, well all love a good campaign

You can use the patch from D2041 (no compilation needed) and check if it stilll happens - it should not

I think you're running in infinite loops (because the rest of the gam has been fixed enough to be playable). We have a ticket for that: #5460. I can't actually reproduce a crash with your commands.txt though gameboy