FeXoR

I wish you lot's of fun with it (But that doesn't mean I have to like advertising web side's offers)

(I consider most posts in this topic spam...)

There's also the concept of scrollbars

Regarding the first post: IMO "good" is not a property of anything. People rate things as "good" or "bad" instead. Just a little trick to make more people believe that what one thinks is not just an opinion of that person The more rational way of "And that's good!" would be "I like it!". (Ofc. a society is based mainly on sharing values so this little (self) deception may actually be quite important for getting people to work together. I still don't like it very much and would prefer "Hey, that's what I want, too! Lets do it!".)

Yea, sad story. While I agree it's mostly a people problem (mainly the attitude of those players not welcoming players they don't know/that have low rating but also for those rejected to be persistent) so less a problem of the game. But what we can do is not granting PPL the tools to deny other players participation and on the other hand granting players the option to host games that are actually played. One way would be to remove the kick option but add an option to only allow players that at most left 5% (about 1/(2*max players)) of the multiplayer games they entered (so basically a whitelist. More options like autobalance and minimum games played/rating could be added with a sufficient playerbase - but I don't think we should overdo it).

That doesn't make much sense to me since the information is somewhat important to decide whether or not to unlock it

I mean large areas on the "rather flat heightmap" some seeds. In some cases they are to rough or steep to build upon (Thanks for the reminder - though I got (or more guessed x)) this one right). So, yes, I'm aware the water and the ramps are on the "same" "rather flat heightmap". That's why I proposed non-lineare scaling. Linear scaling only the parts below sealevel would make the water deeper, too ofc, yes. But that wouldn't change the ramps. And I'm not talking about oceanic depth but about 50% of water covered area to be more then hip deep (unwalkably deep) Yea, I didn't get this one (therefore my edit, not saying that I'm enlightened now ). But now I'm not sure if I explained well what I had in mind, trying again: Add the tiles of the path as is now with one type tag/key, say "road", to the abstract map (to be later covered with the path texture) Add the tiles surrounding the "road" tiles in a range of 1 or 2 with say "road_clearance" (avoiding tiles marked with "road", to be later covered with the surrounding region's texture but no entities) Optional: Add the tiles adjacent to "road_clearance", but not in "road", "road_clearance", with say "road_trees" (also avoiding start and end point by 3-4 tiles (depending if you chose 1 or 2 for the clearance), where later the alley trees could be placed) I guess that's more clear (and ofc. the path painted with textures or the clearance could be made broader as seen fit). And you could use those areas to place the chicken on (but a default placement method would be preferable). But if you have other plans already, go for it!

Oookkkk... (still not through the code...it's quite a read ) Roads: AFAICT you first paint textures, then you paint roads taking the textures painted into account. This means you are overpainting existing textures. What about defining areas instead of textures you can than take into account for the paths to be placed, then you place paths (again as abstract regions, maybe an inner one for the part textured and a second, larger one for not placing terrain entities - and not containing the tiles of the inner path [if you want to you could also add a 3rd - again not containing any of the inner areas - that can contain entities and maybe avoiding start and end point by slightly more than it's own width to generate something like @elexis had in mind]) and then you paint the textures (with all the other map generation stuff in between ofc.). That way your approach will still work (weighted path search) but you don't have to overpaint textures and you can avoid entities close to the path and @elexis can have alleys (if you avoid forests or other entity rich areas because this is likely what is wanted). And I'd say try 5 tiles unobstructed path width (or 3 tiles from centre). Domestic animals at start locations: You can just place them after line 194 like "berry bushes" or "starting trees". Did I miss something? (And what issues does which newer placement method cause?) Large areas covered in water and ramps that can't be build on: Making the water deeper and the ramps flatter would do IMO. I don't get the entire main landscape procedure yet but maybe non-linear scaling (e.g. with square root) of the heightmap ("before" mountains are added - yea, it's in one go but in different sections) could change this without having to change much else? (on the other hand there should be an exponent scale factor for higher and lower terrain anyway IIRC) I can live with it as is but really think at least deeper water would be nice - and more realistic BTW (If the water level is set before the main landscape procedure one could also change those areas separately ) Roads avoiding water: Yea, no big deal. Still strange looking to me and AFAICT easy to avoid in placers.js line 513. Textures: Not looked into, yet. To tired ^^ Well, I hope you can make something out of this rather chaotic set of suggestions. Keep it burning @Pyrophorus EDIT: After a closer look you do most of the suggested stuff in "roads" already. Additional Area types (e.g. road_clearance and road_border) and changing the texture placement might be enough.

About An Egyptian Oasis: The two main things I noticed that don't work well yet: Paths are quite narrow so large armies have trouble to use them if they go through forests. While the texture width is OK there should be no obstructions that close to the path. It actually seems like they are not continuous and broken apart by tiles with trees. Starting locations don't have domestic animals like chicken or pigs. This can put some players at a rather heavy disadvantage for some might wind up having camels nearby but others don't. And cavalry can gather meat quite fast. Other more minor issues: Some maps have rather large areas covered by water and "ramps" that can be walked on but not build on. This makes it quite hard to use defences. Maybe the ramps can made a little less steep and the water a little more deep (so units can't walk through most parts of the water). The actors on mountains are those of actual mines. That might confuse quite some players that will mistake them for spots to gather from. Replacing them with non-mine actors would solve this The texture around start locations abruptly stops when reaching the playable map area's border. Instead I'd place the texture but no entities (or the actor corresponding to the entity) in the entire area if not outside the map (the square map where textures can be placed but I mean here). Roads often leading to/through lakes. This is not really an issue because units can walk through most parts of the lakes anyway but it looks like this is not planned The wet sand texture extends quite far into areas not covered with water. That looks strange to me. While I like your choice of textures very much in the barren flat regions the light grass texture doesn't fit very well IMO.  I haven't read through the entire code so it's absolutely possible some of my comments don't make a lot of sense Expecting requests for more concrete suggestions ^^

There is no concept of momentum in 0 A:D.. And IMO there shouldn't be. Instead arrows should be acting like missiles IMO so not the way things act (momentum for units, pure parabolic arrow path's) but the outcome is what's about realistic (units are hit with a specific probability, maybe dependent on distance - though "always hit" wouldn't be as bad as "can always be dodged" IMO). And, yes @Sundiata , part of the problem is the simplistic unitAI's targeting but the above approach would "solve" this (yea, also not very realistic but it's the outcome what matters most IMO and it's doable even if the arrow path's might not perfectly correspond to the hit unit's position). Also I agree with @wowgetoffyourcellphone (just there have been several attempts to implement this and none of them where really pleasing IMO).

Off topic: @thankforpie I want to remind you this is the "Gameplay Development & Technical Discussion" part of the forum. The tone this thread went is not my taste but this is not at all what I understand as a "discussion" and won't drive development. So I ask you to keep this kind of comments out of here

We could add a minimum angle restriction between the newly placed walls and those already connected to the same tower. What about limiting access to stone when the game advances (Yea, but slingers/catapults/... ;/)? Though a minimum angle definitely makes sense to me, too. A more personal request of mine would be to use the words "bug" and "cheat" more specifically - for they have a meaning and are useful in communicating game development. So please mind your words - and if only for my mental stability ;p

(Just thought about "hyper realism" - which doesn't make much sense to me as a word in the first place as long as we are not living in a matrix - and are not really opposed just: Wouldn't players be a bit ... put off when they have to e.g. film themselves to convince their units to join their cause and in 90% of the cases as a result they would just be ignored or even lynched? Not to speak of the declining player numbers ;p) Less accuracy, moral/fatigue or "no focussed fire" fits well to combat in battalions. But as is (without battalions) the result of making ranged units less strong in this many aspects would likely result in no ranged infantry being build at all (except siege). For ranged cavalry it's the combination of range and speed that makes them so versatile (Would making them more expensive help?). Friendly fire is also hard to manage for the player resulting in just another kind of micromanagement. Not sure. (Focussed fire could be avoided by instead of dealing damage units have a chance of killing en enemy they hit (so basically no health but death resistance lowering the chance to be killed) but the outcome of early skirmishes would be basically random)

Iberians get towers in the random map Snowflake Searocks, not walls. (I'd agree with making it an option if I'd agree to the options system in multiplayer)

I agree resource entities should be reachable (at least somehow like after chopping all the way to that tree in a dense forest).

As @(-_-) said shared code (thanks to @elexis) for most maps. Only few use their own starting resource distributions.

IMO this is a path finding and unit AI problem. That doesn't mean we shouldn't change the maps but that will not fix the underlying problem.

I agree with that. While there should be some resources available close to the base the large stone and metal mines provide to much IMO. (There is no consensus in the team about that though AFAIK though there could be found a compromise I guess - either reducing the amount of resources the (initial) mines grant or to place them further away from the Cilic Centre - though this will not be easy to do for e.g. all random maps for that will cause interference with Iberian's walls or in-game build walls)

Oh, nice to see so much going on here Try to catch up This is not really true for the random map part if you avoid using placers/painters/constraints. And some part of code has to be first being fast enough that other parts are recognized to be slow and made faster x) It's likely just a few parts causing most of the cost - as usual - so identifying those would help. This is where we propose code contributions to get reviewed and eventually committed. See https://trac.wildfiregames.com/wiki/ReviewingPatches I agree that trying to add a map with this features (though gorgeous) for the coming Alpha would be a bit hasty. But I would love to see one entering the review queue at some time! ATM I can't see a huge advantage of this besides partial upgrading (which also might need border tiles) ... but it's absolutely possible I'm blind (I'll read it again after I hit the pillow) ;p Also this would AFAICS restrict this object only to properties in from the beginning (e.g. normals, waterHeight, waterVelocity are not used in most maps but might be wanted in others ... which then can't add them). If I am wrong here please teach me differently! Is inheriting from an instance possible (assuming the instance is generated in the libs which don't know the needs of a map)? Also what about the performance of derived properties like grad/rot/div of the original properties? Any benefit here (besides partial updates)? So, sorry I can't give you an opinion right away Good! But I can tell you I consider many parts of it better than mine! I consider both of you painters valuable! The map looks promising already. Yes, texture variation could be higher for my taste. Breaking patterns of the textures is possible by applying more than one chosen randomly in the same area. But those have to really match well to not look to patchy/edgy/separated (don't know better words).

IMO Base terrain generation should go to /heightmap (maybe separate in different files but it's not that big yet). Painters, placers and constraints should go to /rmgen . Functions they depend on should also go to the same file. The g_Map object should IMO only contain stuff that is needed to be exported. Anything else should go into another object (e.g. map_extensions or something). This includes the slope/incline map (vector/scalar) as well as the planned collision map and abstract water height/speed maps (to simulate water driven erosion). Recomputing those maps over and over again is indeed insanely inefficient. I have the same problem with the collision map (updating whenever an entity is placed is fast but means to hook in the collision system in even if it's not needed - though no performance impact than with a collision.enabled flag. Updating whenever needed means "number of uses" more calculations of the entire map). I think the way to go is "update manually when needed" for those heightmap related maps - though this is prone to induce bugs by oversight. Updating whenever used and update needed might be appropriate in some cases - a copy of the underlying object could be stored and - on change - update the derived thing if used (this is somehow against the "direct access" policy I usually prefer though).

I just noticed that we actually don't have a way to smooth a specific area of terrain yet (there is rectangularSmoothToHeight but this is not exactly the same and the smoothing effect es stronger near the center than the edges). So a painter for that is definitely welcome! I also find getting and painting areas by slope very useful and think maps could become much more natural looking with much less work when utilized. Nicely done! (The terrain still shows artifacts in the direction of the coordinate axis and in a 45° angle to them. It would be nice if those could be removed but otherwise we then have multiple smooth tools now )

@Lion.Kanzen In metadata.json search for "mapSetting" and you should find Seed there alongside the other settings. To recreate the map setup Atlas to those settings - usually random map, map size (see below), and number of players should be enough - as listed in metadata.json and generate. You can save the map (as a scenario) then to replay it. Map sizes strings correspond to the following map widths in tiles. Tiny: 128 Small: 192 Medium: 256 Normal: 320 Large: 384 Very Large: 448 Giant: 512 The first line in commands.txt also contain the map settings.

@Servo "Caledonia meadows needs more animals" Do you mean more huntables or domestic or fish or different types of animals? I actually thought there where to many huntable animals and berry bushes. I reduced the ammount of fish due to reviewers requests BTW. I agree we should have at least some maps that support teams being much closer to each other and allowing uneven teams. This shouldn't be the default though. If you have the replay of the map you liked you can regenerate the map in Atlas by using the same random map seed.

I assume the straight lines have the same cause than the sharp cliffs: The random offset not declining right from the beginning. Erosion/smoothing and/or recalculating mountains/steep areas (and maybe flat areas too) should hide them. Erosion/smoothing will wash away some details too though. Wind driven erosion would also create structures similar to this so I don't think they are to bad

No need to be ashamed in any way ;p I love how you drive this approach further! And you made me think about how we can use code from water driven erosion to add details to realistic terrain maps without the water plane (I was told the engine doesn't really support that though somehow implemented with different water levels in mind) just with terrain texture. Though not as cool as rumbling rivers it would still add some more detail if painted with bog texture like an overgrown river or at least occasionally wet, muddy ground.