FeXoR

Looks a bit long-winded to use but I'll give it a try. Don't have much time right now though.

Well, I could add further trees/group of trees on the mid level terrain (Grass without interactive entities but the starting entities) at the end of map generation. Since it was requested before I'm.willing to add those. For terrain flattening: The problem is that the players are placed on mid level ground (Grass) and close to both, low ground (Bog with Stone/Metal) and high ground (Woods with trees/berry bushes/deer) to have access to at least some of each resource type. That means the start locations are placed on the side of a hill with a high rate of incline. Flattening it beneath the Civil Centre will lead to a higher rate of incline towards low/high ground. So that's not suitable IMO. I somehow agree but I think the map description pretty much makes clear that this map is not a "standard" map. Any suggestions how to make the description more meaningful very welcome!

Spahbod: Good job! Have you seen this?: http://www.wildfireg...=60#entry257300 It does not seam to be added though you seam to want it ^^.

By klicking the "garrison" button when (non-siege and for some buildings non-mounted) units are selected and then left-click on a "garrisonable" building (Civil Centre, Barracks, Temple, Wall Towers, Defense Towers, Fortresses/Army Camps and in a lesser extend Outposts) the units will go "into" the building untill its "full". Depending on the building units inside it grands bonuses: Civil Centres, Wall Towers, Defense Towers, Fortresses/Army Camps and Outposts get additional "attacks" by garrisoned (non-mounted soldier) units. Units garrisoned inside a Temple and (in a lesser extend) inside a Fortress(or Army Camp, not sure here) regenerate health. You can "ungarrison" the troops again if you like.

I think defensive structures are available to late in the game so that rushing is always possible before walls are available. And if walls are available siege units are also at the same time (well OK after building the needed building to produce them). In addition I find walls quite useless due to the lack of the wall towers range. It would be enough if they don't get the bonus like defense towers (one more arrow/2 arrows per garrisoned soldiers) but still have a "normal" range like archers have. Defense towers could then have a higher range due to the higher position of the projectiles start of flight. On the other hand citizen soldiers are overpowered due to their ability to build up their own economy. So massing cittizen soldiers will always led to a dominance in sense of the armies size. Even though elite units may be stonger they can't make up for the exponential strngth gain by punping citizen soldiers.

Ah, just to say it: It is historically (and actually) incorrect that trading generates resources. Gathering stuff and forming stuff to more complex stuff (and inventing new even more complex stuff) raises the total amount of "value" compared to the time before (but not resources and even lowers the amount of gold, that goes to the trader). Trading only raises the variety of stuff available in the trade partners societies (and grands the trader itself wealth). That might be seen as a higher value for the quality of living but it doesn't raise the amount of resources in any of the trade partners economy or globally.

First: Acropolis is a scenario, not a random map so I don't touch it and this thread is about random maps. Perhaps Aegis Bot can handle adding gates to walls/closing walls? Not sure. Have you tried to play it with the Iberian player in question being Aegis Bot? That the walls can's be closed/closed only with short/medium wall segments is indeed bad. EDIT: I've tested it and indeed the bottom entrance can only be closed by a medium wall part directly. The top entrance can't be closed directly because some areas along the line is to step to build there. However, you can build indirectly (with a corner) and so ensure a long wall part on both entrances. I agree though that the gaps should be made so that closing the walls lead to a long wall part so gates are possible.

True. But isn't it a bigger mess if we need to write the same functions several times and maybe all acting differently? E.g. wall towers placed ingame will always face the same side than one of the appending walls. In RMGEN that's not always the case (as you can see for Iberian civ bonus walls). Still both have to be compatible (They are AFAIK). You say: "keep the name-space small" I say "keep the name-space unique" like e.g. calling every events TE_BlaBlub etc. Then use the triggers to make random map libraries called like RM_wall_builder.js or something and import them wherever you like. That way collisions can be avoided commonly. Even if you got a function called getEntity() in several libs you can import them save. Darn, it's not Python! Bad, bad... still you could name them unique as mentioned above. You could also bundle the libs in associative arrays/dictionaries when importing them (like Python does) and run each property of the dictionary after import. Ugly as well... (The darn editor messes around with my pasted text and newlines again! Could anyone fix that???) EDIT: I think in the end stands the decision how restrictive we whant to be. I don't like encapsulating and restriction. I'm aware of the problems arising with it from harder to debug scripts to the mentioned name-space problem as well as its harder to keep the overview over one big area of code. And I think it IS an argument that you can hack anyway in an open source game relatively easy. That means you have to grand the scripting community at least some trust. And I hope the "bad" maps/AIs/whatever will be sorted out by the community as well so it's a dynamic social process to keep things clean. As said before I think for now we will not go this ways (making AIs/RMS based on triggers) anyway so we don't need to focus on that. But Triggers should be as close to the engine as possible to be powerful and fast. In general I forgot something about triggers. They can be active or inactive at the beginning meaning they will be checked at event occurrence or not. The can also be "repeated" or "single shot" while the first will stay active after it fired and the second will turn itself off if fired. It then can be turned on/off again by other triggers actions.

Yes, It would be indeed a good Idea to warn the player if the map contains triggers (perhaps only those containing specific action types?). But in the end you can't make powerful triggers without security issues I think.

In WC3 there are e.g. the trigger event "generic unit event" just saying "a unit [action]". The action could e.g an action or "state change" like "attacks" or "gets attacked" or "dies" or "returns resources" or something. Then (for that specific trigger) some variables where set like "triggering unit" or "attacking unit" (if the units action was "attacks" both are the same but they get also set if the units action was "gets attacked"). So you could use those variables for e.g. the condition. You could set own variables and conversion functions where available like intToString(playerNumberOf(ownerOf(pickedUnit))) or something. It's hard to explain because it was mainly a programming language itself: http://en.wikipedia.org/wiki/JASS Here's an example of a function that sets the start locations for players on a random map I've written (and the triggers where never "meant" to be able to do that): NOTE: I got the German version so some words may be in German (Most parts where not translated though, Auslöser = trigger, Ereigniss = event, Bedingungen = condition, Aktionen = action(s)). NOTE: The trigger is NOT called by an event but from another trigger Since the post editor refuses to allow indentation here's a text file and a screen-shot as well as the entire map (not sure how playable it is, it's an older version): Screen-shot: Text (not code!): Trigger Example WC3 - RMG - Place Start Locations.txt As code: (12)FEXOR - RandomMap 2010-6-4 - Triggers.txt Entire WC3 random map: (12)FEXOR - RandomMap 2010-6-4.zip So to say it short: You could do close to everything (The minimap refuses to get updated if you change the terrain). If a function missed you could just convert the trigger in question to a script (like above the "(12)FEXOR - RandomMap 2010-6-4 - Triggers.txt") and add the function you need. Here's the documentation of what triggers can manipulate in the engine: [still searching for it...] More information can be found: http://jass.sourceforge.net/doc/ http://www.wc3jass.c...page/Main_Page/ In AoK/AoC you could only add some types of variables and there where no type conversion functionality. That and the fact that no generic events like "a unit ..." could be used (and so somehow "pick" that unit and do something with it in the action) the possibilities where very limited (I not even managed to get a tower defense map to work properly). Instead only specific unit events could be used like a unit already placed in the map and named could be selected and then used for a trigger. Or any unit could activate the trigger but in the condition/action it was impossible to manipulate this unit because it was not stored.

Indeed. You look at it from a more "human" perspective. That speaks highly of you

Well, if I talk of triggers I mean really powerful stuff like in Warcraft 3 (as said before). You couldn't do much with e.g. AoK/AoC Map editor triggers.

Warning, off topic: I got 7 x) Windows Data Secondary: - Ubuntu - darn Small Linux - Old Kubuntu (with KDE2, just great) - A random test linux distribution Linux Swap

Hi and welcome to the forum. On the new web-page the installations available for Linux can be found at the download-page at the bottom that send you here: http://play0ad.com/download/linux/ If you have installed 0 A.D. with your distributions default repositories it may take a while until it's updated to Alpha 12. It may help to know what distribution you are using to give you more specific information.

Are you talking to me? I had the intention to make it more calm and maybe rational. If I failed, I'll stop trying ^^ (without being offended, I had my fun).

I couldn't find any sign of "holocaust denial" in this thread. Such accusations are not helpful. (If I missed something please specify where you see "holocaust denial"). I'm not so sure. It mainly seams to be the German point of view. And they are a minority - as every other nations population. Yes, 0 A.D. should live with the consequences. But it's just not a Nazi symbol - at least not exclusively. So why leave this symbol to them? I don't want to give them anything, not even my attention - until I meet one in a bar telling stupid stuff: Then I tell him he's telling stupid stuff. But even telling stupid stuff is not a "Nazi property" ^^. There's a huge difference between an effect and a goal. That's your rightful decision.

To make triggers powerful all those functions have to work. Here are some examples for all used functions in the cheat - but this time ones making sense: (TE: Trigger Event, TC: Trigger Condition, TA: Trigger Action): TE: playerEntersChatString("-stats"), TC: true, TA: showPlayerBoard("kills", "losses") TE: playerEntersChatString("-stats"), TC: getPlayerType(chattingPlayer) == "observer", TA: showPlayerBoard("kills", "losses", "food", "lumber", "stone", "mettal", "population", "populationCapActual") An example for a king of the hill scenario: TE: turnEnds(); TC: endingTurn % 100 == 0, TE: givePlayerResources(getVariable("kingOfTheHill"), 1)) TE: unitEntersArea("hill"), TC: getPlayerType(getOwnerOf(enteringUnit)) == "activePlayer", TA: setVariable("kingOfTheHill", getOwnerOf(enteringUnit))

It's an open source game. How would you prevent someone from hacking? OK, games will get "out of sync". But I'm sure it's relatively easy to cheat/hack anyway. BTW: That means that you fear a scenario may include some cheats? I can't really think you would not play a scenario because of this ^^. It may include: Trigger event: playerEntersChatString("Hiho") Trigger condition: chattingPlayer == getPlayerIdByName("FeXoR") Trigger action: GivePlayerResources(getPlayerIdByName("FeXoR"), 1000000) How do you want to avoid this? Though since it's a script it will be easy to find such hacks. But I think the best way to go here is trust ^^.

I mainly agree. But this is what I meant in this thread: http://www.wildfireg...showtopic=16828 Some people might feel offended by that. Even if not rational - well I guess we as humans can't be entirely rational anyway - I think it is a valid argument to drop it. As I said it'd be a waste of artwork done - and that's a shame - but I think it is a good thing to respect someones feeling. If it seams irrational its a good thing to tell this person that you see it this way also. But in the end it would be nice to let the more "emotional" point of view have their way so that none feels bad (as long this person didn't cross other persons borders along the way - what might have happened in this post). And I fear he's not alone with his strong feelings. I'm from Germany too and know how it is. Seeing a swastika feels similar to an electronic shock ^^.

Yes, but the functions used to edit e.g. the GUI so that if a button is clicked something happens could use triggers as well. If you have a scenario with several options to chose in-game you need the same functionality. But as is now everything (that can be scripted) has its own scripting environment (simulation, AI, Atlas, RMS, Civilization/Unit/Mod/Game-rules definition). And every function needed in more than one of them is duplicated. Maybe I'm missing something. If you see what this is please let me know.

That's why I think in the end having triggers implemented and used for the map editor, player interaction, random maps and AIs would be the cleaner design. That way you'd only need the trigger layer to access the engine and have the other parts use those functions. But I don't really get what simulation includes so I'm not entirely sure. But for now I should set my sights lower and be content with working triggers

How do you plan to implement the action? It should be possible to write a javascript function and give it to the trigger as an effect without running the given function at initialization. When the trigger event happens and the trigger conditions are true the function could then be run. I don't know how this should work but I think that would be best. I'd like to help but until I have an example for a working trigger I'm staying out of the C++ part since I don't have much experience there. If I have an example trigger (and maybe a list of wanted trigger events/conditions/actions) I'd like to help. I cannot access the link. Would it be possible to allow me the access (or make it public)? BTW: Are triggers officially wanted (now) or will this be a community project that, if working well, might then be added to the main game?

Hi! I hope I can help. Scenario: - Place at least a civil centre (can be chosen and then placed in "entities -> structures/[civ]_civil_centre") of the used civilization (can be set in "Player") for each player. Random map script: - Use "placeCivDefaultEntities([X-coordinate of the players start position], [Y-coordinate of the players start position], [Player ID, 0 for gaia (the player who owns all non-player entities), 1 for the first player and so on], [building placement angle, should be -PI/4]);" for each player. Additionally you would at least have to place some resources of each type (food animals like pigs, food vegetables like berry bushes, wood sources like trees and some of the bushed, Stone and metal) somewhere on the map to make AIs capable of playing this map. The resources need to be placed for player "gaia".

ONLY the stats effect my in-game decision. I hate not being able to see unit stats. That doesn't mean they have have to be seen in the tooltip of the build icon or the unit itself but they have to be available during play for that version of the game you actually play. So a tech tree including all stats (or even a list of units/buildings sorted by civ, but I don't really like that) would do as long as the stat values are linked to the values in the templates and the information are available in-game. A web page for example would not do because it would not be linked to the values of the templates the player is playing right now. Making an unlinked (to the template stat values) ""help article" would be bad too, because it would have to be updated every time any stat changes (e.g. for balancing reasons). So the accurate values of all useful stats (maybe not e.g. how long an attack animation lasts before the hit actually takes place for example) should be available during the game and if any value changes (e.g. by triggers/updates etc.) they should be automatically updated wherever they are shown (separated in base value and upgrades at least). To use colors for bonuses is a good idea IMO.

At first glance it looks like hoke...