FeXoR

That would be very helpful (adding template information to rmgen). But that's not what I meant. If it is possible to change the games behavior with triggers it should be possible with RMS as well. The code would not even have to be called during the rmgen interpretation but a "trigger code string" would need to be stored with the map (though common editors highlighting will not be amused about a "string of code", well, but there has to be better ways about as simple ^^).

And someone could add code in there instead of using the GUI? It's good to have a GUI to keep the barrier of entry low. But I like scripting. BTW: I meant more like a working code example and where to add it to the map and where to add the trigger implementation needed for that (the thing that is manipulated is not the matter, I only want to understand how you want to manipulate simulations at a specific point in the game by something written in the map file). Than triggers are given to the map generated by rmgen "exportMap()" as well and then manipulating the game in simulations?

Sounds good. I would like to add "triggeringEntity" to the returned values:The ID of the entity that activated the trigger. If needed that way another check could be done e.g. for the units type, it's state or other properties like it's actual health. Another thing is that the code for triggers would have to be part of a map but is not to be executed when the map is loaded but - when a trigger fires - "something" has to check if the map has code to be called matching that trigger event.

The maps/RMS would need access to simulation. But as it is now RMS are run before simulation is started. For "normal" maps, as I said, I'm not sure. But how would I write one with an editor (so I could add trigger scripts)? Not another, the only one. Python is supported by any OS officially supported by 0 A.D. (Added native Windows support in the next version). And Python would not need something like SpiderMonkey at all AFAIK (Just a file to wrap the needed C++ functions to Python and import them wherever you like - Well maybe ctypes/boost is something like SpiderMonkey x) ). You will always have to punch a hole in the engine to allow scripting whatever language you choose. SpiderMonkey for Javascript. If you don't like it it's another reason to think about changing the used scripting language. But since the development has made it that far it's perhaps a matter to live with. Generating random maps before simulation starts, however, is a concept flaw. That way simulations and RMS can never work with each other without some hacky stuff. Could you give me an example how I would add a new unit type to be able to build in a building of a given type on a specific map (Just so I understand better how that would work)?

I'm not sure if we all have the same understanding of triggers. For me the following thing should be possible in javascript e.g. added to a random map: A trigger should consist of an even, likely a string like "aUnitDealsDamage", a condition (not required IMO but this is how it's mostly done) like (unitTypeOf(damagedUnit) == "units/athen_infantry_spearman"), and the code that is executed when this trigger event happens and the condition is true. To enable trigger events nearly every game relevant function in the game (for the example the function handling damage dealing) engine has to be extended by adding the event calls. To enable helpful conditions some variables (like "damagedUnit") has to be stored before the trigger event calls all the functions added to this type of event on the javascript side. That variables has to be accessible by the javascript side for the later called code. The code evaluated after the trigger event took place and the condition was true has to do things with the engine again (like setMaxHitpointsOfUnit(damagedUnit, 2*getMaxHitpointsOfUnit(damagedUnit)) or something like that). I know this example is stupid. The result would be: If a athen infantry spearman is attack his maximum life is set to twice the maximum life it had before the attack (not the actual hitpoints, so it still might die by the attack). That would simulate that units get tougher by having combat experience. But as it is this is done by ranks (which is OK but badly interferes with the unit type for triggers (if just taken from the actual template name) as the unit type string differs dependent of it's rank like "athen_infantry_spearman_b" or "athen_infantry_spearman_c"). I don't see why this should be a small amount of work. I strongly suggest to start ASAP because this feature is so powerful and many things otherwise done ugly (like with mods) and about the same time-consuming to implement can then all be done in the map it's wanted for without interfering with the other maps. For random maps it would be just part of the random map code (that would then be evaluated during game time though, quite a lot of work as well). I don't know how fixed maps are loaded/to edit with an text editor but I doubt it would be easy for them as well.. BTW: When adding triggers it would be a good point to think about the used srcipting language. I'd personally prefer Python. P.S.: My girlfriend said it as: "Powerful triggers for computer games equals life extending potions for the joy gained by playing them!". I can only say: THX!

I was referring to triggers like in Warcraft 3. That's hell a lot more powerful and easy to work with than AoK triggers. Changing unit stats should be able with triggers, too. That's why I mentioned several times in the past that triggers are so important. They have to be implemented well, powerful and make mods (which tend to be untidy) totally unneeded.

"Im Deutschen Kulturrat haben sich die Verbände der Künstler, der Kultureinrichtungen, der Kulturvereine und der Kulturwirtschaft aller künstlerischen Sparten zusammengeschlossen." Translation: "In the "Kulturrat" artist organizations, cultural facilities, cultural clubs/societies and members of the cultural industry are gathered." The "Kulturrat" has an advisory function to the government. As far as I can tell it's quite neutral in the sense of "not dominated by one faction" e.g. the industry side. However, they have no authority to legislate or judge directly in any sense.

I would do this if we had triggers, dut they are dropped to part 2. So until we have triggers (and such maps got easy to make) I think it's not worth the effort. So the wise order to do things are 1st implement triggers, then make such awesome maps (Not only this ofc. ^^).

That would be this: misc.zip misc.js.diff That does: As long as the map does NOT explicitly set the defenses to add for Iberians it adds nothing in tiny maps and walls on non-tiny maps. Explicitly setting Iberians defenses to "walls" overrides the default and so walls will be place for any Iberian player on any map size. Example to override default behavior: placeCivDefaultEntities(x, y, playerId, BUILDING_ANGlE, {"iberWall": "walls"}); I think that is best. EDIT: I should add the abiltiy to set the radius of the defenses, too. In the map "Snowflake Searocks" for example the radius is to big. That way RMS designers could tweak the iberian walls better. Please let me know when/if the patch is added, Spahbod, so I can add that functionality. THX. EDIT2: While you're at it could you please fix the typo I mentioned in http://www.wildfireg...=60#entry257116 Oh!, Already fixed, thx!

The wall outside the map will slowly fall apart (because the territory border is not expanded beyonf the map border). This is a know issue and I put (untested code) for this (removes all objects outside the map border) here: http://www.wildfireg...=40#entry254333 (See the spoiler) A better way IMO would be to just not place the civ default walls for Iberians on maps that don't grand space for it (by the map designer).

I got: ATI Radeon Xpress 1250 AFAIK not concerned by this.

I totally agree. But the bad thing is... we're not alone ^^.

Well, with a comment like: "We value the needs of the victims of Nazism. For those here's the option to turn all content that may be in some brains related to that off." It would at least follow the mind of the law in Germany ^^. Still I doubt it would be "bulletproof" in a court.

I fear the svastika is indeed a legal issue in Germany (and may be in other states of central Europe like e.g Austria). In the best case the usage will only result in bad publicity (despite there is such thing). This could at least be used as a legitimate count of an indictment in Germany (which should be avoided in any case). As I said before for me it's not that important but the bad publicity is a valid reason for me as well. Just keep in mind that some Jews/Germans get sick just on sight of that symbol.

OK, just wanted to tell and if it could just be flipped easily it would not be to much work. It would be still a historically correct svastika and would differ more from that of Nazism. But if it is to much trouble and work I'm OK with it.

This thread is meant for discussing the following controversial questions, all pertaining the visual portrayal of the Mauryan civ in 0 A.D.: Will we use Hindu swastikas in 0 A.D.? Will we portray Mauryan warrior women with exposed breasts or with covered breasts? How will we decide on these topics? I will be moving posts pertaining these questions from another thread to this thread. These are very emotionally charged topics and opinions differ strongly. Still, let's do our best to keep this discussion civil, as it has been so far. Aviv / Jeru ----- I noticed the "Swastika" on the shields. I personally don't really mind (since such symbols where widely used in history and still are) but some Jews and/or Germans might since it was also the symbol of Nazism. Would it be possible to at least use left bended Swastika or is it known that Mauryans only/mostly use right bended ones?

True and it's buggy on tiny maps with 4+ Players, small maps with 6+ Players and even on medium maps with 8 players: But for reasonable map size to player ratio it's quite OK: The problem that maps don't work properly/are quite unplayable with to many players on to small maps is quite common for random maps. My main concern is that most parts of the wall are to simple IMO. So if anyone has cool ideas plz let me know. ATM I'm thinking of adding palisades in front of the main walls... BTW: I found a typo in wall_builder.js. Replace: wallStyles[style]["defenseTower"] = new WallElement("defenseTower", "structures/" + civ + "_defenseTower", PI, 0, -4*wallScaleByType[style]); with: wallStyles[style]["defenseTower"] = new WallElement("defenseTower", "structures/" + civ + "_defense_tower", PI, 0, -4*wallScaleByType[style]); ("_defenseTower" -> "_defense_tower") It doesn't effect the official maps but raises an error if that wall element is used in other maps. It would be nice if you could fix that, Spahbod. A side note: It feels like the tower upgrade that adds twice the number of arrows for each garrisoned unit is overpowered. Maybe scale it to 1 + ceil(1.5 * numberOfGarrisonedUnits) arrows? That way a tower garrisoned with 5 units (capable of adding arrows to the tower) would have 9 arrows which seams enough (compared to 11 arrow as is now or 7 arrows with the other tower upgrade). So ungarrisoned towers would have more arrows with the other tower upgrade while towers garrisoned with 3 to 5 units have more arrows with the upgrade in question (towers with 1 or 2 garrisoned units would have the same amount of arrows despite the upgrade chosen).

I want to make a random siege map. This is as far as I got today: siege2012-12-3.zip It would be nice to have cool concepts for the walls. Until now only the area around the main gate are somehow special. Any input very welcome.

In case I ever do or did anything art related for this wonderful game 0 A.D. I hereby declare: I am the copyright holder of original works I post in the Wildfire Games 0 A.D. Art Development forum. I hereby release all original works I uploaded to this forum in the past, and those I will upload in the future, under the Creative CommonsAttribution-Share Alike 3.0 Unported license.

Wall placement was improved as well.

I think ribez is right, me too can only see the top part of the picture. Perhaps it stopped uploading from your PC for some reason. Converting it to JPEG would make it much smaller as an option. Like quantumstate asked before it would be nice to have a link to the code itself since this is the most interesting thing in this topic (at least for me).

(I don't have permissions to see the old thread you linked to) I like unit build buttons being easy to recognize and to notice the connection between the button icon and the actually trained unit in-game. I don't know how high quality the portraits are but maybe they could be added an encyclopedia (like is planed AFAIK)?

I agree! I just wanted to tell that I "don't see" a way to make it work well especially in the cases it is meant for. I personally find it very frustrating to put quite some work in something just to see it's not added. If I where aware of the possibility that and a concrete reason why my work would NOT be added I could at least mentally prepare for that disappointment. By telling this I want to avoid the big frustration of the contributor in the end though that might mean I discourage him a bit in the first place. In many cases I changed my approach (or chose it in the first place because of discussions befor I started the work or even totally abandoned a "feature") because someone else told me about the problems that may arise with an other approach previously preferred by me. So at least I for myself find comments to things I'm working on very helpful especially if they unveil problems/issues/flaws I didn't see before. I hope my words where not to rude. I'm quite sure I'm not best at that . (I admire feneur for his ability to say things straight while staying kind )

Indeed an awesome Project.

Yes, it would be nice to have working terrain flattening (for me because it's more realistic and alters the hightmap ingame what I find interesting). But as I said in the ticket its a very bad thing to fix a visual inconvenience by adding a gameplay issue (especially if more code is needed for that). For me it feels like making the game worse by adding code - a very questionable way to go . Many gameplay features planned for the game at the beginning are not working out yet (at least for me) like formations and stances. That doesn't mean we should abandon them totally but perhaps make them "optional" until they really work out or focus on things driving the game towards beta stage which may include dropping additional things from Part 1 and delay them to Part 2 (like for me advanced naval combat). In the first place 0A.D. is a game and the first priority of a game should be to work and make fun. Even better if it doesn't annoy the player with it's behavior (otherwise it's less fun I guess ^^). For me it's much easier to accept inconveniences that occur because something is simple but I really hate things that "try to do it awesome" but in fact make it worse (for me in 0A.D. the non-descrete building placement would be such a thing). I noticed that most community members most of the time prefer the "awesome looking" way without having a good solution at their disposal or (even better) a patch to test it. I don't know if all of the community members are aware of this, but adding all this awesome stuff needs time and delays getting to Beta phase longer. I don't say that 0A.D. is not working. Indeed it works quite fine. But there are some very basic (gameplay) features not working well like the unit AI (at least for me) or pathfinding (which is worked hard on AFAIK). Other features vital to an modern RTS game like "attack-move" are not at all implemented, yet. So there's already enough work to do and adding "cool stuff" that will raise other complications (and for terrain flattening it's quite clear it will: On steep terrain the edges of the flattened part will get more steep) should be thoroughly thought trough before adding it as the default. Additionally it may effect the pathfinder as well (because it might also change the walkable terrain when applied to steep ground - the case it's meant for ) - another piece of code complicated enough already. As a conclusion I'd say: thomasf: If you think you can make it work without much pain go for it as long as you keep in mind it may not be seen as the best solution in the end and so might not be added (I have to say for myself I don't see an approach working well in most cases that really fixes the issue but perhaps you do). For the building foundations: I think in any case it would be good to have foundations reaching far into the ground. More natural looking foundations might be nice. This should be added to all new work while step by step adding this to the existing models as the art team sees fit. For the Hellenic Civil Centre I gave a working solution in the ticket: http://trac.wildfire...t/21#comment:10 With a natural looking foundation it would work and look well IMO.