elexis

(Don't forget the controversial "or later" clause of GPL)

refs #5070, discussions about chat in replay since ever. Probably a good idea for the purposes of creating good memories for the players and observers who were participant, and probably a bad idea because of creating bad memories alike, and replays being shared on the forums while players might have assumed some of their ingame chat to not become public. So it would require solid understanding of the player that the chat may end up in the replay forum. Or some technical solution to split purposes. Anyhow. Using them for moderation purposes however is entirely different. People post screenshots of chat, that's technically not granted by any policy and may be objected (GDPR 21) or the like. Wildfire Games does not host any ingame matches, so there is no way to obtain actual knowledge of what happened there. So this ought to be respected, WFG can't be held accountable for that. Only the data people post on the lobby is something that can be governed (including the rating and lobby chat data, advertized games). If players want that their ingame behavior is controllable by the lobby provider, then there would either have to be some shady backdoor or the lobby service provider would have to host all matches. The latter is actually in the theoretic plans of development for the purpose of minimizing rating fakery. So maybe something will change in that regard in the future. But rating and chat are two different pairs of shoes, the chat may still be encrypted so that it might remain protected from the hoster. On the other hand ingame chat may be interesting for good memories, perhaps the users can chose. It would require actual notice. I guess this comment doesn't help any further, other than stating that there is a ticket, that posting ingame chatlogs is possibly objectionable (I guess people would have to fight who has overriding legitimate interests in publishing ingame chatmessages for the purposes of moderation. If someone wants that, they should write it into the terms of service directly or indirectly).

(He resigned a match in compensation)

DDOS attacks typically work on the transport layer, not the application layer. We had this before (https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol#DDoS_attack). Edit: One can make them for applications too, but why go to that length if the attacker can use prewritten scripts. Secondly the attacker needs to find many vulnerable machines running that to perform the DDOS attack, consumer-end routers are most available, but can't really perform enet/pyrogenesis connection attempts and xmpp doesn't sound widely supported by routers and probably not exposed to significant DDOS leverage)

SLAYER - Eyes of The Insane

Or a different player (owner), undisputedly. That was the naive thought committed, I still hold other uneducated thoughts, so actually let me forget this now gg. I guess there tickets, logs, forum posts of animal UnitAI that one can pay for with his time to uncover. Also UnitAI has 6000 lines, which means it takes more than 6000 lines of your life away when you look at it. Doesn't mean that my naive thoughts that I forgot might have been true in retrospect. I'm currently on a different construction site, perhaps the others can tell you more. It would have the advantage that it is not linked to animals at all. And the simulation components are as far as I understand the situation a part of Pyrogenesis and not 0 A.D., since they should also be usable for mods that don't base on 0 A.D. templates/art/history. (For example starcraft like RTS with arbitrary entities that aren't animals seems like a realistic use case for Pyrogenesis with a solid UnitAI)

Oh it's public now. I don't know if it was public before already or if someone moved it. Anyhow, the linked graphcis are broken, but the cited graphcis above comes from this thread. The links were broken 2 months ago and there hasn't been a response to my posts and proposed fixes yet. (That's what I meant with noone handing out gifts.) (Editing the thread manually may work for this specific thread but won't scale to fix all old threads.)I'll just funnily attach it here: I guess the text is more important, but if the graphcis are missed, the text that refers to the graphics becomes less comprehensible.

I didn't read all posts of all related threads, but these are relevant points I found so far: Account for the previous game designs: Hard-counters were designed already in 2004, it ought to be implemented or consciously argued against it, not ignored. Account for the development process: Reach out to devs: It is rare that people make gifts towards each other, seeking out developers and asking them questions when and how something may be reviewed is much more successful than offering something and hoping that someone will come around and do the hard work without being bothered. It shouldn't be like that, but it is. Package it for devs: Entirely unrelated features should not be added, the more features are combined in one diff, the harder it becomes to review and audit, the more oversights and mistakes are added, the more has to be fixed in retrospect. It can only be committed for a24 / svn, not a23. The longer this is postponed, the more changes gets added to a24, the harder it becomes to transform it for a24. Successful communication: Communication is bidirectional, so I guess if we haven't conveyed the information what we wanted to change, then we probably didn't express ourselves appropriately. But communication is bidirectional, so you also always have the choice to read statements multiple times and ask questions for those that you didn't understand. At least I asked the above two points before in the lobby and on the forums already. About the design stage, I didn't reall all versions from the design documents, nor all related forum threads. But fatherbushido posted it in 2017 already, we reminded in december 2018 again to evaluate that, it must be done before thinking about having your proposal commited. The source for this hadn't been posted. It's from 2004, so from the time when 0 A.D. was closed source (< July 2009). After 0 A.D. was open-sourced, noone had spent the time to try to make these relevant threads public. I spent the last months on IRC logs with that regard, when/if I finished that I will try to publish it for all versions of the design documents (unless something changes my destiny) and relevant old forum threads, but this will take a while. Perhaps this thread can be published, perhaps as a PDF. It was discussed by WIjitmaker (project founder), Acumen (programming manager) and Phoenix-The-Real-Deal (Ken Wood) This should be accounted for, at least by the one who does the review if not by the general public.

The Polar Sea map originally introduced the wolves as non-domesticated animals and made non-domestic animals controllable, so that the wolves could be ordered to attack the player. But following D156#6745 the wolves were changed to a domesticated animals rP19323 so that they can both receive orders and roam. I think using the name "Controllable" would be more descriptive than "Domesticated", since there are some domesticated animals that can't be ordered either, I guess domesticated sheep sheep are not ordereable in real life directly but they are only fleeing from orderable domesticated wolves. Also entity component properties are supposed to determine the behavior of entity components, not Identity classes. But I speak from ignorance as I don't know what the previous generations of developers laid out in plans (and I don't intend to work on UnitAI right now).

So there are three classes of contributions: Hard-counters (core idea) Prerequirements / Dependencies Unrelated goodies If that is correct, then I would again recommend to stop working on unrelated goodies, get the dependencies uploaded if you want this in Wildfire Games 0 A.D. (like FeldFeld did with the hard-counters tooltip). Then get the hard-counters in. Then you can continue to work on unrelated goodies. The more unrelated stuff is added, the more time-consuming it becomes to split it apart later, for you, anyone who would commit it, and anyone who reads it years later. If you want to only have it a mod, I won't stop you, but if your objective is to not have it in a mod, there has to be some theory how this happens. I understand many people offer their contribution and leave it there, but reality is one chances to get something committed increase by some orders of magnitude if one actively looks for oneself how to get it in (i.e. trying to identify the developers, getting them interested, making it as easy as possible for them to agree). The mod was tested for 5 months now, so I guess you have sufficient results to stop adding new unrelated features? I mean it's your work and WFG review is the end-boss, your choice, I can only show the situation.

I seem to recall that you wanted to make a hard counters mod in 2016, but then didn't do so because you thought the developers would review and reject the idea, or reject the idea based on prejudice? The problem is more the missing caretaker. But I don't recall ordering you to do something, but rather explaining how WFG operates with regards to committing such changes, which was mostly creating a branch that has one single feature and nothing else, getting that tested, then committed, then considering the next feature, rather than stacking many features. Secondly the design document needs to be checked. 0 A.D. started in 2001, people wrote on design documents until 2003 until development was started. There was a link to the hard-counters in the design document since 2017 in the thread. In december 2018 we reminded that there is this design document that should at least be reviewed. One can still decide against it if it turns out to be a good idea. After that I had tuned out due to several circumstances. But I didn't order it. Problem is if one spends some time to give some valuable feedback, one gets implicated (i.e. one gets bad reputation if one provides some feedback for improvements but doesn't finish off with a complete review, test, discussion, commit, fixing bugs or balancing defects of that afterwards), so developers are often faced with the decision to not respond at all, to go all the way, or to appear as someone who orders someone to do additional work for no reason. I.e. one has to bring a lot of dedication and time if one wants to start working on something. If I look at the description on the first page I see so many features. Suppose the hard-counters were tested against the design documents and there is a developer who wants to commit the hard-counters mod, it seems very difficult now to review, distinguish the changes: It should be development of one feature (hard-counters?), then that should be tested and committed, then one can add the others afterwards. FeldFeld did everything correct with uploaded the tooltip to display hard-counters in D1707. I understand that you take the opportunity to test multiple features if you already make a mod for hard-counters, but to me doing this is more assuming responsibility than doing something that is entertaining, i.e. to me it's hard work to do it right and (reviewing or development). I'm sure it contains a lot of hard work for you as well that you didn't want to do. If you wanted me to review this, why not ask me, why not check for the design documents as we asked, why keep adding stuff instead of closing the development and proposing it to be committed as is? Perhaps the plan is to have the above list of features all committed as above (similar to the scythetwirler balance branches from years ago)? I remember we also had a discussion in the lobby to split these into one feature per commit and that you mentioned that it was a lot of work but doable. But why not avoid that extra work by adding only one feature at a time? I'm open to alternative ideas, but I'm currently inactive (I either get stuck reviewing day to night because everyone wants something and expects another review or test and commit after one review as posted, or I have to not even give the first feedback). The other developers may also be open to different ideas how to get the best and acceptable contributions into the game. One's chances to find a developer are greatly increased if one actually looks out who is active, who is involved in which areas of development, which deal they could accept (i.e. making it as easy as possible for them to accept. For some it may be easier to review one feature at a time, for others it may be easier to commit a huge bag of features. One also has to consider that that merging balancing branches makes it harder for future people to look read what that commit changed and to identify possible mistakes or improvements in it). Target audience, indeed. My perception has been / is that the experienced players aren't an exclusive target audience, but they are the ones who are most able to identify defects in the balancing, since they run the laboratory tests in these petri dishes all the time. Less experienced players may be considered part of the target audience, since they are many too. But less experienced players either stop playing or become more experienced players, so it's questionable to me whether to optimize it based on the mere fact of quantity of inexperienced players. It should be done for the people who enjoy the game IMO. Singleplayer mode is currently only supported against Petra and gaia zombie waves, no campaign mode. So it's considerable that the difficulty of the AI influences the sensitivity of the entity template / tech / aura balancing. However, if all the experienced players discover that some units are OP or useless, these units are also OP or useless against Petra bots, zombie waves and campaigns using that template, if the according AI uses the templates as effectively as possible. So there have been historic clashes between SP and MP players that develop the game. If one doesn't play online multiplayer and the AI isn't as player-terminating as competitive players, then there is more incentive to save ones time with figuring out the perfect balancing. If one wants to play this game against his online buddies, there is more incentive to invest more time on testing so that the game is actually not broken (degenerating the gameplay into snowballing of one OP unit and clicking the fastest). So mostly I think it partisanship should be tried to overcome by contributing in such a way that all stakeholder interests are represented and no fact left neglected, ... and whatever. A policy (that might exist and just hadn't been uncovered from the archives) could restrict whether or not and how far and for whom and for what purposes one has or has not to care about policies. I took steps one at a time. If we get 10 reports about unit X being too strong every day from the players, there must be something to it, especially if one can reproduce it in a test case. So I mean we don't need a policy if there are intersubjectively witnesseable facts that determine quality of life of users (combined with the proclaimed intersubjectively valid argument that SP and MP have effectively the same balancing constraints, as a competitve player or competitive AI uses the same templates regardless. Open to controversy.) Thanks for the list, reminded me of some better memories, and it provides a good example of easy research that new contributors can do!

Updating the coordinates in the command in the JS file allows you or anyone you might distribute it to to perform a consecutive update to the heightmap.

You propose someone to write a different design document. My point was that the ones who do the implementation should not leave things up to chances but should attempt to keep the game enjoyable (even if you don't consider it enjoyable).

(Maps with two opposing sides have the same area and same maximum traderoute length ideally. Differences become very pronounced with normal and smaller mapsizes. The number of mines, trees and hunt is proportional to the area.)

Translating the map means terrain is lost and has to be filled with something else. Since it uses a heightmap, the blank region was intended to be filled by the heightmap data.

On the one hand one can change the mapscale, on the other hand maps that don't use heightmaps also use custom scales, on the foot there are some heightmap maps that use more proportionate scales (ratumacos). Mediterranean: There are more examples, Hellas picks a random subset that meets some requirements (between 20% and 30% water), or Jebel Barkal which loads an Atlas map (you can load the image in atlas and save as a PMP file and load that in the random map, but that means one can't recenter it afterwards), Lower Nubia combines a heightmap and a composites to get a more precise shape of the nile, Elephantine uses OpenStreetMap data (since the blue marble data is very blurry when zooming in to that level). The comments are all in the headers of the JS files.

That code is posted in the mapscript. According to https://tools.wmflabs.org/geohack/geohack.php?pagename=Red_Sea&params=22_N_38_E_region:EG_type:adm1st_scale:100000000 which is linked from https://en.wikipedia.org/wiki/Red_Sea I didn't confuse latitude / longitude. Chosing a different heightmap is an iterative process, one has to gradually change decimal places until one get's the optimum.

Credit goes to _kali. It's easily possible to move the heightmap: * wget https://eoimages.gsfc.nasa.gov/images/imagerecords/73000/73934/gebco_08_rev_elev_C1_grey_geo.tif * lat=22; lon=41; width=30; * gdal_translate -projwin $((lon-width/2)) $((lat+width/2)) $((lon+width/2)) $((lat-width/2)) gebco_08_rev_elev_C1_grey_geo.tif red_sea.tif * convert red_sea.tif -resize 512 -contrast-stretch 0 red_sea.png Problem is that it heavily influences balancing, all players are supposed to have roughly equal chances to victory at gamestart, but often the game has already decided after pressing the Start button. Pyrogenesis only has support for one level water plane, but in the desert some areas are dry despite being below water level (for the same reason, the Nile on Lower Nubia has few water). (Same with the Nile dams on Lower Nubia) One can add some code to modify the terrain artificially afterwards. (Fixing it in atlas means the fixes are lost if one recenters the map)

"Misc Hacks" menu item

But you understood that I don't mean that players should count tiles, but take a look at the number of 16*16 groups of tiles that are highlighted differently? So you can see area one has 5 groups of 16*16 tiles, the other area has about 4 groups. That's how you can get a more precise estimate than mere eyeballing at the same pace, without having to place fields, or playing.

There are more indications than individual terrain tiles, groups of 16*16 blocks, and two lines through the center.

Wireframe mode

If the purpose of a review rule is to ensure that the commit was accepted by one person determined by the repository owner to be reliale and trustable, then this clause only costs more time and requires three instead of two people: If person B was not determined to be reliable and trustable to decide over the fate of a diff by the repository owner, then the postulated purpose of the review is not satisfied anymore (refs 2016, refs Diffusion_of_responsibility). If person B was determined to be reliable and trustable to decide over the fate of a diff by the repository owner, then person B would receive trust in a formalized way distinguishing it from untrusted members, which is equal to providing commit access for that purpose, without involving an additional person. So regardless of that clause, the difficulty is developing developers and developing trust. And as WFG history 2003 to today shows, luck in getting computer science students willing to develop on a daily basis. The process can't become simpler than one person knowing what they do if not sacrificing the objective of the deployment conditions to investigate the correctness of all parts of the development stack. https://en.wikipedia.org/wiki/Waterfall_model#Model https://en.wikipedia.org/wiki/Software_verification It's inevitable that if noone tries hard to disprove the correctness and completeness of a proposal that it will be defective. If each commit adds one or more defects and if the project is not finished until the defects are gone, the process will not converge towards a finished product. If a developer needs a guideline or someone else instructing them how to review a patch, then that rather indicates that the developer lacks the knowledge how to skeptically examine the correctness and completeness of a proposal to begin with. The developers that can determine the ramifications of the patch don't need instructions for that. The developers that can't determine the ramifications of the patch won't benefit from these instructions (because it is necessary to deduce the ramifications of the proposal in order to investigate the correctness and completeness). For code changes, consider a one-line change to the 6000 lines file in UnitAI. Impossible to test it based on any guideline. For balance changes maybe, although it's probably only reifiying what balance testers already do. Receiving 5 times the same bugreport every day for half a year and worse makes one appreciate the silence of users enjoying a balanced bug-free game. Alternatively going offline works too. Balance patches were mostly committed by the Wildfire Games members who were actually playing the game. Reluctancy to commit balance changes is attributable to many reasons, getting artists or programmers to commit balance changes is probably not the most time-efficient or quality-assuring procedure and the reluctancy would be justified in that case. Reviews eat a lot of time, extraordinary much time for reviews outside of the comfort zone. So better figure out who will create good quality without help and let them do their thing. I suspect Wildfire Games members currently don't play the game, there's just a balancing department missing it seems. The question is only whether a balancing department makes sense at all (due to the overlaps with the design department which formulates some existing constraints (DD) and can't operate in the realms of realistic development without knowing the confinements of realistic development). About balance patches in particular, if the more five most trusted players already have eight different opinions on the patch, it's hard not to become reluctant. If those however would cohesively demonstrate for one balancing patch and can substantiate their claims well, one would have to be reluctant to not commit or provide commit access for the ones identifiying as active Wildfire Games developers. Getting someone else with commit access to spend their time is one of two solutions to the stated problem. (https://www.youtube.com/watch?v=SVY0D37FyBU)

(#5147)

(The rejoined player has g_Farms empty, so when the water rises, the non-rejoined players have that field removed but the rejoined player doesn't? Should be fixable by having g_Farms = GetEntitiesByClassor something. Or if it it's a Trigger property then it's serialized)