Search the Community

https://wildfiregames.com/forum/index.php?/search/&q=POGs&search_and_or=or

Who are the pogs? LordGood can you upload the paths (see filenames above) as a file attachment in the forum post? I guess the textures are already committed for other actors?

POGs may be your solution.

The OOM error occurs when exporting the map due to the iteration over the objects. Javascript (or the interpreter, spidermonkey?) can't handle loops bigger than 1,000,000 (not sure about the exact value). There's not much I can do about it. EDIT: Correction: The OOM error occurs only on giant maps AFTER the map is exported and saved so while the engine loads the map I guess. This only happens when the number of "Entities" (shown in the mainlog after "Saving map...") is bigger then 10,000 (not sure about the exact value again). That means on giant maps (512*512 = 262144 Tiles) only one entity every 26 tiles... Another Correction: It indeed seems that it's not the number shown in the mainlog but depend on something else. Deep Forest raised OOM errors with roughly 13,000 "Entities" while Belgian Upands generated fine with 27,690 "Entities" according to the main log. A giant Belgian Uplands map seed had 37,960 entities which is to much though. ADDITION: A Giant map with half the prop density still raises an OOM error though it contained "only" 20,222 entities according to the mainlog. The number of interactive objects, however, was unchanged. So indeed there seams to be a difference but in the mainlog the number of objects are shown (not the number of "Entities" as it states). The exact error (only this one): "ERROR: JavaScript error: simulation/components/ResourceSupply.js line 37 out of memory" POGs would indeed be good. They lower the number of needed actors (and so the size of the loop during exporting the map) and make it less pain for a map designer to place them (less clicks in atlas/less needed actor types in RMS). Some of the actors seam to be such things already (like many in "campaign"). If it will become another type of objects RMGEN should handle them so entities/actors/POGs can be used with the same syntax (I can't figure out how to place terrain on a tile similar to placeTerrain() with an array of terrain string (and randomly chosen one per tile) that also support terrains with actors, not only templates/entities). Checking other maps for examples... BTW: The naming is pretty unclear to me: - While in Atlas choosing "Entities" (in opposite to "Actors (all)") only objects in simulation/templates are shown (is it an "Entity" or an "Template" then?). In RMGEN the Entity() class is a template type with a position on the map.with a certain orientation. However, it works for Actors as well (Things in art/actors) and Entity() instance can be placed with placeObject(). So is it an "Entity", a "Template", an "Actor" or an "Object"? I'd prefer the last at least for RMGEN. - In Atlas "Actors (all)" additionally shows everything in art/actors but they are placed in random maps with placeObject() or (in Goups though the name "simple object" doesn't make that clear) SimpleObject().place . However, createSimpleTerrain() supports strings made of a terrain type string, a separator (a pipe |) and an Entity path string like e.g. "temp_grass_mossy|gaia/flora_tree_oak". That, however, doesn't work for actors so here "Entities" and "Actors" are different in RMGEN while in general it seams they are put together as "Objects" with the only difference that the type string of an actor has to start with "actor|" and include the file extension like ".xml" (which is good IMO except the need of the file extension). The problem here is that a string is used while it wold be better to use an array IMO. "temp_grass_mossy|gaia/flora_tree_oak" works but "temp_grass_mossy|actor|props/flora/bush_medit_sm.xml" doesn't because it contains 2 pipes. It would work if createSimpleTerrain() would use an array with one entry being the terrain and the other the "Object" to place on the terrain. So the "Object" could be an entity e.g. "gaia/flora_tree_oak" or also could be an Actor e.g. "actor|props/flora/bush_medit_sm.xml". If RMGEN had access to the engine (like trigger based RMS generation would provide) there would be no need to differentiate between Entities and Actors at all because it could search in both paths and only throw if the given path string is invalid for both (simulation/templates and art/actors). Off topic: art/props/flora/grass_underbrush_mediterranean.xml does not "bend" to the terrains surface but looks like it should... EDIT: Added many props to the map: http://trac.wildfire...com/ticket/1688 EDIT: Trying to reduce the number of props on "Very Large" (slightly) and "Giant" maps (scip most of them) to avoid OOM errors.

Hmm, any actors (i.e. non-gameplay impacting entities) shouldn't be as much of an issue as entities. I would say that e.g. stones which doesn't have alphamaps could be used a lot more frequently though. Big maps will have to be worked more on anyway, so don't let that concern stop you from making the maps look good. And as far as I can tell the OOM issues are when generating the maps rather than playing on them? Speaking of that, would it help to have objects which consists of several smaller objects? If the issue is that there are too many objects for the game to go through in the RM generation phase that should help I would guess. Michael had some ideas for what I believe he called POGs (I think it was short for predefined object groupings or something similar) which would essentially be small "scenes" that a scenario designer/RMS scripter could include in his maps. That should work even for less ambitious things like a bunch of stones and grass objects.Hmm, did a quick look among old mockups and found the attached image, seems like POG is short for premade object groupings =) At least I wasn't too far off

I think this is a great idea to implement at some point. Another useful concept for random maps is the ecotope, a collection of entities that occur within a given biome according to certain probabilities and constraints, but on a smaller level, say 16x16 tiles. Examples: "temperate forest", "temperate grassland", "tropical forest", "desert plains". The more of these that are defined, the more variation the random maps will have. The basic design would be generating high level strategic elements first (terrain, player positions, etc.), if the map will have multiple biomes do that next, then split the biomes into separate random ecotopes that match their terrain, and then finally place some POGs and other small elements. I like this better than the current piecemeal approach which is slow and hard to understand.

Looking at a map's XML, I can start to see how "POGs" could be possible. <Entities> <Entity uid="13"> <Template>gaia/flora_tree_carob</Template> <Player>0</Player> <Position x="212.539" z="506.22016"/> <Orientation y="2.35621"/> </Entity> <Entity uid="15"> <Template>gaia/flora_tree_carob</Template> <Player>0</Player> <Position x="262.94837" z="499.05585"/> <Orientation y="1.01987"/> </Entity> <Entity uid="24"> <Template>gaia/flora_tree_carob</Template> <Player>0</Player> <Position x="206.7829" z="477.50257"/> <Orientation y="-1.5824"/> </Entity> <Entity uid="26"> <Template>gaia/flora_tree_carob</Template> <Player>0</Player> <Position x="253.0978" z="522.48066"/> <Orientation y="-1.6237"/> </Entity> Each entity shows a position and orientation. In a POG this could be relative to the boundaries of the POG. Once you place a POG then those positions and orientations are recalculated for the map. If we wanted to go super cool, we could still have these placed items be connected in an underlying way so that you could hold ALT and re-drag the POG after its already been placed, even if you've already repositioned (or deleted) some of the individual items. Something like that would be good for custom scenarios. Now, POGs for random maps would be awesome because a script could place a variety of POGs to give a nice hand crafted feel. What are POGs? Premade Object Groups, a concept I came up with some years ago. Basically a designer could create a small "map" in Atlas, place some objects in an aesthetically pleasing way, like a vignette, then save that "map" as a POG, which can then be used later, either by the designer (or other designers--I could envision "POG Packs"!) or called by random map scripts. I suggest POG mode would have a standard length and width so that POGs don't get too massive, or a small number of standard sizes.

Cool Ben Random maps are starting to get to the point where they rival custom made maps, not yours though Michael That will take a while longer Seriously though, andom maps will probably never be as visually interesting as maps created by humans, on the other hand, with things like POGs they'll sure be more interesting than in most games.