wraitii

This has been fixed, thanks for your patience. The remaining issues are going to be fixed also over the next few days and weeks, see https://github.com/wraitii/0ad/tree/D13_outtakes for an up-to-date view of upstream changes.

There's a mistake... I incorrectly assumed that we would always have a herd position set if I set it in Order.Gather, but that might not be true. Reproduction needs multiple units that gather from one resource, and doesn't always happen. I'll fix that tonight.

This isometric effect is _really_ trippy.

Hey @gameboy This will be fixed soon. @wowgetoffyourcellphone is right that it's related to deers and elephants. However, you might notice after the latest auto build that deers are working correctly now (haven't checked elephants but they should be too). I still need to commit some things before whales work correctly again. Thanks for your patience

Hey Gameboy, thanks for reporting this. This is expected, D1969, D1982 and D1983 are required for whales to correctly swim again.

Ah yes that's my bad, I did a simple change to the diff this morning that should have been completely straightforward, and I botched it and didn't re-test... Will be fixed tonight.

This is with preferglsl set to false?

There is a fix for that at https://code.wildfiregames.com/D2018.

I'm gonna answer the super late as I've just been through this thread: maybe.I appear to have some code to make sky reflections a bit less prominent, but didn't use it for local reflections. Indeed as nani said objects are renderer without shadows, so they're shaded but not shadowed, which might make them too bright in forest situations. Adding shadows would be even slower though, and probably not doable for now.

Some interesting insight into what we can improve too. What's a "worker" for example. It's not obvious which units can gather. How to garrison? Things like that.

The easy way is to make it so that the first to start repairing is the only one who can until all repairers are killed.

I believe the intent is that archers hit units even if they're inaccurate - they're basically supposed to be long-range artillery. Probably doesn't work in practice though...

During AoE2's design they considered allowing capturing. The way it worked was that building below 25% HP would become disabled, and repairing them above 50% would make them yours. I've come to think, over time, that this is a strictly better design than ours. The question is whether the player meant that to happen. All orders from the player are forced, with I believe no way to un-force them. Perhaps we should only mark them forced on double-clicking, not single clicking. In the heat of a battle, if you order a catapult to attack one unit from a group, you probably aren't expecting it to chase that unit.

@Boudica What stance does this happen in? Default stance for siege units is Stand Ground, which sounds like it shouldn't exhibit this behaviour - if it does, it should be fixed. The way I understand it, there are a few things at play: Catapults auto-unpack if on "aggressive/defensive/standground" and units come in-range. That does sound wrong on most states to me. Cancelling packing/unpacking at 90% progress is instant ( @Boudica you would prefer that it takes as much time to go 0-90 and 90-0 I understand?) Catapults try following their target when it gets out of range, i.e. automatically packing and then trying to move This sounds broken to me in all cases, even for forced orders. We could do it only for forced orders, never on its own for unforced orders. Regular stances are not sufficient for catapults No way to tell them to prefer units or buildings Agressive/defensive/flee/standground isn't very helpful with regards to packing - unpacking. Is this complete? Points 1-3 seem like unitAI issues that we could fix for A24 - depending on what happens exactly. Point 4 is probably something we should do but it would be harder. Point 2 is doable also, but would be a change of behaviour - not sure if we want that or not, as @Feldfeld has said, AoE 2 has immediate-cancelling.

Hey @gameboy I am working on these issues, and uploading diffs regularly. They will be fixed, don't worry. Thanks for reporting them anyways

The goal is to: Make unitMotion easier to change, more consistent, and fix some bugs (such as the long-standing bug that units were gliding at the end of their path, which is now fixed). Make UnitAI, its counterpart, also more consistent Thread the pathfinder Formations aren't really changed - I think the pathing might benefit from a little cleanup after all this.

There is a need to be able to differentiate berry trees from other trees, though These trees look incredible guys.

I've updated the first post with a more detailed proposal, including a possible grouping of civs.

https://code.wildfiregames.com/D1926 would help with running the game on really slow machines I guess.

It could be done, but it would be so tricky and fragile that I don't think it's worth it. Really we just need to upgrade our animation system to support interpolating animations, I think. Anyways, https://code.wildfiregames.com/D1987 will make the chasing/fleeing act like on A23 even without D1970. The point of D1970 is that you also don't need to run behind the fleeing-unit to catch it - something I dislike and also wanted to remove, but it seems I forgot to do it in the original patch.

I meant equal speed - I don't see how the attacker could catch up then. Maybe that just didn't happen that often. Well my change makes unit flee not so far away. I guess you're right that they're kind of equivalent overall. How well should our units flee is a good question. We could make women just go and garrison when they're attacked if we wanted to reduce micromanagements. On paper it works like that, but attack speed and walk speed would be synchronised (since we can only have one animation at a time). So that wouldn't look too good unless we were super careful :/

That only worked if the chasing unit was faster though, didn't it? I think the chasing might still not go through this 'in distance' check enough though, that's probably fixable in unitAI rather. That would be the new behaviour. It's similar to AoE2 - makes it a bit more micro-managey, but it reduces the issue you describe below. I guess I see that as _very_ clunky, not "a bit". Very out of scope. We need far better animation support to really make this work. Edit: we could do it for riders with turretts, but for infantry... It could mean making the top-part of the unit a turret of the legs, right now... Which is at best weird. I haven't really played a proper game in forever - never really did to be honest. I used to just watch the AI play. I regularly do test runs, but given that I'm very rarely on clean svn, I don't really have a great feeling for svn behaviour. On this topic, I would have described it as you do, but since I did have doubts I prefer to ask those that know better.

I think that's fixed with D1969. That's not bugged actually... That's just 0 A.D. 's correct behaviour. I'm not sure how svn used to behave there though. D1970 fixes this issue for good by changing how fleeing works. Noticed that, needs to be fixed in unitAI, should be trivial. Likewise I think D1969 fixes that. -- BTW the animal roaming issue is fixed in D1980.

Thanks for the report, this is fixed by https://code.wildfiregames.com/D1975.

Testing it on everything is interesting