FeXoR

Concerning waypoints for AIs on maps: Thats a bad idea. Likely the map designer doesn't know that much about AIs in general and he would need far-reaching knowledge abot the player AI that actually uses the waypoints. For random maps it is even worse because the RMS writer will likely know less about the actually generated map then an analysis of a specifically generated map would. Having different AIs available might mean different waypoints are needed fo each of them so it gets worse the more modifiable things get.

I like the idea of giving freelancers an opportunity in 0 A.D.. However, it might be difficult to make this work for both sides: - For 0 A.D.it's vital that things really improve by payed work. - For the freelancer it would be vital to know he gets the money for his work. So for 0 A.D. it would be optimal to set some (well defined) goals and offer payment for a solution (after it is done and tested). (the problem here is the "well defined" I guess since solving one issue e.g. should not result in adding a new (maybe worse) issue) For a freelancer it would be optimal if the payment is guaranteed (if the issue is solved by her/him) e.g. not dependent on the team liking the solution. I don't know if this can be solved.

I don't like this. The GUI should work even with smaller resolutions (scrollable widgets are hopefully available in out GUI toolkit). In general I'd prefer resizing elements (like e.g. changing the font size (in options, not present ATM) would resize the buttons). But visuals are favored over usability here once more. With scrollable widgets it would still work (though sometimes bad to handle). Separating the editor from the options is a good idea IMO.

Hephaestion: THX much! Sometimes a motivating/inspiring post (or a kick in the butt) is what I need ^^. I'll add more flowers.

Good idea! I'll do that!

I'd remove "var myReliefmap = " and search for myReliefmap. All new functions directly manipulate g_Map.height instead. So if you have a function really needing a heightmap to set use "g_Map.height" instead of "myReliefmap". If you only use the new functions that should not be needed though because every function should fall back to g_Map.height if no argument is given for the heightmap. Since this argument is optional now the order of the arguments have changed as well so you might check them. (That's the problem with using heavily "work in progress" code)

I guess this can be done without much performance issues indeed. But before we'd need to have "knockdown" animations (and maybe even "fly" animations if units are to be thrown through the air) as well as a system to handle this (I still don't see why it would be that resource intensive). I think at least knockdown is planned (not sure). The animations would be still a lot of work.

I have some questions from the practicable point of view: - Who will implement this? - If implemented who would be able to use it on their current hardware? - How much work would be to adjust the artwork (e.g. textures)? - How much improvement would be seen from a default RTS perspective? I'm not sure but I think: It would be a huge effort to implement involving long term development of a/some really skilled person/s that is/are not around yet. Only a few percentage of PPL would be able to use it on their hardware and the result would be cool but mainly from a much shorter distance then PPL actually use to play. I think for an RTS game the graphics are quite nice allrdy. There's nothing bad in better it if (and only if IMO) this doesn't mean less players will be able to play the game and things don't get messed up (e.g. by the need of supporting multiple rendering methods).

textueByHeight: Yes, I don't use it any more and I'll remove it soon. It's just a relic from the randomBiome usage. Paths: Tailing from player to player (mainly straight). It's simple to make bend paths though so they would likely not go through the lake. (see the path placement in Deep Forest e.g. use "- 0.5 * pathAngleOff, 1.5 * pathAngleOff" instead of "-pathAngleOff, pathAngleOff". However, this should only be needed for 2 and maybe 3 players.) BTW: My new code had a bug in the angle setting (x/y angles where independent). Thx for making me find it ^^. EDIT: I just noticed that if you use a random player derivation it's not clear if the path will bend in or out... (so you have to find out if the path is placed clockwise or counter clockwise first or even better place the start positions by angle, not by height so you know the order of them. This should work for your map since it's general shape is roughly rotation-symmetric.) Fog color: OK, found it. Atlas does nothing obviously wrong. I roll the random biome multiple times to force the biome to be alpine (to test it). The alpine biome does not change the fog color but some biomes do. (Biome savanah has the fog settings {r:0.847059, g:0.737255, b:0.482353, a:0} so this was rolled before hitting the apline biome) Sorry for the confusion and thx feneur!

Thx! Updated the RMGEN lib reference track pages environment section (removed setWaterShininess since I couldn't find it anywhere, is this correct?). I'll bother about the general ambience later I think. I couldn't find though why the fog was brownish before. It's set to 0.8/0.8/0.8 by default (environment.js) and that should be gray. However, setting it to the same value in my map makes it gray (removing the line makes it browniish again ofc.)... EDIT: Hm, Atlas seams to reset it after rmgen libs are loaded: log("g_Environment.Fog.FogColor = " + uneval(g_Environment.Fog.FogColor));Output: g_Environment.Fog.FogColor = ({r:0.847059, g:0.737255, b:0.482353, a:0})

Thx! Rivers (and lakes on different levels): If you mean this I didn't use it because it's slow and I can't set different water levels so it would not look very nice. I finished the Alpine biome and noticed some problems: - Textures (placement): Using a single texture leads to regularly repeated terrain. Using multiple textures leads to the loss of their beauty if randomly placed. (Possible solution: Divide the map into irregular polygons (of target size) and place one texture per polygon. Some work and may be slow) - The distance fog is brownish by default! IMO it should be gray... I didn't find how to change it in RMS (e.g. here). - Textures (not fitting textures of one biome): In the Alpine biome there are different types of grass (most looking awesome) but many don't fit to each other. Some are bluish (In fact I never saw such grass though I was in the alps quite often) while others are (mainly) pure green. They don't fit to each other at all. [My impression of the alpes was much more gray (rock with a little moss, some lichen and few but deep green grass/plant spots like alpine_mountainside) and rich dark green grass (mainly in wind covered areas below cliffs and in high valleys/hollows like alpine_grass or even greener/darker/richer).] Any suggestions for texturing welcome! realisticTerrainDemo2014-3-23_alpine.zip Some screenshots: Other things to do: - Try to fasten base terrain generation by using splice() - Add avoid class (or similar) support for terrain placement and paint the paths - Reduce water murkiness, lighten water color (EDIT: Done. See last picture)

It would be nice if Atlas had something like: Misc hack -> Camera: Map overview ...that would set the camera to a distance at the current angle so the entire map is shown in the main frame (at least roughly and maybe in a fixed quite high angle). Start camera bug on random maps: While the camera is set to the 1st players start location after generating the first random map it's just set to (0, 0) for the following generations. EDIT: And it would be nice if in the actors selection as well as in the texture selection right klick -> copy relative path and filename or something similar was available so a moder don't have to search through the directories to get the exact filename (and relative path). Also selecting something (like the seed number), moving the cursor away and then press strg+c will do.. nothing since the GUI element lost focus when you moved the cursor. If a terrain texture is written wrong (like space and underscore mixed up) Atlas will hang. In this case a fallback should happen IMO. Those annoyed me for some time now.

Thx! Yes, the generation time is not really a problem for me. Just thought the speed increase would be quite noticeable. The speed depends much on the seed so I don't think it really became slower. Tree density: Lowered it. Textures: Well, I'll try by hand which pairs look well on a wide area and which single textures does. Then I will see what biomes work well and set them up by hand. Paths: Actually draw some texture on the paths. (Was a bit out of motivation when I wrote the last post but it's back now ^^)

I rewrote all functions so they now directly manipulate the heightmap (and use (deep)copies of it if they need a reference). So now every manipulation should take place on float32arrays. However, map generation now needs ~2 secs more though I also use deepcopy less often. Code structure got straighter in the process though. I also use the center of the diamond square generated heightmaps now so presets work much better now. realisticTerrainDemo2014-3-21.zip EDIT: Did some texture changes depending on the biome. Now I hope thinks look much less weird: realisticTerrainDemo2014-3-21b.zip I now did all I could think of so far (not very pleased with the textures but much better). It's not good enough I'll abandon the random biome stuff and paint everything myself. Oh, and forgot beautification of the secondary resource spots... (OK some things still to do...) Anyway, input on style and especially playtest would be helpfull. Some more screenshots:

Thanks much both of you, I'll try using typed arrays. So... Much faster and smoother now. Still to slow for my taste (about 3 secs for the player order and the path's heightmap smoothing on a normal map with 8 players). And the paths partially devastate the nice terrain but, well... (Guess I'll try doing some terrain analysis to skip unneeded paths) Example (Overview/Valley/Dam, seed 6200, medium, 5 players): Map: realisticTerrainDemo2014-3-20b.zip

Yes, I need 2 heightmaps for some functions. In global heightmap manipulation functions (meaning every value might be change) it doesn't matter for it's speed if I manipulate the old object given to the function and generate a new one as a reference or use the given one as reference and return an entirely new one. But for functions calling this function it makes a difference in usage (if I just call it or if I set something to it's output). And the reference to the original object in the calling function will be broken if I use the original as reference returning a new object (which is bad in some cases).. On the other hand returning an entirely new object enables the calling function to have both objects at hand easily (wich might be handy in other cases). However, the getSmoothedHeightmap (in the map it's rectangularSmooth (line 502) since it was never meant to return a value) functions does only change local values in a small rectangle so in this case it's better to directly manipulate the heightmap and use the (much smaller) rectangular area as reference (and in the end throw it away) since the new object to generate is much smaller (?). And other functions can use it by just calling it. Well, understood a bit better but still not sure if I'll get which way to go in some cases. Any other input welcome.

Well, maybe I'm missing something. If I use: myHeightmap = getBasicHeightmap(bla, blub); function paths(heightmap, ...){...heightmap = getSmoothedHeightmap(heightmap);...} paths(myHeightmap, ...)The heightmap is not altered at all. So I return the hightmap in the path function and use it with myHeightmap = path(myHeightmap) and that works. So what am I doing wrong? (guess if I use deepcopy and return once in the process (here in getSmoothedHeightmap) I have to use it always (since the reference is broken then)?) I just never know when it's better to set something directly in a function and when its better to return the result and leave the original untouched... I guess for big objects like the heightmap direct manipulation is (most of the times) better than deepcopy and return. It's just getting to resource intense otherwise (?)

The "player connectivity" problem is solved. Sadly it takes long ATM (the entire hightmap is passed back and forth throughout functions to often. I'll fix that shortly). Here's an example: Overview: Valley: Dam: The terrain alteration is much to strong sometimes but I will fix this alongside the "hightmap passed to many times" issue. realisticTerrainDemo2014-3-20.zip

This is cool! It now has a functionality not possible with a dropdown (with that many civs).

I guess you are right for the orders. Luckily in the case of a closed road there is a much simpler solution (THX leper!) since the path will never cross itself in the optimal solution (I forgot that): So we just start with 3 players in any order and calculate the path's length (3 distance checks). Then we pick another player and calculate the difference of the path's length for putting him in any of the 3 possible positions (2 * 3 = 6 distance checks). And so on. For 8 players that leads to 3 + 2 * (3+4+5+6+7) = 53 distance checks (compared to 8 * (8 - 1)! / 2 = 20160 distance checks with my previous method ^^).

I want to find the shortest "circular" path to connect all start positions. I wrote a function for getting all permutations of player numbers: function getOrders(elements){var orders = [];if (elements.length < 2)return [elements];else{for (var i = 0; i < elements.length; i++){var newElements = deepcopy(elements);newElements.splice(i, 1);var newOrders = getOrders(newElements);for (var k = 0; k < newOrders.length; k++)orders.push([elements[i]].concat(newOrders[k]));}}return orders;}// DEBUGvar elements = [];for (var i = 0; i < 8; i++){elements.push(i);log((i + 1) + ": " + uneval(getOrders(elements)));}Sadly this is really REALLY slow! In fact Atlas returns an OOM error if trying to run this for up to 10 players... Since I want to generate a circular road only (numberOfPlayers - 1)! / 2 different calculations has to be done (-1 because the start of the "circle" doesn't matter and /2 because the reverse order is the same). Example for 4 players (always starting from player 1, the reverse orders are stroke): [1, 2, 3, 4], [1, 2, 4, 3], [1, 3, 2, 4], [1, 3, 4, 2], [1, 4, 2, 3], [1, 4, 3, 2] Sadly for 5 players it's not the first half starting with player 1... So any idea how to make a function for that? Making my example function faster (and then check for a valid sequence to start with 1 and otherwise check if the reverse sequence was already checked) would be OK too I guess...

That's why I suggested the manual being accessible from many places including the match setup screen. Of cause we can add buttons for partial information everywhere but IMO the manual would do the trick much cleaner. (only one button to add and only one detailed manual to design)

Part 2 is planned to cover 0-500 AD (Part 1 cowers 500-0 BC) AFAIK.

I usually use the mouse wheel to choose from dropdowns (though that didn't work in our GUI last time I tried). Isn't there a dropdown content mousover tooltip support? I like to have as many information on one sight (like the match setup and all players settings) rather then a window/screen for each type of information. Combined with a detailed manual to study that's perfect for me. But if the majority of PPL like the shiny solution better I'll have to live with that

Well, things stack. But yes: I don't think that a game would be rejected because of the way the civilization is chosen...