FeXoR

As I experienced AoM it was quite imbalanced (the chance to cast myth units on hit hersir). I didn't play it online or much in multiplayer either though. I can't imagine though it had a long living big online gaming community due to the lack of balance (like e.g. AoE II: AoK/AoC, Starcraft, Warcraft III had/have). I have no information about this though so I might be wrong. I don't think that a game would be rejected because of the way the civilization is chosen either. I just find it worse to use and in general are opposed to "better locking, worse to use" things (which gets quite common). Good looking is better if it means no drawback in usability IMO. I seam to have another priority than most PPL but I'm quite sure the long term success of programs/games lies in their usability, not the best look. (That's why most money can be earned by making good looking games while the most played games have average graphics but are much more thought through and balanced. That's why close to no innovative games with high replayability potential get to the shops: They don't sell. And that's why "hardcore games" get more and more frustrated.) But we can change that! We're not here to make money, we are here to make a lasting fun game (I think). [sorry, I got carried away a bit ^^. But I mean it]

Spahbod: Glad you look into this. I rarely work with placers/painters but he wanted to paint tiles by height. So I wrote an example function HeightPlacer(). Could you check if I forgot anything to make it work with avoids/constraints? (That's what I guess is at least part of the problem)

IMO the match setup should be optimized for playing the 1000th's time (and you don't need the manual in this case or any IMO "space wasting" selection window). If someone is new to the game he should have the possibility to access all information (and not depend on trial and error) so he should be able to access the manual from everywhere it is useful. This would mean one button in many pages but the big work of a well designed manual would only be needed once. I agree it's beautiful BTW. That's not my point. It's just a huge space requirement for information you only need about 10 times (until you got used to it) and functionality that could be done in a dropdown. Concerning the manual itself: The data in there should come from the templates so changes automatically go to the next "manual build" (AFAIK someone is/was working on this already).

Visual size vs obstruction size: But we can make the obstruction larger. Visual shape vs obstruction shape: Non-square/circular obstructions will most likely result in more unwanted behavior as well. Before introducing this (if at all) make sure those units can still guarantied perform all possible move commands. (I've seen no game where this worked so I'd say: Hands off!)

This should go to the manual IMO (which should be accessible in the main menu, the gamesetup and in-game similar to the civ tech tree in AoE II).

Why do we need a window/full screen menu to select the civ when one dropdown menu can do it? For me this would be a change for the worse... (I have nothing against adding "random groups") To have such things for the single player campaign would be OK but in MP I'd always like to see what other players pick.

Hephaestion: - "If" instead of "min" would not likely be faster here because the if condition would be the same calculation. - The "1 -" at the beginning is for the negative square function (before the "+") that should give a probability between 0 and 1. Similar the "- 1". - The "+ 1" in the second part (after the "+") is just to make sure the probability is never 0 (would do nothing). (ATM I go from the center to the edge of the window. Reversing that could remove some "+/- 1" but I would find that counterintuitive) (I could get rid of the "/ 2" by just halving both parts individually but the way it is it's simple to combime multiple windows functions. I like that.) - I don't plan walls on this map but I wrote the RMGEN wall_builder.js lib (where every wall element length is "hardcoded" again due to the lack of entity access which is bad ofc.).

Kk, thx.

Ah, k. They are placed in 0ad/binaries/data/mods/public/art/textures/skies/cirrus and the format is .dds. Gimp can convert images to .dds with a plugin. (Not sure if the existing ones are volume textures rather then plane images) Why do we use a Microsoft format? Isn't there an open format for such things? (Guess the specifications are open and Microsoft follows it for a change ^^ (?))

You can see the error in the mainlog.html. Sometimes however it's not very helping (like a missing vital ";").

http://trac.wildfiregames.com/wiki/Rmgen_Library#EnvironmentHelpers Hephaestion: Thx

Hephaestion: Well, I learned something (at least for relevant for Python I use most of the time) ^^ What I was mainly asking for is a fast well fitting function to replace the gaussian with. As a windows function I use a combination of a 2nd order polynomial and a trapeze (looks OK and is quite fast): var scaleX = (1 - (wx / dx - 1) * (wx / dx - 1) + min(min(3 * wx / dx, 3 * (2 * dx + 1 - wx) / dx), 1)) / 2;var scaleY = (1 - (wy / dy - 1) * (wy / dy - 1) + min(min(3 * wy / dy, 3 * (2 * dy + 1 - wy) / dy), 1)) / 2;(I could replace the "/ 2" with "* 0.5" but that's not the time consuming thing here anyways) The template information indeed would be very nice (though mainly for wall placement and debugging).

@ first glance: - Trees in water: The tree placement function is from Deep Forest (AFAIK). It is based on a possibility derivation across the entire map and doesn't support constraints. - Constraints/avoid classes: http://trac.wildfiregames.com/wiki/Rmgen_Library#ControllingPlacement:Constraints - Framerate: The framerate is low due to the many trees. There's not much you can do about it. You can raise it a bit by only/mainly using low poly trees (e.g. gaia/flora_tree_pine) and avoid the higher poly ones (e.g. flora_tree_oak_large). It's the same with Deep Forest. - Open space: Just remove the possibility factor based on the map radius (in the possibility derivation mentioned before). General notes: - Make sure the order of things is correct. It matters (e.g. in Deep Forest paths "overrider" woods so they have to be placed later). - You use different concepts never meant to work with each other (Placers/Painters/Constraints/Avoids vs. Global tree density functionality vs. Height based placement). Maybe you should first get a concept of code in your mind ready, decide which one to use and then stick with it.

Plz don't. This will likely not prohibit any spammer activity because they likely generate a new account and then directly act. It will however annoy sanely acting members after a longer absence. If it's really helping, well, OK. But AFAIK it will not.

It was never like this... I don't intend to make this map, niektb does. I just help him to fix bugs.

There where some additional bugs: - My HeightPlacer() didn't work properly (I used [x, y] instead of [x][y] and if no constraint was given it failed) - You gave an actor to the painter but it only takes "terrains" and you don't want to add the actor to every tile (so I changed that) - The LayeredPainter() needs the "width" argument being an array of the length of the terrain array argument -1 (the center doesn't count. See: http://trac.wildfiregames.com/wiki/Rmgen_Library#Areapainters for an example) - The RandomTerrain() class argument has to be a string of a terrain and optionally, separated with a "|", an entity from 0ad/binaries/data/mods/public/simulation/templates and a subdirectory (like "medit_sand_wet|gaia/flora_tree_dead" so without the ".xml"). You cannot use actors (from 0ad/binaries/data/mods/public/art) or templates (0ad/binaries/data/mods/public/simulation/templates without a subdirectory). [This as a great inconvenience and one of the reasons why I try to avoid using the RandomTerrain() class and that includes painters etc.. Additionally doing simple things like adding a patch of terrain easily depends on 10 other functions/classes so it gets horrible to debug.] - Additionally you used the UPPER height limit of the lowest level as the LOWER height limit for the painter (same for the upper height limit). I changed this accordingly. Here's the map as far as possible working with your approach (Since actors cannot be used I placed trees representative but you should avoid placing trees in water. The unit AI can't handle them.): schwarzwald-fex_v1.zip Additionally you should flatten the terrain where you place the paths (should be the SmoothElevationPainter()).

The water texture is not painted because the HeightPlacer() uses g_Map.height as heightmap while you modified myReliefmap and didn't apply it at the time you run the code. Apply it by: setReliefmap(myReliefmap);(That's one reason I don't want to add a library prematurely. It should be working simple with other libs code.) The path code does not generate the paths arround areas in avoidClasses(), the painter just doesn't paint it there (so it's interupted). The two maps you choose in fact use painter/placers/avoid very rarely. Perhaps you should also try to avoid them if you want to go with those two maps code as a basis. Or, if you want to use placers/painters/avoid you may want to use other heightmap manipulation functions that directly apply the changes to the heightmap (or you could just use setReliefmap(myReliefmap) simply every time you manipulate it).

Maybe if he adds a white line (disconnects the tools handle and heading) the C would become more obvious (If that's ment to be it ^^)

A placer for a specific height would look like: However, I try to avoid placer but it's up to you ofc. I can't find placers for slopes. If you want to use slopes extensively perhaps look into the getGrad() of my erosion approach: http://www.wildfiregames.com/forum/index.php?showtopic=16233&page=5#entry274289 This will generate a "slope" map.

If you are generating a new map open a new topic for that. I'll answer there.

It is if the fun/micro-management ratio is worse then the rest of the game. But that's ofc. a matter of taste.

Are terrainBaseBorder, terrainBase, terrainBaseCenter, baseRadius defined in your script? (Without the hole script it's hard to tell)

PLZ don't limit anything (I'm already annoyed with limited towers/fortresses). Balance things instead, please. (even a population cap would become unneeded if we had some kind of "upkeep" system e.g. gather rate decreases with population/number of buildings to simulate payment and administration costs)

Moderators are only needed if there are ways to abuse things. (If the chat is meant PPL just have to learn to handle this. It's an ability needed for living in a society anyways.) So just make things so they can't be abused.

The only thing I need to know is how to bias the realistic terrain generator to create a valley. Furthermore do I want to know how you made sure that the levels are playable. I noticed BTW that a lot of other RM-scripts use a heightbased texture painting too without looking very tiled. I'll try and see if it works for me. You can influence the general shape of the map by giving a rough initial heightmap (e.g. 3x3) like: initialReliefmap = [ [heightRange.max, (heightRange.max + heightRange.min) / 2, heightRange.max], [heightRange.max, heightRange.min, heightRange.max], [heightRange.max, (heightRange.max + heightRange.min) / 2, heightRange.max]];and then give it to getBaseTerrainDiamondSquare like: var myReliefmap = getBaseTerrainDiamondSquare(g_Map.size + 1, heightRange.min, heightRange.max, 0.5, initialReliefmap);You will have to apply the reliefmap to the g_Map if you finished manipulating it: setReliefmap(myReliefmap);So if you use the realistic terrain demo just add the initialReliefmap code (search for initialReliefmap to see where. the other preset initial heightmaps are documented out and will form islands). It then will look similar to this (tiny, 2 players, seed 1): (The diagonal appearance comes from the start locations being added that way, not from the initialReliefmap. The right and left side medium height "valleys" however do.) The getBaseTerrainDiamondSquare function doubles the size until it's bigger then the needed size and then cuts the bottom left part of the needed size. That will change in the future so the center is used rather then the bottom left. So until now on some map sizes the lake will not be in the center of the map. Additionally keep in mind that the shape is most suitable for 2 players. You might want to make the initialReliefmap depend on the number of players here because it's not radial symmetric. Also you should change on which height the start locations are added and add more tree covered "height levels" (textueByHeight array). Hope I could help. (Could someone PLZ make the post editor stop adding/removing spaces tabs and newlines insanely?)