FeXoR

In general I like the normal, 'simple' solution with structural points/health, attack and armor. A 'chance to hit' for ranged units can be added by checking if the tile that is passed by an projectile contains a unit that has at least the hight of the actual projectiles hight. That way a mounted unit may be hit more often than a foot soldier. There might also be a chance to be hit smaller then 1 (100%) for smaller or more agile units. That would represent luck and avoidance though avoiding an arrow for example is quite impossible when you are in a battle facing an enemy in melee combat. A chance to block may be added depending on the equipment. Peasants and archers have no close combat weapon or shield so they have 0 chance to block anything (though they may have a little higher chance to avoid attacks like 10%). Units carrying close combat weapons like swords, clubs/maces or axes may have a chance to block melee attacks of 10%. Swords are indeed designed to block melee attacks and so may have even 20%. Shields are designed to block both, melee and ranged attacks so they could give lets say 30% chance to block melee and 20% chance to block non-siege ranged attack. Units wearing spears or polearms could deal higher charge damage instead. Javelins get the bonus for the shield if present and can use their weapon for both, ranged and melee attacks, but don't get a block chance for their weapon. The reason why I like the 'normal' system is that something like blocking/evading can be added by simple mechanisms that are understandable for the player and can be displayed to him properly and consistent. A short list of example equipment with block modifier for the more detailed part below: - Helm, chest/leg/other Armor: Adds armor as it is now, no block (perhaps lower chance of evade but evade is not that important IMO as stated above) - Sword/saber: ~20% chance to block melee attacks (melee block 2) and of cause enables the unit to deal damage (as it is now) - Club/Mace/Axe: ~10% chance to block melee attacks (melee block 1) and of cause enables the unit to deal damage (as it is now, perhaps a little higher to balance the block) - Javelin: No block, grants an ranged and melee attack (as it is now), can hold a shield as well. - Spears or other two-handed weapons: No block, enables the unit to attack at melee range and deals high (charge) damage. Some of them may be able to attack above 1 tile. Since such a unit can't hold a shield it has no block at all. Those units should get attack bonus versus cavalry IMO. - Shield: ~30% chance to block melee (melee block 3) and ~20% chance to block ranged (ranged block 2) but adds no armor! Block values may differ type dependent. - Bow/arrow: No block, for balance reason (and realism) they may get higher range. Getting more detailed: In the code it may be useful to work with exponential functions to make sure no unit has 0 chance to hit a specific other unit. The chance to hit can be then calculated by 0.9^n where n is the sum of all 'melee/ranged block' values of the targeted units equipment. If a unit for example has a sword and a shield (somehow the maximum block to get) it has a chance to get hit in melee combat of 0.9^5 = 0.59049 and in ranged 0.9^2 = 0.81. The rounded values than can be shown in the gui: 41% chance to block melee (1 - 0.9^5 = 0.40951) 19% chance to block ranged (1 - 0.9^2 = 0.19) This hast the additional advantage that moders may add raising block values and the chance to get hit will never reach 0. With an attack/defense value system the chance to hit/get hit/block depends on the pair of units fighting and so cannot be displayed directly. Instead some values are displayed that doesn't tell the player much about the strength of the unit when he doesn't know the formula (and even then he will rather know due to gathered experience then actual calculation). To randomize attack damage units could have a minimum and a maximum damage and the actual damage is randomly chosen out of this range. Indeed only a maximum damage would do (and actual damage = random number between 0 and the maximum damage). As it is now is the armor just the value subtracted by the incoming attacks damage? Because that has to be kept in mind when randomizing damage. IMO an attacked unit should at least loose 1 health/structure point if hit.

Here's the next version. Get the rmgen script 'library.js' from the SVN repository for Alpha 9 (actual version in the download). Here the overview or take a closer look And here's the download: deep_forest2012-3-23.zip

1: Oh, yes, my hills (renamed them to general hight map, I guess that's what you mean). That is not really finalized and could be added to a lib as well if finished. Indeed they cause bugs when changing the order in which paths and hills are placed. May be the reason for the strange acting SmoothElevationPainter. Somehow forgot about them ^^ 2: Hm, not so good. Maybe it's worth a clean up mission. Using paintClass() to add areas to classes works well, by the way.

For me it works fine. I have installed alpha 9 (had alpha 8 before and reinstalled) and the SVN version somewhere else. I manually added the directories C:\Users\[user name]\AppData\Roaming\0ad\cache\mods\public\maps\random and C:\Users\[user name]\AppData\Roaming\0ad\cache\mods\public\maps\scenarios like said here (it's somehow hidden IMO). It works with both, Alpha 9 and SVN version. Don't know it this helps in this case and which folder it is exactly for Mac...

I like it though I don't think it should be the default. Perhaps you could write a random map supporting that system or, if working well, add a new random map library. So some maps can use it and others may not. I don't think that the majority of players will accept maps running slower for good 'world simulation' but if it runs smooth...

@ avoidClasses: Yes, I think that was a bug in my script (though I added the center of the resource clump to clHill with addToClass). @ own libs: Yes, I may do this. But for now I want to finalize my wall tool (circle and generic fortress allrdy working without rotation yet, 'placeSimple wall' that places a wall of given wall elements from 1 point to another will be added too). Than I will look into the coordinate change that effects the unit placement as well and so has wide effects (see this and following posts). To add placement functionality like in my map I have to look deeper into the code to make it compatible with the existing ones if possible (would be nice). @ paintClass(): Thx, that might help. Testing though unneeded at the moment. Some other questions: 1.) What do you mean by 'hard-coded'? Beyond the forest placement (which is IMO unique and might not be generally useful for other maps) and the paths (there need is somehow a consequence of the deep forest) I don't see any hard-coded things. When I'm satisfied think of rewriting them for libs though. Of course the player's start position placement could be generalized for different types of maps but it is done like that in other maps too. If I had access to the SVN repository I would really be more inspired to add library functions and total new libraries than I am now. I don't want to ask someone regularly to add an SVN update! However, Please tell me what other parts belong into libs. 2.) Why are the rmgen libs written in a style that prevents refactoring? If something is a class in many cases there is a function that gives back the class but by reading the function you are not closer to understand what the function does because it just gives back an other class object for example. Then, reading the class's construction code, you are not much closer because it uses another class though the used class is exclusively used by 1 other class (or function). Sometimes it appears to me someone wanted to avoid people refactoring the code. That might be an issue only appearing to me, though. As I said before the functions available does reflect the needs of a random map API quite well. Sometimes I just want to stir around in their guts and have to find out that the code needed for that is longer, slower, more complex and less readable than hard-coding the functionality in the given map itself.

Half the code needed for that so see the full code further below. I'll do that but it works for now... I know: var pathWidth = 5; // This is not really the path's sickness in tiles but the number of tiles in the clumbs of the path It does, but the uncommented stuff is the thing in question. So in this code it's the 'avoidClasses' and I have no idea why. I fixed this by painting the hills after the path, so don't tell me that it will not work because no tiles are added to 'clHill' at this point . I just wanted to tell that 'avoidClasses' sometimes fails (maybe because of the centered placer with given coordinated, I don't have a clue) For the dark forest map I want the forest to be placed differently from the other maps to really make it dark (well, at least in theory possible). So I add it on every tile if a random check vs the 'actual density' succeeds. This 'actual density' is mainly the 'maxTreeDensity' (constant for a single map dependent on map size to avoid out of memory errors) scaled by other density modifiers (Dependent on distance to next start location or the center eye candy and the radius to have room to place additional resources at the given radius). This works fine and as I want it. However, to enable the players to reach the center and each other on more than 1 path I added paths that should cut through the woods (I think that would just be possible by adding the paths after the woods, but I wanted to get used to the painter/placer/constraint/area usage that is in most cases the perfect thing). I noticed that the paths sometimes run in the non-starting-resource-hills and that looked bad so I added an TileClassPainter(clHill) to the resource area and the avoidClasses(clHill) constraint to the paths. But it didn't avoid the hills. So I placed the hills after the paths. That was most likely a bug in my code that I didn't find because for the woods (that avoids paths) it works and it's a centered placer, too. Besides: As it is now only the center of the paths and the resource terrain clumbs are in the corresponding classes not all terrain clumb's tiles. Here it is though not in a PM, someone might find it useful (like your suggestion to use float, not int): And a download: fexor_simple2012-3-22.zipBy the way, NONE of the existing maps use 'TileClassPainter' so I'm quite sure it doesn't work properly. For SmoothElevationPainter: I can't reproduce this on a simple map (why ever) but just replace line 223 with: var painter = [new TerrainPainter(terrainWoodBorder), new SmoothElevationPainter(ELEVATION_MODIFY, 0.0, 10.0)]; And play around with the 'ClumpPlacer' and 'SmoothElevationPainter' arguments. Then generate the map and watch the terrain elevation below bushes/wild animals/apple trees (all in 'terrainWoodBorder') I recommend to generate it with 3 players on a small map. It generates relatively fast then and has enough wood/wood border to play around with the variables and see the results. Writing a test map...

OK ^^ Then what do I do wrong when: var placer = new ClumpPlacer(pathWidth, 1, 1, 1, x, z); var painter = [new TerrainPainter(terrainPath), new ElevationPainter(-randFloat())]; createArea(placer, painter, avoidClasses(clHill, 20)); // AVOID CLASS DOES NOT WORK!!! Because of centred placer??? Here: var placer = new ClumpPlacer(1, 1, 1, 1, x, z); var painter = [new TerrainPainter(terrainWood), new ElevationPainter(randFloat())]; // new TileClassPainter(clForest) RAISES ERROR!!! SmoothElevationPainter(ELEVATION_MODIFY, randFloat(1), 1) STRANGE ACTING! createArea(placer, painter, avoidClasses(clPath, 2)); If I add SmoothElevationPainter here it's only lowering the terrain when I set elevation AND blendRadius negative. However, when used with a bigger ClumpPlacerit seams to work much better though even if the elevation is positive it sometimes lowers the terrain on the right.

Here's a version with randomized stuff, some templates changed to temperate and lots of animals to hunt. I don't like wolfs so I didn't add them yet. I will when they don't destroy buildings or an acoustic alarm with event position is added. NOTE: This is for the SVN version and will not work properly in alpha 9! deep_forest2012-3-21.zip

I noticed that some placers/painters does not work in combination. - avoidClasses does not seam to work for centered placers. - SmoothElevationPainter does not seam to work for non-centered placers (at least not properly for a ClumpPlacer of size 1). - TileClassPainter does not seam to work at all.

Here is a total rewrite. Not finished but 1/4 of the lines of the previous version It may happen (though it only happened to me once) that a path runs out of the map and causes an error. deep_forest2012-3-20.zip I'm still not happy with the terrain textures. Any suggestions welcome. If you play with many players on a small map everything will be covered with paths. But 3 players on a tiny map is ok so it's not that bad. On large or greater maps the woods is still thin to avoid out of memory errors. Ideas and criticism welcome. Edit: Start position and starting resource placement not randomized yet. Deer, sheep and chicken to be added.

I'm a little surprised as well. In most communities the problem is that players leave before the game is over and ruin it for other players especially when in teams. To ensure high gaming quality in public servers the only decent working mechanisms are whitelists and votekicks with all other players agreeing. And even then players will sometimes be kicked without a serious reason... I can't understand this...

Well, I don't know if I can do it and what '...engine's random map loader so it does the conversion...' means in total, since I only read the rmgen libs yet. However, I can of cause look into it and I would like to help documenting the results to RMS scripters. The documentation of code change should of cause be done by the person who changes it... I'll look deeper into the code on Monday.

If they are able to hit an enemy running away at all (which is not the case a.t.m. since the attack will be broken up cause target out of range) By the way... what about ranged cavalry? I agree that chasing (running) could solve some things. If an attack deals damage right at the beginning of the attack animation it could help melee units as well (and is realistic since the unit can arrange his attack while running) However, it will be a bit out of sync with the animation unless there will be a chasing animation with raised weapons.

1st: The army camp costs mainly wood witch is (on most maps) massively available. 2nd: The normal fortress is to cheep in my opinion Lets calculate: 15 Upkeep, 20 garrison space and production building ~= 3 towers (125 resources each) + 3 celt huts (100 wood each) + barracks (200 resources) -> 675 resources... and I didn't took in consideration the firepower (I think > than 3 towers) and that you can produce better units.

Well, then talk to them. I don't really mind what comes out in the end, but I think (like stated above) the advantages of default x/y plain behavior are greater than both, the 3D mathematical consistence and the clockwise rotation. Whatever happens one thing is important to me: Unit placement and the functions of the rmgen libs have to be consistent! If I can do anything just ask... I just don't know how to help ATM.

Hm, ok. Did this by: var placer = new ClumpPlacer(1, 1, 1, 1, x, z); var painter = [new TerrainPainter(terrainWood), new ElevationPainter(randFloat())]; // new TileClassPainter(clForest) createArea(placer, painter); for every single tile. The TileClassPainter is commented out because he throws an error. (Not a problem for me cause I can add them by addToClass but in general it is) A problem is that the SmoothElevationPainter does not work properly too. Even if I set height to 0 and no matter if I choose ELEVATION_MODIFY or ELEVATION_SET a single tile is alway very high on the left side (perhaps +10) and about half as high on the right. However, it works with ElevationPainter as I did it manually. Thx! Just needed a little motivation ^^ What happens if you place 2 clump placers at the same position when painting entities. Will there be 2 placed at the center of the same tile?

The map is not working any more due to changes in the rmgen libraries. I'm working on it...

When I have a list of tiles for example tileList = [[23, 116], [23, 117], [65, 86]] is it possible to use the standard area/placers/painters/constraints methods to place terrain/hight/... on them? As you can see the tiles in the list are not necessarily connected. I can add them to a tile-class or place terrain and set hight manually but I want them only to be placed if constraints are ok so their placement has to check other tile-classes. So it would already help if I could check the constraints of the other tile-classes. I would be grateful if someone could help me with that. I don't mind the notation like tileList = [x1, z1, x2, z2...] or whatever.

I had no such error in this map but I had it when the getAngle function was changed. It was caused by the try to place terrain on a tile outside the map.

OK, I did a little more drawing... For better readability as pdf, too: angle_explain.pdf

Oh, true x) But theta < 0 because it's the angle from vector to point1 towards vector to point2. It just that phi - theta = 2*PI (not phi + theta = 2*PI) no matter how often you rotate them around full circle. That make phi = 2*PI + theta, but since theta < 0 -> phi < 2*PI. Sorry x) Though it's a wonderful conversation but I have to go , will get back to this tomorrow...

getAngle: Should give the same angle since it's smaller theta < 0. My dear, open pics in new tab to read them... Hope that explains it...

I'll do, edited my last posts in sync with you posting x) Perhaps read them again, sry. I'll add the pics in a new post...

Exactly! It should be phi but it doesn't really matter cause sin/cos will give the same values, or? Edit, yes, they do. and you get the same result when using them for building placement. Otherwise phi%(2*PI) Edit: Makes no sense, always smaller than 2*PI and never negative. Yes, and both should be consistent of cause. As we agree that z should just be taken as y counter clockwise starting from positive x would be the choice to take.