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.

The reported player will be muted for 1 day upon the next login (notified)

Yes The only real difference between the original purpose (creating a fun, modifiable game), and the present is the added open source component. From what I remember reading, the original devs wanted 0 A.D. to be open source. However, they were afraid they wouldn't be able to prevent multiplayer cheating with open code, so they chose "freeware" instead of open source. (Multiplayer wasn't implemented at that time, so there were many unknowns about it.) That was the early 2000's; I imagine that they might have created the project as open source if they were starting the project today.

Those weren't two solutions but one. Players, scripts, AIs may send arbitrary or broken commands, so the component should test for both conditions to be true simultaneously. Only testing for the latter would be wrong, because the idea of the commit mentioned above is that arrows shot are either handled by UnitAI for units that only shoot one arrow at a time, or by BuildingAI if they shoot multiple. (So the purpose of the fix had never been to correct a tooltip, but the broken tooltip was one of the consequences of the oversight addressed in that commit)

Sure, but that approach: The recommendations above are to recommend not limiting oneself to that. At least one contributor got himself a review by acting on that post, so it wasn't useless. If you see that people don't have enough manpower to keep up with the review queue, the obvious conclusion is that there must be more team members that do reviews, and thus you and everyone else capable should become one and allow others to upload patches in the principle "here it is, take it if it's any good". That may be true for newcomers, but you have gained much more knowledge than that. Contributors become educated over time, become able to take responsibility, so that they can also take decisions on community patches. If people persist walking, they will walk all the way. Finishing the game, making it available under exclusive free licensing, minimzing the cost for others to study, reuse and extend it, and thus for instance publish revision history. So apparently there are some differences. Great! what now? Just because it can take a while to get to the bottom of feature doesn't mean that we shouldn't start working towards this, but rather because it takes a while, we should start working towards this and document any pieces of information when we come across them. Hence I raised a concern on this commit, since at the comment is wrong, the documentation missing, and at least one more person than dismissible me having wondered the same about the possibility of more appealing solution. @Mijorious any progress with finding the maps ingame?

Thanks. I'm reworking Saharan Oases (4).

I was thinking for the Gauls that they could get something like this But with some items like these details (antlers):

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.

Nice man! Looking luuuvly... I love the way you are spitting out entire biotopes like it ain't no thing... I'm still just barely at 4 variants for the acacia's, lol... "Trying" to keep up got me like:

congrats we got 7 fan palm variants

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)

No worries, we will make a poll to build a pool in the backyard with a big pole so everyone can see they are invited, have fun and enjoy our choices.

@LordGood Indeed I forgot to fix the AO ^^ better now .

@LordGood Works like a charm

you may need to rotate, but try this

Hello and welcome! I have a few questions: What kind of documentation do you intend to start with? Are you familiar with LaTeX, Markdown, XML, or other markup languages? What do you think of https://play0ad.com/ ? Have you already registered at https://code.wildfiregames.com/ and https://trac.wildfiregames.com/ ? What would you be able to do as a team member you can't do right now? There is actually a third kind as well: in-game documentation.