Atrik

Buildings don't decay because they are outside your territory (in 95%+ of cases, they sit on their own territory influence), they decay if not connected to a root. This would be unchanged. Territory ownership and connection to territory root are two different things. So nothing will change if you capture a CC and opponent have no other root attached to buildings => all buildings will decay. Your opponent will still own the "blinking" territory until the buildings are decayed to a new owner (unchanged and unaffected by proposed modification).

There is no need for whatever complication you imagine. We just want buildings to always be in owner's territory. Which is how it should be, you cannot own a building but the land is to someone else (in this game at least). If this land is not connected to a root, then all buildings on it decays still, like what happens commonly in games when buildings are reasonably spaced. Basically in the picture with the CC in the comment above, the territory line would be between the CC and the barrack. There will be no more territory lines crossing buildings, which makes sense. None of the decay conditions are changed, beside that now the CC center point will actually be in the owner's territory (as it makes intuitive sense) and therefore buildings in the territory won't decay unless the CC is totally enclaved.

Meaning another building cannot extend the territory into another's player building. This should still allow decay if this piece of territory is not connected to a territory root. Your misconception here is to think the building needs to be outside his territory to decay but really it's about being connected to a territory root. In the scenario with the barrack, the territory limit would happen exactly between the CC and the barrack => not into the CC

One fix idea, although haven't digged into what would take, could be to have building footprints (their size) always be the territory of the building owner. This would kinda make sens too. Maybe I'm overlooking some potential drawbacks of doing so.. Anyone can think of one? I think for non-root, this shouldn't prevent decay if not connected. IIRC I noticed a bug where dropsites, owned player but "outside" your territory (example enclaved by an allied barrack) is not considered by your gatherer. So that would also fix this kind of bug.

@manowar I still think we should try to fix the underlying issue. If I build a barrack next to my CC and it gets captured by an opponent then I will also have my entire territory decaying right (something that could happen in any game mode)? I've just tested and it is indeed the case : You can see here the house is decaying although there the CC looks very much not so much enclaved

@manowar, I see.. The issue seems that even if the territory area is influenced by the CC (the territory root), the CC is still considered outside of it, so "no root is attached to the territory". Good catch. A enclaved CC is probably expected to have territory outside the enclave to decay. But here the enclave is just created by the barrack having bigger weight then the CC. So here I would say it's definitively a territory influence weight problem/bug.

Fishes have the specificity (unlike berries) to stop regenerating if they have any gatherer on them. So it doesn't matter much if you have 1 or 4 boats assigned they will not regenerate much anyway.

I said this because I think smalls things like that doesn't add any "uniqueness" but add some kind of inconsistency. Each civ should have a list of things that make them unique but it should be easy to describe on the civ summary, and everything else should follow a pattern.

Probably because bots posted here before getting deleted...

Sheeps are in "passive" stance, while gazelles and all fleeing fauna have "skittish" stance.

Should be in for next release where (mostly useful for corrals) gathering from animals continue if other animals of the same stance are nearby. https://gitea.wildfiregames.com/0ad/0ad/pulls/9083

You post so many ideas that I'm getting the reflex to skip your posts, just so you know you might want to be more concise. What you are describing here will be implemented next release : https://gitea.wildfiregames.com/0ad/0ad/pulls/8525

@Vrayer, congratulation on making your first mod! I have to warn you however that changes like theses will cause oos if you play with players that wouldn't have the mod. For the mod you posted, you should keep the compatibility check enabled in the mod.json to avoid problems. If you really want to create a compatible mod that does this without compatibility issues (that will not oos), you would need a different approach where the UnitAI behavior stay unmodified but triggers re-issuing a command, for other clients to serialize the same behavior as you want. That's tiny slightly more complicated to do but very feasible.

@Vrayer If you want to could add a poll to this thread (maybe also change the title) and if people think units should continue to hunt other animals it could be done for next release. It could also be possible to do it depending on animal "stance" for example units would keep hunting any other non-aggressive animals or any animals basically in the same stance that your initial order was.

To do this, you would just need to remove this line: https://gitea.wildfiregames.com/0ad/0ad/src/commit/9598c6c2e1f4cc58f92d4fd6a54fda39ad195bf9/binaries/data/mods/public/simulation/components/UnitAI.js#L2755 But beware this line was obviously here for a reason. For example, if you are slaughtering a bunch of sheeps but an elephant comes by, then your units will attack this elephant.

https://gitea.wildfiregames.com/0ad/0ad/issues?labels=-24 Here you go

Exactly. For a game overlay, they are the worse thing possible.

If you are referring the @Thalatta's last mock, then the dead space would always be less then current ModernGUI layout (10 slots vs current 12) but it's a bit closer to screen center which might look worse as said above. Your other points I acknowledged them in the last comment, so agreed but you always have to make compromises, goal is to make the best ones. We're back to first exchange : too much clutter, too much space used. The second option is just slightly better enough to make it interesting.

I think I'll consider this proposed layout, I see a some benefits. One of them might be an option to hide it as some players like myself already know each unit command hotkey. I also like that you get 10 slots for unit commands which is the exact number to not have any overflow for single-type selection even including new capture button (the 10th is "back to work") but doesn't have much dead space. The overflow in multi-type selection (worker + building) will overflow but that's somewhat fine, not worth adding space for this. About the construction panel layout, it's not worth pursuing your attempt to order building, in my opinion. Due to the fact that the list of construction is very variable : across civs, mods easily add some, and in a multi-type selection (if any of the selection is a trainer, a researcher or can be upgraded) then you cannot keep the ordering. Also on your mock the order isn't even done by any entity classes that would make it possible.

I like the gain in clarity and the attempt to normalize panel's heights. There are a couple reasons why I still couldn't go for this. Lateral space is already scarce in ModernGUI if you don't have a big screen Although your suggestion takes as much total space as what's implemented in the mod, it adds the clutter a bit more to the center of the screen. For users that use hotkeys for unit action anyways, or at least for myself, this is not desirable (maybe it's just something you could get used too idk) Contrary to what you say, the placement is logical. All possible actions are on the right side, all attribute-like options on the left (formation stance..) Currently the single selection detail panel wouldn't be able to shrink down height without losing something. You are basically saying the wording "turret point" is confusing but you aren't suggesting anything.

Have to say you are right. Hardly a bug. But it's confusing game-play choice (in fact, just a left-over from old wall towers being able to shoot). I have a pending patch were I replace garrison for turret points on wall towers.

The absence of a bug is generally less noticeable then when it's here

Vanilla UI doesn't have space to display all unit action button, so it doesn't show it. You can use the hotkey as an alternative. I can also recommend using ModernGUI as others and myself contributed to fixing bugs and limitations of the game UI. There are at least 100+ bug fixs like this in the mod. You can also choose to wait a few decades for them to be addressed in vanilla (no sarcasm, just a extrapolation of the time to get one item merged), staff and contributors do whatever they can to make it happen but the process is slow by nature.

@SadRdz see: Just tested the option by @ffm and it actually works after restarting the game/session.

Yes it does, but in the videos, this opposite force is just not applied as it should, so the effect is less then its supposed to be.