FeXoR

Oh, sorry, that was misleading. I meant the paths will be at a specific height (above the water) but might break the coastlines and may sometimes be unrealisticaly long. Not that much of a better explanation but I hope you get it ^^ @ Bridges: Yes, at the very end I might think of that ^^. Indeed I plan to add entity placement by functions (given to the placement function) to the wall builder lib. If that is finished it'd be quite easy to place bridges on paths through water if the paths shapes are given by a function.

Thanks for testing and your comments sanderd17. Paths Yes, I plan to do this (I'll try paths as used in Deep forest first - with some changes). The height will be set to a certain, fixed level at the center of the path and softly merge into the original height at the sides (similar to how start locations are smoothed ATM). A little concern of mine is that sometimes the paths will go through water as well and that might look ugly (but we'll see). Expansion mines I plan to give a different decoration to them (as well as start locations). That's somehow breaking the concept of textures/actors mainly by height (and only change the probability of placement in some conditions though ATM it's not used because it works well without and is quite slow - even with the faster distance check - because it's checked for every tile). I might try to change the placed texture dependent on the distance to an expansion mine (which would also need distance checks but would at least need only one texture placement for each tile). I might change the height they are placed closer to the forest/water. I agree on that in general but I'll first try how it looks with further decoration first.

Maybe you have the version I posted once to the IRC channel (if so the peaks should be lower in the center of the map - test of the terrain smooth function)? This should be listed as "Base Terrain Diamond Square Test" in Atlas AFAIK. The 2 latest versions should be listed as "Realistic Terrain Demo" and should add start locations.

Playability reached! Resources at start locations are now added (though wood/food not according to the biome yet). Further stone and metal mines are distributed among the map. Optimizations: Terrain smooth functionality and distance check much faster and no distance check needed for all tiles any more. So this map should now be playable. Further suggestions for playability very welcome! Yet to come Clear the code of inconsistent code (e.g. a point might be [35,726, 197,758] or {"x": 35,726, "y": 197,758} or just x = 35,726 and y = 197,758). Remove use of functions just calling other functions returning a "fixed" value as far as possible. Remove the need of any other library as far as possible (to keep it easy to debug and change). Add support for circular maps. Change the random biome system and chose better fitting textures and decorative props. RealisticTerrainDemo2013-10-4.zip

Progress Start locations are now added quite sane (players in one team might not be next to each other yet). The terrain around the start locations is smoothed (though on tiny maps the incline might still be to high for satisfying results). Trees and decorative props density is lower in the surrounding of a start location (This drastically increases generation time so I'll think of a faster range check). The Iberian civ bonus walls are not placed at all yet due to the lack of space (I'll think of something to at least add them on medium or greater maps). Coming soon (hopefully) Next step will be to add resources to the start locations and distribute some stone and metal among the map to make this map playable. Then I'll hope to change the random biome system with Spahbod to enhance terrain textures and decorative prop placement on this map. (In general the RMGEN libs are quite chaotic and should be cleaned before adding further libs IMO) RealisticTerrainDemo2013-10-3.zip

Well, then mounted units could just need more space in transportation units.

I don't have much time right now but I'm on it. A terrain smooth painter is implemented and I'm trying to get the terrain generated initially be smoother at predefined start locations. The start locations are the main problem IMO so I try to solve this first before I continue with terrain texture and additional props. For this I fear I'd like to discuss with Spahbod first to slightly change the random biome code. Also there is a quite fundamental question concerning how heightmap changes should be applied before it becomes an rmgen library. http://www.wildfiregames.com/forum/index.php?showtopic=16242&page=10#entry274907

Seems so. Should be strg+rightKlick.

Yes, I agree, that's annoying.

The first case: Should only happen if an attack-move order was given (so ATM never since attack-move is not implemented (AFAIK)).<- [i didn't know, Awesome!] The last case: I though "try to find a path around the friend/foe" is exactly the case to avoid(?) (Should not happen if an attack-move order is given). So, no, the range manage does not have the priority to decide what's to do. It should depend on the order given.

I copied the oft topic parts to: http://www.wildfireg...41

A quote from "Paid Development: September 2013 Activity Status" thread because this comment better fits here: " PLZ don't treat formations as units! That will throw away one of the most basic aspect of RTS games and will extremely favor formations (especially those with many units in it) over single units (because focused fire would be impossible against formations). That would mean a formation with 2 units is about 1/3rd stronger than a the same troops not in a formation. (Calculation: Assuming a unit dies after 4 attacks. Formation attacks the first non-formation unit. It will die after 2 attacks. by then at least 1 of the attack against the formation would likely hit each unit in the formation (if the target is chosen randomly) so both are still alive (since 4-1 attack at most hit one of them) so in the 3rd attack the formation still has 2 attacks while the single units in total (well, OK in this case only one is left) has only one left). This effect gets stronger for more units in the formation (because the damage (even if the target is randomly chosen) can be distributed amongst more units). Additionally (if we are serious with the max. range of the units) big formations would have to run into each other if the formation width is larger than the units ranges (which is quite likely) to guaranty (not possible at all for big formations) the (randomly chosen) unit of the opposing formation is in range. So at least something will happen breaking unit behaviour/game rules (like max. range) even further. I strongly opposing this idea from a gameplay and logic point of view! " The Battle for Middle Earth 2 has among of the worst solutions for combat of any RTS game I have played so far (just topped by the first part and Cossacks). Many melee units can't reach the fight even if only about 20 are around. That's why ranged fighters get dominant even faster with rising numbers of involved units. This will even get worse with greater battalions (AFAIK in TBfME2 it where 5-10 per battalion?) like it will happen in 0 A.D.. Considering a formation with 100 units making a 10x10 square formation. If it meats a similar formation only 10 melee units can fight. 1/10th. I call that an optimized minimum in effectiveness (well a circle would be even better). In my previous post I don't assume the damage is dealt to the battalion but to a random unit in the battalion. That's enough to make it much stronger because focused fire will not be possible. Why do you think this would be better?

Well done!

I don't think it would be terrible to let enemy units be shifted. In the end the passing units would much likely die while passing through. Still this might need some thoughts. Oh, true! minimize(finalDistance * (pathLength + finalDistance)) might do? As it is minimize(finalDistance * pathLength + finalDistance^2) the minimum of finalDistance^2 is "stronger" than the minimum of finalDistance * pathLength (as long as finalDistance > 1). Not sure... Or maybe minimize(pathLength * (pathLength + finalDistance)) ? I'll think of it... (still babysitting would be OK ATM)

Stuff happens ^^ Well, decide on the basis of what's best for the game in the future but consider to wait with the changes if (as it seams right now) roughly 10% of the users can't play 0 A.D. any more. That number will most likely decrease over time. If I can't play/contribute to 0 A.D. any more I will accept your choice (and hopefully get compatible hardware soon). Still I think if it's not that much of an issue right now (I think path finder and range manager have higher priority and would even make the game playable on more instead of less hardware) and I'd love if you could wait dropping ARB.

I'm not sure if this is wanted. IMO defensive structures should be quite strong at the beginning of the game (Phase I, not even available as is), decent in mid game (Phase II, more or less as is now) and not getting any stronger afterwards (Phase III, still useful but not withstanding full scale attacks) so the game doesn't wind up in a turret match. ATM that is done by capping the amount of towers you can build - and I don't like artificial/arbitrary caps. I'd give more offensive things further upgrades in Phase III (as it is now more or less already) so defensive structures become less strong (compared to the offensive units). Not being able to focus turret arrows would make them stronger against few units (like in early game) and less powerful against massive amounts of troops - making this reasonable. One could argue that a tower just doesn't have enough windows on one side to allow everyone in to attack the same target (not that true since it still can if only one unit is in range though). In opposite to formations I can see an improvement of overall gameplay dynamics in this case not allowing focused fire.

PLZ don't treat formations as units! That will throw away one of the most basic aspect of RTS games and will extremely favor formations (especially those with many units in it) over single units (because focused fire would be impossible against formations). That would mean a formation with 2 units is about 1/3rd stronger than a the same troops not in a formation. (Calculation: Assuming a unit dies after 4 attacks. Formation attacks the first non-formation unit. It will die after 2 attacks. by then at least 1 of the attack against the formation would likely hit each unit in the formation (if the target is chosen randomly) so both are still alive (since 4-1 attack at most hit one of them) so in the 3rd attack the formation still has 2 attacks while the single units in total (well, OK in this case only one is left) has only one left). This effect gets stronger for more units in the formation (because the damage (even if the target is randomly chosen) can be distributed amongst more units). Additionally (if we are serious with the max. range of the units) big formations would have to run into each other if the formation width is larger than the units ranges (which is quite likely) to guaranty (not possible at all for big formations) the (randomly chosen) unit of the opposing formation is in range. So at least something will happen breaking unit behaviour/game rules (like max. range) even further. I strongly opposing this idea from a gameplay and logic point of view!

Thx, but I fear my English is not much better ^^. I'm quite sure your help is appreciated in general. However, being added to the team might depend on other things like how desperately improvement in the area you want to contribute to is needed and most of the time PPL are chosen have already contributed to the game for quite some time. You can still contribute to the game as a community member. Just stick around, read some forum posts and try to help here and there. Welcome to 0 A.D. and enjoy your stay

Bridges are actors (only visual, non interactable). ATM entities (like the horse unit) can't "walk" on other entities/actors (like the bridge). So the rider is actually riding on the (raised) ground below the bridge. So ATM there is no way to prevent this bug (but very accurately forming the terrain below the bridge ...which is not that easy).

Yep, I perfectly agree.

Information about entity/actor templates: http://trac.wildfire...com/wiki/Entity http://trac.wildfire...ayout#templates AFAIK the sounds (.ogg) are placed in 0ad\binaries\data\mods\public\audio and subdirectories including an own .xml there. Templates are placed in 0ad\binaries\data\mods\public\simulation exmplates and/or subdirectories where the specific audio .xml is set in the section <Sound>. I'm not very familiar with this stuff but I hope that helps a bit.

I agree. One tiny comment though to: In case the attack range of the ordered unit is smaller than the minimum distance reachable it might me better to minimize finalDistance / pathLength. The player might not want a unit to walk around a big obstruction (like mountains or forests) for nothing. On the other hand this could be seen as a case where "babysitting" units might be acceptable.

This video more or less covers my feelings about most so called modern games in general (so "modern" became a negative attribute in this context for me). Hype the graphics (and often enough add violence I personally don't even like) but ignore game features, playability, balancing, challenge (particularly vs. AI) and especially replayability. ...and I think they are doing this on purpose (e.g. to ensure boredom after a short amount of time to make you buy the next game). In fact I think marketing, public relations, franchise and advertisement (as is now and especially the direction it goes) is bad for people (yes, even for those working in that area). So please take care of what aspects of modern games you want to get into 0 A.D.. Especially for an open source project stability, playability, balancing, compatibility, replayability and modability are much more valuable than graphics or how polished everything is. That does not mean those couldn't be enhanced but IMO shouldn't at the price of one of the others. Yes, cool graphics also encourage PPL to contribute to a project and draws others to play it. But in the long run it's more important which way those contributions go and how long players stick with a game (again especially for an open source project).

I don't know if any OS is capable of running 0ad from console but anyway I would not assume anything about where you get after the game exits and so think "Exit program" would be the more accurate and descriptive naming. "Restart match" would be a nice addition.

General heightmap manipulation question In all the heightmap manipulation I work on most of the time the heightmap is parsed from one function to the other and deepcopy(heightmap) is used quite often. This is not the fastest thing to do and needs more memory than directly applying the changes to g_Map.height. On the other hand this is more suitable for experimenting with the heightmap, all those functions have return values (to be used as seen fit by the code calling it) and in case of generating multiple maps in one script (AFAIK not possible yet) it would not be otherwise possible (and it's still less memory intensive than parsing a whole "Map" object). So the question is: Do we want the hightmap to be parsed or do we want all the functions to manipulate g_Map.height directly? A third option would be to add all the terrain manipulation functions as prototypes to the "Map" object and follow object oriented programming style (which would make the function names more cryptic/longish/unreadable though).