FeXoR
-
Posts
1.426 -
Joined
-
Last visited
-
Days Won
28
Posts posted by FeXoR
-
-
Is there a particular reason why the Iberians in Acropolis 7 (the southern acropolis) don't get any gates, when the Iberians in Acropolis 2 (the northern acropolis) get gates? In Acropolis 7, the southern ramp can be walled off but the wall segment is too short to support a gate, while the northern ramp can't even be walled off without rebuilding the walls. Also, the default AI in Acropolis 7 is Aegis Bot when at least most of the other maps have qbot as the default AI instead.
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.
-
I see. But none of that really implies throwing all scripts into a big hodgepodge like suggested above. We can make one trigger API into the UI and another one into the simulation, without compromising their separation on non-trigger maps.
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).
It's not just about security, it's about integrity. What if two different scripts both define an object named 'MyObject' in the same scripting environment? You get some kind of collision, and one of the scripts break. These issues can be avoided by running separate things in separate environments.
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.
-
nope i understand but he is very angry, and he don't thinking about he says.
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.
-
Lock this Topic. this discuss it now insane and irrational
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).
-
First: I think it's a matter of politeness to answer somebody that opens up the discussion again and expects an answer, so, after checking in again, I saw two answers and chose to post back. And so it went on, since people obviously feel they need to persuade me into some kind of holocaust denial, because they chose to ignore modern history.
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 consider this sick - since it's the majority that thinks so,
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.
Third thing: As I said, if you think, using Nazi symbols is a necessary feature of the game, use it - but don't complain if people feel offended by it.
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" ^^.
If your goal is to offend people, go on!
There's a huge difference between an effect and a goal.
This is the very last post now, don't expect any further answers.
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))
-
As far as I know, Atlas does not rely on scripting at all - it's written in C++. As for simulation, AI and RMS, those need to be separate - if I download an RMS someone made, I don't want to have to worry that it might be hacking the simulation to give my opponent an unfair advantage, for instance.
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'm sorry that you have difficulty separating yourself from the negative association, but Michael's right about this. There's no link between the two. In fact, Hitler chose to flip the swastika and tilt it ironically because the Nazi party was the antithesis of peace. If, because of this, you can't look at a Hindu swastika without being reminded, I pity you. No one is trying to force you to contribute, we're just saying that you're being irrational. None of us are saying that it wasn't a crime to kill jews - we're just saying you're misinterpreting this whole thing.
To suggest that we did this intentionally to spread Nazi propaganda is beyond me. That's possibly the most absurd accusation I've ever heard made of 0 A.D. I'm sorry you feel this way, and we're sad to see you go, but at least recognize that we're not at fault.
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 ^^.
-
1
-
-
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.
If it's helpful, I found a really old thread that contains some of CheeZy's wisdom on triggers and a list of proposed effects/conditions: http://www.wildfireg...?showtopic=7274
Good to see that you're making progress on this! (Even if I don't have any idea what you're saying
)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".
-
I found the tooltips to be quite confusing as a new player, they're also pretty huge; so much blank space!
The information which is of most use is definitely the cost, followed by counters/is countered by.
Stats are only of use to more experienced players, and we can possibly assume that a)they're not going to factor in in-game decision making, and b)experienced players won't need things spelt out for them.
[...]
Grouping unit costs with the name allows new players to instantly see unit cost without spending precious seconds searching around the tooltip. 'Cost' marker is not needed as it's quite obvious when we have the icons, and stops the tooltip looking like a long list of stats
Huge bit of blank space follows health. Armour is also a defensive stat so no reason they can't be shared. Hack pierce and crush will mean nothing to new players; who are better off looking at the counter/countered by section, so might aswell save the space and group them together.
"Ranged attack" is too long. I think everybody knows that archers have ranged attacks. Unless there are plans for 2 types of attack by archers in the future?
As a new player, I'm not sure of diff. in-game between walk and run, and even if I did, it wouldn't factor in my in-game decision making.
Finally, counters and countered by is very wordy. A plus and minus, accompanied with red and green font does the same job much clearer.
"vs." takes up too much space, and seperates the information too much; making it unclear.
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...
-
I don't think triggers should have anything to do with random maps, unless you are creating a random interactive scenario... Otherwise, if the random map generator needs to know something about entities before it places them, we just add entity template parsing into the random map generator. It's really no big deal, we only have to get to it eventually.
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).
I see no flaw in that. The simulation is supposed to take place inside the map, so it is only natural that the map would have to exist before the simulation begins.
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.
-
Why not do this with normal simulation scripting?
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)?
Adding a dependency on yet another scripting library when we already have SpiderMonkey == madness and/or SPARTA!
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!
growing trees / trading
in General Discussion
Posted · Edited by FeXoR
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.