Jump to content


WFG Programming Team
  • Content count

  • Joined

  • Last visited

  • Days Won


FeXoR last won the day on April 29 2017

FeXoR had the most liked content!

Community Reputation

386 Excellent

About FeXoR

  • Rank
    Primus Pilus
  • Birthday 03/03/1978

Previous Fields

  • First Name
  • Last Name

Profile Information

  • Gender
  • Location
    Germany - Cologne
  • Interests
    - If 'our' interpretation (not the formula) of the general theory of relativity turns out correct
    - How 'we' manage to get rid of time as a so far widely needed variable (IMO needed for a deeper understanding of the structure of... well, 'it all')

    - Ontology

    - The different infinities IMO caused by a poor definition of 'countably infinite' and the hair-raising 'proof' of the existence of cardinal numbers.

    - Putting human rights to reality
    - Ensuring enduring finances
    - Ensure system stability

    - neuron/brain simulation and artificial intelligence in general

    Gaming: RTS games mainly and mapping/modding them

Recent Profile Visitors

1,617 profile views
  1. Yet another random map generator

    Oh, nice to see so much going on here Try to catch up This is not really true for the random map part if you avoid using placers/painters/constraints. And some part of code has to be first being fast enough that other parts are recognized to be slow and made faster x) It's likely just a few parts causing most of the cost - as usual - so identifying those would help. This is where we propose code contributions to get reviewed and eventually committed. See https://trac.wildfiregames.com/wiki/ReviewingPatches I agree that trying to add a map with this features (though gorgeous) for the coming Alpha would be a bit hasty. But I would love to see one entering the review queue at some time! ATM I can't see a huge advantage of this besides partial upgrading (which also might need border tiles) ... but it's absolutely possible I'm blind (I'll read it again after I hit the pillow) ;p Also this would AFAICS restrict this object only to properties in from the beginning (e.g. normals, waterHeight, waterVelocity are not used in most maps but might be wanted in others ... which then can't add them). If I am wrong here please teach me differently! Is inheriting from an instance possible (assuming the instance is generated in the libs which don't know the needs of a map)? Also what about the performance of derived properties like grad/rot/div of the original properties? Any benefit here (besides partial updates)? So, sorry I can't give you an opinion right away Good! But I can tell you I consider many parts of it better than mine! I consider both of you painters valuable! The map looks promising already. Yes, texture variation could be higher for my taste. Breaking patterns of the textures is possible by applying more than one chosen randomly in the same area. But those have to really match well to not look to patchy/edgy/separated (don't know better words).
  2. Yet another random map generator

    IMO Base terrain generation should go to /heightmap (maybe separate in different files but it's not that big yet). Painters, placers and constraints should go to /rmgen . Functions they depend on should also go to the same file. The g_Map object should IMO only contain stuff that is needed to be exported. Anything else should go into another object (e.g. map_extensions or something). This includes the slope/incline map (vector/scalar) as well as the planned collision map and abstract water height/speed maps (to simulate water driven erosion). Recomputing those maps over and over again is indeed insanely inefficient. I have the same problem with the collision map (updating whenever an entity is placed is fast but means to hook in the collision system in even if it's not needed - though no performance impact than with a collision.enabled flag. Updating whenever needed means "number of uses" more calculations of the entire map). I think the way to go is "update manually when needed" for those heightmap related maps - though this is prone to induce bugs by oversight. Updating whenever used and update needed might be appropriate in some cases - a copy of the underlying object could be stored and - on change - update the derived thing if used (this is somehow against the "direct access" policy I usually prefer though).
  3. Yet another random map generator

    I just noticed that we actually don't have a way to smooth a specific area of terrain yet (there is rectangularSmoothToHeight but this is not exactly the same and the smoothing effect es stronger near the center than the edges). So a painter for that is definitely welcome! I also find getting and painting areas by slope very useful and think maps could become much more natural looking with much less work when utilized. Nicely done! (The terrain still shows artifacts in the direction of the coordinate axis and in a 45° angle to them. It would be nice if those could be removed but otherwise we then have multiple smooth tools now )
  4. @Lion.Kanzen In metadata.json search for "mapSetting" and you should find Seed there alongside the other settings. To recreate the map setup Atlas to those settings - usually random map, map size (see below), and number of players should be enough - as listed in metadata.json and generate. You can save the map (as a scenario) then to replay it. Map sizes strings correspond to the following map widths in tiles. Tiny: 128 Small: 192 Medium: 256 Normal: 320 Large: 384 Very Large: 448 Giant: 512 The first line in commands.txt also contain the map settings.
  5. @Servo "Caledonia meadows needs more animals" Do you mean more huntables or domestic or fish or different types of animals? I actually thought there where to many huntable animals and berry bushes. I reduced the ammount of fish due to reviewers requests BTW. I agree we should have at least some maps that support teams being much closer to each other and allowing uneven teams. This shouldn't be the default though. If you have the replay of the map you liked you can regenerate the map in Atlas by using the same random map seed.
  6. Yet another random map generator

    I assume the straight lines have the same cause than the sharp cliffs: The random offset not declining right from the beginning. Erosion/smoothing and/or recalculating mountains/steep areas (and maybe flat areas too) should hide them. Erosion/smoothing will wash away some details too though. Wind driven erosion would also create structures similar to this so I don't think they are to bad
  7. Yet another random map generator

    No need to be ashamed in any way ;p I love how you drive this approach further! And you made me think about how we can use code from water driven erosion to add details to realistic terrain maps without the water plane (I was told the engine doesn't really support that though somehow implemented with different water levels in mind) just with terrain texture. Though not as cool as rumbling rivers it would still add some more detail if painted with bog texture like an overgrown river or at least occasionally wet, muddy ground.
  8. Yet another random map generator

    I love the sharp cliffs but I can't find in the code where they come from and why they don't show up in setBaseTerrainDiamondSquare generated heightmaps While over all your approach looks similar to Caledonian Meadows I'd love you to try and find your own way of creating a playable map from this beautiful and realistic terrain EDIT: Reading through the code a bit more the cliffs seam to come from "tProgress" specifying that finer details keep a high offset until the threshold? (I'd make this one an argument BTW). And you recalculate the mountains to be rougher in the tour, very nice! You also use e.g. some height limits from Caledonian Meadows so I guess you have roughly read through it already
  9. error at start

    It's absolutely OK to report an error and be confused about that something didn't go as expected ... but please don't curse
  10. Yet another random map generator

    I'd go for this. In heightmap rectangularSmoothToHeight() would do the trick. I at least can't tell the shape of the smoothing (rectangle) with the default window function (Paraboloid). The transition is quite smooth and leaves the general terrain shape intact. With a strength of 0.5 to 0.8 it should still create a suitable base.
  11. Yet another random map generator

    Hi @Pyrophorus I haven't looked into the code or generated some maps but I wanted to at least give you the feedback: This is awesome! Please continue I especially like the "some areas harsh, others more even" part! @realistic and fair: It is possible by choosing a symmetry matching the number of players and use realistic design for the part left. The symmetry will leave a notable global pattern but locally the map will be mostly realistic. In hope I'll find the time to take a closer look next week...
  12. I don't have anything against spreading the word on other platforms But that doesn't include embedding those on our website.
  13. Also there's a guide in the forum by @Palaxin (In case you haven't seen it's linked in the wiki guide): EDIT: For random maps there are also functions to manipulate heightmaps like erosion of by decay, sun and wind (e.g. rectangularSmoothHeightmap) and simple water driven erosion (splashErodeMap). It is absolutely possible to also make them brushes in Atlas but currently they are not shared. Backward erosion for reconstruction of historic topography is not possible just with the surface data though (entropy increased, information diffused).
  14. I also don't like the idea of open source software project making themselves dependent on third party applications needlessly.
  15. The differential equations only hold true for each side A and B only having one type of unit each, though not necessarily the same. Still something I'll take a closer look at, thx! I don't know if there's an equation for the "combat strength" of just one units depending on (simple) properties like health, attack speed/time and damage assuming all unit are able to engage in combat. I think it would be something like KombatStrength = (health * damage / attackTime)^0.5. Multiple units don't add up though but combined unit strength grows exponentially (I guess, though this is much more easy to test) so another equation is needed for army strength. This all doesn't include the dimension of the battlefield (2D usually ;p), ranges attacks and move speed that would also matter in a real-time strategy game. EDIT: Since the article was quite short I read it right away. They use the same assumption for the unit strength as I did. I would have hoped for an equation of total army strength for mixed troops but that is not included. So there's a third equation needed for combined troops but neither I nor the article can say something about that ;/