FeXoR

I have nothing against any of the features and think they all are 'nice to have' and for most people they might have a well higher priority. For me the priority of them is not that high because they mainly effect the look of the game an (for me) less the feel of the game. I'm more concerned about easy to add existing custom content as I think it makes a game growing far beyond it's release quality (mainly variety) after it's published. For me that includes: - Scenarios: Implemented ok already. Custom map folder should be somewhere like 'my documents/my games/0ad/maps/scenarios' - Skirmish maps: see skirmish concept. Not implemented yet - Random maps: Implemented ok already, Custom map folder should be somewhere like 'my documents/my games/0ad/maps/random' - Triggers: Not planned before 0ad2 AFAIK. I still think they are important because they can have a big impact on how the game feels. - Entities: I'm not well into this... - Civilizations: As far as I know you have to change a lot of files to add further civilizations so far. Adding different civs from different designers/programmers is only possible by fusing code manually AFAIK. So for the average guy it seams not possible to add custom civilizations at all. - Player AIs: I don't know if there is a folder for custom AIs but anyway it's not that hard to add a custom AI. I think there should be a separated folder for that. And how easy it is to generate custom content ofc. But I don't think that is such a big problem since it's an open source game and should attract a community more into coding.

Perhaps a tutorial video might be a mix. You don't have to read and everything is explained but since no in-game triggers are implemented yet it's much easier to provide.

This guy is a little bit confused But he can laugh about himself like I could I'm out of breath x) The player is maybe not the highest competence regarding RTS games ^^ I didn't watch the hole video but some things he stated: - He wants a map preview for scenarios - He found it unusual that the basic citizens can't build barracks - He thinks hunting has to be made easier

I'm not into this but I think that would be much work in texture art and coding for the uncommon case... If there is a simple solution though, why not

You'r a wise man

THX, feneur. Philip has already talked to me in chat and made some comments. And I agree on having a 'finished release version' might speed things up. Maybe I just ran into exactly those parts of the game that are split from other parts of code (RMGEN/AI). I'll try to stay calm ^^

Welcome to the 0AD forum. In the dev chat I could read: 'interesting thread btw: http://www.wildfireg...=0' ...and I'm not a team member. Your AI development sounds nice to me and I'm thinking of writing an own one, too. I'd appreciate to rip the heart off your AI when playing against it. I'm not the best player but usually have a 30/1 kill ratio against 2 AIs so it will do ^^ Optionally I'd like to run AI matches anyways. So if ready to use post it and I'd gladly test it.

Are you using the alpha 9? In the actual SVN version there are yellow edges at the actual stance(s). So I think its fixed.

Yes, another pathfinding and/or unitAI issue ^^ I wish the developer enough stamina to fix it all and good luck!

I really thing the success of a game and the growth of a community around it highly depends on easy to generate/script - Maps (any kind: scenarios, random maps, ...) - In-game triggers that do something during game time - Units and buildings (look: models, skins, scale, animation, ... and stats: ) - Technologies (Availability, dependencies and generating new ones) But I noticed that for different parts of the game different APIs are written that often rebuilds the functionality of the core engine and/or each other again and again without getting close to provide all possible functionality. Of cause that makes it much more easy to modify things that are 'meant to be' changeable and to debug things but it prevents people from modifying other things that might prove awesome in the end but wasn't clearly seen to be useful or making sense in the beginning (witch is IMO normal for great innovative stuff). That results in more code and confusing different behavior in different parts of the game and a the lack of access to properties or functions that are implemented but not for any specific part of the game. For sure it is good to make common stuff easy to use but it's not good to make it difficult to change less common stuff. Perhaps functions that can get more fundamental information (for example about an entity in random maps or AI scripts) that may not be as easy to use but still grants access to various stuff already defined somewhere could be added. Changing the map during game time is already possible in Atlas but for some reason not in-game. With some timers added it might be at least a start to implement triggers if adapting this functionality in-game. As far as I know that isn't planned in the 'near' future (whatever that means). In Glest , an much simpler open source real time strategy game with 3D engine, 'factions' (like 'civilizations' in 0AD) can be designed by XML scripts that include buildings, units, techs and resources without viewing any other code (though the double reference sucks like a tech contains all units it effects and the unit contains all techs it is effected by). So all the sophisticated stuff is done in deeper layers of the game. It doesn't seam to me with code designed like it actually is in 0AD it will ever be possible to add custom civilizations without rewriting or at least changing large parts of the game (civs, entities, techs, RMGEN libs, AIs and maybe more). Warcraft III wasn't the best RTS I've ever played (for me it was AoE II + Conquerors) but it's success depended mainly of the all mighty map editor (worldedit) that included all functionality mentioned here (and full online documentation of all accessible pops and functions by added jass code inside the maps). The vast amount of easy to add custom content (indeed it was automatically downloaded when joining a game) kept the game 'new' up to this day (released 2002). The community is still huge though the majority plays custom maps like DotA rather than using the original game content like in melee maps. However, that made it mappers heaven BTW: The 'factions' was not defined directly at all. It simply depended on the starting units you had. In 0AD it seams to be a mix of both: There are civilizations defined but if you get your hands on an enemy worker you can build all their things as well. Seems redundant to me. I just think 0AD deserves to get really popular and stay it for a long time!

I added a ticket: http://trac.wildfire...com/ticket/1311 That fixes the bug in the random map fortress: rm_fortress.jpg I also added a demo map as a code example for wall placement in random maps: rm_wall_demo.jpg

After a total rewrite and many changes a screen-shot of the new wall_demo random map that should provide code examples of how to use wall_builder.js rmgen. Changes: - Added easy to use placeLinearWall(startX, startY, targetX, targetY) function. It can be set more accurate by optional arguments (wallPart, style, playerId, endWithFirst). - Added easy to use placeCircularWall(centerX, centerY, radius) function. It can be set more accurate by optional arguments (wallPart, style, playerId, orientation, maxAngle, angleOff). - Set everything up to the changed random map object placement. - Adjusted celtic and iberian walls. - Removed the wallTool class that held all the information. That means some functions take more arguments but most of them are optional. - Added and rewrote documentation. - Wrote a wall_demo random map as a code example for most cases the wall tool will likely be used.

Hi and welcome. I like the idea of heaving a cover, too. I'm not the right person to ask for publishing or representative issues in general so don't take me to serious here. But since the game suppose to be historical correct I thought I'd add some comments: - 'In the spring of the world...': If 'world' means something like 'existence' or 'universe' it would correspond to the big bang and (as far as we know) that was about 13.75 billion years ago (If you prefer creationism it still was at least 2000 BC depending on culture and believe). If it means the planet 'earth' it was about 4.54 billion years ago. If it means 'homo sapiens' it was 200.000 years ago. If it means the first high culture it would still be 3000+ BC. -'...the dawn of history': Similar to the above. Historic records was found from 2000+ BC AFAIK. -'You must prove which civilization is the greatest of all.': What is 'proven' by playing a game? All civilizations in the game are history and gone so why 'is'? ...but I have to admit: it sounds nice

For scenarios (simple maps), random maps scripts (random maps) and random map libraries (rmgen libs) this topic might help for windows but it's for the svn version. For alpha 9 just replace 'Local' with 'Roaming' in the paths starting with 'C:\' and replace [username] with your windows account name. To see the 'AppData' folder you have to turn on showing hidden files and folders in the windows explorer. I agree that it could be mentioned somewhere more obvious.

To keep compatible with the svn version deep_forest2012-4-6.zip EDIT: A new version was added to the svn, thx quantumstate!

Very nice!

Oh, quantumstate was faster

The folder from which custom random maps and scenarios are loaded changed in a recent svn patch: Now it is (in windows) for - Scenarios: %localappdata%/0ad\cache\mods\public\maps\scenarios or C:\Users\[username]\AppData\Local\0ad\cache\mods\public\maps\scenarios - Random map scripts %localappdata%/0ad\cache\mods\public\maps\random or C:\Users\[username]\AppData\Local\0ad\cache\mods\public\maps\random - Random map script librarys %localappdata%/0ad\cache\mods\public\maps\random\rmgen or C:\Users\[username]\AppData\Local\0ad\cache\mods\public\maps\random\rmgen Some files of the folder "C:\Users\[username]\AppData\Roaming\0ad" are not longer of any use and can be deleted though it is not done by default. The log directory changed from 'roaming' to 'local' too for example... This is for sure better than risk deleting custom content but I would like to know which files/folders are no longer needed (so I can delete them manually) I found it nowhere in the forum so I thought I'd tell it here...

You don't need the ships fully manned. The firepower doesn't depend on men in it (yet?) as far as I know. That means they only take 10 population.

Welcome to the 0ad forum. Your report seams to be the known issue posted in this topic as it says: 'Lag The game does not run as fast as we would like. Late in the game you will probably experience some lag, this is caused by a mixture of things, AI and pathfinding are big ones. One thing that can be helpful is giving us the profiler information, if you hit Shift-F11 this will be dumped into a file (location given at the top of the screen), the contents of which are useful for working out where the lag is coming from so please upload.' Maybe more hardware related information will be posted by other's more into it. As fare as I know multi core threading is not widely available throughout the games functionality.

You mean the 'normal' wall, the siege wall or the non-civ-specific palisades? Romans in the wall tool has the normal wall that is quite the same as for carthagians, helenes and persians. I don't really know what you mean by 'system of tramps'. Falling debris damaging the units around? I should improve my english x)

In general I like the normal, 'simple' solution with structural points/health, attack and armor. A 'chance to hit' for ranged units can be added by checking if the tile that is passed by an projectile contains a unit that has at least the hight of the actual projectiles hight. That way a mounted unit may be hit more often than a foot soldier. There might also be a chance to be hit smaller then 1 (100%) for smaller or more agile units. That would represent luck and avoidance though avoiding an arrow for example is quite impossible when you are in a battle facing an enemy in melee combat. A chance to block may be added depending on the equipment. Peasants and archers have no close combat weapon or shield so they have 0 chance to block anything (though they may have a little higher chance to avoid attacks like 10%). Units carrying close combat weapons like swords, clubs/maces or axes may have a chance to block melee attacks of 10%. Swords are indeed designed to block melee attacks and so may have even 20%. Shields are designed to block both, melee and ranged attacks so they could give lets say 30% chance to block melee and 20% chance to block non-siege ranged attack. Units wearing spears or polearms could deal higher charge damage instead. Javelins get the bonus for the shield if present and can use their weapon for both, ranged and melee attacks, but don't get a block chance for their weapon. The reason why I like the 'normal' system is that something like blocking/evading can be added by simple mechanisms that are understandable for the player and can be displayed to him properly and consistent. A short list of example equipment with block modifier for the more detailed part below: - Helm, chest/leg/other Armor: Adds armor as it is now, no block (perhaps lower chance of evade but evade is not that important IMO as stated above) - Sword/saber: ~20% chance to block melee attacks (melee block 2) and of cause enables the unit to deal damage (as it is now) - Club/Mace/Axe: ~10% chance to block melee attacks (melee block 1) and of cause enables the unit to deal damage (as it is now, perhaps a little higher to balance the block) - Javelin: No block, grants an ranged and melee attack (as it is now), can hold a shield as well. - Spears or other two-handed weapons: No block, enables the unit to attack at melee range and deals high (charge) damage. Some of them may be able to attack above 1 tile. Since such a unit can't hold a shield it has no block at all. Those units should get attack bonus versus cavalry IMO. - Shield: ~30% chance to block melee (melee block 3) and ~20% chance to block ranged (ranged block 2) but adds no armor! Block values may differ type dependent. - Bow/arrow: No block, for balance reason (and realism) they may get higher range. Getting more detailed: In the code it may be useful to work with exponential functions to make sure no unit has 0 chance to hit a specific other unit. The chance to hit can be then calculated by 0.9^n where n is the sum of all 'melee/ranged block' values of the targeted units equipment. If a unit for example has a sword and a shield (somehow the maximum block to get) it has a chance to get hit in melee combat of 0.9^5 = 0.59049 and in ranged 0.9^2 = 0.81. The rounded values than can be shown in the gui: 41% chance to block melee (1 - 0.9^5 = 0.40951) 19% chance to block ranged (1 - 0.9^2 = 0.19) This hast the additional advantage that moders may add raising block values and the chance to get hit will never reach 0. With an attack/defense value system the chance to hit/get hit/block depends on the pair of units fighting and so cannot be displayed directly. Instead some values are displayed that doesn't tell the player much about the strength of the unit when he doesn't know the formula (and even then he will rather know due to gathered experience then actual calculation). To randomize attack damage units could have a minimum and a maximum damage and the actual damage is randomly chosen out of this range. Indeed only a maximum damage would do (and actual damage = random number between 0 and the maximum damage). As it is now is the armor just the value subtracted by the incoming attacks damage? Because that has to be kept in mind when randomizing damage. IMO an attacked unit should at least loose 1 health/structure point if hit.

Here's the next version. Get the rmgen script 'library.js' from the SVN repository for Alpha 9 (actual version in the download). Here the overview or take a closer look And here's the download: deep_forest2012-3-23.zip

1: Oh, yes, my hills (renamed them to general hight map, I guess that's what you mean). That is not really finalized and could be added to a lib as well if finished. Indeed they cause bugs when changing the order in which paths and hills are placed. May be the reason for the strange acting SmoothElevationPainter. Somehow forgot about them ^^ 2: Hm, not so good. Maybe it's worth a clean up mission. Using paintClass() to add areas to classes works well, by the way.