Jump to content

FeXoR

WFG Programming Team
  • Content Count

    1,346
  • Joined

  • Last visited

  • Days Won

    26

FeXoR last won the day on April 29 2017

FeXoR had the most liked content!

Community Reputation

420 Excellent

About FeXoR

  • Rank
    Random Comment Generator
  • Birthday 03/03/1978

Previous Fields

  • First Name
    Florian
  • Last Name
    Finke

Profile Information

  • Location
    Germany - Cologne
  • Interests
    Physics:
    - 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')

    Philosophy:
    - Ontology

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

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

    Coding:
    - neuron/brain simulation and artificial intelligence in general

    Gaming: RTS games mainly and mapping/modding them

Recent Profile Visitors

2,043 profile views
  1. Yea, sad story. While I agree it's mostly a people problem (mainly the attitude of those players not welcoming players they don't know/that have low rating but also for those rejected to be persistent) so less a problem of the game. But what we can do is not granting PPL the tools to deny other players participation and on the other hand granting players the option to host games that are actually played. One way would be to remove the kick option but add an option to only allow players that at most left 5% (about 1/(2*max players)) of the multiplayer games they entered (so basically a whitelist. More options like autobalance and minimum games played/rating could be added with a sufficient playerbase - but I don't think we should overdo it).
  2. FeXoR

    Grumpy Gurken's recenst ramblings

    That doesn't make much sense to me since the information is somewhat important to decide whether or not to unlock it
  3. FeXoR

    Yet another random map generator

    I mean large areas on the "rather flat heightmap" some seeds. In some cases they are to rough or steep to build upon (Thanks for the reminder - though I got (or more guessed x)) this one right). So, yes, I'm aware the water and the ramps are on the "same" "rather flat heightmap". That's why I proposed non-lineare scaling. Linear scaling only the parts below sealevel would make the water deeper, too ofc, yes. But that wouldn't change the ramps. And I'm not talking about oceanic depth but about 50% of water covered area to be more then hip deep (unwalkably deep) Yea, I didn't get this one (therefore my edit, not saying that I'm enlightened now ). But now I'm not sure if I explained well what I had in mind, trying again: Add the tiles of the path as is now with one type tag/key, say "road", to the abstract map (to be later covered with the path texture) Add the tiles surrounding the "road" tiles in a range of 1 or 2 with say "road_clearance" (avoiding tiles marked with "road", to be later covered with the surrounding region's texture but no entities) Optional: Add the tiles adjacent to "road_clearance", but not in "road", "road_clearance", with say "road_trees" (also avoiding start and end point by 3-4 tiles (depending if you chose 1 or 2 for the clearance), where later the alley trees could be placed) I guess that's more clear (and ofc. the path painted with textures or the clearance could be made broader as seen fit). And you could use those areas to place the chicken on (but a default placement method would be preferable). But if you have other plans already, go for it!
  4. FeXoR

    Yet another random map generator

    Oookkkk... (still not through the code...it's quite a read ) Roads: AFAICT you first paint textures, then you paint roads taking the textures painted into account. This means you are overpainting existing textures. What about defining areas instead of textures you can than take into account for the paths to be placed, then you place paths (again as abstract regions, maybe an inner one for the part textured and a second, larger one for not placing terrain entities - and not containing the tiles of the inner path [if you want to you could also add a 3rd - again not containing any of the inner areas - that can contain entities and maybe avoiding start and end point by slightly more than it's own width to generate something like @elexis had in mind]) and then you paint the textures (with all the other map generation stuff in between ofc.). That way your approach will still work (weighted path search) but you don't have to overpaint textures and you can avoid entities close to the path and @elexis can have alleys (if you avoid forests or other entity rich areas because this is likely what is wanted). And I'd say try 5 tiles unobstructed path width (or 3 tiles from centre). Domestic animals at start locations: You can just place them after line 194 like "berry bushes" or "starting trees". Did I miss something? (And what issues does which newer placement method cause?) Large areas covered in water and ramps that can't be build on: Making the water deeper and the ramps flatter would do IMO. I don't get the entire main landscape procedure yet but maybe non-linear scaling (e.g. with square root) of the heightmap ("before" mountains are added - yea, it's in one go but in different sections) could change this without having to change much else? (on the other hand there should be an exponent scale factor for higher and lower terrain anyway IIRC) I can live with it as is but really think at least deeper water would be nice - and more realistic BTW (If the water level is set before the main landscape procedure one could also change those areas separately ) Roads avoiding water: Yea, no big deal. Still strange looking to me and AFAICT easy to avoid in placers.js line 513. Textures: Not looked into, yet. To tired ^^ Well, I hope you can make something out of this rather chaotic set of suggestions. Keep it burning @Pyrophorus EDIT: After a closer look you do most of the suggested stuff in "roads" already. Additional Area types (e.g. road_clearance and road_border) and changing the texture placement might be enough.
  5. FeXoR

    Yet another random map generator

    About An Egyptian Oasis: The two main things I noticed that don't work well yet: Paths are quite narrow so large armies have trouble to use them if they go through forests. While the texture width is OK there should be no obstructions that close to the path. It actually seems like they are not continuous and broken apart by tiles with trees. Starting locations don't have domestic animals like chicken or pigs. This can put some players at a rather heavy disadvantage for some might wind up having camels nearby but others don't. And cavalry can gather meat quite fast. Other more minor issues: Some maps have rather large areas covered by water and "ramps" that can be walked on but not build on. This makes it quite hard to use defences. Maybe the ramps can made a little less steep and the water a little more deep (so units can't walk through most parts of the water). The actors on mountains are those of actual mines. That might confuse quite some players that will mistake them for spots to gather from. Replacing them with non-mine actors would solve this The texture around start locations abruptly stops when reaching the playable map area's border. Instead I'd place the texture but no entities (or the actor corresponding to the entity) in the entire area if not outside the map (the square map where textures can be placed but I mean here). Roads often leading to/through lakes. This is not really an issue because units can walk through most parts of the lakes anyway but it looks like this is not planned The wet sand texture extends quite far into areas not covered with water. That looks strange to me. While I like your choice of textures very much in the barren flat regions the light grass texture doesn't fit very well IMO.  I haven't read through the entire code so it's absolutely possible some of my comments don't make a lot of sense Expecting requests for more concrete suggestions ^^
  6. FeXoR

    Missile Dodging / Dancing

    There is no concept of momentum in 0 A:D.. And IMO there shouldn't be. Instead arrows should be acting like missiles IMO so not the way things act (momentum for units, pure parabolic arrow path's) but the outcome is what's about realistic (units are hit with a specific probability, maybe dependent on distance - though "always hit" wouldn't be as bad as "can always be dodged" IMO). And, yes @Sundiata , part of the problem is the simplistic unitAI's targeting but the above approach would "solve" this (yea, also not very realistic but it's the outcome what matters most IMO and it's doable even if the arrow path's might not perfectly correspond to the hit unit's position). Also I agree with @wowgetoffyourcellphone (just there have been several attempts to implement this and none of them where really pleasing IMO).
  7. FeXoR

    Siege unit

    Off topic: @thankforpie I want to remind you this is the "Gameplay Development & Technical Discussion" part of the forum. The tone this thread went is not my taste but this is not at all what I understand as a "discussion" and won't drive development. So I ask you to keep this kind of comments out of here
  8. FeXoR

    Cheat walls

    We could add a minimum angle restriction between the newly placed walls and those already connected to the same tower. What about limiting access to stone when the game advances (Yea, but slingers/catapults/... ;/)? Though a minimum angle definitely makes sense to me, too. A more personal request of mine would be to use the words "bug" and "cheat" more specifically - for they have a meaning and are useful in communicating game development. So please mind your words - and if only for my mental stability ;p
  9. FeXoR

    Ranged Units

    (Just thought about "hyper realism" - which doesn't make much sense to me as a word in the first place as long as we are not living in a matrix - and are not really opposed just: Wouldn't players be a bit ... put off when they have to e.g. film themselves to convince their units to join their cause and in 90% of the cases as a result they would just be ignored or even lynched? Not to speak of the declining player numbers ;p) Less accuracy, moral/fatigue or "no focussed fire" fits well to combat in battalions. But as is (without battalions) the result of making ranged units less strong in this many aspects would likely result in no ranged infantry being build at all (except siege). For ranged cavalry it's the combination of range and speed that makes them so versatile (Would making them more expensive help?). Friendly fire is also hard to manage for the player resulting in just another kind of micromanagement. Not sure. (Focussed fire could be avoided by instead of dealing damage units have a chance of killing en enemy they hit (so basically no health but death resistance lowering the chance to be killed) but the outcome of early skirmishes would be basically random)
  10. FeXoR

    Game rewards turtling too much

    Iberians get towers in the random map Snowflake Searocks, not walls. (I'd agree with making it an option if I'd agree to the options system in multiplayer)
  11. I agree resource entities should be reachable (at least somehow like after chopping all the way to that tree in a dense forest).
  12. FeXoR

    Game rewards turtling too much

    As @(-_-) said shared code (thanks to @elexis) for most maps. Only few use their own starting resource distributions.
  13. IMO this is a path finding and unit AI problem. That doesn't mean we shouldn't change the maps but that will not fix the underlying problem.
  14. FeXoR

    Game rewards turtling too much

    I agree with that. While there should be some resources available close to the base the large stone and metal mines provide to much IMO. (There is no consensus in the team about that though AFAIK though there could be found a compromise I guess - either reducing the amount of resources the (initial) mines grant or to place them further away from the Cilic Centre - though this will not be easy to do for e.g. all random maps for that will cause interference with Iberian's walls or in-game build walls)
  15. FeXoR

    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).
×