FeXoR

IMO all heroes should have a "heroic glow" to better be noticed on the battlefield. The aura could than be displayed by granting a weaker (less glow radius?) version of that glow to all effected units. The color of the glow could be different depending on the hero. Since one player can usually only have heroes from one civ it could be of the players color and only differ in how light/dark it is. If units are effected by more than one aura that might not be clear from which hero they get a bonus due to an aura though. So perhaps it might be better to use colors only depending on the hero despite the player's color. Guess that has to be tested. Another way would be to add something to the selection "rings" e.g. to fill them with a color depending on the aura they are effected from and give the glow only to heroes. That selection ring inner color should then be visual all the times even if not selected and so should be quite transparent to not fill the view with distracting rough shapes. I'm not sure about this but perhaps the glow could only be shown to the player the hero is owned by. That way it would be harder for an enemy to detect the hero.

Guess with the exception that AIs can't handle being Mauryan? Can AIs handle playing against Mauryan human players? Anyway a good note!

Me too!

Giving formations a very high bonus feels like enforcing they make sense. I don't know if they can be implemented well and will grand a significant gameplay value. It would be really nice if we had a "no formation" formation so that the order is just given to each unit separately. That way "balancing" the different formations would be easier and we could see how big the bonuses for formations would need to be.

The file I modified was 0ad\binaries\data\mods\public\maps\random\rmgen\pathplacer.js I have no good solution to it so it's not fixed (see Spahbod's last post). That would be the best solution

I think I heard that http://www.bing.com provides a cross social media API. Couldn't find it at first glance though. Concerning the button to turn on/off social network support: As I said before it should disable loading the code for it as well as removing the buttons from the GUI. That's the least. And I agree with Yves that code not used anyway does not need to/should not be installed. This doesn't only apply to social media support. This could include e.g. the high quality graphics actually not delivered with the prebuild Alphas or even Atlas for people that only want to play because it's quite of some size (Indeed for me it would be formations, too ^^).

True, the option to turn it on/off could only effect what you see and what is loaded, not the installed code. But it's not that unlikely to not install specific features of software at all. It can/should be enabled by default. But the option to turn it off is a must-have IMO.

This is far from being easy at this point. If I got my will and everything would be trigger based you could generate own entities at runtime and so in atlas, too, and the needed graphical user interface would be easy to add. But triggers are suspended until part 2 so it will take at least a year until I see such a feature even being considered (But I can be wrong of cause ^^). Until then you can (or have to, depends on your familiarity with code) write your own civs and entities to enable such things.

Since docks can be placed well ingame and bridges would have to be placed similar I don't see why not. However, I'm not working at that part of the code so it's the decision of developers who do to add this feature. It will be some work for sure and I don't think it has the highest priority but I think it's worth a thought. Sorry for not saying " I'm already working on it" but that's just not the way open source projects work .

Well, there are bridges (look map "bridge demo") but they cannot be build ingame.

True! But this doesn't mean we have to mystify them or that mysticism in any way betters our understanding of "reality" or "the world" or betters our quality of living in an enduring manner. Just an example: There was much mysticism in the dark age but not much gain of knowledge or the quality of living IMO. (This is ofc. no proof, just an example)

A bit of topic: Well looking dunes will soon be available for random maps with the erosion lib I'm working on. It already works but is not yet well documented and organized. I think it will be ready to use in a few weeks. It would be cool if some global weather variables could be set and used by different parts of the game. One example would be the wind speed, direction and how squally it is. This could then be used for tree movement, terrain erosion and dust/smoke/steam particle movement. This will be hard to do ATM because e.g. RMGEN has no access to the engine and there's no way to set such things in the engine determined by the random map AFAIK yet.

Though I don't like it you are right. Player AIs code is "loosely" bound to the engine to make it a threaded process later in developement (when we get to this point), which is OK but IMO not optimal. RMGEN is run before the engine is started and generates a map that afterwards is loaded by the engine (which I think is a bad choice). The reason why I don't like it is that the programmer does not have full access to all the games content (and things are rewritten in all the parts if needed). I'm sorry to say I have no quick answer. I build my own function to place paths in the RMS "Deep Forest" and are not familiar with the pathplacer.js. Trying to figure out what's wrong... EDIT: This error only appears on giant maps for me. On very large maps its working fine with the seeds I tried. It's more like normal that giant maps throw with an OOM error than an exception x). I think reworking all maps to make sure everything works fine on giant maps is not the best idea (though I did it for my RMSs). I agree with myconid to raise the memory for the Javascript runtime engine (Spidermonkey?). I don't really mind if it is set automatically or can be set in a config file. I'd say the best way to do it would be to target automatic settings but to fix it "easy" and quick add a property in a config file. If it's set to 0 automation is enabled (default). Otherwise it's set to the given value in kilobyte (or whatever is preferred). This ofc. doesn't fix the initial bug that paths have more points than a giant map ^^. Didn't find it yet. EDIT2: The number of totalSteps can be greater than the distance from the start to the end of the "path" if Waviness and/or Smoothness are > 4. In "Alpine Valley" in line 247 (create hills), 266/270 (create passages) and 289 (create rivers) the Smoothness is 9 on giant maps. The Waviness is 0.4 and so the numSteps is "only" about distance/10 (+1, irrelevant on big maps) and numISteps about twice the distance. So totalSteps are about 2/10*distance*distance (which should be OK) and will be about 50k for giant maps. BUT then lines of the paths in x direction are drawn - though the tiles in y direction the path contains is MUCH smaller than the 50K (512 at max for giant maps). So many tiles are drawn multiple times. Checking the output with added debug code before PathPlacer.place returns it's value retVec: var duplicatedPoints = 0; for (var i = 0; i < retVec.length - 1; i++) { for (var j = i+1; j < retVec.length; j++) { if (retVec[i].x == retVec[j].x && retVec[i].z == retVec[j].z) { //log("PathPlacer.place: Duplicatd values found: retVec[" + i + "] and retVec[" + j + "] are " + retVec[i].x + "/" + retVec[i].z + " and " + retVec[j].x + "/" + retVec[j].z); duplicatedPoints++; break; } } } log("PathPlacer.place: " + duplicatedPoints + " of " + retVec.length + " points are duplicated"); ...shows that most of the tiles are duplicated (duplicated tiles may be 1 bigger but that doesn't matter). Part of the mainlog: So the problem is in the function "PathPlacer.place". I don't really get the function so perhaps historic_bruno or Spahbod could fix it more sane. OFC I could just remove the duplicated tiles from the return value by skipping the "y lines" and "x values in that line" already added.

I don't know what intentions you had when writing this but I think I don't like them...

Babylon 5 - The political thriller in space ^^ The big bang theory - I fare to often see myself in Sheldon for my taste x)

I strongly agree!

Any further suggestions? Otherwise I think this map is quite playable now. No out of memory errors, no problems with many players on small maps, decent looking "empty" (no interactive entities) mid level ground (grass), very natural and random design in general compared to other random maps, no problems with the AIs as far as I tested. So if there are no others ideas at this point I think it can be added to SVN. Ticket: http://trac.wildfire...com/ticket/1688

I agree. "Just don't zoom out that far..." is not a good argument in general - the player should be allowed to decide how far he zooms out. Why should zoom out be limited? I agree that zooming out that far that tiny maps are only 1 pixel and might be missed by the observer is stupid but that's pretty far. Indeed I never did that and it would take ages to do that if it works. By the way: A new version of Belgian Uplands is available at http://trac.wildfiregames.com/attachment/ticket/1688/belgian_uplands2012-10-5b.zip

I successfully got rid of the OOM errors even on giant maps (at least for the about 10 seeds I tested) by reducing the prop density to 3/4 on very large maps and 1/4 on giant maps. Here's a screen shot of a giant map: ...and a closer look: Now checking how long each loop takes in average to add progress bar settings... Edit: Done: http://trac.wildfire...ds2012-10-3.zip

Just noticed that RMGEN function SimpleTerrain.placeNew() random placement angle is 0 to Pi but should be 0 to 2*Pi. ATM I'm trying to figure out how to place a terrain with an actor similar to "terrain|entityPath" but it's not working with placeTerrain().

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.

Yes, and they are all entities so using them lowers the number of possible entities with a gameplay impact (or big maps will wind up with an out of memory error). However, using them infrequently would be OK. I'll give it a try.

Well, give it a try. As long as it works well and not to much hacks are needed to make it work. Would look more natural for sure. I feel the empty space on grassy terrain is to big on some seeds. Any good idea what to place there? Some eye candies perhaps? Does razed buildings give resources? If so perhaps some buildings for Gaia?

Ah, that is good! Did get that wrong then (Thought they'd need to "drive" to turn). Added a ticket to add this map: http://trac.wildfiregames.com/ticket/1688

Yes, that's a bad thing. An citizen soldier, even if a bit weaker than others, can still be useful to gather stone/metal because it might costs the resources easiest to get on a specific map. For elite units this argument won't work of cause. In general I agree with you.