wraitii

You're really not addressing my point. The technical side is trivial to an extent. The fact is that the gameplay would change, and that's not a good player experience. Changing the revision while joining a game, so you don't even know what you're playing? Absurd. That being said, including an easy way to auto-update, even with semi-regular releases, is likely a good idea. Whether it should be a priority, I'm not so sure. We'll take patches, should they be sufficiently well written.

I'm not convinced that we need to, or indeed should, switch to a "continuous release" model, to be honest. Yes, it has pros, namely more testing more often, but it'll make the game both less buggy and less stable. Further, for players, continuous balance changes won't be very good. There are advantages to periodic release - 'marketing', things like that. 'Real' companies do a bit of both, but video games that I know tend to work with semi-regular "patches", not actual continuous releasing. There's likely a good reason for that. It would also be rougher on modders, who would need to maintain their mod continuously to avoid issues (though of course, it somewhat makes it easier). I believe shorter release cycles (4-6 months) with an "svn" alongside, is overall a rather good model.

Ah so you mean in the file they are frequency=1, and overwriting it with frequency=0 doesn't work ?

What do you mean?

More like x50-x1000, truthfully. In terms of "Full Time Equivalent", I would wager 0 A.D. averages under one FTE/day. Forgotten Empires, the makers of Age2, are 51 people at the moment. I'd wager the team making Age 4 is even larger. The gap isn't large, the gap is huge. Two decades, in fact

Unfortunately 10.11 and before are no longer supported. Indeed, the reason is that the older SDL2 version was bugged on 10.12+, so we had to upgrade, but that upgrade meant we could no longer support 10.11 and earlier. We had to make a choice, and 10.12 being released in 2016 it seemed fair to upgrade. Your iMac should support newer versions of MacOS, so I would suggest you upgrade unless you have very good reasons not to (which you may). The build instructions are yet to be updated entirely, since the release isn't out yet.

I created #5970 for that. No promise whatsoever that it will be worked on for A25, but it seems like it would be useful for campaigns, which are aimed for A25, so maybe.

Oh man you're right, thanks for investigating further. So having units in formation, ordering them to go somewhere in formation then shift-clicking to gather works, but giving 2 separate movement orders first doesn't. In that case, the gather order is lost. I totally missed that when 'implementing' queued orders for formations (which didn't work _at all_ in A23)

Yeah you ordered it to go somewhere unreachable and it took a few turns to realise it was indeed unreachable. Compared to A23, units will probably lose a little more time, but you'll also have fewer cases of units that fail to reach points that were actually passable. It's a tradeoff and for A24 it's in favour of 'correctness' over 'efficiency'. That's an unlucky situation, but it's not new, it could also happen in A23 and even earlier. Pretty rare that it happens with 2 moving units, and unfortunately not a _lot_ that can be done until unit pushing is introduced.

The bonus was changed. The main change is that rotation takes time - this makes unit movement less fluid. The unitMotion rewrite has changed things on the surface but I doubt it'd be very noticeable. Then formations-by-default has changed movement further, but that IMO increases fluidity. The primary objective was to make 'dancing' much, much harder (which we've succeeded at).

We did a few changes for general sanity that probably explain this, indeed. I think the A23 behaviour ought to be considered buggy in general, to be honest - a catapult needs time to re-aim, arguably even a javelineer. I agree with fixing the case where it's the same entity being targeted, though.

Yeah there's no debounce on that. I didn't really want to fix it before I merged further gameosetup work, but you're right that it might be worth doing. Should be easy. That's a result of switching to a list to fix the lag-on-append issue. Not fixing for A24 imo. Had to choose to show Stables while the minimal resolution we support is 1024x768. @vladislavbelovneed stats That legit sounds impossible. I'm quite curious. There's a few things (such as some tech research, or diplomacy changes) that can hang. Pathfinder also can trigger lag spikes. The game will usually show horrible FPS in those situations because of how it's counted. Curious about 5/8/9

Hm, can you post the commands.txt to go alongside those? Seems like an issue with formation units

Hello I think the atlas source code simply isn't picked up in the translation files, so it's not actually translatable/translated. That sounds quite fixable indeed. We'll certainly take patches regardless

It would, but at "normal" camera orientation and FOV there's really not much we can hide. Level of Detail would help, but it's work. Patches welcome ™ This we need to for HD displays and 4K. I think we could do it now, just again, needs work. That I believe would be somewhat straightforward to do & is definitely desirable. Last resort I think. Unit pushing (D1440) does something like that in a saner manner, but it needs a lot more work to be mergeable.

Some work went into A24 - you might have seen that we now have FXAA/MSAA options. Some more work will likely go into A25, further improving capabilities and/or performance. At this time, nothing can really be promised

This is what it should do right now, but SDL2 doesn't have perfect translation and it fails for some keys, unfortunately. I think we'll have to manually patch a few cases, but that seemed trickier.

It is, it's a new change for A24 which makes the default hotkeys work for keyboard layouts out to the box. If you use the hotkey editor, it's actually saving the 'position' of the key you're entering, not the key itself if you change layouts the hotkeys remain in the same spot.

Don't worry about it. It's true that pathfinding is slow, so it's not like it's not a problem either, just don't expect that it'll fix everything, yes . It is probably the #1 cause of lag, but removing it doesn't mean you'd get 60 FPS either in the end-game, is all. We're excited about the release too, it's been a while, and it's setting us up to make A25 really cool too!

This isn't actually that true, though it's an extremely persistent myth. The lag in the late game is, indeed, in part caused by pathfinding, but other areas of the game also largely contribute to it, such as simply updating gatherers, checking if new enemies have entered Line of Sight, running the JS Garbage Collector, etc. Basically, threading the pathfinder will _not_ entirely fix lag with many hundreds of units. We have more work to do for that. It remains a problem, and had likely improved relatively little for A24 - there have been some optimisations, and also a few things which are perhaps slower. There is however, one thing that could help pathfinding: units now move in formation by default, and that helps. I think part of it is also that the 500ms turns in MultiPlayer make the game look more laggy than it really is (something I aim to try and change for A25 too). Overall, no, don't expect much improvement for A24, unfortunately. We're targeting threading the pathfinder for A25, which will help some. The renderer is also being worked on, and that will help FPS indirectly.

Well, you would rather obviously see if they've got new fancy armour or not

You might not take a fight, basically, because in equal numbers you'll get beaten, so you retreat instead. Now in 0 A.D. proper, at the moment, this is maybe not so relevant because numbers probably matter more, but it could be. ---- A second component to this is to show contextual stats. You have units selected, you hover a tree, you should be able to see the gather rate (possibly via a toggle/option). This will teach player a lot of important data in an easy to discover, intuitive manner.

I don't disagree, but it's more complicated to implement . As for the resolution, this is just what we support right now. I haven't seen stats lately on what our users are doing, so I'm going with that for the time being. That being said, I think we could afford to enlarge the centre panel based on resolution, to fit more things. Assuming that people read tutorials is not necessarily a good idea, unfortunately. This also eases in players that come from Age of Empires, which we might want to consider since Age 2 is absolutely thriving right now. Except that this lets you check quickly if your opponent has researched technologies, which you probably want to know. Further, it will make it possible to have tooltips on attacks / armour specifically, which probably will make them more readable. Overall, I think the current strategy takes too much space for what it does. Either we basically remove everything, because what's the point (even health bars are already on the map itself, and the icon / names are completely dispensable, all in all), or we try to show some more stuff. I draw inspiration from other games, because I haven't really done the research, and they have, and for example Age of Empires 3, for its Definitive Edition, removed the 'click to see stats' interface and just put them on the unit directly: https://static.ageofempires.com/aoe/wp-content/uploads/2020/10/Definitive_100_Musketeer-2048x1152.jpg Overall, I would like to go for easier modulability, more flexibility with perhaps options.

I'm not sure what component you're referring to here? Those are all center-to-center, because, respectively: - healing range is handled in unitAI - territory influence is handled in its own component doings its own thing - I believe it's centre-distance. - vision range is LOS, which is handled center-to-center, hence the 'popping' of structures when exploring. The problem is that large units might not open the gates (they'd have to be very large, but not unfathomably so). I prefer to keep it consistent for those with edge-to-edge. In practice, this remains a "circle around the obstruction", so this just accounts for possible visitor-size, it doesn't really change the range. And for once, making it larger/smaller depending on gate-size is probably a good thing.

Yes, that's one big potential issue: how to handle multiple attacks? I guess in 0 A.D. proper it's unlikely to be a very large problem (we'll probably have most units have just one attack). (and yeah icons are obviously placeholders to an extent) The problem with that is that you don't really have room for the capture bar and the resource bar (or at least not all three bars), and several of our unit names are quite long, and simply wouldn't fit. One problem is that our minimum supported resolution is 1024 × 768, which doesn't really leave much more room. The UI is already big at those scales. I am considering moving the commands to another panel for wider screens, e.g. maybe to the right of the buildings, where you don't risk misclicking them so much. I think they should remain (possibly optionally) visible though, because beginners won't necessarily know about them. Yes, but there is debate regarding what a "key number" is and isn't. I think we could also make it an option. My approach above is a trade-off, it shows _something_ instead of nothing (Armour in particular is important, because HP really isn't the end of the story). I think there is an argument to make that this acts as a tutorial: it shows new players what information is important. Those that care can always look into the details. Further, this will help us declutter the tooltips, possibly making it easier to read the relevant information when you need.