FeXoR

Well, but: - Real terrain data: If we had access to a huge amount of terrain data (like e.g. from google earth) it would be a lot of work to build a scenario for all those areas at a suitable scale. Making random maps that only determine the biome and the use those heightmaps would grant a giant variety of realistic maps. - Randomly generated heightmaps: Not all heightmaps have to come from the real world. Anyways they could look more realistic. - Erosion on "normal" random maps: Random maps could in general get more realistic heightmaps by just applying a water erosion function to the generated heightmaps. That way riverbed could be generated just using the "default" noise heightmaps most RMS use. That already would look more realistic without really adding water to those riverbeds. Maps with unreachable areas with entities that can be gathered from: - Alpine Lakes: On low ground but still surrounded by cliffs e.g. seed 1130, 4 players, medium - Alpine Valley: On low ground but still surrounded by cliffs e.g. seed 1130, 4 players, medium - Archipelago: On islands e.g. seed 1130, 4 players, medium ...and many more. BTW: All RMS with isles have that problem. That doesn't work well for objects. If it would help I could add a tileclass for the Iberian civ bonus walls so those tiles could be avoided. It will be a lot work though because we have no access to the objects properties in RMGEN (which is really bad IMO) like footprint/obstruction size.

In general it looks good. It seams that the waves are reflected at the edges. If you can't change that it might be a good idea to only capture the middle of the calculated area so the reflection cannot be seen. I'd love to play around with this

Can you set the "boundary conditions" so the water height on the left/top equals those on the right/bottom? That would make it fit together. Or how are you planing to do that?

I like the model but it's very different from the other gates because of the "towers" at the ends. It fits well between two wall towers and leave a gap if you put a wall next to it (see random map "Wall Demo" at the bottom though this is not the common case ofc). I like differences between races though so I'd just make it a bit longer to fit directly to a wall. Sorry for grousing

Anyone willing to implement this in rmgen? I'll be gone for 3 weeks but I would really like to have Heightmap/erosion, best both ofc. If anyone is at it please let me know. Would be awesome ofc if it would be in when I return

I will change "placeCivDefaultEntities" to call "createStartingPlayerEntities" to reduce duplicated code. Thx Spahbod for pointing this out. In addition I will add a keyword argument (like the Iberian civ bonus walls are already) for the entities to place so it is possible to do everything with one function. The common case will always be supported without keyword arguments though. @vts/vtsj: It would be nice to have your changes of documentation in the wall builder. It was good! Afterwards I will fix the issue I found while trying to explain the wall builder: http://fexor.dyndns....r%20concept.pdf. It's not really an issue ATM but ofc it should be clean. There's still the problems with entities at the edges of the map (e.g. Anatolian Plateau: Trees). Even if they are reachable only few gatherers can harvest from them. That often results in stacked peasants that block each other. On tiny (and maybe some small) maps the Iberian civ bonus wall reaches out of the map, too. I think it would be good to add a function in rmgen that removes all entities outside (and at the edges of) the map. That could then be called before exporting the map. I'm not sure if some sort of "removeObject" function exists. I'll look into this. That function should always warn (or at least log) if any entity is removed to help rms programmers to notice what they can do better to avoid placement outside/at the edges of maps. A related thing is that it is possible to place overlapping entities. It would be good to add a function that places an entity and removes all entities overlapping with it. Ofc that would need an "removeObject" function as well and the information of the space each object needs (which AFAIK is not available in rmgen ATM). The AIs have problems with entities surrounded by other entities as well. This is very common on any map (scenarios too) e.g. a tree surrounded by other trees. I think it's an AI problem, not an rmgen problem, but just wanted to say it here. It seams like areas surrounded by cliffs are somehow common in random maps though I think they are very unlikely in reality. besides: Unreachable areas should not contain any entity that can be gathered from. Many rms don't grand enough space to the player's bases. There's a section "Design Tips and Conventions" at http://trac.wildfiregames.com/wiki/Random_Map_Generator. It would be good that experienced rms programmers would add ideas here (or directly at the wiki) that would further enhance general rms design. I'm thinking of adding a function to load scenario maps into an rms. That way one could use a scenario but still could choose the civilization free. The other option would be nice as well: Exporting a random map script and save it as a scenario. This can be done in atlas already but I think it would be nice to have as an rmgen function as well. The problem is that I don't know a way to define the payers civs in an rms. I would like to have support for a heightmap/erosion given by an image like myconid suggested here: http://www.wildfireg...howtopic=16233. That would increase the realism of random maps much! Is there a method to determine if a player chose "random" civ? Those are mainly some thought. I will be gone for the next 3 weeks so I will get to it afterwards. If any other changes to rmgen is needed plz let us know. I am desperate to add new stuff after my brain was useless for about 2 weeks since I was ill ^^. P.S.: I will do some of the above but if anyone is willing to support me with adding triggers that would be even higher priority to me. The result of that would be extraordinary! I tried to make that clear here: http://trac.wildfire...1449#comment:20 (skip untill "The perfect world") and here: http://www.wildfireg...showtopic=16096 EDIT: After I was told again that it was thought about triggers and definitely pushed to part II I'll try to shut up

Yes, though perhaps there could be just 2 shadows (then without particles): One on the water surface and one on the ground below the water. The shadow on the water would be for refractivity differences of water/air and particles in the water/at the water's surface. The second would account for the light still shining through. The second (to be absolute realistic) might also need to consider the refractivity difference of air/water. I have no idea about particles or GPU abilities in general, just a though.

Looks very nice to me!

Good (riveted) chainmail where in general rare because it was expensive to get and to maintain. The most available (and used) armor in any age (until armor became pretty useless) was the scale mail while the materials used differed by region and culture. Even most plates where cheaper than good (riveted) chainmail.

Oh, I noticed. It happens when the number of players are small compared to the map size (whatever that means ^^). I fixed it and added it to the corresponding topic (http://www.wildfireg...=20#entry243899) and created a ticket for the patch (http://trac.wildfire...com/ticket/1522). Thanks for the reporting ! I only tested with tiny 1-2 players, small 2-3 players, ... before.

Here's a new version fixing the out of memory errors on large+ maps with only a few players: deep_forest2012-7-4.zip Here's a table of the entities per map depending on map size and the number of players: size width tiles entities with: average tree density 8 players 1 player 8 players 1 player tiny 128 16384 430 1827 ~0,026 ~0,112 small 192 36864 1365 5519 ~0,037 ~0,150 medium 256 65536 4862 8604 ~0,074 ~0,131 normal 320 102400 7010 9029 ~0,068 ~0,088 large 384 147456 8295 9439 ~0,056 ~0,064 very l. 448 200704 9213 9777 ~0,046 ~0,049 giant 512 262144 9916 9866 ~0,038 ~0,038

It's an exception, alright, but it shows well that 8 players on a tiny map don't grand enough room for much map design and even the players are to close to each other. It crashes ? With what error/massage/reason ? For me it generates fine in any size... BTW: I seam to have edited my previous post while you where responding, sry.

Tiny maps with 8 players are not going to work in many cases: - Iberian civ bonus walls will overlap/be so close to each other that they shoot at each other from the beginning - There will not be enough room to build a full base - There will not be enough room to place much more than the recources close to the start positions There is a forest heavy map: Deep forest. But if generated as a tiny map with 8 players most of the map space will be covered with free space from bases and roads. There can be seen that tiny maps with 8 players leave no room for much map design. Perhaps the Iberian walls should be replaced with the smaller circle of towers (used for some maps without enough space already) if the map size is tiny and the number of players is > 4 (and perhaps on small maps with more than 6 players too). In general give the players enough space to build their bases would be nice. Perhaps it should be considered to place only chicken/pigs/sheep (or similar) and a few bushes/trees in a 20 rms tile radius around the players start locations (and their starting entities ofc ) and nothing else. That way the player would have to scout for stone/metal and the game would have another early challenge and scouting would become more vital. That does not need to be a convention, just an idea for some maps. There are some design tips here: http://trac.wildfire...m_Map_Generator

Ah, ok. That still leaves the problem with the player dependent obstruction mapping. But if it can be done...

I think this should be inside the unit AI. It should give back some "unreachable target" signal/state IMO.

Ofc. save/load maps have to be supported in simulations as well, yes. That was AFAIK the reason why all the map stuff is not inside simulation. Not sure: Is the map loaded befor the engine is run? And a new map can only be loaded after the engine is closed again?

Hm, yes, my fault. I noticed that before but didn't think that would cause problems. I'll fix it... The random map script takes care of no entities are outside the walkable map.

Thx Roads can be placed with this as well though crossings are not supported well, yet. I'm arguing with some team members to move rmgen to simulations and perhaps make things trigger based. Then all functionality could be used everywhere like placing roads in-game or at least in Atlas. It's a big change though I think it's worth the effort since it's payed back with much more functionality and easy to change/add features without duplicated code. I'd do/help doing that but simply feel overwhelmed ATM doing this alone. vtsj checks the code/documentation/concept this days so maybe he has other ideas or knows better how to do this. I will stick to rmgen ATM.

Attack rate/time and range should be shown at the same place as the attack.

Working on a documentation PDF to make the concept of the wall builder clear because I find it hard to describe in words. Here's an early version: http://fexor.dyndns.org/files/wall_builder_concept/wall_builder%20concept.pdf

That way you would still need multiple areas to update for the pathfinder. It has to take care of moving/dynamic objects anyway so you could just place a blocking "gate door entity" when the gate is closes and remove it when it's opened. So a gate would be like 3 entities: 2 for the parts that always block (walls at the edges) and one for the center part that only blocks if the door is closed. I don't know if it would be easier to remove the center "gate door entity" or lower it's collision radius to 0 (or remove it's footprint).

For sure it looks better. And I guess theres no way to avoid textures in non-right angles towards each other (and the textures where originally not meant for that). So at the bottom and top (where the effected terrain meats the unaffected parts) textures doesn't line up well. Still it's better than the extreme texture distortion without the effect. EDIT: Great idea! The problem is: It has to be implemented twice: Once for simulations to be used in atlas and once for the RMGEN part (since it has no access to simulation AFAIK). I think it would be highly valuable to think of fusing RMGEN into simulations. So one could add e.g. a circular wall in Atlas by drawing a box.

Isn't that for erosion over time? So you could add a painter for that to Atlas and a function that can be used for random maps (though only the result counts here, not the process over time). If triggers are in terrain could really use erosion at game time ^^.

That looks much better on slopes! Is the effect used for every terrain texture tile? Because if I get it right it's mainly helpful when the gradient of the terrain is high and so might only be used there. Then the resource needs might be not that much of an issue. It seams like not all textures are in a right angle towards each other. This could look strange at the border sometimes I guess?

What would be the advantage of "opening" gates if your own units can pass them anyway? Pathfinding is already hard to do, so I don't think complicating it further would be wise.