wraitii

Pausing the game mutes the sounds & ambient sounds, but not the music. Are you referring to 'background pause' here?

This is a classic example of a shadow bias problem. It shouldn't be particularly new, can you verify that this only happens following a recent commit? Edit: Vladislav confirms an issue -> D3457

This didn't get fixed by updating the Player.js code?

Hello everyone, For the purposes of helping me review patches for Alpha 24 (coming soon!), I made a quick mod to get an easy "macro" view of templates and try a few things out. My intention is that this mod should be compatible with most other mods, not just 0 A.D. itself, even most total conversion mods. I'm releasing it publicly, it'll soon be on mod.IO and it's on GitHub: https://github.com/wraitii/balance_test_mod See the wiki over there for some more documentation. I'll probably keep adding a few more features until I'm happy, and intend to maintain this somewhat since we don't really have a better tool. Here's a screenshot of the "good stuff":

I've merged the above patch. You can now turn the default formation off, put units in formation, and they will leave the formation if any order but "walk" and "patrol" is given. I'm unsure at this point if I should change the default configuration for "default formation", since it is only used for walk & patrol (e.g. attack-walk moves units individually). I haven't done so in rP24703.

@wowgetoffyourcellphone: you need to update your Player.js overwrite, you have no "Deserialize" function and it throws an exception now. Edit: your save games are also broken because of the same issue btw

Hm, this should be fixed since https://code.wildfiregames.com/rP24675. The solution is to remove the "unused" in your config file and set them to = ""

As written in the commit message, the Library is now supposed to be exclusive to Ptolemies. However I missed the thracian sword mercenary could build it.

I've made a diff that introduces a "hybrid" behaviour : https://code.wildfiregames.com/D3413 In this case you can have no default formation, but also force "no formation" on gather/attack orders.

Hmm, the argument that it's foiled by small spaces is certainly convincing, as the formations use a large pathfinder class. I think a 'simple' solution to improve behaviour would be to have the 'auto-remove formation' feature on, but not the 'auto-activate formations'. So you could put units in formation and then attacking would take them out of formation automatically, but walking wouldn't. Edit -> good point by Freagarach that attack-walk will not behave as it used to, which is probably a problem.

No, we're just single-threading really. The problem I was describing is that e.g. unit Motion can right now send messages to any other component, there's no "barriers". Essentially at the moment the only things we can really thread from the rest of the game are (NB: they are not threaded yet) - The range queries, which have their own data (but they need some clever thread pooling, starting a thread every time would be too slow) - the pathfinder, which also has its own data - AIs Yeah that's a know issue. The problem is that pathfinding is slow enough that fixing it properly was not really attainable in the past. Once the pathfinder is threaded, it'll probably be more doable. The visual field (LOS/Fog Of War) is computed per player, but AIs don't use it. The problem is that AIs are designed for threading, and that requires giving them their copy of the data, and we never got around to giving them their copy of LOS data. --- Most of the problems are known, but need a lot of rather substantial work usually. You're welcome to help

I think the main area in the simulation where memory fragmentation matters is the Sim components. Right now they're basically random, and we can do much better. Threading in general isn't that easy because the game's architecture assumes that everything can be modified mostly at any time. There are a few things that don't (namely the pathfinder is 'easily' threadable), but most things are.

While this is true, I'd like to point out that: - In MP, it makes more civs viable, meaning this actually increases diversity. - Our civs were never _that_ different to begin with.

Well, true-ish. The AI is actually not that great if you're a somewhat experienced competitive RTS player, but there's a big difference between the 'competitive' RTS play and the more relaxed style of play you seem to enjoy, and we ought to support both equally I believe you can 'cheese' the AI somewhat with towers and walls, if that helps. We should probably look at reducing the AI's effectiveness for the next Alpha, though, I agree, as this is a rather recurrent problem.

Yes we've decided that we'd merge the campaign patch for A25, but soon after A24 is released. We felt it didn't make much sense to have a campaign patch without campaigns.

Overall I think the main problem is that the AI snowballs better than beginner players, whatever happens. It collects half as fast, but it can easily get twice as many units. One interesting thing would be to limit the AI pop to a % of the Player's pop at lower levels.

I'm pretty sure I wrote a patch for that earlier in this thread, or perhaps in another thread. IMO it's definitely a better way forward. Show information that's relevant contextually, not just 'show information'.

That I could agree with. I don't think 0 A.D. at the moment makes enough of a difference that it actually matters. There is a way to fix this with the setup we have, by giving different priorities to different sources, but it needs to be implemented. Given that it was a bug of the Health component however, I think these techs might have no difference between A23 and A24.

This is actually somewhat inaccurate, the order is: Template values Global (techs/global auras/other modifiers such cheats) If any 'replace' is present, it is picked. If multiple 'replace' are present, a random one is chosen. Otherwise, X * mult + additions. Note that the replace behaviour isn't changed from A23. Local modifiers & auras The main difference is that global auras now multiply and add alongside techs, instead of on top of them. I don't think this is obviously better or worse. In practice, since most auras are local, there should be limited difference with A23. It was buggy, and it's not even that it's not possible to revert to it but simply not desirable. I would legitimately disagree with you that modifiers, in general, should depend on the creator's civ. Cheat modifiers, for example, are obviously tied to a player. Techs are a bit of an annoying in-between where, for some of them, they're more like "stuff that should replace template values", and for others, they're more tied to the owner's civilisations. E.g. a better spear-point is probably something that should be carried over on capture, but better training is arguable, and stuff like higher gather rate is probably not carried-over. You focus on structure HP but that's actually about the only place where the A23 bug could be noticed, and to be honest I don't think it's that much of an issue, it's a pretty minor thing all in all. In my opinion, the current situation is very satisfactory. That being said, I agree that it would be nice to make "carry-over" techs possible, but that requires more thinking. This seems like a straightforward template fix. My take is that we went from a straight up bad situation (attacks being broken is horrible) to a not-great situation (ranges varying so much by building obstruction sizes isn't awesome). That being said, I think it's not such a huge concern: areas aren't a perfect metric either, because units are discrete things and you can't really "fill" an aura range with units, it's not how things work. So, I would argue, for most cases, the distance remains rather relevant since it's what will matter for "how long until unit X is in range of Y", and for battlefield tactics I also think you'll find the actual advantage not as big as the maths say. -- In my opinion, though I acknowledge the concerns, none of what you raise here are large enough issues that they must be fixed for Alpha 24.

I have an interest in this, which ought to be obvious given I started this topic in the first place I've not found the time to work on this in ages, but it's something I'm seriously considering for the future, because I very much dislike our current presentation.

I think this is a visual thing, movement remains rather faster in formation. That being said, I think increasing the formation controller turn-rate makes this look much better, so I'll do that.

Yeah that's what I was describing above, it's because the controller rotates and we have pretty bad handling of rotating formations. I'm afraid it's essentially unfixable at the moment, and the movement is still working (maybe even better than with an individual order), so I'm going to call that a "won't fix" for now, unfortunately. You can, if you want, de-activate the default formation feature on those maps.

Can you be a bit more descriptive? Testing right now, it doesn't look great because the formation rotates un-naturally, but it's functional enough. For these maps, you can de-activate the default-formation manually anyways. Mh, that's a good point that I didn't think of. It's unfortunately not that easy because it needs to be synchronised for MP play, I'll see if I can do something not too tortuous.

Hello everyone, This message to inform you that I have merged in SVN the 'default formation' patch, which is a rather substantial behaviour change, though it can be de-activated. In Alpha 23 you have to put units explicitly in formation. In SVN and A24, units will now go into the 'default formation' when walking, and will act as individual when given orders like 'gather' or 'repair'. This is intended to leverage formations for movement, but to avoid issues with specific orders where formations make less sense. The "box" formation is the default. You can change this in your config file, and by right-clicking on a formation icon in-game. If you want, you can deactivate this entirely and go back to A23-like behaviour by choosing the 'no formation' as a default. Modders, you can easily chance which orders get which formation by changing the calls to g_AutoFormation. Since this is all GUI-only, you can mod it locally and still play games with unmodded players, too. Hope you enjoy playing, Wraitii

K, this is starting to make no sense Can you confirm that you've checked: - Your binaries/data/mods folders don't contain the mentioned files (if you're using git, they might be there but not noticed) - Your user mod folders don't contain the mentioned files - The mods you've activated (possibly start with the command line 'mod=public') - You've cleared the cache after checking the above