Leaderboard

We talked with @elexis about constant references and I gave an example why passing by value may be better than passing by constant reference. During todays refactoring I met another important things that you need to know about constant references. Aliasing Take a look at the following code. Do you see a problem? (It's our code from ps/Shapes.h). // Interface class CSize { public: // ... void operator/=(const float& a); // ... public: float cx, cy; } // Implementation void CSize::operator/=(const float& a) { cx /= a; cy /= a; } If not, would the following usage example help you? CSize size(2560, 1440); // Normalize the size. if (size.cx) size /= size.cx; debug_printf("%f %f", size.cx, size.cy); You'll get: 1.0 1440.0 Because the a references to cx, and the first line of the operator modifies the cx. And in the next we just divide the cy by 1. It may happen in each case where we get the same class. I fixed the problem in D1809. Lifetime Another important thing is a lifetime. Let's take another look at another example (fictional, because I didn't find more detailed example in our code yet): std::vector<Node> nodes; // ... duplicate(nodes[0], 10); // ... void duplicate(const Node& node, size_t times) { for (size_t i = 0; i < times; ++i) nodes.push_back(node); } From first look it seems ok. But, if you know how std::vector works then you know, that on each push_back std::vector can reallocate array to extend it. And then all iterators and raw pointers are invalid, including our constant reference. So after few duplication calls it may contain a trash. So, you need to be careful with such cases.

That's again taking the presence for an immutable fact instead of determining the ways to change it. Maybe you can't change the lives of the members, but you can change the members by trying to become. Meeting a bunch of people with too few enthusiasm and availability is exactly the situation I found myself in in 2015, so I could increase that number by 1 and maybe more, depending on how you count. And that's the point that I'm trying to get across. If the external contributor doesn't show that he is autonomous enough to manage to work in spite of the limitations of the environment, how would he be able to work with the limitations of his environment if he became a member. We need people who take over responsibility where responsibility is not assumed, rather than more people that require more attention. Bunch of people with no enthusiasm + 1 people with enthusiasm > people with no enthusiasm We have enough team members who upload patches in the sense you said, offering something but not going further, but we need reviewers, and a reviewer means that he is able to walk the entire way. By definition we can't trust external contributors to do their thing right, so we require the reviewer to walk the entire way. If a reviewer shows that he can walk the entire way, he showed that he is qualified. So while it does work for people who are employed to have half of the work done being by the author and the other half being done by the reviewer, it is much more likely for the author to suceed in a enthusiasm-limited volunteer group to do 99% of the work and leave the other 1% to the reviewer (pressing the commit button). Sure, many people do see this as *their own* product, I never did, I see it as a public good. From the general public, for the general public. If I play this game and I see 20 times the same bugreport per day, how does this bugreport relate to my personal desire, but not to benefit of the general public? me and you are the means, not the ends. The incentive depends on whether the objective of the contributor is to participate in a review process or whether the objective of the contributor is to improve the software or whether the objective of the contributor is to fix the missing enthusiasm in the team by becoming an enthusiastic team member We really need the last type if we can't fix our own motivation problems. If they want to become a team member, they should walk all the way. It's exactly the crux of the problem. Wildfire Games is comprised of volunteers and their enthusiasm and assumption of responsibility is only as great as that of their volunteers. There is no difference between external volunteers and member volunteers, other than that the latter had gained the trust to work autonomously. WFG is not a corporation who exclusively hire employees as members to participate 8 hours per day in a review process, so it's simply false to expect volunteers who work 8 hours per day on something else to behave like that. Programming a patch is not the same as getting a patch into the codebase that the general public uses. There are so many mods that are dead because a new version was released and the mod hadn't been updated. But if the features in that mod were committed to 0 A.D., they would have been migrated. The more the codebase becomes unified, the more the general public benefits. The more it becomes fractured, the more features are lost. I agree, as a contributors who gained Wildfire Games trust, I became limitated only by myself and could get more done in 3 weeks than in a whole year of noone volunteering to go through my review queue. Both are volunteers, which means they work on something if they have positive motiviation to do so, and the motivation is the furtherance of the project. I'm not talking about lala fantasy land but I talk from the past years of experience and looking at how Wildfire Games had operated in previous decades, it seems quite similar. External contributors who are enthusiastic and overcome logistic problems of the team are exactly those that are invited to the team. If a contributor shows that he gives up too early, how would he not also become an unenthusiastic member if he is surrounded by them. You have a brain and muscles in your fingertips, and the situation is bad, therefore it's in your ability to change it as far as your brain and fingertips carry you.

Wonderful news. Please tell me when Spork AD comes to fruition next April.

Not from the XML file it's a missing prop point in the DAE file ( Which is also a XML file although different)

The first line you modify comes from rP16577, I don't know about that. The second line you modify is a wrong line from rP17784, so it's correct to modify that if one doesn't want to redesign BuildingAI. But the line should not check for SiegeTower class, because every entity that has BuildingAI and can capture should pass if the order is to capture. You reminded me of things that were not okay.

thank you, was just making sure dont want to get in trouble for having parents who play 0ad, lol

It can indeed be done. For anyone interested: add the "capturable" element in "templates/special/filter/foundation.xml".

The elephant stable spam is a typo in the headquarters.js: at line 2003 (whether to build the elephant stables, line reference to Git-version of DE) it says: !gameState.getOwnEntitiesByClass("ElephantStables", true) but in the template it has the Elephant_Stable class. For the AI they never match, so it keeps building the stables. A fix would be to make the classes match.

I hope everyone enjoyed it. I would congrat those who got all the refs. Hehe good point, I didn't know

Terra magna

Some love from uruguay!!!

The purpose of present-day Wildfire Games is to create, improve and educate about free software with and for the general public. The principles of free software empower any user to adapt and redistribute the software to their own best interest without hindrance, qualify the software as a pure public good, authored and purposed for the public interest. A pure public good is non-exclusive, meaning "it is impossible to exclude any individuals from consuming the good", and non-rivalrous, meaning "for any level of production, the cost of providing it to a marginal (additional) individual is zero." The IRS defines a non-profit organization to be "organized and operated exclusively" for charitable purposes (see Organizational Test Under 501(c)(3)), serving public rather than private interests. Whenever Wildfire Games acts through SPI, uses funds that SPI holds, it must be exclusive to the furthering of charitable purposes. So Wildfire Games can provide anyone who does follow Wildfire Games usage policies and exclusively serves public interest a subforum with the funds of SPI. Other than not having funding for non-free software practices, I suspect Wildfire Games might distance themselves from any closed source practice unless having concurred with SPI. Anyone who requests a subforum may demonstrate good faith with that regard.

Notice that the data displayed on opentopomap are (1) elevation data, probably a derive of the old SRTM NASA data, and (2) polygons for that island. I think (2) is exactly the OpenStreetMap data, and especially not part of the heightmap. So yes, I think exactly what you're seeing there is the same data used on the map. Notice that the implementation of Elephantine was done by converting that to a heightmap image. I recall spending one or more days trying to load the polygon as JSON, but failed for some very specific reason. Should be mentioned in the IRC logs of the time before Elephantine was committed, I don't remember exactly what it was. Selection of which shapes one wants is one challenge, because OSM provides a lot of information one doesn't want to add to the elevation map (streets for instance), and the polygon needs to be filled, so one would need an additional algorithm for that (flood fill). Coordinate transformations can also be annoying. (But there was some other specific complication that took me like 10 hours to discover, I don't recall.) These commandline tools are very important, it allows one to generate a heightmap at an arbitrary geocoordinate and arbitrary zoom level. I remember that I needed something like 10-20 tries to find the coordinates and zoom levels so that the terrain shapes one had looked for become recognizable. Then 10-20 coordinate / zoom trial and error modifications to center the map perfectly for artistic and balancing aspects. But if one takes a screenshot from a map browser, edits it in gimp, one has one try. Chances are it might not be ideal. Then the entire map created in Atlas is stuck to that error forever. But if there is code to place the entities and actors, you just need to press 4 buttons to do the entire map all over. (There is a terrain recentering patch on trac, but the lost area is replaced with a level plane instead of the heightmap data, and one can't change the zoom level)

The map Elephantine is using OpenStreetMap data to create the shape of the river and island. It was not only a fancy proof of concept, but necessary, because all available heightmap data was way too imprecise to capture any shape of the island at all. /** * Heightmap image source: * OpenStreetMap, available under Open Database Licence, www.openstreetmap.org/copyright * https://download.geofabrik.de/africa.html * * To reproduce the river image: * You need a gdal version that supports osm, see https://www.gdal.org/drv_osm.html * wget https://download.geofabrik.de/africa/egypt-latest.osm.pbf * lon=32.89; lat=24.09175; width=0.025; * lat1=$(bc <<< ";scale=5;$lat-$width/2"); lon1=$(bc <<< ";scale=5;$lon+$width/2"); lat2=$(bc <<< ";scale=5;$lat+$width/2"); lon2=$(bc <<< ";scale=5;$lon-$width/2") * rm elephantine.geojson; ogr2ogr -f GeoJSON elephantine.geojson -clipdst $lon1 $lat1 $lon2 $lat2 egypt-latest.osm.pbf -sql 'select * from multipolygons where natural="water"' * gdal_rasterize -burn 10 -ts 512 512 elephantine.geojson elephantine.tif * convert elephantine.tif -threshold 50% -negate elephantine.png * * No further changes should be applied to the image to keep it easily interchangeable. */

Speaking of which. Credits to bigtiger.

Unless the opponent dances with 10 unit. Though I agree that might reduce the problem already to the point where people don't collectively push each other into using this thing. Notice that even if we'd nuke or restrict patroling, players can script such things (at least Lefo scripted his base building commands already). Another issue is that the likelihood to strike a unit is reduced with the distance to the unit. Mostly I wonder whether the trajectory code itself doesn't offer a nearby solution. We only need a consensus amongst coders, not everyone. If the problem is gone either way, the topic will be gone. If the problem only morphed into another problem, we have something new to talk about the alpha following that

I'd just like to add that this discussion is good illustration of why it's difficult to move forward on gameplay decisions. Dancing is an exploit, plain and simple. But there are some experienced players who have a vested interest in maintaining this exploit because it allows them to win vs noobs and/or people who refuse to stoop to dancing an individual unit to win a battle. Such cases should be clearly identified and tackled. Dancing on the frontline of a battle is just dumb, and if it allows the dancer to win the battle, it's hella frustrating to everyone that can't be bothered to go into first person Billy Eliot mode to win. This is basically the inverted of something I've suggested several times myself (I suggested ranged units randomly selecting 1 out of the 10 nearest units, spreading fire across the group being attacked, not just the nearest individual): The only caveat I can see with nani's suggestion is how would you focus fire on a specific unit, like an elephant storming towards your CC? I don't think you'd have that problem if you follow my original suggestion, which is the most natural, organic, logical and intuitive solution (don't know if it's feasible from a programming side though) I repeat my suggestion: When a group of ranged units attacks another group, the ranged units each individually and randomly select 1 out the 10 nearest enemy units in range to fire on. This would cause groups of ranged units to fire across a front, not an individual. Dancing would be rendered ineffective and ranged combat would start looking a lot more natural. Perhaps "focus fire" could be a tech to research, to help sniping heroes? Secondly, directional defence should be a thing. So that units carrying a shield would become less vulnerable when attacked from the front, and far more vulnerable when flanked or attacked from the back. Currently a unit's attack has a direction, no? How come the defence stats can't be applied differently to a direction (front, back, left, right)? Also, the poll is misleading, as option 2 and option 3 are basically the same option and option 1, 2, 3 are more similar to each other, while people are allowed to vote on more than one option at a time... Skewed results.