elexis

There were some wishes for the public mod, for instance if there are visible garrison spots, the player should be able to determine which units go there (for instance if you want the bolt shooter or the citizen archer on top). And in case your units have low HP and you don't want to expose them, there should be a way to not have units visibly garrisoned. So basically a panel, maybe hotkey was wanted.

Welcome to the club (-> Second invitation to the club?)

It's a preference to use createArea to modify terrain. (If we can generate more than 65 maps with only one type of terrain modification call, that makes it extremely easy and powerful. Newcomers and devs only have to comprehend one way to call things, rather than one way to call things per map.) Doesn't mean we may not introduce something else if it's impossible to reuse the existing interfaces. Terrainshaping is usually done prior to entity placement. But sometimes things are mixed up for some random legitimate or illegitimate reason. Jebel Barkal is my flagship and I'd like to create 60 maps better than this one (just that ones life is too short too accomplish that). Indeed that was the idea. We had such issues in the GUI often and adding a deepfreeze call revealed when something wanted to change the cache that noone was aware about (as there was too many indirection to notice the cache modification): #4257. I really would have to look into the code before I can say something true, because it looks more like a design issue than an implementation issue. If the Cell objects are superior and accepted, we may consider using them everywhere intead of Vector2D. Then there is still only one way to do things and every map benefits. I was wondering if createArea couldn't be called with other prototypes than Area (CellArea?) that have the same function names and are somehow compatible (if things can't be unified). Not a trivial task, but it's possible to merge things one way or another.

I don't know the exact details either, something that must be diminished. As far as I observed it kicks "Don't use profanity in the lobby" once or more times, then goes on to muting. I suspect that bans are not performed automatically (which I'd personally prefer where possible). WFG has no influence on user hosted games, we can't read mute ban or anything in games. There are different opinions on that, I personally prefer laissez faire where possible. It also means that it's hard to find out the causes of flamewars in the lobby that started in previous games. We draw the line at flamewars in the lobby.

Stating that it is an incontestable truth that moderators are trolls is something I would disagree with. Troll is a vague word. When I think about all famous 0AD people I know and ask myself "would I consider this person to be a troll" a different reason could be found for every one of them to make this a true or false accusation. Accusing developers to be trolls is one thing, but the task of a lobby moderator is commonly understood to be preventing trolling, so your statement would logically imply that some of our moderators should be removed from their place. I don't know who you mean, I could do some guessing. There is a difference if someone does his way of jokes as a player or whether one does that while performing moderation. At least for the latter I haven't seen an indication for the ones who are active (or do you mean the ones trolling that wanted to become moderators and then never did anything?)

I think the majority of createArea calls use multiple Painters to consecutively paint to the same area. Calling createArea a second time after some other statements is possible too currently (RectPlacer + StayAreasConstraint, possibly introducing an AreasPlacer proxy). I guess the argument for having that nochism boolean is to be able to reuse that painter. But then I'd rather add a Setter function if it really can't be moved to the constructor. clone() or constructing new objects remove the freeze. If there are no other choices we can also consider to remove a freeze calls. Which ones exactly were in your way?

The paint function is called by createArea with only one argument, constructors contain all the arguments required by a Painter. (Also it's better to avoid default variables when there is a choice. This way the mapscript is mandated to tell what it wants. If it doesn't do that, the caller often doesn't consider what value is actually passed and then the function potentially doesn't do what it should. In `misc.js` of alpha 22 / gaia_entities in a23, there were tons of default values and maps used a random subset of the defaults that were wrong in a number of cases, which could have been prevented if they'd have to specify constants. (Maybe the oversights of rP20405 fixed by rP20531 aren't the best example since it's still human error)

Very promising! Needs more decoratives (stones, grass, bush, reeds actors), the path might or might become a bit larger, maybe some random patches for the areas. For the final touch, the balancing will be relevant, there should be mines here and there, not too many, not too few. Some animals and berries and you can call that top 10%-20% of the maps that people did so far. Edit: But that is the recipe that every map uses. The final touch per map is going through the entire list of actors and regular entities in the atlas actor viewer and see if there are some kinda unique ones. (For instance the well on danubius or the kushite statues on JB)

You forgot the generic biome maps. Those are "mainland with bumps" that not even differ in texture/biome sometimes. IMO what makes maps good is uniqueness. Something noone ever thought of before. But really half the players on the lobby are Die Hard mainland players, because they don't want to have to adapt to changing conditions, but optimize the build order for the average map in a petri dish. (As mentioned I don't share the premise, but) just to mention that if some people don't like some maps, some of these people could use a custom mapfilter. Then they can bookmark their favorite maps and have randomness only amongst them. Surely my memories that I saw it being discussed on the forums can't be that off. I thought this was already filed as a ticket, but as I couldn't find any, filed #5209. Never tried until now: Index: binaries/data/mods/public/simulation/data/settings/map_sizes.json =================================================================== --- binaries/data/mods/public/simulation/data/settings/map_sizes.json (revision 21835) +++ binaries/data/mods/public/simulation/data/settings/map_sizes.json (working copy) @@ -37,6 +37,46 @@ "Name": "Giant", "Tooltip": "Very large maps are not recommended as it takes very long to reach the enemy and the game performance can be reduced.", "Tiles": 512 + }, + { + "Name": "1024", + "Tooltip": "Chose this if you don't want to finish map generation.", + "Tiles": 1024 + }, + { + "Name": "2048", + "Tooltip": "Chose this if you don't want to finish map generation.", + "Tiles": 2048 + }, + { + "Name": "4096", + "Tooltip": "Chose this if you don't want to finish map generation.", + "Tiles": 4096 + }, + { + "Name": "8192", + "Tooltip": "Chose this if you don't want to finish map generation.", + "Tiles": 8192 + }, + { + "Name": "16384", + "Tooltip": "Chose this if you don't want to finish map generation.", + "Tiles": 16384 + }, + { + "Name": "32768", + "Tooltip": "Chose this if you don't want to finish map generation.", + "Tiles": 32768 + }, + { + "Name": "65536", + "Tooltip": "Chose this if you don't want to finish map generation.", + "Tiles": 65536 + }, + { + "Name": "131072", + "Tooltip": "Chose this if you don't want to finish map generation.", + "Tiles": 131072 } ] } 0adsvn -autostart="random/new_rms_test" -autostart-size=65536 -autostart-seed=-1 -autostart-players=8 -autostart-player=-1 -autostart-nonvisual I could successfully generate 1024*1024 visually, IIRC non-visual is much more faster, but larger sizes froze my system, despite the random map script being empty. We arguably can't have a faster mapgen time. One could now look which of the remaining parts are that slow or don't support these mapsizes from the data structure. Perhaps exportHeightData could be omitted by converting the 2D array to a 2D vector in C++ (See #4816#comment:3 for screenshots of my initial troubles). If lucky, this might simplify the code in both RandomMap.js and MapLoader.cpp while improving performance to allow such mapsizes. Other parts of the C++ part may be too slow as well and we should take a look at the most significant bottleneck consecutively. The Profiler2 (see EngineProfiling) may or may not be used to measure which C++ parts are the slowest. (If there aren't Profiler2 calls in the slow functions, they won't be listed I believe). Usually I added a debug_printf with the current timestamp to see which parts are the slowest.

I'm not on board with that. I've had some dozen of matches on that Alpine map, even within the first month of installing 0 A.D. A snowy labyrinth experience I don't want to miss. IMO the crappiest one is mainland, but thats somehow the most popular too. new_rms_test maybe. I don't know what you mean with playable, nor which maps you mean. (Anyway, it's offtopic.)

A23 has SlopeConstraint and HeightConstraint Don't recall if FeXoR other devs commented on it, but my opinion is about minimizing code complexity while maximizing effects and performance. Increased code complexity without adding new features can increase the error-proneness in the entire related code and generally gives more maintenance and consumer more reader time. If alternative data structures can make things faster, it were less maintenance and errorproneness if they would replace existing data structures where possible. (At least that was the aspect I recall when I looked at this the last time.) I don't know if it's true, but code should only be obscured if we don't have an alternative. There are some extremely slow bottlenecks in the code (+1min time), but obscuring the code to improving the map loading time from 14 to 13 seconds seems meh. rmgen doesn't scale well, so if one wants to argue with performance, one could test if proposed alternatives to the current code could allow larger mapsizes than 512*512. (I found it a bit sad to not be able to create a larger map for the jebel barkal scene in the a23 trailer than that giant one.) I'm personally happy to take up new random map code into the map base, as long as we don't have too different ways to create maps. First time readers are mostly familiar with Spahbods mapping style, but FeXoRs maps (Caledonian Meadows, Deep Forest iirc) used entirely different code for mapgen, same as wraitiis maps (Belgian Uplands, Pyrennean Siera, for instance) or _kalis maps (rmgen2/, Ambush, Red Sea). To some degree it has been reinvention of the wheel three times, so I'm just cautious to add more redundancy. Diversity of approach in the random map scripts is good, but in the library only where it is really needed. In Alpha 23 a lot of things were made more conform and the Placer/Painter/Constraint interfaces were used where possible (some of the new Painters and Placers were converted from global heightmap library functions or abstracted from code of individual maps). Since these are interfaces, It allows people to understand what a new prototype does even before they read its contents. What I wanted to say is that we have this ingame mod downloader in alpha 23 and you could spread your maps there too (after one of WFG signed it). Yes, different noise placers should be fine too if they are different enough. Yes, that is the performance we should try to achieve. But ideally it should be achieved by all maps. If a new library can do the same faster, all the maps should switch over too to faster equivalent code where possible. Also code readability improvements (less lines of codes) that make things slower but not measurably slower should be prefered IMO (to improve map author performance). 5 seconds is really promising for a large map, I will have to test (once I am free of bug fixing and maintenance of previous code crimes). I really prefer new maps over deleting old maps and replacing them with ones that have an entirely different character. I would miss the old Alpine Valleys map generation and I don't know if the original author would agree to have his work replaced by something new. All of our maps are favored by players, even the most dumb mainland is played heavily. New maps that provide something unique that no other map provides is something that keeps 0AD interesting to people who played all 65+ random maps already up and down. Also we should have maps that are specific to one scenario, historically and geographically accurate site , rather than remaining generic and featureless (like Continent for instance). That's not a secret that some constraints are very slow. Mostly the avoidClasses and stayClasses ones when passing larger numbers, the area to test increases by the square of the radius. It's one of the reasons why the StaticConstraint cache thing was implemented. There will surely be better ways to refactor that class. Anyway, I didn't say anything actually specific to the code which is likely what you were looking for... I think it should be possible to add new stuff to the library, it should just be like Lego bricks. One should be able to opt-in easily and combine with all the other bricks. So if we need to cache vector slopes or whatever, it could be stored in a new prototype that could be instantiated optionally and passed around to the things that need it. But I will have to take a close look once I can get to it (Stuck with stupid bugs since months). I wish the best luck to the map development until then.

I didn't say that having hitboxes is the sole reason for 0AD being slow but being a reason why the originally cited game is quick and not comparable with 0AD. I couldn't find anything on their pathfinder online. But likely by not computing a new path but most likely by pushing. This might have other downsides like units not finding a path (dumb zombie spam behavior). Wasn't unexpected that someone would use the B word . But what you advertize for batallions is already the case for formations - only the formation entity computes the longpath and the units in the formation only compute the shortpath. So temple told me it were preferable to keep formations on Jebel Barkal as a performance improvement when I considered disabling them for being buggy sometimes. The fundamental problem is that noone has reworked (or finished rework) pathfinding since alpha 19. It could be much faster independent of unit grouping by trying to achieve less perfect results at the gain of performance.

This error was reported here already https://wildfiregames.com/forum/index.php?/topic/24234-support-of-modio/&page=3

I must say though that I don't have that much demand for increasing the population count by a lot. People often complain about too much micro needed and the game being too stressful. This problem is proportional to the population limit however. One doesn't have that much todo with 100pop, with 150 it's more comfortable to purchase economy upgrades. Beyond that one really has to pay a lot of attention to chose good battles. We still need a good amount of performance improvements though and we want to support more than 8 players (certainly 9 at least if there is a gaia player for instance, already doubling the total number of units).

Like this one? It looks like the units don't have hitboxes, so tens of thousands of collisions less to test.

In case this was about clickbait: Wow, 19.333 entities in 0 A.D. rendered at the same time, 60FPS in 1080p... This 1 minute scene on a giant Jebel Barkal map (set 1080p) was rendered for about 6 hours on my computer (until it crashed) and 1 hour on Imaroks computer: It took between 10 and 30 seconds on my computer to advance one second in the match. But the video was rendered targetting 60 FPS and 1080p. We can further increase the number of entities in trailers as long as the CPU or GPU don't melt (it did for bb when creating a trailer scene), maybe to 100k too sometime (but that were overadvertizing the game performance by a factor of 100).

or they changed the format (which should not happen, so hopefully just a downtime). Someone could check the JSON with a packet inspector or cpp debugging.

Wasn't there just one .DELETED commit and that was flagged for defect?

Since the library was rewritten for 6 months every day, this won't be the last thing you may have questions about. One can find out such things with svn blame and log or in case of good commit messages by simply searching for that name on trac: https://trac.wildfiregames.com/search?q=exportmap&noquickjump=1&changeset=on The easiest way to learn about changes is to look at any of the map codes in alpha 23 and see how it's structued. Every map is sequence of some declarations (terrains, entity templates, heights), 1 map init statement, like 20 createArea and createObjectGroup calls, timed logging in between and 1 export call. Will you remove Alpha 22 backwards compatibility code or extend it to achieve Alpha 23 compatibility?

I'm here

Not sure which civilizations you consider, but I'm sure they were invaded by rome.

At least the html logfiles have passwords removed. If this only happened after some local networking was disabled, is one of the paths 0ad uses a networked directory, such as the config path maybe? https://trac.wildfiregames.com/wiki/GameDataPaths

It's not rigged at all but all players have the same chances. If you had searched for treasures you could have had the same economic advantage. Becoming familiar with the game and the maps is something that distinguishes the good fromt he better.

Ping me if YilmazGNG is online, so we will ask him to resign. If he is reported again he can be banned.

The subforum is intended to have players watch something interesting