elexis

Wildfire Games uses the development platforms including the forums in order publish as much development history as possible, so as to minimize the cost to reuse and improve the code for any member of the general public.

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.

Dark Funeral - Live At Peace and Love Festival https://youtu.be/z0hU5zOkbPo?t=1671

If you find someone at Wildfire Games who tries to accomplish their own goals, please notify me! Finding people who try to accomplish goals is one thing. Wildfire Games should exclusivley operate for the furtherance of charitable purposes, for the creation of a public good. I don't recall people being here to do their own thing but to do something for the public benefit, for the software and the organization. Hence I mentioned: (or analogously demonstrate the benefits of a feature if committed) As long as the usage terms are met, contributors are entitled to ask for a review of patches they upload to Wildfire Games development platforms. One can also ask more than once without actually bothering the people. And one can ask a different question everytime instead of repeating oneself. What does it hurt someone to receive a friendly mail to ask for 5 minutes to voluntarily further a charitable cause? If the patch is perfect, the proof of correctness undeniable and delivered along, all possible questions of the reviewer anticipated, then ideally you're only asking for time to understand and approve your argument and grant authorization. Hence: The few-sentences clause however implies that one can ask people only few times if they are not motivated to volunteer further. So if people aren't active themselves (review spree), there is only a limited window of opportunity to get responses from people. So you have to work with what is there and try to achieve the most with the least effort for the requested person. That inherently should motivate the requester to work on the more important tasks first, and those should be tasks that are important for the success of the project, not only for one person. There is a small grammatical trick, one can say "bothering people is bad because X", this way one removes the subject component "I believe" which obfuscates the reason why that belief is not a random one, but an understandable one. Another communication enhancement is to not ask people to do anything, but just to show how great a feature would be. Then only by chance the person could figure out that he could actually commit the patch. Making their mouth watery without asking anything. The more one restricts his own messages to the properties and goals of the task, then people can jump in and drop out at anytime they want (something between textbook voluntarism and post-volunteer voluntarism I guess). This states how people are expected to behave (should), but the problem stated how we expect people to behave (actually do). There is apparently a discrepancy between what is the case and what should be the case. The conclusion can't be to remain passive but to determine why the discrepancy exists, and which means you have to change that. As a reader of irclogs and being somewhat familiar with the devs, you can exactly find out who has which weaknesses. But one can work around them, or better, one can find the actual cause of the discrepancy in expected behavior. For example in some cases I remember that I had explained in long forum posts (30-40 sentences?) how some thing worked, reprhased the thing three times, but the only thing that the user on the other side needed was the definition of a single word used, and suddenly he understood everything. Communication is a tool, it can and should be used and adapted to the problems at hand, instead of assuming that everyone can be triggered with a simple rational request. If the people didn't respond with the communication pattern chosen, one didn't use the right "attack vector" for the problem yet. So the question is to find the magic passphrase to the brains of people that make them do stuff that is beneficial to the general public, without lying, without being unkind, without being selfish or so forth. It's a hack and we should only use it with our whitehats on (not the racist ones). See comments above with regards to "exclusive operation for charitable purposes" and the voluntarism mechanism. Where did you get that vocabulary? I'd have to look again, but I think the Community Guidelines discourages nagging. There is not only the choice between being silent and nagging. If people are not motivated then one can try to improve the presentation. Putting pressure on people can demotivate them, whereas making their mouth watry can motivate them to support the cause. If every "you" reference in the sentences is removed, there is no personal pressure expressed in the sentence. If you ask people whether they want a pizza, they might decline because they have other plans. But if you happen to bake one, they might trace the smell to the concerned item voluntarily, even without any verbal information. If (1) effort minimization (2) exclusive operation for public benefit aren't incontrovertible, they at least stand unrefuted for now. The other aspect, (3) appeal to responsibility is restricted to addressees who assume responsibility. And one can appeal to responsibility of a person without blaming the person. If one can show that there's a bug that makes the game crash and that the situations in which it crashes are not uncommon, that's objectively bad and who wouldn't want to fix that if he had a verified patch. I just often have the feeling people constrain themselves to follow the guidelines on trac, and give up if the branded workflow doesn't flow; instead of taking a step back, using their creativity, analytic thinking and good faith to determine what can be systematically changed to change systematic problems. Carrot > Stick. This is a perfect process in theory. But the observations and measurements say it's not working, therefore something has to be changed systematically. While WFG does have authority over which code is ultimately committed, WFG does require honest, trustworthy and capable people to take the responsibility that they don't have the capacity to take. First phrase the goal to achieve (for example get a patch committed), then observe what the realworld situation is (who hasn't left completely yet), then try to design a process that can achieve the goals with the existing resources. We can't just take a process that works well for a billion dollar company and apply it to a group of 5 volunteers without modification. If we see someone who can't swim, we don't let him drown either just because we expect him to be able to swim if he enters the deep water. At least many people work on 0 A.D. because of 0 A.D., not because of the participation in the workflow being the goal. If the goal isn't the path but the objective, then it's worth considering to change the path to achieve the objective. It's not forbidden to upload patches because uploading patches is fun, but some upload patches because they want them committed. The worth is in the commit, therefore, the question is how to obtain the commit (and in the long term, see how WFG can get more active people that can commit patches). "here it is, using it would benefit hundred thousands of players for reason1, reason2, and the patch is correct because of reason3, reason4, something friendly" (so you only need to press the red button as you already saw it's good and as you already know the related code) So there's a big difference between asking people to do a lot of work (asking for a better design) and asking people to do little work (reading a proof that this is undeniably the best design). Basically one can do the task of the reviewer beforehand except doing the commit. (The law places no duty for reviewers operating a non-profit organization to volunteer their services, so there is no moral duty for people to review patches. Therefore one can't argue it' to be WFGs obligation to move any finger, it has to go through voluntarism if there is no contract.)

We use the software development platforms precisely in order to remove the need for communication and action to be immediate and allow delayed communication and action. Tickets on trac, reviewable patches on trac and Phabricator, concerns on Phabricator don't lose their validity or their informative value over time. It is one of the reasons why we should gather all knowledge about a patch in the revision proposals / trac tickets, not only enough information to get it committed, but provide information for the people who will audit it years in future years. And for that reason we also preserve and publish the versioning history, not hindering anyone in any way to extend the free software. I have three requirements on my list that need to be met for me to be motivated to commit code, one of them has been established, the other two are in progress. It's just demotivating to walk alone, so months pass by. But I do intend to work on code if I can fix the remaining two metadevelopment problems, and if nothing unpredictable stops me from having as much computertime in the future. So such information is valuable in the distant future, and I would act in the near future, depending on what near means. The other participant in the discussion has the freedom to act on the information in the near future in various, on Wildfire Games platform for instance by finding a way to get someone to commit a patch. The problem in most cases with that is that people don't want to spend time. If a patch uploader can (1) demonstrate undeniable proof of correctness of a proposed patch within few sentences, (2) demonstrate that there is damage to players if the patch is not committed and (3) show a responsibility of the contributor to commit the patch (him having introduced a defect for instance or him having done the most maintenance on the code), then that person has the choice to commit the patch with as little time as possible, maybe within less than an hour or even minutes, and has the incentive to do so. (As in bothering people in the most friendly way to get a commit and never resigning until the commit happened.) No, but I would wonder graphics/graphicsgraphics would hold. The absence of a defect does not imply the absence of possibility improvements. It may be argued to be a defect if it would be shown that the additional complexity is not necessary to achieve the same purposes of the code. Maybe you do based on the current information, but is it the best choice for the general public and can we convince our self-critical minds and communicate it to others? I don't have an opinion yet as I didn't gather all information, requirements, alternative solutions (no condemnation without investigation). Indeed we don't have to dive into this now if we don't intend to commit something in the next 2 months or so, because the topic won't go away until the purpose and implementation logic of the user mod became clear as crystal to any developer and any user encounteing the mod, including Mijorious. So if there was an unclarity and discoverable improvement, there will be future threads or tickets or revision proposals to discuss it. .

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.

Yes So it was "Yes, the comment wrong in four ways", not "Yes, the comment is wrong in four ways or I am wrong in four or less ways". The bad news is I only have one banana left, the good news is that we discovered actionable information.

Joke acknowledged, one of the two propositions is obviously correct, and the sentence can be interpreted as only asking whether at least one of the two propositions is correct, not which of the two it is, that is funny. But the purpose of the forums is to further 0 A.D. development. Although I read this precise pattern of jokes (answering a question syntactically correctly but intentionally semantically incorrectly by omitting information) the first time from this account, it had been seen as unconstructive by readers and moderators in the past. So it should be made transparent to users as soon as possible by Wildfire Games what communication patterns may result in needless disputes before it can accumulate and escalate. (So I clarify this not because of this single incident but because of the entire history of this pattern.) If people complain about not being asked before taking decisions, it might be the that they don't respond to questions with answers but intentionally don't answer the question, but make a joke out of not answering it, and possibly even taking it as a sign of a weakness of the one who asking (lack of knowledge) rather than offer of participation in the decisiontaking process. Phrasing a hypothesis as a question instead of a statement establishes space for the communication partners to determine answer without any presupposition, leaving room for providing reasoning in answer and avoids phrasing statements as a priori fixed facts. (For the same reason foldernames that are jokes that don't inform the reader what the folder contains and not contains are inappropriate, especially when the files in that folder are claimed to be an area of code of supreme importance.) That's what I read in these three letters, but perhaps you meant those three letters differently and I am bananas I suspect it's not the only alternative. The question is whether it's a good idea to overwrite data in the svn dev copy from Pyrogenesis, or whether it should not instead behave identically for dev copies and release copies - always writing to user/ or whatever that may become. I mentioned two possible alternatives: Thank you for your answers!

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)

As I never fully understood the purposes of this mod and why it's only used for development copies, I didn't want to say something wrong, so I only said that it's a reserved keyword. I recall the user mod mostly from the fact that it resulted in the same code marking replays as either comaptible or incompatible depending on whether one runs a code checkout or a release. It was hotfixed by making the replay compatibility check ignore the "user" mod. The same check was added to other places. So the question is whether one could achieve the same the user mod was supposed to achieve differently, without having to spread exceptions throughout the codebase. The purpose of the "user" mod is to allow users to store custom maps / mod data? I know it's in Gamesetup.cpp, but the information there doesn't clarify the purpose of the mod: const bool add_user = !InDevelopmentCopy() && !args.Has("noUserMod"); // Add the user mod if not explicitly disabled or we have a dev copy so // that saved files end up in version control and not in the user mod. if (add_user) g_modsLoaded.push_back("user"); From reading the file, it is not clear what "saved files" refers to. But it doesn't sound like an invitation to create a "user" folder to store mod data. If that's the purpose, it should be added to the ModdingGuide or similar. "saved files" could mean for instance savegames or modified JS/XML code. The idea comes #895#comment:7, implementation from rP13472 fixing #1940. So the historic use case is Atlas saving maps indeed, just like the user reported here. So the reason was to provide Pyrogenesis a writable path for both dev copy and for a copy fo the release. I wonder why it was chosen that Pyrogenesis should write to a different location in dev mode than in release mode: Yes one can open an existing map, modify it, save it, and commit it. But one could also open the map, edit it, save it, move it to the data path and then commit it. There is the posisbility that Pyrogenesis overwrites gamedata that wasn't intended to be overwritten, possibly without the dev noticing. If only the developer can overwrite data files, then there won't be any accidents. One simplification of the existing implementation would be to launch the "user" mod in any case. It was mentioned in #1940#comment:3 too. So sounds like a committed improvement with an open question that future users have to answer to deal with the unexpected implementation. The other question is whether a "user" mod needs to be invented to achieve the given purpose to begin with. It could just as well write to a "public" folder instead of a "user" folder? Perhaps the expectation to always have a Pyrogenesis writable path can be implemented without introducing multiple unexpected behaviors. Perhaps there were discussions on IRC, the ones on trac are very brief. At the very least, the reasoning should become clear from the codebase itself, and the wikipages should answer related questions. Going back to the code: const bool add_user = !InDevelopmentCopy() && !args.Has("noUserMod"); // Add the user mod if not explicitly disabled or we have a dev copy so // that saved files end up in version control and not in the user mod. if (add_user) g_modsLoaded.push_back("user"); Is the comment wrong in four ways or am I wrong in four or less ways? Add the user mod is added if not explicitly disabled AND (not or) we have a RELEASE copy (not dev copy) so that Pyrogenesis always has a writable path "That saved files end up in the version control and not in the user" is the purpose for _not_ launching the user mod under development copies. Even better than fixing the comment would be implementing something that is clear without comments, without having to study the code or the metadata, or contacting a spirit medium.

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. */

Title != filename. A map titled "Good" could be found in bad.xml. http://trac.wildfiregames.com/wiki/GameDataPaths https://trac.wildfiregames.com/wiki/Modding_Guide

Removing RangeOp definitely sounds like getting rid of a lot of ballast. I'm sure we can get a factor 8x or something if we remove all library bottlenecks and silly code we find. But if we use the approach to increase the grid resolution by a factor of 16, we still need to see if we can go beyond an array of a native-type array proposed in D1637. I guess one should dive into implementation (commit removals, find most significant bottlenecks), but if we had some theory to make TileClass grids 16x faster, we would have the knowledge that LordGoods screenshots would be implementable using higher resoluted grids. Perhaps one could also get away without using higher resoluted grids, or only using them for a local area. Consider the bush|path|fence|field screenshot again. We don't want to hardcode that a bush is placed every 1m parallel to the path, because thats too regular and looks unnatural. We want random placement constrained to specific distances to other areas. It sounds like we only need the high-resolution check in close proximity, and can use the low-resolution check for distances greater than 1. I'm reminded of another performance improvement idea I had: The performance degenerates drastically depending on the the distances to tileclasses in the constraints: avoidClasses(clWater, 0) finishes instantly, whereas avoidClasses(clWater, 40) is terribly slow. But if we know in advance that there is only a check against distance 40, then we can paint the water and extend that area by 40 tiles, so that avoidClasses(clWater, 40) can finish instantly too. Stuff like that. It seems code is a vampiric lifeform that thrives of developer lifetime. Yes, that's exactly the XML I meant. I'm not sure what you mean with serialization copy paste, but XML is a form of serialization of the entities, and loading XML is a form of deserialization to load them. The code to parse Atlas XML files is already present in C++, only need to expose it to JS. We did the same for Atlas PMP files last release.

Hill Cliff Desert FertileLand Water IrrigationCanal Passage Player BaseResource Food Forest Rock Metal Treasure City Path PathStatues PathCrossing Statue Wall Gate Road TriggerPointCityPath TriggerPointMap Soldier Tower Fortress Temple RitualPlace Pyramid House Blacksmith Stable ElephantStables CivicCenter Barracks BlemmyeCamp NubaVillage Market Decorative Consider the most complex random map in a23 (jebel_barkal): These are 40 rasterized areas. The building grids are necessary to control distances between buildings (houses close, fortresses far apart). For few buildings it makes sense to store the polygon. For water and paths, spare voxels might make sense. But for Decorative (bushes, actors), there is the chessboard situation and we need rasterization for something like the entire map. So we can save probably 40x as much memory. But spare voxels and polygons are slower than rasterization, no? Random maps already consume 30 seconds or more, we can't make it 16 times slower. So the only performance optimization possible would be optimizing rasterization, i.e. what to do with D1637, maybe use C++ magic for 2D bool arrays? The only other performance improvement I can think of is making the maps smarter (less checks) instead of improving the library. Actually I didn't check whether the OOM really comes from TileClass bool 2D arrays or whether there aren't many parts in pyrogenesis that fail with mapsize >= 1024. (But if we increase the resolution of TileClass grids by a factor of 16 to create LordGood grade maps, it would be better to not make mapgen 16 times slower and not 16x as much memory, when it already is too slow.)

Terrain would be good but not necessary. The paths on this screenshot are actor entities. Entities, we need the information to place Entities. Look at the fence, field, bushes. Placement must be 2-4x more precise than the tilegrid. Good for few large entities yes. But bad to describe 10.000 trees or 40.000 bushes! It looks like this: Black = tiny bush / tree White = empty Sparse tree would consume like 5-10x more memory than a raster grid for this case. And we need bushes / actors everywhere, on the whole map.

One of the most common reasons is as feneur mentioned: (1) not looking at the correct maptype in the maptype dropdown in the gamesetup, (2) not looking for the map title entered in atlas in the map selection dropdown in the gamesetup. That sounds like you created a directory for a new mod, but didn't add the mod.json file and didn't enable that mod in the options. Modding_Guide. If you didn't intend to create a custom mod, it should be "public", but I'm not sure if if the public folder is launched if public.zip had been launched before. Also "user" is a reserved name for mods. Just create "mods/yourmaps", add the mod.json file and your maps to "mods/yourmaps/maps/scenarios/". (I hope I didn't add a typo.)

You misunderstood me: Not the heightmap, nor the texture map. TileClasses. They rasterize arbitrary areas. For example the area of all water on the map, the area of all forests on the map, the area of player 1's initial territory on the map, the area of all paths, the area of a gaia city, or whatever area the mapper defines on his map. The random map script author can use these areas (TileClasses) to determine where to place entities and so forth. It uses rasterization to represent the area, basically a bool 2D array. The code must be 100x faster and 16x less memory consuming if we want to place entities as close as on LordGoods screenshot using rasterization. nani proposes a performance improvement for that in D1637, but I don't know if we can't use something else than a 2D bool array. We might want to continue that discussion at the revision proposal. That could work for the entities too. Assemble entities / actors in Atlas, save as XML, load from random map script. Thus no need to higher resoluted bool 2D array. That would be good for some shapes, but bad for many others. Imagine a checkboard map where 50% is part of the area, 50% not part of the area (for example bush and grass actors). Describing that area without rasterization sounds extremely bad for memory, no? Even if only 25% of the map has this checkboard pattern.

I had split the public/mod mod into pyrogenesis/pyrogenesis-gui/gaia/0ad mod in a branch to #5366. The entire simulation code is moved to pyrogenesis, so that 0ad doesn't introduce any simulation code, and other mods like 500ad can just come with artwork and templates without adding any code or reintroducing gaia artwork. Ideally the AI would be agnostic of the 0ad templates and balancing, so that it supports everything that the pyrogenesis simulation system supports. Then the AI could become part of pyrogenesis and reused by any mod without modifications. At least the code left Wildfire Games version of Petra is dependent on 0ad, so that I was wondering too whether it should be made a separate mod back then. The problem with splitting into too many mods is that it can increase the effort of the user to activate all mods necessary to play 0ad against an AI, and it leaves the possibility for the user to forget enabling Petra AI and then wondering why there is no AI opponent available. Now that Petra is developed independently, there is another considerable benefit to splitting it, which would be that the code can be disabled with one click and replaced by a different mod. But that would require the new Petra to be compatible with vanillas codebase, which sounds unlikely. If it was compatible, then one can launch the new Petra without splitting the old one into a mod (relying on .DELETED whre needed). So still not sure what's better. Mostly the splitting is useful for redistributing everything that is wanted but nothing more (for example redistributing pyrogenesis with a game content mod but without 0ad).

I see 9 hidden posts @Glestul zip it

You clicked on "Agree"

Well, the wall placer choses closest wall piece length (small / medium / long) and the excess length is hidden inside the turrets, no other means of hiding that I'm aware of. Pretty sure one can extend from every turret, @Hannibal_Barca has perfected his skills of placing walls in places that noone expects to be buildable and can perhaps post an exemplary screenshot. How would the mechanism work with standard lengths? Just no hiding inside wallpiece lengths? I wouldn't be surprised if that's already possible with the templates, @s0600204 was the last one to work with these wall templates in vanilla and might know. But the problem is that if there is literally no adaptation, that players might not be able to seal off their walls. Consider an area that has the length 10 meter / feet / bananas, but wall piece lengths are fixed to size 4. Then you can either cover 8 or 12 meters / feet / bananas. If there is some terrain obstruction at 12, one won't be able to close the wall off at all. And walls are only effective if units can't walk past them. Even if there are no obstructions anywhere and the player only wants to create one ring of walls, the last piece might not fit perfectly and thus remain open. If you don't mean to remove adaptation of wall piece lengths, I don't know what you mean. At least in some cases I agree, two wall turrets very close together looks ugly (can also break the balancing). @vladislavbelov We were discussing a random map generation problem in the post above. Currently we have a mapsize² grid, that's up to (512 tiles)² and realized using an array containing a JS typed array (u8 I think). (1024)² already gives out of memory errors, that's why 0 A.D. mapsize is limited to 512. The purpose of the grid is to remember an arbitrary area, for example all water on the map, or all forests. The problem is we need to increase the resolution of the grid if we want higher quality random maps that look as good as on this screenshot. And we need one grid for every information to remember (one grid for water, one grid for trees, ...). The area can be arbitrary, so it uses rasterization (for example paths are very random). So we can't store the shapes. So do you perhaps have a recommendation how to store a rasterized area with as few memory as possible without too much performance loss? In many cases, the area will only be a small subset of the map area (only 10% of the map have paths), but in other cases, it may be a lot (30% of the map being forest). I thought about BSP to improve lookup times, but I'm not sure how we can save memory when working with so many high resolution grids?

I think the application forms come from back in the day when 0 A.D. hadn't been open source yet. Indeed http://trac.wildfiregames.com/, especially http://trac.wildfiregames.com/wiki/GettingStartedProgrammers are the entry points. The AI receives some information via C++, but other than that it is written almost exclusively in JS, so it is easy to start modifying it. I've also wondered whether it wouldn't be cool to have multiple AIs and have them fight each other (reminds me of playing counterstrike offline against bots). While you can probably find some tickets on trac, I would recommend to start playing the game, become a bit familiar with how it's played, and find some obvious defects or missing feature of limited scope. In your case you might want to observe bots playing instead of playing yourself. If there are errors popping up, that can give you a good starting task. Other more obvious choices are "silly" behavior of the AI that could be redesigned (silly for every human, but it's not so easy to detect such behavior with code). For example trade routes through enemy territory were a frequent example. I don't know if the author who is currently working on a fork of 0 A.D. has worked on that. If you have specific questions about the Petra AI, you will probably get a more qualified answer from them, as Petra is the product of mimo. There was a previous AI in 0 A.D. called aegean by wraitii, but that was removed long ago. Creating a new AI sounds really good, but there are many strategies that need to be accounted for. For example I imagine naval transport to be difficult. But perhaps one could also start with an AI that is optimized for Mainland. In case you have created some kind of patch, 0 A.D. also provides the possibility to run games from commandline without graphics, allowing to test it more quickly, see README of the source.

The ingame wallbuilding changes the size so as to adapt to the playerchosen area to cover. There are small medium and long wallpieces, and any length is achieved by hiding excess wall length inside the turrets. I guess you know that already. The problem is that it sometimes looks odd? It should be possible to adapt the length numbers in the templates to not get ugly results. If one only uses fixed length pieces, it won't be possible to wall off some passages. It might even result in not being able to close a circle if there would be no adaptation. So if they sometimes look ugly, I think it should be possible to use better numbers, so that the ingame wall placement algorithm can chose 3 medium wall pieces that look better than 4 short ones for instance. Or what's the issue that needs remodeling? I forgot the OOM. That was the reason we support mapsize 512 (giant) and not 1024. You are right that one could avoid initializing a grid for the entire map, but only allocate memory for the parts of the map that were written too. The problem is that it map authors probably need to be able to create something the the high res grid and then refer to that grid later on. So one can't discard the grids automatically after a single processing step. Using Binary_space_partitioning one could access the high-res-grid areas with good performance. However partial grids won't save much if the the majority of the map area uses these grids. Map authors could deallocate the grids if they don't need it anymore, but a solution that doesn't require these additional steps would be easier to handle. I recall the alternative was just storing all entity shapes, which could be extended to include visual actor shapes. The RandomMap object already has a list of entities stored and can easily lookup the obstruction sizes of the few templates used by the map. With BSP one could do the collision tests quickly. Actually we don't want to test for obstruction collisions but want to mark arbitrary areas on the map with a tag (tileclass), but that could still be solved by storing area formulas instead of rasterizing them.... At least for rectangles and disks that would work, but not really for paths, meh. Perhaps these grids could be eh compressed with lzma...dunno...

(x, y) -> (-y, x) should be cheap enough, so it depends on the number of calls mostly. The important part is to abstract this somehow. The magic of random maps is that one can do anything with the createArea(Placer, Painters, Constraints). Every feature so far could be refactored into a Placer, Painter, or Constraint, so one could combine all of that arbitrarily like Lego bricks. It sounds like we just need to extend, or transfer the concept to vectorfields, or whatever this is. I guess. Well we have a PathPlacer algorithm that comes with interpolation, one can vary the number of nodes on the path, it's modeled by some sine waves. It sounds like that part of the problem is solved already, it only needs to be extended to pass the angles and distances to the path to the painters, and possibly constraints, and it must be performant enough. I guess the performance problems of using high-res grids (if going for those grids to begin with) could still be limited by using the high-res grid only for the operations that need it, and the regular grid for the ones that don't, while updating both grids when painting (tileclasses). I don't know further, so I'll make a tea.

That's about the same approach as used for buildings on Danubius. It uses the linear wall placer. But it's a terrible hack, because the entities that have an offset (here buildings) cover a significant area, can overlap. Those wallbuilder values are a set of magic numbers that were basically obtained by trial and error. Currently one first places a path, then one can place paths at distance 0 to 1 near it. This way the trees border the path directly without having to compute any angles or coordinates. But that only allows symmetric path decoratives. It's not possible to have a path and left of it one kind of tree, on the right side a small stream. To achieve that, we would need a pathplacer that applies different painters depending on the distance to the path. To place fences and visual actor paths, these painters would still have to be informed of the angle, which could be achieved by passing functions angle => Painter instead of just a Painter instance. That won't work with the central createArea idea of mapgen, but I guess that's inevitable. To gain a greater resolution that tilesize 1, one could just assume higher resoluted grids and do performance optimizations. The same approach angle => Painter could also be used for some ObstructionPlacer to achieve paths going around a building. One could obtain your and probably LordGood's screenshots with that, and obtain the connecting paths by connecting two random nodes that don't collide with any of the buildings or path tiles. So I guess we need createVectorArea, PathVectorPlacer, ObstructionVectorPlacer, and these somehow consuming Painters and VectorConstraints. I'm leaving a ping for @historic_bruno since he mentioned to be back recently and had created the random map PathPlacer 7 years ago that is used by every better map in 11152 /#892. Perhaps he has an idea how to create a random map script that looks as great as LordGoods sceenshots at