Jump to content

Pyrophorus

Community Members
  • Content Count

    76
  • Joined

  • Last visited

  • Days Won

    1

Pyrophorus last won the day on September 9 2017

Pyrophorus had the most liked content!

Community Reputation

119 Excellent

About Pyrophorus

  • Rank
    Discens

Recent Profile Visitors

549 profile views
  1. Not Bella Gallica but Belli Gallici (plural neutral nominative of second declension). I doubt you'll find one because very little is known about gallic speach(es) of this time. Some words survived in later languages but there is no written testimony. It was certainly a member of the celtic family but it would be inaccurate to pick something in those. For instance, old britton used in Armorique around 600/700 is not a mere survival of gallic. It received influences from British Isles. More of it, gallic (or gaulish) existed not as a rather standardized language like latin, there was certainly a wide number of local variations even if people understood them rather well. That's probably why latin spread so quickly in Gaul after the conquest: it offered a common speach, like English nowadays. Friendly,
  2. Pyrophorus

    Yet another random map generator

    Hi, OK, that's what I suspected. Of course, as long as it's still possible to do otherwise, I have nothing against it. I agree. It's a design issue, and for myself, I think rmgen would benefit to have a unique cell object collecting most tile information in it. It would make many things easier and faster, but it's not a ten minutes task. In the mean time, I updated the library to add a warning and a possible workaround. Instead of giving a Cell objects array to Area constructor, gives a Vector2D array holding the same coordinates. There is a zoneToPoints() function to do that (already used in the YPatchPlacer place() method). Instead of: new Area(some_Cell_Array); use: new Area(zoneToPoints(some_Cell_Array)); Friendly,
  3. Pyrophorus

    Yet another random map generator

    Hi, If I understand correctly, createArea is to you the normal if not the only way to create the landscape, which landscape is populated after using the created areas ? Not exactly. It's quite impossible to tune the original fractal painter in order to get only hills or only depressions, but it's probably what scripters want most, and this is what the fractalpainter gave with a standard call 'paint(area)'. The nochiasm optional parameter was here for the rare case a fully random landscape was wanted. Anyway, I removed it and created three painters which offers the same functionalities: one of them creates only hills, another one only depressions, and the third creates both. That's right, and it is one possible workaround. Actually, the YPatchPlacer is safe to use in createArea calls because its place() method returns a Vector2D array created on the fly, and not a Cell array. But the regions returned by its other methods (not rmgen standard) are Cell arrays and may be frozen if used to create an Area. I listed the deepfreeze occurrences in rmgen and found out 12 (just in case I could miss some). Most of them can't create problems because they freeze new objects or clones. There is one at line 50 in library.js which has nothing to do with yamg. The last one is in Area constructor, and it's probably not so easy to remove. I imagine you freeze the points array to avoid the membership cache becoming inconsistent, and cloning the points array you get as parameter wouldn't be very efficient and useless in most cases. There would be no problem if the deepfreeze could happen only on the array itself and the Vector2D members of the Cell object (their coordinates never change and could become read-only), but I doubt Javascript allows this. Friendly,
  4. Pyrophorus

    Yet another random map generator

    Bad news... I found out a major compatibility problem with a-23 rmgen. I thought it was OK to make my cell object inherit from Vector2D. Then one could use them in any rmgen function requiring a Vector2D (or an array) in their parameters. And there's no problem on rmgen side: it works nicely. But there's a side effect which creates errors in further uses of the cell object in yamg: many rmgen functions freeze the objects they get as parameters. If somebody uses a cell array to create an Area for instance, the cell objects become read-only and any yamg function trying to write them (YPatchPlacer, buildRoads) will raise an unexpected error. The fractal painters are not impacted because they don't use the cell object. Of course, it's possible to work around this trap, but I don't like the idea to share such a breakable code. I think I will withdraw it. Sorry...
  5. Pyrophorus

    Yet another random map generator

    Excuse me, but what's irrelevant here is to reply a question I asked to Elexis. I would like to know what he has in mind, and since you're not him, you can't say anything but commenting rmgen code I can read just as well as you.
  6. Pyrophorus

    Yet another random map generator

    And what if I want to do something in between ? For instance selecting a second painter after the result of the first one ? createArea can certainly manage most use cases but not all of them. Friendly,
  7. Pyrophorus

    Yet another random map generator

    Yes, but AFAICS createArea is not the only opportunity to invoke a painter. What if you want to apply successively two painters to the same area (for instance an ElevationPainter and a TerrainPainter) ? You call createArea twice ? Friendly,
  8. Pyrophorus

    Yet another random map generator

    Hi ! The screenshot don't show them very clearly, but there are some mines (behind the roman caer) and animals (not only crocodiles). But the map needs a better painting and some more decorations, that's right. Yes, you're right. mapSize in only defined in my test script "Usually" ? Anyway, I think the best would probably be to have three painters, because for now Fractal and Cracks painters give exactly the same result when nochiasm is set to false. Friendly,
  9. Pyrophorus

    Yet another random map generator

    Hi, I'll try this out of curiosity. Thanks. Now the YAMG for A-23 is on Github. No new features but a full upgrade. The fractal painters expect an Area in their paint() method and mesa and depression painters provide a Vector2D array, instead of point array. The Cell object inherits now from Vector2D and can be used in rmgen where a Vector2D is required. Of course, the placer and the utilities which rely on this Cell array can't be used without creating a g_TOMap Cell objects first. AnEgyptianOasis is still a work in progress. It works nicely and don't lack features, but some details need to be fixed, particularly players starting resources. I have quickly copy/pasted some code somewhere and this code fails at time for some reasons. Have fun !
  10. Pyrophorus

    Yet another random map generator

    Hi, Is it possible to specify larger map sizes than giant for now ? (From the map script, obviously). Friendly,
  11. Pyrophorus

    Yet another random map generator

    Hi, So what ? Except denigrating my work, I can't see the purpose of this. It would be interesting if you could provide some measuring tool for playability and players respective advantages (balance) It would certainly be nice to have this. But I fear you have none, and all this is only an opinion. I don't work with opinions, only facts and algorithms. I would be glad to know how you would simulate water running downhills with a scalar definition of slope. If greater than zero, you'll know it should run, but where ? You need a direction for that, and what's the name of something having a (scalar) modulus and a direction ? A vector, isn't it ? You can split the two in different variables and call them as you want, but this don't change what they really are. I don't like long members names, but if not, I would have used 'very_inaccurate_slope_modulus_approximation' instead of 'slope' in my program. This crude approximation is sufficient for my current needs, but pretending it's slope definition would be language abuse. Sorry, but even if your sentence looks good, it is very confusing. Every variable convey information in a program, and "varying over space" is a very vague formulation. We have functions, gradients and derivatives to describe accurately 2D surfaces and the fact a mesh is not a continuous surface is a difficulty in the modeling problem. We're only making illusions here, and even very convincing, they aren't science in any way and don't allow us to redefine at our fancy scientific notions. Maybe you noticed not, but this is exactly what the fractal algorithm does, even if in professional softwares they obviously have much more elaborated algorithms. The point is noise is used as the map production mechanism, not a way to blur too regular maps previously created with geometric procedures. Yeah, creating a tile class first, applying the constraint to create a new region containing the border and finally merging it into the initial region. First two steps are fairly time consuming as you know, particularly on large regions (I remember someone writing somewhere tile classes and constraints were very inefficient in rmgen. Was it you or not ? I wonder...) . With a YPatchPlacer, you can do that using its 'expand' method, without using expansive data structures and computations (BTW, no rmgen placer has such a method). Keep peeling apples with a corkscrew if you prefer, yes it works and I have nothing against it. The really interesting point is both methods don't give exactly the same result: rmgen will add a border equally large everywhere and the YPatchPlacer don't (and can't easily). Is this regularity desirable or not ? It's map author choice. How can you expect to produce constructive criticisms about something you understand not ? It's impossible to anyone, including geniuses, you know, so it results only in rather sterile bashing. Try to understand or turn to something else, it would be better to everyone. Friendly,
  12. Pyrophorus

    Yet another random map generator

    No. More accurately, it's the only way script currently have to do things like resources or players bases setting. Maybe you're not aware you're immediately formalizing the problem using geometry as if it was the only solution. But we're not designing a geometry solver but building a convincing illusion of a landscape and using geometry is not mandatory. It's only the most obvious way to go. Maybe you missed the fact my work uses very little geometry if any. It's not coincidence. First of all, rmgen already offers a lot of geometry based features, and it would be stupid to duplicate them. Next, euclidian geometry applies on euclidian spaces not on meshes we're working on. To give an practical example, the YPatchPlacer can compute the border of a region. One can of course discuss the accuracy of the result and try to prove it is wrong using a mathematical method to compute an accurate border. But, rounding the result to fit the map mesh will ruin this accuracy, and I bet the final differences between both methods shall be unnoticeable. BTW, the feature exists not in rmgen and there's no easy way to expand a region as well. Same with slope: mathematically speaking, slope is a vector, not a scalar and is not constant on most tiles because, generally, they're not plane. Rmgen computes a slope factor in a way, I do otherwise, but nobody is right, both are wrong. And last but not least, geometric procedures generate regularity and monotony which can be avoided only adding a lot of noise. That's why I explore other ways to create maps and I hope here to enlarge the tools choice, not replacing anything. If someone is more easy with constraints in rmgen fashion, it's OK to me, of course. But don't tell me those constraints are absolutely necessary features. One more time, the proof is in the result: I don't use constraints, only locks and regions. And as you say: Thanks, you're clearly not ready yet to enter my fan club but time helping, who knows ? But I disagree: there is not a single good direction. There are many each one having it's strong points and drawbacks. I think this at least partly explain why I meet some incomprehension among developers here. They try to make me enter the Procust's bed of their geometric model and can't see why I resist. What do you mean here ? It's not "on paper", this script is working and you will be able to verify it as soon as the A-23 upgrade will be out. Now, don't expect me to reproduce exactly existing maps to create a valid benchmark. I should reproduce even their defects which is ridiculous and impossible: can you really admit at last my placer is not a duplicate of any rmgen placer ? It's like a knife and a corkscrew: both can be put at some limited purposes like opening a bottle but you wouldn't try to peal an apple with a corkscrew. And yes a knife can be used to open bottles, but does this means corkscrews are useless ? Of course not, but your user experience is not very valuable to me because many things are known or even so obvious to you that you imagine not their ignorance can be an obstacle to ordinary users (I have the same problem of course and anyone having some degree of technical expertise, as you say). An example is the "random" label we put on these maps scripts. They are fully deterministic and the only "random" thing in it is you can let the computer choose a map within the large set of maps the script can produce (2^16 I think but maybe it's 2^32 or even 2^64). To you, there is probably no mystery here, but it's against common acceptance of the word "random" and it can puzzle people knowing not how a pseudo RNG works. The challenge here is to learn how end users figure in their mind the process of creating a fully featured map, as a cooking recipe, using their words and not ours. Believe me, this is far less obvious than it looks. Friendly,
  13. Pyrophorus

    Yet another random map generator

    Hi, everyone No, the YPatchPlacer doesn't work with constraints even if you can add surrerogatory constraints in the parameters. It makes a region grow around a starting point, selecting on the border the best candidate to expansion. It's not the same as selecting in the whole map or in a region tiles matching a set of constraints. Try to get something like the examples I gave in this very thread and you'll see. The TOMap object is not technically necessary. I could have stored all it's stuff in the g_Map object itself. The reason why I didn't is devs opinion. They think there's a risk ExportMap could fail if g_Map houses some extra stuff. The major design problem is not here but in the Cell object TOMap holds. In my development, there's only one object holding all tile properties and in rmgen there are potentially many. It's exactly the same problem in databases design when one duplicates the same data in different tables, and worse, in Javascript, we have no triggers to keep the data in sync. Now it solves the constraints checking problem as well. You may say I implemented them in an obscure way and I agree but any set of constraints can be tested in two bitwise operations and I doubt you can find faster. A convenient interface can be easily designed to expose them in a more understandable way of course. Now I'm a little uneasy with your last comments because you speak as if you were the project manager in charge of the future of rmgen and able to decide which part of my work should be integrated and which modifications should be made for that, including it in this refactoring project of yours. I have nothing against it, but maybe you could remember you're not the only one making decisions about rmgen. Personally, I have no opinion about this integration because my goal is to offer a large pallet of tools everyone can use or not at will, so they can come in a mod or in mainstream as well. To me, the fact different placers can achieve the same result is not an issue: I will not tell the RectanglePlacer should be dropped because my PatchPlacer can do the same. It's true, but if you want a plain rectangle, the Rectangle Placer is much simpler to use, and why not have both ? Now you suggest my design changes are not necessary, but the proof is in the result. AnEgyptianOasis produces a fully featured giant map with eight players in about five seconds (with roads and all the shebang). AFAIK, many legacy scripts just hang miserably on this map size after some minutes. Maybe you can do the same or even better using the rmgen data model, but for now, it's only a promise, not a result. Don't misunderstand me: I don't intend to be rude, but I don't work for you or other programmers, because I perfectly know you don't need me to create what you want. To you, all my work is obviously unnecessary, but I work for end users who have nothing to do with these specialists discussions, and I'm sure very few of them enjoy to look at a choked idle computer. IMO, the end user should decide what is useful and convenient, and not the specialists we are, and to me it's far more important to get the feedback from map scripters and even from those who would like to script maps and can't because... Because what ? We don't know and here is the point to focus at. If not, we only fall into the well known trap waiting every programmer: create software for programmers and not for end users. That's why I started this thread: mainly to have end users feedbacks telling me how to make my library more accessible and convenient to their uses and unfortunately, I have very few. Yeah, I got a lot of likes and appreciations which is kind and satisfactory, but don't help me much. Friendly,
  14. Pyrophorus

    Yet another random map generator

    Thanks for this interesting reply ! It works on any region (even not connex) but maybe the result will be rather unnatural if the region is very thin and the bump parameter set to high values. I can't tell exactly because I haven't yet look at the new painters interface (I'm busy with retrieving the functions which vanished or have been renamed and figure if they work as before). In A-22, the interface was standard with some extension: I don't like the idea to recreate a new painter each time you need one. Now, this would be really important if all this was to go into rmgen, but I don't think it will happen soon. I have no idea of what could be this 'modify' functionality I will take a look at it. There are some screen shots in the documentation showing what you can expect from it. Rmgen placers blindly select points on the map not taking into account the underlying relief, but this one does. Now it's really easy to implement constraints in the rmgen fashion from my model. I have given examples in an older version of the library. Of course, I agree with you about extending the RandomMap object, and maybe you read the discussion we had earlier in this thread about it. It would remove the need of a separate TOMap object. But dev staff is reluctant to this idea. Yes it does even if this need to be seriously improved. Yes, you're right, but you're thinking in the perspective of a rmgen integration which is still very problematic for now. Friendly,
  15. Pyrophorus

    Yet another random map generator

    Could you elaborate what you have in mind ? I'm interested in improvement suggestions. (BTW, this random script is more a proof of concept than a playable map). Friendly,
×