Jump to content

wraitii

WFG Programming Team
  • Posts

    3.395
  • Joined

  • Last visited

  • Days Won

    75

Everything posted by wraitii

  1. I think it also comes down to what the gameplay is. 0 A.D. EA is currently more similar to AoE, so a more similar UI makes sense IMO. Fair point, I'm willing to generate some discussion on this too. I intend the implementation to be somewhat flexible, so you could somewhat easily mod the top-right icons to show the unit roles, IMO.
  2. I've started a mod: https://github.com/wraitii/ui_mod / https://code.wildfiregames.com/D3472 So far i've begun with the selection details:
  3. Your concerns about Auras have been addressed as I had to implement variable range queries (UnitAI broke):
  4. Hey, yeah we tweaked some things around because I noticed that UnitAI range checks where breaking, and LOS uses center-to-center (as you well know) for now, so we need to match it. Here's how things stand: Alert Raise is edge-to-edge Auras use center-to-center again - the reason is mostly Nescio's concern that edge-to-edge gave too big an effect to structure size BuildingIA is edge-to-edge (so building arrows) BuildRestrictions use center-to-center again - the reason being again that structures sizes can vary, and I didn't find either particularly better. To be honest, since buildingAI is edge-to-edge, it might make sense to change that one again Gate range is edge-to-edge TriggerPoints are edge-to-edge Collision detections for arrows is edge-to-edge UnitAI is center-to-center
  5. Yeah that's a fair point I think, but I don't believe we need to change this further for A24 at this point. If you're playing 0 A.D., you probably can call back whoever called you since it's unlikely to be urgent work stuff
  6. Do you not have a 'mute' key on your keyboard? I see your use case, but I did not consider it worthwhile given that I assumed most keyboards would have a 'mute' key for these purposes. Maybe I was wrong. The reason for the change, by the way, is that: pausing the music breaks the victory sound in SP (could be done differently) The game auto-pauses when you open the struct-tree (and a bunch of other things), which is annoying since it used to cut the music. I don't think I'm going to consider this a major use case, to be honest . You could just disable music then. It does, but on A23 that doesn't pause the music, nor on A24.
  7. Pausing the game mutes the sounds & ambient sounds, but not the music. Are you referring to 'background pause' here?
  8. 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
  9. This didn't get fixed by updating the Player.js code?
  10. 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":
  11. 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.
  12. @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
  13. 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 = ""
  14. 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.
  15. 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.
  16. 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.
  17. 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
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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'.
  24. 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.
  25. 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.
×
×
  • Create New...