elexis

warn(Engine.GetAIs().length); Does [2] actually exist? It sounds like there is some broken directory, or some "unassigned" placeholder item or something. If the ReadJSONFile call in C++ fails, it should handle that in a somehow sane way, probably report it with a readable error. Edit: What's the result of warn(Object.keys(Engine.GetAIs()[2])); // Doesn't crash - data, id

Then investigate only parts of the object. Test if it's an array. If it is, test the first element, etc. warn(typeof Engine.GetAIs()); warn(Engine.GetAIs()[0].data); warn(Object.keys(Engine.GetAIs()[0])); etc.

It says b.data.name is undefined, which sounds like the json is broken, but your JSON looks fine. Perhaps that sort function has always been broken and noone noticed because noone tried two AIs? Try warn(uneval(Engine.GetAIs())); then you can see the return value and perhaps deduce more.

The OP-ness is specific to naval maps and comes from the fact that once the enemy has an advantage on the sea, he can snowball that irreversibly by: seeing every new dock built by the opponent seeing every new ship trained by the opponent seeing every ship being garrisoned by the opponent, and the unit composition The team with the lighthouse can then focus the entire fleet onto the one point where the enemy operates on the shoreline, rather than having to distribute over the waters to gain the knowledge piece by piece, while having to pay with significant population cost to gain that little view otherwise. In a 4v4 on naval with ptol, a tactic to exploit that is to swing resources to the ptol teamplayer, build the lighthouse, a dock and a manned ship in the first 6min or so, and make sure the opponent team will never have way to even build a single dock. In particular if you have played against Hannibal on Corsica vs Sardinia, you will know that this exact thing is going to happen and you can't do anything about it. (Only anti-ship units can help, which are random imbalanced units not intended for that purpose usually)

Depends largely on the map, but I'm afraid you're right. We played often enough with a "no-lighthouse" rule. Removing the reveal-shore feature entirely would be a bit sad, perhaps it can be fixed instead of deleted. What is @borg-s advice?

terms of service

Only removing the shroud of darkness is the same as discovering the area once, a bit useless? I thought it might be reasonable to restrict the range of the effect, instead of yielding a global illumination. Shoreline-only yields a weird pattern for island maps in particular. Also shouldn't it reveal all ships in the illuminated area? If the effect had only a short range, one might let the player build two or so perhaps. (Also related tickets on trac)

General Data Protection Regulation, Internal Revenue Code and contract law

the 0ad / pyrogenesis network protocol is based on the enet protocol, that is indeed p2p. That is based on UDP. But the 0ad networking protocol uses a central server, the host of the match. (See also the wiki page noone wrote.) XMPP is lobby code, but that's not essential for a multiplayer game. Since 0ad defines its own network protocol on top of requiring enet, a NodeJS server can't run 0ad unless interacting with a 0ad binary, maybe through HTTP or a similar API... Not sure what you wanted to achieve, probably a dedicated server I suppose.

We offer under the terms:

One can push few logic to the keywords, for example requiring that every map has either a land tag or a naval tag, but not both. Then having one checkbox per keyword would behave in an expected way and would allow expressing many cases. But it still wouldn't allow selecting all land maps excluding trigger maps. Sounds like a GUI for And/Or/Not would be needed (or just XOR ). trac and thunderbird have that too for example. Or one filter for keywords that must exist and one filter for keywords that may not exist. Or one three-way checkboxes / dropdown per keyword found. (Or just keeping the current mapfilters specifying a logic, but moving them to individual JSON files)

Checkboxes: Ticking no checkboxes means all maps are matched. Dropdown: Current "Default" filter returns maps with arbitrary keywords excluding three specific keywords adds a new myfilter.json file that defines the label, description and filtered keywords of the mapfilter. Everything remains the same way it is to the user. As you saw in gamesetup.js, maps only refer to keywords, and filters only relate to keywords. So filters and maps are unaware of each other, an interface basically. With checkboxes a new filter would be like this: filters/naval.json Player-defined mapfilters are also imagineable, but that should preferably not change the map files, but instead filter depending on a player-defined maplist stored in the user config system. (The ini files aren't so well suited for structured data, perhaps it could become a new config/mapfilters.json file for player-defined mapfilters. (Also we need a new config/user/ directory to support configs per user.))

Then the label and description would have to be removed: Who will know what a trigger map is otherwise? (I guess "Scripted" might fit better as well) When removing the mapfilter definition, one will only be able to do direct relation, but that should actually be fine with checkboxes. One could also make a JSON file per filter, so that modders can add them without overwriting a file. (The danger of allowing too much tag freedom is to gain too many tags (like one per map in the worst case). Another danger is using to weakly defined / fuzzy tags, for example "Default" still doesn't tell us anything that is covered.) (Another feature that people wanted was to tag maps themselves and thus pick a random of these maps when chosing the "random" item. But that sounds like it would be different from the keyword filter and not unifiable.) So I guess any of the possible downsides already exists, except for the missing descriptions, with the alternative of defining the filters in one JSON file each.

The XML / JSON file contains keywords, such as "naval" or "new", and the gamesetup(.js) filters depending on that.

But when you select "random map", then you want to be surprised whether the map comes with 30% map being water, 20% hills, or 100% land? For this map-aera problem, one could make it so that the map area relates to the passable map area, not the total map aera, but not sure if that makes it really more expected. If map authors are good, every map is unique, so the problem can occur with any setting. For example on a map with many hills or water, Regicide is a different deal. That we have a "random map" item to begin with implies the design principle that random maps adapt to the settings given by the user, not the other way around. It actually has been wished that random maps can restrict the settings that the user can chose, for example requiring a specific victory condition or mapsize. Then "random" won't work anymore without reinventing that (random selection from the maps that support the chosen settings. That has the disadvantage that the user can't predict which maps are subset thereof). It's not uncommon in multiplayer games to remain for half an hour in the gamesetup stage to make 8 players (and the other 6 players that wanted settings and left again) happy with every possible setting. So anything that will shorten that period without reducing the setting expectance will be benefitial. Yes, that was bad. I had already removed 20-30% of the forests and there is still too few space. The map author actually said it's the intention of the map that players have to use docks and chop wood. So I still think there is more deforestation necessary before I play that map. They aren't fake. I guess you're asking for tooltip that tells you that you need a merchant to pick it up. Which is just a random bug, that doesn't break the gameplay experience in such a way that it would have to be removed from the "acceptable map" filters. That always happens when there is enough space for a dock but too few space + a dock + a ship passing it. That's the case on about every map that comes with a small river or passages. Might be fixed by making docks not placeable in places where there is only space for a ship. But then players report that as a bug that they can't build a dock there. So eh, not sure what we're supposed to do. Players at least can expect from the size of the ship and the dock that this will be blocking in some areas. For this specific maps the thames can become larger. which I suspect is part of the reason why the "Land" filter is the "Default" one. But all of this feedback is feedback for ship and map development, not for the gamesetup filtering, no? English Channel in particular is one of the better than the worse maps IMO.

4.2MB -> 500KB is a lot. There is the drawback of requiring longer to decompress. Usually we already compress at highest lossless compression. If you mean https://tinypng.com/ it also uses 8bit instead of 24bit colors It says So that would not be lossless however.

Mapsize depends on the selected mapsize, unless you're talking about skirmish/scenario maps. Tiny maps are too small for every faction, a gimmick. Also "Normal" is too large for 4 players on many maps and just right for 4 players on other maps, depending on the area covered by water and hills. Which maps do you mean are sub-par or no fun at all to play? Island maps like Cycladic Archipelago or Islands are designed to have play expand. Other maps like English Channel can be set to large for 8 players, since half of the map area is water.

I think the point is about regularities that would not occur in nature. For example the perfectly symmtrical islands and ring on Gear. But roads are manmade, and men can also can create small passages between the canyon. The regularity / radial symmetry is observable on most maps. So at least it may be difficult to draw a line. Kerala, one of my favourites, is also a real world map; that's not the issue.  With realworld map I didn't mean the portrayed location, but the fact that it uses a NASA heightmap. It's not a problem to players who check from the map presented to them whether there is passability, rather than people expecting passability from the geographic design. I guess you are right however, there contradiction that the map design says the map shall reflect the terrain accurately while the realworld terrain has this distinct quality of being passable to ships there, and that this is a quality lost by downscaling (whereas the shape of the terrain is not lost when downscaling). Which would mean adding passages, but that would falsify the terrain shape. So it will be a tradeoff. Last time I checked in multilpayer and singleplayer I could play the same way. And I suppose we don't want to provide a list that is intentionally false in any case. People in the past have decided that naval maps should not be listed by default - probably because players start with the expectation of starting a land warfare game and don't want to find out after starting the game that they started a naval map unintentionally. Regardless whether it's a good choice, I think the filter labels must be clear - "Default" doesn't tell you anything what's in there, "Land" does. (We wouldn't be discussing now what the purpose of that filter was if it had been labeled more precisely.) Map quality is determined by both gameplay and aesthetics, so if we want to sort out the ugly and the weird, we should find a good wording for that. And I suppose it won't be possible without changing the Dropdown to Checkboxes to satisfy the "beautiful" maps by default and "land" maps by default at the same time.

The definition of Naval maps is that enemies can only be reached by building ships. On Gulf Of Bothnia, ships are an alternative to land warfare. You won't find a map under Naval where you can attack the enemies via land, at least if you play them the way they are intended to (english channel, corsica, ... one team per island/continent). Square maps are deprecated in Atlas, although I guess Pyrogenesis RTS engine should always support them if it wants to be an RTS engine. Last alpha many square maps became circular, those 2 are the only ones where I don't know how they could work on circular maps without changing the way they were designed. Square maps have 27% more map area than circular maps of the same size, this changes gameplay drastically. Atlas Mountains doesn't have few resorces. Canyon isn't much more unnaturally appearing than the other maps, is it? Mainland, any of the maps with random hills etc. I wouldn't know how to distinguish naturally looking from unnaturally looking maps with tags. Ratumacos is a realworld map, but not condensed? We can let players add their own tags, but the question is which maps we should hide from new players by default. So perhaps it should be a "Best maps" category for the 10 or 20 best maps, and then if players like the game and want to play more than that, they can chose the other filters (but which filters are to be provided).

I always proponed to rename "Default" to "Land maps", that's what it's actually filtering for IIRC. If you remove ugly maps from the "Default" filter, then there's no more "Land" filter, but there is clearly demand for that filter. (That's why I had proposed to add a new filter above.) Edit: Filters could also become checkboxes. ([x] Ugly, [x] Land, [X] Naval [x] Scripted [x] Demo)

It's planned to allow players to add banmasks, so that "anti-buddies" can't join ones server (rather than having to ban them after they joined), and also can't join after they created a smurf account (by banning the IPs and VPNs). But offensive chat should not be hidden by one person, because then the offensive chat is still visible to everyone else. It doesn't solve the problem, instead the offensive chat should not be transmitted anymore, for example by someone actually muting the offensive players or more.

In Austria they are proposing or introducing a "digitales Vermummungsverbot", i.e. you can't post anything on the internet without leaving your phone number. Always reminds me of this quote from Jean-Claude Juncker: But the quote is wrong or antiquated because they obviously continue step by step regardless whether there is a fuss and people understand what has been decided.

That would leave the best impression for a player who plays 10 maps. But we also want to keep players entertained for as long as we can. The ones who suffer from 0addiction cycle through all of them. A map downloader be sufficient for multiplayer, but I wonder if we still shouldn't distribute them for singleplayer. A mapfilter might do already for the existing maps. Or even better would be improving all of the maps to be as beautiful as the best 10 best maps. It's not only weirdo maps like Polar Sea or Survival of the Fittest that you refer to but for example also maps that don't look so nice but still relate to the games themes like Anatolian Plateau or Belgian Uplands. So perhaps the fastest way to achieve your goal would be changing the filters this way: ?

Predominant slow code I found was code that either relied on retries when it had more information available before (i.e. unnecessary calls, using createAreasByAreas instead of createAreas, and constraints that are too often unmet), large distances to tileclasses (large area checked) and the Clump/Chain/Path placers algorithms being slow when creating complex patterns. The other problem is maps becoming increasingly complex, more calls overall. I.e. no more bottlenecks, but 60 individual map script statements that can be reduced from 1s to 0.3s each, i.e. very dull work and in the end it only improves the performance for this one map. It says a lot and nothing at the same time.

Sure, we can't increase the precision without increasing the performance.