Light Style© by Fisana

Jump to content


Photo

Some strange working rmgen lib functions


  • Please log in to reply
8 replies to this topic

#1 FeXoR

FeXoR

    Centurio

  • Community Members
  • PipPipPipPipPip
  • 925 posts

Posted 21 March 2012 - 10:56 AM

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.

Edited by FeXoR, 21 March 2012 - 10:59 AM.

  • 0

#2 Spahbod

Spahbod

    Triplicarius

  • WFG Programming Team
  • 588 posts

Posted 21 March 2012 - 11:05 AM

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.


Well, according to this, none of the current maps should work.:P
  • 0
Omid Davoodi [ aka Spahbod ]

Wildfire Games Random Map Designer, Low-level Programmer
Contact me: myops37@yahoo.com


Support Wildfire Games!

#3 FeXoR

FeXoR

    Centurio

  • Community Members
  • PipPipPipPipPip
  • 925 posts

Posted 21 March 2012 - 12:56 PM

Well, according to this, none of the current maps should work.:P


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.

Edited by FeXoR, 21 March 2012 - 12:57 PM.

  • 0

#4 Spahbod

Spahbod

    Triplicarius

  • WFG Programming Team
  • 588 posts

Posted 22 March 2012 - 05:18 AM

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???


First of all, how are you defining x and z?
And second: coherence and smoothness should be floats to ints. use 1.0 instead of 1. I had the same problem before.
pathWidth is not technically correct. Size parameter defines the area of placer not it's width.
But your overall code should work. What do you want to do exactly?

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.


I should see your complete code this time. Could you show it to me in PM?
  • 0
Omid Davoodi [ aka Spahbod ]

Wildfire Games Random Map Designer, Low-level Programmer
Contact me: myops37@yahoo.com


Support Wildfire Games!

#5 FeXoR

FeXoR

    Centurio

  • Community Members
  • PipPipPipPipPip
  • 925 posts

Posted 22 March 2012 - 11:10 AM

First of all, how are you defining x and z?

Half the code needed for that so see the full code further below.

And second: coherence and smoothness should be floats to ints. use 1.0 instead of 1. I had the same problem before.

I'll do that but it works for now...

pathWidth is not technically correct. Size parameter defines the area of placer not it's width.

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

But your overall code should work.

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)

What do you want to do exactly?

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.

I should see your complete code this time. Could you show it to me in PM?

Here it is though not in a PM, someone might find it useful (like your suggestion to use float, not int):
Spoiler
And a download: Attached File  fexor_simple2012-3-22.zip   3.12KB   20 downloads
By 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... 


Edited by FeXoR, 22 March 2012 - 12:18 PM.

  • 0

#6 Spahbod

Spahbod

    Triplicarius

  • WFG Programming Team
  • 588 posts

Posted 22 March 2012 - 01:08 PM

Really strange. But answer this first: Did you add the hill tiles into clHill? You don't do this right now and this can be the reason avoidClasses didn't work.

I think all of these are caused by your hardcoded map generation. That's why I think you should create your own random map generation library based on some "areas" that have a chance of having trees/special terrain/ etc.

I personally use paintClass() instead of TileClassPainter(). It seems it is buggy. Use paintClass() instead and you may find out that avoidClasses works for the first part.
  • 0
Omid Davoodi [ aka Spahbod ]

Wildfire Games Random Map Designer, Low-level Programmer
Contact me: myops37@yahoo.com


Support Wildfire Games!

#7 FeXoR

FeXoR

    Centurio

  • Community Members
  • PipPipPipPipPip
  • 925 posts

Posted 22 March 2012 - 08:14 PM

Really strange. But answer this first: Did you add the hill tiles into clHill? You don't do this right now and this can be the reason avoidClasses didn't work.

I think all of these are caused by your hardcoded map generation. That's why I think you should create your own random map generation library based on some "areas" that have a chance of having trees/special terrain/ etc.

I personally use paintClass() instead of TileClassPainter(). It seems it is buggy. Use paintClass() instead and you may find out that avoidClasses works for the first part.


@ 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.

Edited by FeXoR, 23 March 2012 - 08:12 AM.

  • 0

#8 Spahbod

Spahbod

    Triplicarius

  • WFG Programming Team
  • 588 posts

Posted 23 March 2012 - 05:30 AM

@ 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 tough. 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.


1: I mean your hill and forest codes are complex enough to cause strange bugs like these. I use a combination of both rmgen functions and my own codes but I try to write my codes in a way to generate content very similar to rmgen functions in structure so that it doesn't cause such errors. One of the best examples of such a thing is Snowflake Searocks.
But there are two solutions for a problem like the one you have. Completely use rmgen functions (which doesn't have the flexibility and beauty of the current system) or completely use your own hardcoded ones (like what is done in the current Latium map but is very hard and time consuming).

2: The whole code is like that. I tried working on some tickets and found such refactoring very common. In fact it is much worse in the code because it uses functions to send values into main engine (C++ one) and vice verse. For a simple patch like "set trading goods for all selected traders" I had to scan 5 different files until I found two appreciate ones.
  • 0
Omid Davoodi [ aka Spahbod ]

Wildfire Games Random Map Designer, Low-level Programmer
Contact me: myops37@yahoo.com


Support Wildfire Games!

#9 FeXoR

FeXoR

    Centurio

  • Community Members
  • PipPipPipPipPip
  • 925 posts

Posted 23 March 2012 - 08:27 AM

1: I mean your hill and forest codes are complex enough to cause strange bugs like these. I use a combination of both rmgen functions and my own codes but I try to write my codes in a way to generate content very similar to rmgen functions in structure so that it doesn't cause such errors. One of the best examples of such a thing is Snowflake Searocks.
But there are two solutions for a problem like the one you have. Completely use rmgen functions (which doesn't have the flexibility and beauty of the current system) or completely use your own hardcoded ones (like what is done in the current Latium map but is very hard and time consuming).

2: The whole code is like that. I tried working on some tickets and found such refactoring very common. In fact it is much worse in the code because it uses functions to send values into main engine (C++ one) and vice verse. For a simple patch like "set trading goods for all selected traders" I had to scan 5 different files until I found two appreciate ones.

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.



Edited by FeXoR, 23 March 2012 - 08:58 AM.

  • 0