smiley

I have never heard of google/pprof mentioned in the Geany wiki but this seems like the missing piece for the JS sampler I already have. It should be able to spit out such a graph for JS code as well.

You can put them into the user mod. /home/username/.local/share/0ad/mods/user/ The sub-paths are correct. Create a maps/[random, skirmishes, scenarios] in user/ and put the map files in the right folder. --------------- Ideally, map files would be distributed after being packaged into a mod file which could then just be opened with 0ad.

Perhaps this range should also be part of stances and used for stuff like "Defensive".

See if disabling autociv helps.

In the meantime, you can download the uncompressed / lossless source files directly from https://trac.wildfiregames.com/browser/audio/trunk/music.

Indeed. The alternative was generally worse due to the hardcoded placement logic and results in overlaps and whatnot.

Isn't this the existing behavior? Engine would start with mod mod which is pretty much a game selection screen.

Wildfire Games is more like a banner under which we volunteer instead of an organization / company. No formalities required, just work on the game however you want, and you are part of Wildfire Games.

The projectile would be reduced to a velocity. (launch pos + time * direction == unit bounding box). In the case of moving units, this has to be evaluated at every turn since unit positions vary over time, and we can't simply assume that the projectile would not hit any unit until after the fact. In the case of buildings, they do not move over turns, and if a building bounding box intersects with the velocity at any time value, they can be assumed to do that at the future turns as well. (launch pos + x * direction == building bounding box). Building constructions and destruction would have to be taken into account.

This would be the ray cast I mentioned, or maybe not a ray since it's a segment now, more accurately line segment to polyhedron intersection I suppose. It's in the realm of possibility that we can make buildings block projectiles, but units are out of the question as they won't have the same position each turn and would need repeated ray casts unlike a static building which can be done just once, with the caveat that buildings placed and constructed after the projectile was launched would not block. Somewhat interesting, and I believe I have had this discussion on IRC sometime back in 2018. Indeed they don't. AoE4 have even more simplified ranged attacks by making them always hit. Essentially delayed damage, instead of delayed hit testing we have.

Projectiles are a pure visual element. The simulation engine is agnostic of the actual arrow or stone. Ranged attacks are simply a velocity and the damage code just run a calculation, there is no physics simulation going on. The visual projectile is also a local entity, which can be considered to not be part of the game, is not serialized, does not affect the game state and is there purely to be seen by the local player. Unlike FPS games where bullet physics are actually simulated, for RTS games with thousands of units, its not going to be feasible. Have to do ray casts over several entity meshes per turn per projectile. There is a potential optimization if only buildings are considered, which do not move, and are also reduced to cuboids. In which case, it might be potentially okay. However, projectile paths are not rays, there is some ballistics going on. A ray will not have a curved trajectory going over a wall. So I assume a more expensive form of collision detection needs to be done. This will be a complete overhaul of how ranged attacks are currently implemented.

The Atlas grid lines are showing tiles. The emphasised lines show 16x16 patch borders. Its an engine constant, https://github.com/0ad/0ad/blob/6f02aadf5b3ae6996a3fbf6a10a18ec22a406ad9/source/graphics/Terrain.h#L40 There is a scale discrepancy so not sure if calling them meters is actually accurate. But they are called meters which should be read as Pyrogenesis units.

A little bit lower at 4 meters.

_SC_NPROCESSORS_CONF returns offline cores too which will cause sched_setaffinity to fail. _SC_NPROCESSORS_ONLN is a fix but that also ignores sleeping cores, which I believe is somewhat common on power saving modes in laptops. This is unconfirmed as the documentation is not clear if sleeping cores are actually considered offline, however, there is a thread of Mozilla bugtracker about this not not counting those cores on some weird ARM setup. Either that or don't ensure sched_setaffinity to be successful and handle offline cores I guess. I would check but I cannot really go through the hassle of rebooting.

An alternative is increasing cavalry obstruction so that dense forests would not be accessible. A speed modifier could also be a thing for forests. Maybe with a group aura or something that kicks in when n trees are in r radius of each other or something.

How exactly? What are the choices? Not in vague abstract terms please. Why does someone else have to be the change you want to see? You or anyone else here are on equal footing with people who have commit access to propose changes. https://code.wildfiregames.com/feed/query/all/ read as far back as you can and see how contributors interact with each other. The usual story is that someone posts their opinion with no attempt at justification and expects everyone else to treat their subjective opinion as axiomatic truths. Justification is hard, which is why 90% of people just stop after a forum post. And the vast majority of reaction comes from other gameplay & balance experts. That might have provided a clue as to why borg stepped down. Its up to you to convince people around here the merit of your contributions. If the community wholeheartedly rejected it, and the game is developed for the community, isn't it in the projects best interests to make most of that community happy? You are seeing this with more organizational structure and bureaucracy then there is. FOSS is just flat. "heres a thing, play it if you like it. make changes if you don't. just do whatever you want with it". In fact, our favorite license makes it very clear. * 0 A.D. is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details.

Its a bit disingenuous to claim its ignored when all proposed contributions do get recognized. Everyone is free to propose gameplay elements and if objectively justified would probably get merged too. If you need unimplemented features, write out the requirements so that an actual discussion can arise out of it. Having an arbiter of game design will not solve the problem of having voluntary moving parts that can just straight up stop spinning just cause they want to do so. There is no WFG entity making the game. There are people just like you working under said banner. Its not ignored because WFG decided to allocate all its manpower into engine development. Its ignored because no one stepped up. Everyone here are just as qualified to dedicate the time and effort and propose gameplay patches as those with commit access. However, no one is under contract to do so, so we cannot really ask @vladislavbelovto drop his rendering work to instead define counters or implement battalions or something. (even if we could ask it and he did sign a contract of servitude to 0ad, it would be a really stupid thing to do because his efforts are most needed in core engine code) Not directed at anyone here per se, but generally speaking, FOSS is a breeding ground for entitlement of volunteer time. A gridlock yes, but not a meaningful gridlock in my opinion, because usually, neither side involved actually goes beyond suggesting ideas. Ideas by themselves are kinda meh if no one evaluates them, justifies them, implements them and make the effort to convince others its objectively an improvement. Statistics for those who care, there are 326 differentials tagged [gameplay] on phabricator, 257 of them are already closed. Thats 78%. Gameplay contributions are not ignored, they don't come.

What is the current progress of this project? There have been recent commits to the repo so seems pretty active. Merging this into A27 would be nice. With a nicer level selection interface the maps could be committed as the inaugural campaign.

Most of those changes are not visible to end users regardless of how badly they were needed. Gamesetup rewrites, renderer refactorings and SM upgrades don't mean much to anyone who don't follow development closely. Only a subset of changes are userfacing and of those only the very best or the very worst get noticed, and you won't bother posting about how good something is compared to when something is bad. From an outsider looking in, it would seem that rarely anything gets changed and half of those changes that do happen are straight up disasters. Not that development is currently going on at breakneck speed. There were efforts to properly communicate actual progress on a monthly basis quite recently as well, but that's a story for another time.

Moving to GitHub does nothing to bring in more patches imo. See openage and related projects. STK isn't faring much better either. Active Devs here might just exceed them to be honest. You can't make contributions unless you already know the project. In which case, are we relying on the GitHub home page featuring the repo? Discovery through GitHub is pretty bad unless you're actively looking for something. The only real benefit is that the web interface is easier to work with. A self hosted gitlab would be significantly better than GitHub for that. GitHub for the sake of more visibility would be a disappointing endeavour. You are supposed to direct people to a GitHub, not the other way around. Definitely do need git though. Most people here already use the mirror. There was also a time when it was just Philip, so all things considered, not the worst time to be visiting these parts.

Too much holes is still non optimal though. A proper O(1) access container for sparse data would be best. A basic first step could just be chunk based. And memory usage in the vector case would be count*sizeof(ptr) + sizeof(vector<ptr>) I suppose. And I am fairly certain sizeof(vector<T>) is not standard even in debug vs release on some platforms, but that's besides the point as the underlying buffer is the point here which should be ptrs. Having an unnecessarily large block might also have some negative perf impact on the os level from the MMU. For the general case, this would still probably be faster than map though. map<incrementing id, components> ignores some easy optimizations.

https://trac.wildfiregames.com/ticket/1860 (there seems to be two separate proposals in here, including this particular one) https://trac.wildfiregames.com/ticket/4046 wraitii posted in both tickets as well.

I recall seeing this on a patch attached to a ticket from long ago. EntityID as index which I guess is the gist of this. Ultimately it wasn't merged, so if the ticket could be found, there might be noteworthy discussion there. If my memory serves me right it also replaced the map with a vector. (Might just be a goose chase, I recall stumbling upon the ticket sometime back in 2018)

The name and the description doesn't match which leads me to believe the original commit misunderstood what weeding was. Weeding doesn't mean growing weeds, it means removing weeds. Water Weeding -> Removing aquatic plants that pose a significant problem in paddies because If you s/growing/removing the description, it actually makes sense in all ways, scientifically, and linguistically.

JPS doesn't have non-uniform cost grids. This was a thing before the pathfinder rewrite and I believe it was used too considering some legacy code. In layman's term, the pathfinder is going to be pretty dumb.