FeXoR
-
Posts
1.426 -
Joined
-
Last visited
-
Days Won
28
Posts posted by FeXoR
-
-
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 would mix it up with patches of Oaks, Carobs, and European Beech trees, even some pines.I'm on it
Also, there is a problem with the water plane being too high. Lower the water plane so it doesn't stick above ground.Yes, I noticed, can't build there...
How do I do it?
There is a "trick" that can increase the performance. Add some cliffs in the forest heavy areas(...)Yep, sounds good to me.
(...)and fill the borders with trees.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.
Increase the distance between trees(...)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)
(...)and don't add them to the top of the hills. Players won't be able to see the top of the cliffs and thus do not notice that there isn't any forest.Yep.
I can't do much today, but tomorrow I will go for it!
-
I don't know of any function for that, but we could add them to rmgen: getTerrainTexture(x, z) getTerrainObjects(x, z). In the meantime, you can access the data directly with g_Map.texture[x][z] and g_Map.terrainObjects[x][z]
I don't mind if it's a function or not, THX a lot, U made my day (and the next!) ^^
These are functions I am working on these days. But unfortunately, they are not reaching alpha 9's deadline. Probably in SVN after alpha 9
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!
-
You should definitely remove the second var, it will confuse people who are used to block level scoping.
I removed the "var" in my script, just didn't want to spam posts.
Also in terms of formatting you should either use the style:
if (foo)
{
bar;
}or
if (foo)
bar;(Obviously you cannot use the second if you have multiple statements.)
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.
The function is pretty confusing to read, using arccos() is unconventional. I would recommend using Math.atan2(), it will return the correct angle in the range -pi to pi.
I would also suggest renaming the function to getAngle(), this is less ambiguous.
Nice functions. But the thing we usually use for direction is tangent itself not the angle. So it is better not to use arcs in a separate function to save performance.
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.
-
-
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.
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
-
-
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!
-
Got some strange formation issues in the post writer tool... well...
Here's a more reasonable version.
Swapped sin and cos so unit orientation and mathematical point calculation matches.
Still I think that's a little strange...
Many variables are set in the loop now with var over and over again... is this OK?
But it's much shorter now:
// Funtion to place civil centre and starting units at given location for a given player
function placeStartUnits(startLocation, playerId)
// "startLocation" should be a list of length 2 with floats determining the 2d-point where the starting entities shall be placed.
// "startLocation[0]" should be an float determining the x coordinate of the start location.
// "startLocation[1]" should be an float determining the z coordinate of the start location. (Should by y in my book though)
// "playerId" should be the player number like seen in Atlas or the game settings ingame (Starting with 1 for the first player with default colour blue, 0 is Gaia)
{
// Some checks. Enhance if needed...
// Setting some variables
// Setting default building angle, can be got from the global "BUILDING_ANGlE" in further versions
var buildingOrientation = 3*Math.PI/4;
// Getting civilisation dependent default starting entities
var civEntities = g_CivData[g_MapSettings.PlayerData[i].Civ].StartEntities;
// Place civil centre on the start location
placeObject(startLocation[0], startLocation[1], civEntities[0].Template, playerId, buildingOrientation);
// Place starting units
// Minimal distance to start location so that units don't stand in the civil centere
var minDistToCC = 4;
// Minimal distance between units so they don't overlap
var minDist = 1;
// Set angle width units should be spread over
var angleSpread = PI/4;
// Outer loop for the diffrent unit types to place beside the civil centre (so starting with 1)
for (var unitTypeIndex = 1; unitTypeIndex < civEntities.length; ++unitTypeIndex)
{
// Reset default number of units of that type
var unitCount = (civEntities[unitTypeIndex].Count !== undefined ? civEntities[unitTypeIndex].Count : 1);
// Reset the angle added per unit of that type depending on the number of them, for multiple units of that type only (otherwise 0 devision)
if (unitCount > 1) {var angleAdd = angleSpread/(unitCount-1)};
// Inner loop for multiple units of the same type
for (var unitIndex = 0; unitIndex < unitCount; unitIndex++)
{
// Resetting the angle the unit will be placed in comperison to the city centre
if (unitCount > 1) {var angleActual = buildingOrientation - angleSpread/2 + unitIndex*angleAdd}
else {var angleActual = buildingOrientation};
// Place the unit
placeObject(
startLocation[0] + (minDistToCC + minDist*unitTypeIndex)*sin(angleActual),
startLocation[1] + (minDistToCC + minDist*unitTypeIndex)*cos(angleActual),
civEntities[unitTypeIndex].Template, playerId, angleActual);
};
};
}; -
Sooo...
Here's a function to place civil center and starting units just by giving the location and the player index of the player the units should be placed for.
This is the (very) detailed version for (hopefully) good readability, a shorter version will be added:
// Funtion to place civil centre and starting units at given location for a given player
function placeStartUnits0adAlike(startLocation, playerId)
// "startLocation" should be a list of length 2 with floats determining the 2d-point where the starting entities shall be placed.
// "startLocation[0]" should be an float determining the x coordinate of the start location.
// "startLocation[1]" should be an float determining the z coordinate of the start location. (Should by y in my book though)
// "playerId" should be the player number like seen in Atlas or the game settings ingame (Starting with 1 for the first player with default colour blue, 0 is Gaia)
{
// Some checks. Enhance if needed...
// Setting some variables
// Setting default building angle
var buildingAngle = 3*Math.PI/4;
// Getting civilisation string
var civ = g_MapSettings.PlayerData[i].Civ;
// Getting civilisation dependent default starting entities
var civEntities = g_CivData[civ].StartEntities;
// Setting start tile. Not needed but done in the other RMGs so....
var startTile = new Array(2)
startTile[0]= round(startLocation[0])
startTile[1]= round(startLocation[1])
// Place civil centre on the start tile
placeObject(startTile[0], startTile[1], civEntities[0].Template, playerId, buildingAngle);
// Place starting units
// Minimal distance to start location so that units don't stand in the civil centere
var minDistToCC = 4;
// Minimal distance between units so they don't overlap
var minDist = 1;
// Set general orientation of units
var angleMain = -(buildingAngle - PI/2); // This is a bug in my book, it should be the same as building orientation...
// Set angle width units should be spread over
var angleSpread = PI/4;
// Preset angle the first unit should be placed, reset in the outer loop
var angleStart = angleMain - angleSpread/2;
// Preset angle distance between one unit and the next of the same type, reset in the outer loop
var angleAdd = 0;
// Preset the angle a unit will be placed in comperison to the civil centre, reset inside the inner loop
var angleActual = angleStart;
// Preset number of units to place by default of the same type, reset in outer loop
var numberOfUnitsOfSameType = 1;
// Preset unit template, reset in the outer loop
var unitTemplate = '';
// Preset postition the unit will be placed, reset inside the inner loop
var unitPosition = new Array(2);
unitPosition[0] = startTile[0];
unitPosition[1] = startTile[1];
// Preset orientation of placed unit, reset in the inner loop
var unitOrientation = 0;
// Outer loop for the diffrent unit types to place beside the civil centre (so starting with 1)
for (var unitTypeIndex = 1; unitTypeIndex < civEntities.length; ++unitTypeIndex)
{
// Reset default number of units of that type
numberOfUnitsOfSameType = (civEntities[unitTypeIndex].Count !== undefined ? civEntities[unitTypeIndex].Count : 1);
// Reset the angle added per unit of that type depending on the number of them, for multiple units of that type only (otherwise 0 devision)
if (numberOfUnitsOfSameType > 1) {angleAdd = angleSpread/(numberOfUnitsOfSameType-1)};
// Reset unit tamplate
unitTemplate = civEntities[unitTypeIndex].Template;
// Inner loop for multiple units of the same type
for (var unitIndex = 0; unitIndex < numberOfUnitsOfSameType; unitIndex++)
{
// Resetting the angle the unit
if (numberOfUnitsOfSameType > 1) {angleActual = angleStart + unitIndex*angleAdd}
else {angleActual = angleMain};
// Reset the angle the unit will be placed in comperison to the civil centre
unitPosition[0] = startTile[0] + (minDistToCC + minDist*unitTypeIndex)*cos(angleActual);
unitPosition[1] = startTile[1] + (minDistToCC + minDist*unitTypeIndex)*sin(angleActual);
// Reset orientation of placed unit
unitOrientation = -(angleActual - PI/2); // Here is the bug again...
// Place the unit
placeObject(unitPosition[0], unitPosition[1], unitTemplate, playerId, unitOrientation);
};
};
};
BTW, this does'nt seam to be a good place to put this, suggestions very welcome.P.S.: Did I mention this game is pure @#$%ing awesomeness?P.P.S.: Oh, I hope I did'nt break any forum rules now ;0|
-
BTW! The mathematical orientation (defined by cos/sin in x/y direction) and the unit/building orientation differs.
I think unit orientation is:
-(mathematical orientation - PI/2)
How did that happen?
And why is the second vertical orientation named "z" instead of "y"?
I thought "z" would be the hight over ground or to a base hight but in 0ad it's "y"?
Sorry, questions and more questions x)
-
Oh, and for those preferring .zip:
EDIT: My dear, wrong version, now it should work... [hope]
Renewable Resources
in General Discussion
Posted · Edited by FeXoR
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