wraitii

I'm not sure we ever formally decided to migrate, but I guess 'reality ensued' The problem is that SVN is much better than git at handling binary files, and we have a lot of them. It'd need a fair amount of reorganisation to switch, and so far we haven't really found a strong justification to do so. Note however that development is mostly possible on git via the GitHub mirror, which is an improvement on what we had circa A23

Current plan is to have at least a tutorial campaign - hopefully something nice and scenarised. Depending on how things go, we may release a 'preview' of the next Alpha so that other people can work on creating their own campaign with a better tool than SVN, which might be difficult for some. ---- Edit: that being said, yes, don't expect 5 full fledged campaigns That will come one time

We probably should reset it a few weeks before release then, good point.

Made it multi-choice

Bumping now that campaign support has been merged. IMO your "0 A.D. interactions" section should come after Basic Economy ? I definitely need the tutorial campaign should be scenarised too, and not just a tutorial.

If you changed it once, it'll be remembered for your next game. This is _usually_ good, but sometimes lead to undesirable behaviour. If some map has pre-defined teams, it'll also change the team settings, so it can happen without noticing.

Hm, indeed, but for whatever reason it seems to be specifically attackMoveUnit. Queuing a regular attack move works... I'll need to investigate this more.

K, well it'd be great if you could upload the replays next time that happens, because so far the only somewhat related issue we have documented is #6046, but that's actually too many orders, not the reverse

Do you use the default formation feature (or formations in general)? It's the one thing I could see interplaying badly in some situations.

If units are in formation, queuing non-formation orders is a bit wonky. It should work if your units are not part of a formation, though. Can you specify what you're doing exactly? Or if you're up for it, provide a replay, which are at "~/Library/Application Support/0ad/replays/0.0.24"

It'd be good if you could get a more consistent description because it sounds _very_ broken, but we've not really had reports of anything like that except from you as far as I recall. Maybe try playing and recording your screen/input? Ah, yeah, that problem. Indeed that will trigger H if you drop space before H. TBH this is really my fault, I did not anticipate that this would be a problem, and I guess I'm lucky in that I don't personally experience it using control groups (I guess I naturally drop the # first). I'll fix it for A25, but in the meantime the best advice I can give you is to avoid conflicting/ambigous hotkeys or train your brain to drop the letter first. The reason why I changed this was that there was unexpected behaviour in A23: for example if you pressed Ctrl, then D, then 'Ctrl' hotkeys remained active, but his did not happen if you went "D then Ctrl". There were a number of related oddities. Unfortunately in fixing that I assumed that 'retriggering' hotkeys when releasing a key was the most logical behaviour, when it probably would have been better to not do that.

Can you clarify? We didn't change anything in terms of command delay, so I don't understand why you experience 'slower' visual feedback on A24. Can you also explain this further? Those are arguably usability improvements: you double-click to select all houses, it selects all houses. IIRC triple-click will select only the same entity. I'm not sure if that's a hotkey or if you'll have to mod it to change the behaviour. Maybe we could add another option for this, but I would call that a https://xkcd.com/1172/ issue. You write 'fixed' but issues will actually be fixed, I don't know why you'd assume that we'll just pretend to fix things.

I had a diff to make use 'field hospitals' in the long lost past. The big problem with 'healing' is that wounded units should really lose fighting capability for it to make sense. At that point, the whole RTS abstraction we're using breaks down.

I would disagree with that statement. This thread is about adding nice animations when the blacksmith is doing something, which is cool. The impact on player knowledge is next to none since you have the global search bar already. I don't see a reason why it must be added to all buildings either. @Stan` I vote you activate this.

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

Yeah, I agree that we need more, smaller metal mines. I think it also overvalues grabbing territory solely for metal, which is odd.

Yes the difference is that units look near the resource they were gathering and not near their own position when the original resource is depleted. This does lead to the issues you've noted. This change was introduced somewhat by accident a little over 2 years ago, to fix a much larger bug (introduced by unrelated changes), and basically (though I did notice the behaviour like 1.5 years later) neither I nor other people thought necessary to change it for A24. In hindsight, it's probably annoying enough that it should have happened. All I can say is "shame". It adds a bit of micro to the economy, but to be honest I don't think it's _horrible_ in the early game, you have nothing else to do, and then later on you can plot storehouses as needed. Regardless, it'll definitely be fixed in A25.

The fact is that it's possible to dance with infantry too, using fancier methods. That being said, there was a lot of disagreement and debate about turn rates, as the dev that originally proposed this change wanted even slower values. You might noticed that cavalry turn rate _is_ lower than infantry turn rate, though heroes haven't been particularly singled out. I think we might increase global turn rates slightly, but there might be other changes in A25 that make these concerns irrelevant. ---- Edit: and to be clear, from my personal perspective, I would prefer higher turn rates overall. I did grow accustomed to them after a bit, but I'd rather have found another solution to fix Dancing. The problem is after months of brainstorming and so on, we have not found a better solution : /

You must be aware wrong, because they all lost 100 resources 50F50W for archer/Jav and 50F/30W/20S for slingers.

The rams auto-targeted the tower near the houses, it seems, and then since there was no path there, went to the 'closest reachable point", i.e. the corner. The thing is that since they fail to move, they should switch to another target... But that new target is again the tower . Yeah, bit of an edge case here. It's fixable, but has performance implications, so not sure we'll do it now.

That's correct, IP should only be revealed if the correct password was entered. Note that I think for the DDOS described earlier, only the IP needed to be known, so if you IP didn't change it's still possible you'd get DDoS-ed in principle : /

I did some profiling and I found it inconclusive. Jumping from SM45->78 meant we paid the price of the Spectre fault which means that equivalent speed is good IMO. The improvement in SM91 is theoretical at this point, but in principle Warp should make things faster. At this point in JS I have identified a bunch of slow code: - Gathering can take a lot of time (mostly because ai AIProxy messages) - Finding new targets is slow / combat in general - Researching something is generally slow (modification messages are sent) - Changing ownership / Renaming / Diplomacy updates are all quite slow.

I mean we already have an auto build for windows and people don't play, yet all you have to do is redownload svn if you don't want to deal with anything That being said, I do think it would be a good thing to get more play testing, more regularly. Maybe not at the start of a new release cycle though - we want people to play the last alpha to see how it works/find meta, and we want to merge stuff then that might need some more feature work. But when things are starting to be different we could definitely release 'previews' to the next alpha.

To actually run the cinematic, you'll need to trigger the cinematic. You can look at the cinema demo triggers on how to do that.

Unfortunately, that's likely to be basically week 1. I am trying to think of a good solution, but it's not that easy, because there will be engine changes as well. If we were to release a bundle per week or 2 week, you'd have a high change of bug/OOS complicating the balancing test. It might still be worthwhile, but we'd definitely need an auto-updated of sorts. I do feel a mod to track A25 changes would be more appropriate, but it'd definitely have to be custom-made for A24, and hope that engine changes don't completely change gameplay. --- The problem is that fundamentally, the game is still an alpha in development, and to an extent perfect balance cannot be achieved, or it will prevent some changes for good. Every alpha will feel different, and likely will be unbalanced in some way. There is a simple truth at play here: the 'dev team' is different people, and these people work towards different things. I'm really not certain where you picked that up from, but I believe the replies you got say one thing: all opinions matter, but where they are expressed matters most. Again, I will remind you that 'the dev team' isn't 50 people working full time. At the present, it's basically 5 people working a few days per week and mostly after their actual work. We just don't have the time to listen to every feedback everywhere. If you want to contribute to balancing, you have to make a bigger effort than "I dropped some comments in the lobby", unfortunately (talking about the lobby in particular, I don't think we have lobby logs, which is something maybe we should improve). And it will be.