Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 2022-08-17 in all areas

  1. Here is a 470ms frame in Combat Demo (Huge) You can reproduce it easily by playing that map, or by using the automated version I made here trailer_tools/maps/scenarios at main · 0ADMods/trailer_tools (github.com) Messages here are onownership + ondestroy. Most units don't care about it though. In theory that also gets send to all the alive entities, trees building etc.
    2 points
  2. Every component could do anything. Because of that it is hard to paralelize the message-system; and it is hard for the compiler to make optimizations. Did i understand you correctly: you want one mutex per ComponentType? That would be useless because a recource might be mutated by multiple ComponentTypes. The function taking long is PostMessage. This function sends a message to all components which have subscribed to the messageType. Some subscribed components do nothing: RangeManager subscribes to PositionChanged but has to check if it "trackes" the entity (CCmpRangeManager.cpp L570). This could be changed to first ask all subscriped component if they realy are interested in the message (This could be done in paralell). And then sending the message to the interested components (in sequence). An other idea: At the moment most Components have a switch in the HandleMessage. If Messages were static types this switch would not be necesary. This aproach might interfere with JS.
    2 points
  3. Hi everybody, no version update here, just a little piece of information from the author of the LocalRatings mod (me). The next LocalRatings version (v0.26.1) will be released as soon as the new 0 A.D. Alpha 26 is out. I am impatient to play the new Alpha26 and to see how players' statistics change. As you may know, there will be a new civilization, the Han Chinese and it will be interesting to see how players perform with it. And speaking of civilizations... here's a preview of what you will find in the next LocalRatings version! Yes, per-civ statistics. Cool, isn't it? This is one of many new changes and features I have been working on. It will help giving a more concrete idea on civilization balance and I'm very curious to see what the Han Chinese civilization will reveal! I will provide a full list of new features when the release day comes. For the moment, if any of you wants to try it in advance, you can download the zip file of the development version (or download it manually from the GitLab page). It runs on both A25 and A26. I appreciate any feedback, in particular regarding the new explanatory page, that can be opened from the "About Local Ratings" button on the top of the page. Surely more content can be added and the English might not be perfect (my mother tongue is not English), so I appreciate any suggestion in that sense. Other type of feedback is welcome too. Should you have any thought, feel free to send me a private message. Thanks and... see you on A26!
    2 points
  4. Well, AFAIK they didn't use flags as we know them today, nor as we depict them as garrison flags in game. They'd use standards (more like the new battalion standards) or banners. But yeah, each Greek civ too could have their own custom one. It's just always been extremely low priority.
    1 point
  5. Scenario: two component of different type lock their mutex. But both could access a shared/global resources. Oh... now i get the question of this whole thread: you asking about thous shared resources. I don't know but i suspect there are many. And much code to check, also JS. We have information about the cpu's used: https://feedback.wildfiregames.com/cpu/
    1 point
  6. I think buildings should show the owner's flag, not the builder's. (Who'd want to fly the enemy's banner after they captured a building from them?)
    1 point
  7. No matter what i think how much of an emperor i am, there is always still an 0 AD player who is @Emperior :'(.
    1 point
  8. Buenos días o tardes ; @Tyrannosaurus -De ese tema es mejor preguntar a @Lopess o también a @Stan`. -En breve haré nuevos animales y plantas , para ese tipo de mapas. Disculpe las molestias*
    1 point
  9. Parallelizing logic which is using the same data is often problematic, as even with mutex protection you might run into issues. For example, you might protect the data from read/write collisions, but the data might not be in a state that you want to display to the user instead. You could put mutices at the level of larger operations to prevent that, but then they quickly become very expensive performance-wise, possibly entirely denying any gains from parallelization. Additionally, it is MUCH harder to see what is going on if you have multiple threads accessing the same data, making it easier to introduce bugs into the game, and harder to debug them. Parallelization usually works better when you have well-defined inputs and outputs for what you are running on the extra threads, i.e. when they don't affect other threads while they are running, only their outputs are consumed at the end; and the input data is copied for each thread if it could otherwise change.
    1 point
  10. I think we can ask most frequent well known (un-baised) players to help with this task. I would say @rossenburg/ Defcon , and @SaidRdz can help. Probably @Havran too.
    1 point
  11. I'm trying out the Maya Preclassic mod. Very impressive so far, but I noticed that, when I load the Peten and Tropical River maps, I see a little error message at the top of the screen saying "could not load biome file generic/tropic". Think the JavaScript files for those maps need a little editing. Also, the tapirs have no animations!
    1 point
  12. The first phase would just be to separate simulation from graphics. This alone is worth the trouble. I don't understand what you mean regarding mutexes in an event based system. What sorts of problems do you have in mind? Regarding the more ambitious project of multithreading the simulation it's self the javascript is one issue to deal with, but i think not insurmountable. Some code which is currently in JS might have to be rewritten in C++, we would have to consider other engine users as well of course. The threading model I'm thinking of for the second phase is to split into multiple threads during certain expensive tasks and then continue as a single thread soon after, so in some cases JS isn't involved at all. One option is to generate a priority queue sorted in some deterministic order (entityID maybe) multithreaded in c++ and then pass to JS. It's not an easy problem.
    1 point
  13. Mutexes with an event based system seems like asking for trouble. Also what about the js code ?
    1 point
  14. Good to see you back working a lot @wackyserious. Quick tip: the whole structure is very good, only thing you will need later wich was a difficult task since its kinda complicated start adding random handplace vegetation around, is add with props bushes and moss over the walls or hanging moss on the watchtower to mix the building with the enviroment. Keep it up!
    1 point
  15. Currently re-using the Western European art assets for placeholders, I have just committed the partially complete faction over at the repository https://github.com/0ADMods/xiiiad
    1 point
  16. One night, after you became rich due to a Youtube channel focusing on 0AD you told your manager to book Britney Spears for your birthday. When the day came three unshaved, wild looking men with no shirts on showed up. "Who the hell are you ? ", you exclaimed. In broken english they replied: " We are briton ey, Spears ! ", and held their weapons under your nose.
    1 point
  17. Your local svn repo should be in your home directory keeps the permissions simple for building BTW you can run in userland for testing before installing to system land. Enjoy the Choice
    1 point
  18. Me too because the svn repo only takes 12.5GB with build artifacts. (the git repo takes like 20GB though) The partition is not relevant since you would be building it yourself. I would suggest a user owned directory though. ~/ perhaps.
    1 point
  19. Aztecs (Mexica), but still interesting:
    1 point
  20. I really like all these ideas (I know I haven't had a presence in a while, college is busy) I just want to play devils advocate against this way of thinking. A lot of the people making this complaint are from AOE2, where most civs play more or less identically, even when it doesn't really make sense. Its a double edged sword, like most design choices. Making civs follow a stricter common layout like aoe II does make trying to news and exploring easier for new players. However, after a time, all the factions just blend together into sameness and the game can loose its charm, as a lot of players are motivated by learning to play games well, and once you are there in aoe2, there is little more to hold your attention (which is why the latest AOE2 dlc factions have been straining those common layouts as much as the devs dare without annoying their famously fastidious fans) The counter side, like AOE4, AOE3, or AOM; Makes civs that differ more from each other can make it harder for newer players to expand and learn the various factions, because different factions play differently. However, it can keep players on their toes as they play, as the differences in different factions can ellicit different responses from the player depending on the matchup. It can also keep older players engaged, since it takes longer to master each faction. I know it was a little tangent for this thread, but since the thought came up I felt like here would be a good place to mention it. I think the women and helot dynamic was a very interesting design choice, like others in this thread. I mostly just wanted to say that we shouldn't be afraid of making each faction unique, especially if it expands the historical basis of this game, which it prides itself on
    0 points
×
×
  • Create New...