Pyrophorus

Hi everyone ! Erratic replies to random comments generation I can't remember why I have commented those two lines: placeDefaultChicken(fx, fz, clBaseResource,av); placeDefaultDecoratives(fx, fz, aGrassShort, clBaseResource, radius,av); at the end of this script section. Maybe some chicken finally sit on top of stone mines or ugly things of the like, and I hid them cautiously under the carpet. Now I wouldn't say there are issues in the newer placement method. The problem I have with it is roads running to the CAER. One can place chickens or units on the road, but no tree or mines and the placement method can't deal with this particular problem (AFAICS). There are two points here: the underwater and what you call ramps. As you know (or not, which is why I recall this quickly), the heightmap is created merging a rather flat one (on which players can walk and build) and a much more bumpy one to put on mountains. Lakes and pools are part of the first one and this is why they're shallow, and, in this particular context (Egyptian Oasis) it would be IMO rather unrealistic to create oceanic deeps here. But this can be done rather easily, just replacing the lower cells of the map with something deeper. Now, I'm not sure to understand what you call ramps. Maybe you mean the valleys and depressions running across the mountains. If so, and if you find the relief too harsh here, the map creation parameters allow to tune this. There's probably no need to apply some other function. No. Roads are drawn in the abstract cell map prior to any texture painting. It is done setting the 'terrain' attribute to 'road' or 'road2' and the procedure uses other members of the cell object as well. That said, it's not a problem to create a region holding these cells, and, as you suggest, grow this region twice to create a path five cells wide (I think the PatchPlacer can do that, with some adjustments maybe). I'm not sure this will give really good results, particularly with very winding paths. But anyway, there are other solutions, and I'm thinking about. Actually, the script draws roads before any entity placement because it has a useful side effect: it allows to verify no player is jailed in some part of the map. If so, the map is rejected and a new one is created from scratch. It is of course more efficient to test this as early as possible. Friendly,

Hi everyone ! Thanks to @FeXoR for his feedback. He is right to say: ... of course. Point 2 is not difficult to fix most probably. I use here an old version of rmgen routines which works not well every time (don't say I should use a newer version. I know but it creates problems in my design too). Point 1 is more tricky. For now, the road creation procedure draws one cell wide paths, which is not optimal when the path runs diagonally. It's probably why they look broken when running across forests. In mountains it would be even worse, but here, I have already made some adjustments to make roads (rather) walkable. But this is clearly not enough. Il have to rework the thing to create larger paths (and by a side effect, maybe solve the issue @elexis quoted here: Now, how wide ? It's not an easy choice: I often noticed the pathfinder has a problem with bottlenecks: even when the path is more than five tiles wide, if units use it in both directions, they deadlock each other and this results in a absurd mob (and a lag). All these are created by the main landscape procedure. Mountain and water ratios can be modified easily (it's a parameter). It's always possible to modify the map in some way (make the water deeper for instance), but IMHO, the problem is to know if we create (rather) realistic maps players have to deal with (and this is part of the game challenge), or artificial playgrounds where all landscape difficulties are smoothed or eliminated. This is open to discussion but maybe we should make a clear choice (at least for this or a random map category). Agreed... OK... Yes, it's not, but in real world, geomorphism don't cares about paths too... I suppose here the civilization level is rather low here, so paths follow the easiest way. It's possible to make them avoid completely water, but this would eventually result in absurd things: for instance a road climbing rather high to cross a mountain falling into water when it is shorter and easier to follow the bank, wetting slightly one's feet. In some way, I follow the pathfinder policy to connect parts of the map: it avoids not crossing the lakes and rivers even when it's not absolutely necessary. Ideas ? Textures can be changed easily of course, but I'm not that good at it. Feel free to suggest other sets. Don't worry, they make sense...

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,

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,

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,

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

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.

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,

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,

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,

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 !

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

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,

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,

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,