Jump to content

All Activity

This stream auto-updates

  1. Past hour
  2. Ahh, right. In the next release, thanks to PR #8447 adding camera configuration options, including the maximum zoom, combined with the current Bird’s Eye option, I think you’ll have that covered.
  3. 20. (very controversial hence I don't add it to the main list) increase cost of all cavalry by +25 food idea of pand what do y'all think?
  4. 19. Liu Bang, (first Emperor of Han China) radius of cavalry damage bonus increase to 60m
  5. Today
  6. No, that's a vertical view, I mean a zoomed out view (without using the Developer Overlay, or having any unexpected issues). I think the reviewers called that a bird's eye view, when asking for zooming out to have a better view of everything.
  7. Maybe, but who clicks on those links? Is it worthwhile as a spammer? (I know you are spamming 20 Million cases and if only 100 respond you've won).
  8. Thanks - I know I can test it myself, but I was travelling without access to the game. Just tested it - you are certainly right. Question remains, why two different mechanisms for the same effect... (probably I should read the manual or the forum more carefully)
  9. You mean like top-down/cenital view? There is a hotkey for that already. Called "Toggle Bird's Eye View". Shift+Tab by default
  10. I think I got past that, but now I have problems with spidermonkey
  11. Both reviewers of Game of Thrones: War for Westeros asked for the same thing: bird's eye view. Beyond All Reason provides exactly that. I think 0 A.D. should too, together with keeping sizes as realistic as possible (that is, do not shrink ships like AoE and others). All those things should work well hand in hand.
  12. Do you have Beyond All Reason on your radar? Rookie numbers.
  13. Well, I figure out a way around, I manually downloaded the files. But, now I am running into a openAL error make[2]: *** [CMakeFiles/OpenAL.dir/al/buffer.cpp.o] Error 1 make[1]: *** [CMakeFiles/OpenAL.dir/all] Error 2 make: *** [all] Error 2 ERROR: Failed to build OpenAL Soft
  14. They are getting better at writing some BS.
  15. Just retry, the server hosting the file might have been to busy.
  16. @Atrik I believe this problem is worthy of a dedicated issue with the attention of people more experienced than me. Do you think we could get the current PR approved for the next release to allow us to play games without the problem ? At the moment I have it hard-coded to 200m but the distance could be configurable. Then when the larger issue is resolved we could remove that configuration option. Thoughts ?
  17. What about showing the foundation only to the owner (and maybe allies)? It should be just a plan before anyone comes close to it. This would also avoid the annoying destruction of foundations, unless this is on purpose because of some gameplay consideration. I think my proposal results in a more fluid gameplay.
  18. So, just was building the game, and got this: ERROR: Download of https://download.savannah.gnu.org/releases/freetype/freetype-2.13.3.tar.gz failed ERROR: Failed to build freetype I downloaded it from somewhere else, and I think it is past that now. Just was letting you guys know, for any other people
  19. It's fixed for noobs. You can just hold H and then the cav just makes some jerking movements and stays. But don't tell anyone.
  20. I agree in theory, but in practise, my walls do seem to get converted when slowly leaving my territory (yes, this means they become detached from my root, and you can then see that as the actual reason), that's what I meant with: And my first observation was that I think this won't happen anymore with your fix. A detail: there are exceptions to "they decay if not connected to a root", like garrisoned buildings, and docks (which don't even decay in enemy land). And maybe it's not that the wall really leaves my territory, but that each block has it's own too small territory (in a way, this is what you fixed), and the enemy's land expansion makes each of these to detach from root, but still, that's a difference between what exactly happens in theory, and how it looks like in practise. Sure. But I'm not sure if you understood my first observation (which I just clarified), and nothing has been said regarding my second one. The point being not what's actually happening, but how some other things (besides the "Barrack Hack") will behave differently. @Atrik I edited some things to be more concise and clear, just in case you already read a previous version.
  21. "CC denial through units on the foundation. If one is lucky, one can put their cavalry on the enemy foundation during ceasefire and the enemy can't start their foundation because the cavalry won't move." @ffm2 I think its fixed now, when enemies start building your units automatically moves away
  22. 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).
  23. Your misconception here is to think I'm imagining something I'm not. I'm just trying to mentally emulate the consequences of the fix and point out anything unintended, given that you said "maybe I'm overlooking some potential drawbacks of doing so.. Anyone can think of one?". And I'm thinking of a couple of things, as I'll mention (I guess related to your "buildings are reasonably spaced" observation). Indeed "you cannot own a building but the land is to someone else" (except if they are decaying because of that). "There will be no more territory lines crossing buildings" is indeed the direct consequence of the fix, as is "buildings in the territory won't decay unless the CC is totally enclaved", that was your point all along. I see now why there won't actually be "self-sustaining" territories: their footprints are not root, so they should decay if detached from root territory. But I was also thinking about this situation: I've had the issue that part of my walls would decay if the enemy territory expands. If I'm not wrong, this won't be the case anymore, since the fix wouldn't allow anymore for only a part of a long wall to decay. I don't have a problem with this, in fact I think the present behaviour is a problem (because my towers get distracted shooting the converted walls I want to gain back!), and your fix might have solved this. But considering all that, and, again, if I'm not wrong, it would seem that the fix would make buildings not "reasonably spaced" way harder to convert just by territory expansion since, given that "there will be no more territory lines crossing buildings", one would have to detach a whole not "reasonably spaced" group of buildings from the root territory. Maybe this is preferable for some, but seems a bit of a drawback for me.
  24. Why do the spammers keep doing it? Does it actually work?
  25. Yesterday
  26. 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.
  27. game hosting isn't about hardware, it's a network problem. you could get 0ad run on a toaster if there was a headless version/mod to the game but that's not the actual issue preventing people from enjoying the game: not being to join certain games, or hosting games at all lag players dropping out All of which can be fixed with a server in a data center, which currently cannot be made to run headless/seamless. Once a solution to that is found then yeah multiplayer as a whole will be actually functional.
  28. I've been fairly absent from the lobby lately, but I did get to see Uff's hosts, and I think they're a very interesting development. I'm sorry to read that he left over a disagreement. I can understand the frustration, but I can also understand that it isn't easy for the developers to establish rules and enforce them. If anyone is in contact with him,it would be good to tell him not to burn any bridges. It's not worth throwing everything away over the first disagreement. I'm sure there is common ground to be found that could benefit everyone. Of course everyone needs to be willing to compromise on something and work together on any aspects that require coordination with wfg.
  1. Load more activity
×
×
  • Create New...