FeXoR

True, for groups of object these functions are very helpful. But they use sin/cos like I do (for example createObjectGroups) which is not really a good idea as I got to know in an other post you where involved in (THX for your time) : getDistance(point1, point2) and getDirection(point1, point2) from one point to another Sometimes units are very tight packed though. I used functions that only uses tiles to place something but I doubt this is practicable for generating whole maps. I look forward to the beta 9

So the thing to do is only setting objects on tiles (eventually by rounding but only if necessary), never on coordinates (pair of floats) and hope that no missmatch will occur. Things to avoid are then: - ceil and floor (small missmatches of a natural number would often cause inconsistence) - Using polar coordinates for entity/terrain placement (as I have done in my RMG, even if I round afterwards this would not be wise) ...and for sure other things I've done allrdy. I will learn...

OK, Totally agree! But I find many functions inside the rmgen libs HARDER to understand and use then the more basic functions. In fact most of them take or need more arguments... Example: I mainly use "placeObject" to place entities. It takes 5 arguments: - x-coordinate(float) - y-coordinate(float) - template name(string, base filename) - player index(integer, 0 for gaia, 1 for player 1 with default color blue, ...) - orientation(float, 0 for top, PI/4 for top left 45°, PI/2 for right, ...) Everything simple and clear to me. In the RMGs included (for example latinum, great work BTW) uses: var group = new SimpleGroup( // elements (type, min/max count, min/max distance, min/max angle) [new SimpleObject(civEntities[0].Template, 1,1, 0,0, BUILDING_ANGlE, BUILDING_ANGlE)], true, null, ix, iz ); createObjectGroup(group, id); Oooooookkkkkkkkk.... let me see. "SimpleGroup" (astonishing name for that ^^) needs 5 arguments from witch one is "SimpleObject" (even better x)) that takes 7 arguments. Even the RMG's author added a comment for the arguments... This is not "simple" in my book, but AFAIK that was the purpose of that function... Well, still getting to know the functions available better and try to get your idea behind it... So, to say it clearly: U'r doing a great job! I just don't always get it

Uh, didn't think of it! But isn't the map generated on the hosting computer and then passed to the other players? And that kind of functions are used in many (if not all) RMGs like sin and cos. I don't what to argue about how to implement them (and that my code sucks and is only meant as an example) but I feel they are really needed! About the ";" thx for the statements, I'll read it when I have time (x)) but I closely listen to your advises! I have no problem with that, I'll be patient and rewrite my files when it's added. But until then I "have" to use my own functions even if my RMGs only work in single player... because I'm hot now and I admire it Is there anything wrong with that?

I don't think anything I read hits the point. If you really feel like needing regrowing resources, it could (AFAIK there is no possibility yet but it's really REALLY needed to make awesome scenarios) be implemented map by map (or in future libraries) by enabling triggers and functions during game time. I really think if that would be possible, users will start to build maps with regrowing resources (I surely would)! So... implement "easy" to use (as the random map generator scripts) "script during game time" functionality. I don't think that 0ad will ever have (or need) the huge implementation of in-game triggers in the map editor like in Warcraft III and a full support of adding scripts in JASS (similar to 0ad random map generator functionality) But... EXACTLY THIS led to a huge community, a vast variety of maps feeling like totally different games and a long lasting popularity! And I don't think anyone inside Wildfire Games or the community around 0ad would say that is a bad thing In-game triggers are important! Can't say it to often and in to many different font-types

My .json file: { "settings" : { "Name" : "Deep forest v0.3", "Script" : "deep_forest_v0.3.js", "Description" : "The early snapshot of a deep forest map. Siege weapons may have problems to pass...", "BaseTerrain" : ["grass b soft dirt 50", "grass1", "grass1_spring", "grass_field", "grass_moss"], "BaseHeight" : 0, "seaLevel" : -5, "CircularMap" : true, "XXXXXX" : "Optionally define other things here, like we would for a scenario" } } But the roads are still under water... EDIT5: Using the alpha 8. EDIT: In library.js I see this: const SEA_LEVEL = 20.0; EDIT2: I added: setWaterHeight(-5); g_Environment.Water.WaterBody.Height = -5.0; to the .sj file but still the same. EDIT3: log("g_Environment.Water.WaterBody.Height = " + g_Environment.Water.WaterBody.Height); returns "g_Environment.Water.WaterBody.Height = -5". EDIT4: But in the function "ExportMap" (used at the end of my script like usual) in "mapgen.js" I read: g_Environment.Water.WaterBody.Height = SEA_LEVEL - 0.1; and log("SEA_LEVEL = " + SEA_LEVEL); returns "SEA_LEVEL = 20"...

I don't know why, but AIs tend to build mass female peasants especially if the map resources run low. That's exactly the wrong way to go! If the map has not many resources left, AIs should STOP building female peasants because they are useless in that state of the game (and that may be the case from star on). The "new RMS Test" generated maps are quite playable (though not very exciting) for human players with farms and a market. But AIs even have problems with maps with mass wood, stone and metal, just because there are no plants to harvest food from. This really is a stupid thing, I feel. I don't even like berry bushes and apple trees because they only block buildsides, make me gather apples but wood by accident and all got a lower gather rate (including chicken, deer, sheep, corral etc.) then fields (because u can put them right next to your city center). The AI of cause should use them, but shouldn't need them!

OK, I thought so, just wanted to tell. Because, as it is now, a repeated given "go to" order will not get an army anywhere but only drags them together.

THX for the replies! I'm on it Yes, I noticed, can't build there... How do I do it? Yep, sounds good to me. If you mean the borders of the cliff I agree if at a reachable position. If you mean the map border I disagree. They are unreachable and will make gatherers pile up on the map border. That's a real issue IMO. unreachable resources should be marked with a flag like "interactable = false" or so so that no AI player intends to gather those resources. If the pathfinding routine would have a reply like "yep, I sen you near there, but this destination is unreachable" it would be even better. Yes, there's a varable "density" that can be reduced. But I don't know how many tiles distance between trees a unit needs to pass through. And if units can at least walk int the forest a bit, pathfindingroutine will go mad (I'm quite sure about that) Yep. I can't do much today, but tomorrow I will go for it!

I don't mind if it's a function or not, THX a lot, U made my day (and the next!) ^^ Doesn't matter, I can get the terrain for coordinates, everything's fine for me. Why is it so important to have a function for that as well? I often directly use the g_Map vars/consts, what is wrong with that? I don't change them of cause x) ...wouldn't dare to!

I removed the "var" in my script, just didn't want to spam posts. THX, I'm not familiar with javascript. I don't exactly know when to use ";" at the end of the line and it seldom raises warnings when not present. I saw some missing ones in other scripts so if I do something wrong, plz let me know. Oh, well, figured out the function myself because I didn't find one in the helper functions in the rmgen .js scripts and needed it.The main thing is a function with the same functionality despite the name and the exact code.So please add something like that in the scripts.If I find the time I will adjust the code to you'r recommendations.

That was TO dark. Here's a more playable one deep_forest_v0.2.zip

Here's my (poorly implemented) early version of a deep dark forest map. Well at least at size medium and higher. Well, I learned much about what I did wrong when I made it x) Here it is: EDIT: Dont download this! Plz look though this topic for later versions. deep_forest_v0.1.rar deep_forest_v0.1.zip Siege engines might have trouble getting through

Inside the 'if' statement the 'var' in front of 'output' is not needed, but does'nt hurt AFAIK... And sry for my poor english.

The getDirection function fails if both points are the same. So here's a version that don't... // Function to get the direction from one point to another function getDirection(point1, point2) { var vector = [point2[0] - point1[0], point2[1] - point1[1]]; var output = 0; if (vector[0] !== 0 || vector[1] !== 0) { output = Math.acos(vector[0]/getDistance(point1, point2)); if (vector[1] > 0) {output = PI + (PI - Math.acos(vector[0]/getDistance(point1, point2)))}; }; return (output + PI/2) % (2*PI); };

I want to paint the map with terrain and then add objects/elevations but after a terrain is placed I don't find a way to check what terrain is placed on a tile. Is there any function for that, can't find it... THX for you'r pacience

Opened a new topic: getDistance(point1, point2) and getDirection(point1, point2) from one point to another

There are some functions i missed inside the rmgen .js files. Here are some suggestions i find useful and put inside my random map as helper functions. The "getDirection" function is a bit fuzzy but works (consistent with the unit placement orientation AFAIK). Might be written more sober though. I skipped checking the given operands in any way but that might be wise... // Function to get the distance between 2 points function getDistance(point1, point2) {return Math.pow(Math.pow(point1[0] - point2[0], 2) + Math.pow(point1[1] - point2[1], 2), 1/2)}; // Function to get the distance between 2 points given in seperate coordinates function getDistanceXZ(x1, z1, x2, z2) {return getDistance([x1, z1], [x2, z2])}; // Function to get the direction from one point to another function getDirection(point1, point2) { var vector = [point2[0] - point1[0], point2[1] - point1[1]]; var output = Math.acos(vector[0]/getDistance(point1, point2)); if (vector[1] > 0) {output = PI + (PI - Math.acos(vector[0]/getDistance(point1, point2)))}; return (output + PI/2) % (2*PI); }; // Function to get the direction from one point to another given in seperate coordinates function getDirectionXZ(x1, z1, x2, z2) {return getDirection([x1, z1], [x2, z2])};

Of cause I mixed it up... And forgot the area of definition that is only PI not 2*PI... A function working and consistent to the unit placement orientation for getting the angle of a vector from one point towards another is for example (perhaps not the best): // Function to get the direction from one point to another function getDirection(point1, point2) { var vector = [point2[0] - point1[0], point2[1] - point1[1]]; var output = Math.acos(vector[0]/getDistance(point1, point2)); if (vector[1] > 0) {output = PI + (PI - Math.acos(vector[0]/getDistance(point1, point2)))}; return (output + PI/2) % (2*PI); }; The other functions are correct...

I HOPE with the exchanged sin/cos everything's in order

I missed some functions to determine the distance between two points and the angle the vector between them has. So I added some functions to my script: // Function to get the distance between 2 points function getDistance(point1, point2) {return Math.pow(Math.pow(point1[0] - point2[0], 2) + Math.pow(point1[1] - point2[1], 2), 1/2)}; // Function to get the distance between 2 points given in seperate coordinates function getDistanceXZ(x1, z1, x2, z2) {return getDistance([x1, z1], [x2, z2])}; // Function to get the direction from one point to another function getDirection(point1, point2) {return Math.asin((point2[1] - point1[1])/getDistance(point1, point2))}; function getDirectionAlternative(point1, point2) {return Math.acos((point2[0] - point1[0])/getDistance(point1, point2))}; // Function to get the direction from one point to another given in seperate coordinates function getDirectionXZ(x1, z1, x2, z2) {return getDirection([x1, z1], [x2, z2])};

To adjust the "build in" unit orientation of all (I guess) entity placement functions to the "usually" used determination of the unit position in polar coordinates (by distance and angle to the position of the civil center with cos/sin for x/y) it is adjusted by inverting the angle: var uAngle = -BUILDING_ANGlE + PI * (j - 1) / 2; Note the "-" in front of "BUILDING_ANGlE". ...and then adding (or subtract dependent of the braces used) PI/2: var ux = fx + uDist * cos(uAngle) + numberofentities * uSpace * cos(uAngle + PI/2) - (0.75 * uSpace * floor(count / 2) * cos(uAngle + PI/2)); var uz = fz + uDist * sin(uAngle) + numberofentities * uSpace * sin(uAngle + PI/2) - (0.75 * uSpace * floor(count / 2) * sin(uAngle + PI/2)); Note the "uAngle + PI/2" in cos/sin. But it can be done by switching cos and sin like it's done in my second function. I don't know yet if this is mathematical correct implemented when the 2nd planar axis is indeed z and not y. But at least it's hard to get used to for me (and as it seams to others too ^^) Hope i managed to explain my point.

Hehe, U made the same "mistake" like me. Swap sin and cos ^^

But you insist of define coordinated one by one. Do you think that is wise? Or tell me a reason? Well, sry, your decision...

I think something like that should be added to one of the rmgen .js files to make it easier for random map designers. They still can make there own arrangements of starting units if they like. Perhaps some value checks of function parameters should be added... Perhaps the starting units should be placed right (female peasants), left (male peasants) and in front (Scout) to need less space (smaller maximum distance to start location). Greetings U gorgeous bunch of individuals! Oh, did'nt see this, thx!