Jump to content

Pyrophorus

Community Members
  • Content count

    56
  • Joined

  • Last visited

  • Days Won

    1

Pyrophorus last won the day on September 9 2017

Pyrophorus had the most liked content!

Community Reputation

103 Excellent

About Pyrophorus

  • Rank
    Discens

Recent Profile Visitors

396 profile views
  1. wowgetoffyourcellphone's gameplay design

    Hi ! Some ideas about OAD design (excuse me if off-topic): - Food. I think units should eat, or in other words, consume continuously some food (and maybe wood and metal when mechanical). This would limit rather naturally soldiers number, because one should produce regularly enough food to sustain them, idle or not (and some, like cavs and heroes should eat more than ordinary soldiers of course). Even if population limit is removed, available terrain for fields is limited. If food is missing, units starve or fly to enemy. This would force players to maintain a serious productive background, not only during the development phase. - Population Population grow could be automatic: regularly, some new citizen units, female and male, are added in the houses (ratio of existing houses and/or women, I don't know). Then they can be set by the player directly to some productive occupation, or sent to buildings to become soldiers, healers and so on (it would be really training then and not creating people from nothing). This would lead to exponential population grow. Yes. And the player should quickly face the problem to find room to settle them, enroll them in the army, set them to emigrate or even sell them as slaves. Just my two cents...
  2. how open ports for 0AD multiplayer match?

    With 'iptables -L' you should learn if if any filtering rule is active (if none, you should have nothing under the titles INPUT, FORWARD, OUTPUT, or even an error if iptables is not enabled). Next you can try a port scan on the distant (with or without OAD running). If impossible, try to fetch the tcp port 80 with your browser. On Linux boxes, Apache is listening most of time (http://127.0.0.1:80 in your browser to verify). Wireshark is the tool of choice to know what happens really. Run it in promiscuous mode on both computers. Set a filter on UDP protocol if you're overflowed with traffic (probably not with a crossover cable connection). You should at least see one of your computers trying to connect. Hope this helps...
  3. how open ports for 0AD multiplayer match?

    Just in case,, try to see if the UDP port is not already used by something else (with netstat for instance). BTW, crossover cables work very well and the OP did configure it correctly (provided it is really connected to interface enp2s0). Friendly,
  4. Yet another random map generator

    Hi ! No new feature but there is now a comprehensive user documentation here (Thanks to @stanislas69 who reviewed the thing). Have fun !
  5. Yet another random map generator

    There's no need to do that. The fractal library can work with both Vector2D and PointXZ (I think you mean this one). The cell object offers another (much faster) way to deal with the problem, but as I said some times ago, I think all this is not mature enough to enter alpha23. So I think a decision should be made and it would concern only the fractal part of the library (fractal.js) which rely NOT on the cell object. The fractal painters are no more than other painters in rmgen. You can copy/paste them somewhere as they are and if you want to review the code, it's only 340 lines, a great many of them being comments. The remaining part of the fractal library is more a convenience and a code example to create globally height maps. It can be avoided if you want. I can remove PointXZ support for you if you want too, but I don't want to do that in my mod until the release is out, and have no reason to do so if finally you decide to include nothing in alpha23. Friendly,
  6. Yet another random map generator

    Hi ! @FeXoR Thanks for your feed back and appreciation. At least, I think it should be possible to add the fractal painters. It's only adding new painters. There is no compatibility problems. The remainder of the fractal.js can be inserted too, but is more a convenience to create whole maps in one pass. Javascript has not strict inheritance but allows to add properties to an object at any time. So it's easy to add new values to the Cell object or its prototype when they're needed. And we need not to define a full featured Cell object as in Java or C++. In the code, it would look quite the same. For now, if you want to use slope, you have to create a separate slope map first which is stored in a array. Slope (or anything) would be stored in the Cell objects instead. And if you want to know if the work has already be done (rather useful in a library where you have no control on operation order), you can test if the property is undefined on any Cell. For myself, I use four members which will probably never been used in other functions. But it's not a problem. I can easily enhance the Cell object if exists. IMO, there should be no penalty because, obviously, Javascript uses references when manipulating arrays or such containers. It matters not if the object is large or not. But creating a new object has a cost. Now the operator === is certainly faster than (x1 == x2) && (y1 == y2), but I'm not sure it adds a real benefit. If you look at this line: if((neigh.slope < this.slopemax) && (neigh.slope >= this.slopemin) && (neigh.alt < this.altmax) && (neigh.alt >= this.altmin) && !(this.mask & neigh.lock)) where neigh is a Cell object. Using separate maps would result in: if((slope[x][y] < this.slopemax) && (slope[x][y] >= this.slopemin) && (alt[x][y] < this.altmax) && (alt[x][y] >= this.altmin) && !(this.mask & lock[x][y])) which is certainly not faster. But I don't suggest this to improve performances. The real way to avoid updating many times cell objects (or maps) slope or anything is to compute this value only when height map is quite finished. If you modify the height map anywhere in the main script... I'm a object oriented programmer, so I'm not easy with your way to split in many arrays what is to me properties of a cell. In my experience, the main benefit of this approach is not in performances but it saves development and maintenance time. If you library had a cell object and used mainly references to them, the change from PointXZ to Vector2D would have been much easier, because most often, you don't use the actual coordinates. And if there was accessors to the coordinates, it would have been enough to change a few lines of code in the cell object only. Friendly,
  7. Yet another random map generator

    Hi ! Just a word to say I have updated Github with the new features described in earlier posts. Since I have no new from the programming team, I suppose they will catch only the fractal part of the library. It can work as is, in alpha22 or alpha 23. I made provisions to ensure it works with both Vector2D and PointXZ. The various fractal painters have no dependency with the fractal generation of global map. This one has two rather large methods allowing to draw composite maps. They can be included or not, at will. I have nothing more in my TODO list, at least for the library. Friendly,
  8. Yet another random map generator

    Hi all ! Today, I'm making some kind of request for comments. I have finalized two methods of a placer and would like to have [random] map makers opinion and suggestions. Have they the use of such tools ? As they are or working another way ? I'm open to suggestions and requests for features now and later. The picture below shows the principle: The center of the spot (deep green) is created with a good ol' clump placer. From this region, we deduce approximatively concentric regions with the placer. The first step is using a method initializing the placer with the central region. As all methods of this placer, it computes the border of the region (one tile wide), and can be used only in this purpose: get the border of any connexe region. Next another method expands the region, adding the chosen number of tiles. Those tiles can be added to the initial region or returned as a separate one (only the ring). This step can be repeated. Here, we call the function twice, and finally paint the border of the last created region. As one can see, the expansion is not isotropic nor regular, because there are other ways to create geometric shapes. The expansion is ruled by three factors: the distance to the center of the region, the tile height and slope, the weight of each one being a parameter of the placer. Some noise can be added too, which essentially change the border. Maybe other factors could be desirable too or instead. Suggestions are welcomed. I used this very spot to create the pictures below. Applying a fractal painter to the inner region, and raising the two rings to a fixed height: This one is created with exactly the same code, but, a different map seed gives another result: I hope the discussion will bring new interesting ideas. Friendly,
  9. Yet another random map generator

    Hi ! This is a (long) technical post. Don't read if you're not interested in programming. This is a proposal to address integration problems. The point is open to discussion, but my development will be stalled until I have a reply. Friendly,
  10. Yet another random map generator

    Hi ! Here come some previews of the fractal painter. As shown before in this thread, it creates a little height map to modify a region of the g_Map. This region is defined by a pair of coordinates array, i.e. something like {x:some_value,y:some_value}. So it can be anything including Vector2D, cell objects and even PointXZ (converted on the fly). In the former version, the painter replaced indistinctly all the heights of the regions, which gives this: The result is not great, because it's possible to have chiasms at the border of the region. This mode is still available but the default is now to modify only the parts where the computed height is higher than original terrain: The merge is now much better. What if we want not a mountains patch but a depression ? There is a new painter for that: It creates a bumped hole in the map, but the default here modifies only the parts lower than the original map and it merges better: Now another painter. Mesas or cliffs: The top of the mesa (deep green) is perfectly flat, but this can be changed easily: at the end of the painting, the painter stores into a member array all the top points. The top of the mesa is painted using this region. A new fractal painter (or anything else) can be applied to modify this part if something less plain is desired. The counterpart of this painter obviously creates holes whose bottom is flat: In the same way, the flat part is available after painting, for morphing, painting or populating. Just put an Orthanc tower here, some Fangorn forests around and you've got Isenguard ring Please note the painter can be applied on any kind of regions, not only the rather round one I use here. More of it, everyone can define easily a new fractal painter because they all inherit from an abstract object holding all the code complexity. The child painters hold only the part where the two maps are mixed. Here is an example: function MyNewFractalPainter(area,centerHeight,bump,rough,progress, your_parameters_if_needed) { AbstractFractalPainter.call(this,area,centerHeight,bump,rough,progress); this.param1 = your_parameters_if_needed; } MyNewFractalPainter.prototype = Object.create(AbstractFractalPainter.prototype); MyNewFractalPainter.prototype.paint = function() { let res = this.maps(); // this computes the temporary fractal map let depx = res[0]; // these are the offsets of the fractal map in the main map. No need to change them. let depy = res[1]; for (let pt of this.region) { // melting the g_Map and the temporary map. This is the only part to modify. let xg = pt.x - depx; let yg = pt.y - depy; if(g_Map.height[pt.x][pt.y] < this.tMap[xg][yg]) continue; // we skip this value g_Map.height[pt.x][pt.y] = this.tMap[xg][yg]; // we keep this one } } Not in Github for now. The reason is I don't know yet in which format the flat regions created by the two last painters should be created. Friendly,
  11. Yet another random map generator

    @stanislas69 Hey ! Wait ! I'll finish this map script business first ! Then maybe I'll give a go since it' badly needed. I think I have seen somewhere some description of the feature and it's a pity if it is broken. OK, it's not a problem. I'll give a try rotating them by hand and test the result. For now, I don't want to put a lot of stuff into my mod, making it impossible to include in OAD distribution if this is the final decision.But if the idea is abandoned, then everything becomes possible ! Sparkling animated eye candies, strange looking terrains and fantasmagoric landscapes ! Hurray ! Friendly,
  12. Yet another random map generator

    @stanislas69 Thanks for these suggestions. I don't think I need really more terrains for now or vegetation for now. My problem is more to select a set giving good looking results. I'm rather happy with the green parts of the map and mountains, but much less with the others. Desert plants look too green, and in the kind of steppe lying between the players patches, the map exhibits some patterns. I believed at first there was something wrong with the RNG, but at a closer look it is not. Some terrains textures share the same layout, and the color only change. I wonder if is possible to rotate terrains when painting, as we can rotate actors. It would certainly break those patterns. Friendly,
  13. Yet another random map generator

    Hi ! @elexis Thanks for your reply. OK, I perfectly understand that, but including my work in the rmgen library is YOUR idea, not mine. I never asked for this, not because I don't want to collaborate, but because I'm conscious it's really difficult to achieve. I did implement the Placer, Painter and Constraint in my development even if I don't use them and I don't need them, but if this not enough... My goal was not and is not to refactor rmgen or replace it but to experiment other ways to do the same things. At the highest abstract level, we all do exactly the same: creating a heightmap, painting it and placing entities, and at this level, many things look duplicates. Now, looking more deeply on them may reveal they don't give the same result, and according to circumstances and personal tastes, a method can be preferred. Why don't you say my fractal height map creation duplicates DiamondSquare which already exists ? They do exactly the same job using very similar algorithms. Now it's your responsibility to pick in my work what you think possible/interesting to include in your development. But please, take a deeper look at my code/results and stop saying it duplicates other things. I read rather thoroughly the whole rmgen library code and I haven't the habit to reinvent hot water. Can it create up to 100 or more optimal roads between arbitrary points, crossing the moutains in a realistic way, just in one call ? Mine does and not just looping road after road: the work is done in one pass on the map for all the roads at the same time. As a side effect, it returns how many roads nets it created (some points may not be connected because impassable mountains or lakes), a reliable test to know if some parts of the map are unreachable. I'm not trying to sell you my work as better than yours. Just let me say it's not a duplicate. And if you want me encapsulating this in a placer, it's five minutes work. I don't need that area, have already checked map boundaries, and TerrainPainter does nothing more than PlaceTerrain(). Where is the problem ? I don't expect you adding this to rmgen of course, but do you really want to deny me the right to create some convenience short functions ? The problem is creating the region covered with forests. The YPatchPlacer I use creates not the kind of regions rmgen placers does. Since they use geometric shapes, they define rather regular regions. You told me you had the problem in Ambush. Do you see anything of the like in my maps ? Now, I have not yet experimented fully all the capacities of this placer, but as a side effect, it provides the border of the region created . See the hedges in the pictures above, can you tell me how I could do that with rmgen with three lines of code ? Now the placer should be able to expand a previously created region to create an irregular ring around, and even expand and find the border of any other region. For instance, it should be able to be fed with a ChainPlacer result and add some blur and noise at the border or only find the border. Do you really think it's nothing more than a HeightPlacer ? You may think these features are uninteresting and not worth to be integrated, but don't say it's a duplicate. Confined use case ? Are you conscious I'm creating this whole script map without any call to rmgen except to set up players things ? (Which don't work very well BTW, I have problems with this, and I'm tempted to substitute my own code) . Of course, you can say so because no random map script uses these features for now... That said, I know you don't like TileObjectMap for good reasons, but I already told you it was a fundamental design clash and not only something which could be changed or avoided easily. Rmgen has no cell object and splits informations here and there in many places. And the reasons you give apply to rmgen as well: g_Map needs to be initialized, and you can put the slope in a cell object or in a separate map like heightmap library does, they will run out of of sync exactly at the same time and for the same reason. And what if the programmer inadvertently creates two or more inconsistent slope maps as (s)he can perfectly do for now ? Another problem is you can't use the === operator to know if two Vector2D or PointXZ objects are the same, because the library can freely create more than one object holding the same coordinates. So you must access the members and compare them, and you couldn't use a Set container with reliable results because it would eventually store duplicates. This is why I use a cell object, because in the reality, there is only one tile at x,y coordinates, not many. And this is why you can't add any member to this coordinates pair without running into awful synchronization problems. So why make them an object ? Of course, the cell object map should be in g_Map and should have mutators dealing with the sync problem, but we already discuss the matter and it was rejected for some reasons. Then I created my own map to avoid the risk to fool ExportMap() with unexpected additions. Now, I went somewhat further than I use to go. I'm not your boss and give only advices when I am asked. I'm not speaking the TRUTH here, but only my humble opinion: to me, it's poor design so I have no reason to follow it since I don't belong to your programming team. The proof is in the result: I don't need all the rmgen stuff and that's why object oriented programming exists. It simplify greatly the work and makes the design clearer and easier to enhance. I can add easily all compatibility code you want like the place() and paint() methods I don't use, constraints which are here as a proof of concept and never used as well, but don't ask me to rewrite the main code without a Cell unique object and map. I hope you'll understand this and will not see it as a mark of contempt about your skills or your work. Now, you are at the crossroad: if you drop the Cell object (or whatever variation it could be), you drop all the content of placers.js and the random map script as well. I'm conscious it is a difficult choice because you are aware of your library consistency. But I think you should make a clear decision now and not expect I will solve magically the problem. For myself, I don't mind. My job can perfectly live in a mod without clashing with your development process and maybe it's the best solution.Again, do what you think best for OAD. Friendly,
  14. Yet another random map generator

    Hi ! As @stanislas69 suggested, I finally refactored the whole thing to make it a mod and push it into GitHub. There's no feature change from the previous version, but the script has been split in three files, two of them holding most of the code: fractal.js: all the height map creation is here, including a fractal painter. placers.js: various utilities, constraints and placers using the global tile map object. I removed from the script and the library all uses of points objects (PointXZ and Vector2D as well), because I don't need them. There is still one place where it can't be avoided: the place() method of the placers objects which must return an array of one of these types. To make things easier, I return those arrays through a convenience method (zoneToPoints) located at the beginning of placers.js. It creates a point array from a cell array and one can change this to the particular object type (s)he expects. Just for fun, an impregnable fortress : I have to fix this... Friendly,
  15. Yet another random map generator

    Hi... Adding a hedge around the players fields to protect them from the desert wind (... well, to hide bad transitions too). This one is a 'Normal' map, but rather strangely, the execution time is not much larger on 'Giant' maps. Friendly, EgyptOasis.zip
×