FeXoR

Here's the wall demo with all civs included. The argument given to the 'wallTool' (or it's 'setStyle' function) takes the same civ strings as given by 'g_MapSettings.PlayerData[playerID].Civ' with 'playerId' set appropriate to player. For the wall demo map: Take a giant one, otherwise you will just see a mess of walls with many players. Each player gets a fortress of the style of his civ. When the civ is 'rome' (map editor only) the style will be set to 'palisades'. Fortress size depends on player number: - 1: 'demo' fortress (All wall element types included) - 2: 'small' - 3: 'very large' - 4: 'normal' - 5: 'large' - 6: 'medium' - 7: 'giant' - 8: 'tiny' In addition in the map center a 'palisades' style 'demo' type fortress is placed, just to see the size compared to existing civ's fortresses. wall_demo2.zip

THX, I will get to work on it again tomorrow. EDIT: Monday Edit: Well, soon Guess I will more or less finalize it then.

It would be nice if anyone interested could go through the code and tell me what to do better. Most parts of the code are setting up the length, placement angle and indentation of the wall elements appropriate to the template and the predefined fortress types, so this can be skipped and it's not much left to read. The main part I'm interested in is what types of variables should be what type of object (list/dictionary/object). For example the fortress class is not really needed for now but could proof useful for custom fortresses later. Until now a dictionary would do. I don't know how to define an object inside an object because 'this' always points to the 'most top' object. But this would be better IMO since the 'wallElement' and 'fortress' objects are not very useful without the wallTool and only take namespace. Some variables are not that well names like 'centerX' and 'centerZ' because it's only X/Z directed if the angle of placement is 0. And it's more an offset then a center coordinate, since it's the X/Z distance between the (unindented) position of the first wall element to the center. Perhaps I should do it exactly the other way around (vector from point of placement to the first wall element) and call it offsetX/offsetZ... Sounds good at the moment. And should I define the 'wallStyles' and 'fortressTypes', which take a lot of space, somewhere else? I find it makes the main 'wallTool' code harder to read because it splits the code for functionality. Don't exactly know where to put it... Also the getCenter function is really useful but I don't know when to use it exactly by default. (Returns the 'Center of mass' of the fortress) I do it when setting the wall to a preset fortress, though, if custom fortresses have been added to the 'fortressTypes' and have a 'center' defined manually, it will be overridden until you turn the 'recalculateFortressCenter' property to 'false'. That might not be very handy (though I doubt many would search for the center by hand ^^. And you still can simply use the 'wall' property and set the center vars manually). The existing 'wallTypes' are not very well documented yet. But I think they are chosen wisely. Wait to see the other fortress styles... A circular wall tool was requested and I will add it soon. It will have the functionality for generic bending of walls. Edit: Not to the ground but to one and another wall element so a point is enclosed. I guess tomorrow I will finalize the other wall styles and there will be some more screenies.

THX for this map, I can actually play it without lag on my labtop. EDIT: Just bad the AIs can't play it (Pile up peasants in the nowhere). But that was on alpha8... I like the hight map. Will lure into the code ^^ The resource placement is a bit unbalanced though (at least on the maps I played) But over all very nice.

Nearly done. Can be found here soon...

Hui, I didn't read that before but 'deep forest' looks very similar to 'Ardennes Forest' in the 'MAPS AND BIOME GUIDE'. Should really have read that x) Didn't play AoK. Didn't meant to steel someones ideas or offense anybody by naming my map 'deep forest' and not ' Ardennes Forest' (which is already taken btw) or anything else.

OK, I'll do all that. May take some time though until the next version cause I'll do some rewrites. Found some bad code design and since I got to know JS a bit better I want to change it. Thy for the feedback though. EDIT: I'll go temperate. I think it fit's best to a deep forest...

Hiho, I found there had to be a better possibility to place walls, so I wrote a rmgen script to make it easy... and it is! With it a demo RMG to see how it works. Until now only wall design type 'palisades' available... it's a bit of work but other types are easier and will be added soon. To make a custom wall, just do something like: var myWall = new wallTool('palisades'); myWall.wall = ['wall', 'tower', 'wall', 'cornerIn', 'gate', 'outpost', 'endRight']; var startWallX = 100; var startWallY = 75; var startWallFaceAngle = 3*PI/4; var playerId = 1; myWall.place(startWallX, startWallY, playerId, startWallFaceAngle); You can also choose from prebuild fortresses (like it's done in the demo map) by: var myWall = new wallTool('palisades'); myWall.setFortress("very large"); // Sizes named like map sizes, 'giant' is missing, yet... myWall.place(mapCenterX, mapCenterZ, 1, 5*PI/8); EDIT Start: New versions in later posts! Last version for Alpha 8 can be found here. Later versions are for the svn repo and will be added in new posts. EDIT End. Well, to fully get it I think better read the comments in the file. wall_demo.zip And a screenshot of a small map with 8 players.

Here we go. Nothing changed but the function names and removed some unused stuff. EDIT: Well, indeed I put it here. Edit2: Oh, it seams I raised the tree density... sry, well, at least it's a 'deep' forest then... deep_forest_v0.5.zip

Thx, I thought so, I'll rename them... BTW: I hope you mean @ least notepad++

Could you please check your mainlog for warns/errors? Would help a lot if there are some... EDIT: Perhaps I use the same function names as used in the new rmgen libs (and so override them?) and other rmgen functions that are using the overwritten ones act strange.

This is strange! I use alpha 8, perhaps that's it... All functions I used are inside the map, perhaps some rmgen libs changed... I have no clue, I generated the screenshots of my previous post with the downloaded version and didn't change any files... EDIT: U'r screenshot shows No hight mapping(hills/lakes/paths), no texture (base, path, woods, lakes) and no entities but the start entities and start resources... Checking the 2 functions that didn't seam to run at all...

Huh??? I'll test the download today, didn't check it... EDIT: Yes, U'r right somehow, it's a feature Adding some screenshots of what happened to you, I think: On tiny maps: If you have more then 3 players on a tiny map, the map will be quite empty. Similar with small maps and more then 5 players. In addition to that 'expansion' metal (normally outside the start locations) is very near to each other when you have many players on small maps. Should scale the path's more with map size and perhaps the base size. EDIT: Scaled the maximum tree density with the map size for future versions...

So, here's the next version, quite playable now though many details still missing. Feedback welcome. deep_forest_v0.4.zip Whow, making screen shot of giant maps takes about 15 min... but I had to try x)

In fact I think it's path finding problem... Well, pathfinding is always a problem ^^

I don't think it's a bad idea to have some space at the border, looks better, the shadows for example and map doesn't end so abrupt. But it should have no game impact. Perhaps those objects could be shown but marked as non-interactable so no player/AI/Unit AI tries to interact with them... and fails.

THX, THX, THX!!!!

In beta 8 (installed with 0ad-r10803-alpha-win32.exe) yes. EDIT: Perhaps should install on linux and use the svn version to keep track of the actual development... - latium, tiny, players 2, seed 0, bottom on the cliff is a tree. - Cantabrian Highlands, tiny, players 2, seed 0, right bottom of the blue players start location is a tree. - Neareastern bad lands, tiny, players 2, seed 0, bottom left below the red players start location ...did'nt even need to seed to find some...

I don't have problems with vector maths, I have the problem that I don't want to what Ykkrosh told me to avoid. And I don't know how to avoid it. If you wrote functions with about 4 decimal points higher accuracy (The error in trigonometric functions in JS in different OS I rad about in posts was about 10**(-6)) wouldn't it be a good idea to include them in other areas of the game as well?

After a little wile I noticed that it's quite impossible avoiding placing objects on coordinates (z and z in floats). So where can I find a documentation of that 'vector maths' you are suggesting. I only found vector math libraries but don't know if there's a default lib in JS for it and which one you use allrdy (if so). I noticed though that may functions in the rmgen libs use trigonometric functions. Please, answer this one quick so I avoid doing things I have to rewrite. Thanks.

On some random maps (I didn't check all the scenarios) interactable objects are so close to the map border that no units can walk there. I think the the general functions should warn if an entity is placed to close to the map border so that map/rmg designers are made aware of. In my circular rmgs I define a 'playable map radius' variable and set it to 'g_map.getMapSize()/2 - 5' and always check against it if placing entities.Walkable map area my be a bit bigger but I didn't notice units could walk behind a tree placed at this radius. Have to check though.

You are right! I did try that but didn't restart atlas. The .json file does not seam to be reloaded when re-generating the map. THX!

The outcome of that night can be found here.

After a rough night I got further... The story about that night can be found here. The outcome is this: deep_forest_v0.3.zip Bugs: - Resources are not really implemented at all (The resources at start position are more artefacts of the previous version then inclusions of this map) - Didn't find a way to lower the water level, so I raised all tiles - one by one - by one (Sounds strange but it's correct, I guess). EDIT: Now I know, THX howlingflute! Issues: - Still lags on big maps due to the number of entities. - Takes a bit long to generate due to some self-written functions (they are not necessarily bad but can be made faster) - Map code has to be tidied up! NOTE: I got no 'out of memory' problems but I only made 'normal' sized maps (All maps lag on my labtop when bigger then 'medium') Poor design/things to add or comment: - There are too many trees in somehow unused map areas near the map border that only causes laag. Cliffs or Lakes should be added there. (Spahbod's suggestion) - Map border is not designed at all, cliffs/lakes/terrain should be added (I wanted to ensure no chopable tree or other interactive thing is unreachable for units because it causes lags caused by AI, unit AI and/or pathfinding, gatherers pile up there) [cause, cause, cause x)] - To many/broad roads. With many players they will nearly fill the area between start positions. Should be somehow scaled with number of players. - Outer roads should be dragged to the border to enlarge the playable map area. 1 of the 2 roads between 2 given players should follow a 'circumventing' not a 'straight' path. - Roads are to straight IMO. They are generated with a type of 'directed random walk'. If I raise the possible angle the next step directs too much, they might never reach there destination. On bigger maps they might stop somewhere on the map because steps are caped at 1000. (Further tests needed) - A general hight map should be added. I would like nice, smooth hills. Raising the terrain in the map center and lowering it at the map border would suggest lakes at the border rather then hills/cliffs, but we will see... - The forest's floor is to dense. - The forest floor is to uniform. Some sand/dirt should be added. - A 'forest border' should be added with bushes and longer grass surrounding the forests. - The forest hight should be raised in a wider radius. Will be implemented with the 'forest border'. - Terrain textures has to be chosen more wisely. I like the 'mud_slide_2' texture for road borders and bases (looks like dung ^^) but it occurs to often. Single textures of the same type tend to look squared. Have to finetune textures and perhaps rather place them on small areas then single tiles. Available textures are awesome though, great work! - Player's start positions should be randomized more, especially the angle. Increase the angle offset will do IMO but an added absolute radius offset scaled with the squared map radius could help too (tuned for 'giant' maps which I can't test though...) And some screenshots:

To say it first: It was my fault! I should have read all the rmgen functions. I shouldn't have asked, I should have read the code... Well, I didn't... The result was about 5 hours writing and changing code with very strange outcome (I wont annoy you with that but I have to tell my odyssey to get rid of my aching head) ...that had an effect similar to what I wanted but with terrible side effects and left me totally confused (and I still don't know why the hell it somehow worked) If you don't want to waste your time skip the rest of the post... But if you want something to read, here's The Story Somehow it goes back to QUOTE I was grateful and in the late evening started to rewrite my deep forest RMG, where I wanted to have paths going through deep wooded hills. Note that I paint the paths first, since I couldn't find a way to remove trees and wasn't very familiar with terrain back then, and first had tried to lower the terrain of the paths a bit and used the sunken terrains height to avoid placing trees and textures on roads and so. This resulted in water on the roads and that U couldn't build there any more. But with the new 'knowledge' I was determined to do this with the 'g_Map.texture' and/or 'g_Map.terrainObjects' functions by avoiding to place things on road terrain. I had seen the avoidance implementations more commonly known as constraints, but I wanted to do this myself! So I wrote pages over pages and added some functions here that could be useful and the 'g_Map.texture' to check versus my path terrain strings. As I was finished I tested a bit, removed some typos and finally the RMG run through. But there were still trees on the roads. Maybe I swapped some conditions... turned them from false into true and from 'and' into 'or', though I didn't thought it would work cause it felt strange, and tested and, AND... well it looked OK! Really what I had in mind! Woods thinned out at a circle at half the map radius and, finally, no trees or forest floor on roads! I felt relived and thought 'tomorrow you will post this, much better then the last one'. Though I was tired I tried to raise the density of the woods cause somehow it was much thinner than I had in mind. I didn't fear any kind of problem since I lowered the tree density often for generating bigger maps on my old laptop and to avoid lags while viewing the map. But as I looked closer to the code, the density was already at 0.5 (50%, about each second tile) what was quite tight. I reviewed the map in the editor and it was definitely NOT every second tile! I reviewed my tree derivation function, read it over and over again to find the mistake, but everything seamed in order. I added tons of log code to output the actual tree density for every single tile (on the x axis to be correct). But everything was fine. Hm, Perhaps still something wrong with the 'g_Map.texture' condition, well it felt strange. OK, let's take a look... log said it return... UH, numbers! And why does it work... well lets see the function's code. Oh, IDs... I only use strings and arrays of strings... And why does it... ah, let's get the terrain ID by 'g_Map.texture' for every road tile I place and store it into an array so I can check against. ...one hour later with my tired head barely raised above the keyboard the map ran through and... took ages to generate! No warning, no error, no out of memory... it just lasted... and finally run through! But now there where trees on the roads again. Angry I commented out the checks and generated, just to see what happens, nothing special on my sluggish mind. Took a while... why ever... - Oh, trees everywhere, packed so tight I couldn't even scroll, what's up???!!! My tree derivation function did everything right, but the check versus the list of values got by 'g_Map.texture' at every tree placed just thins out the bunches of trees to barely deserve to be called woods! I deleted my hole check implementation, just was to frustrated. 'IT SEAMED TO WORK' it cried in my head. 'IT seamed!' I stared at my code a bit, seeing nothing. Then started to read through all the rmgen files still determined to at least get the 'is road' check right this day. not to mention that it was already 4:50... Most code I already knew but then, out of the nowhere, I stumbled across a Map.getTexture function!!! It was there! All the time I was trying to enforce it by abominable functions and horrible workarounds, it was there. Took me less then five minutes to figure out that it indeed returns a texture string, that 'g_Map' is an instance of 'Map' and to implement the 'not a path' checks needed with simply using 'g_Map.getTerrain'... which I COULD HAVE GUESSED!!! Five hours versus 5 minutes. That's... I'm so bloody incompetent, a dull mangy cur. I was relived though and added some base texture, tried to figure out a good derivation for secondary resources but finally dropped dad in bed. And historic_bruno said 'I don't know of any function' not 'there is no function'... Hope I learned from it though... well, hope dies last.