sanderd17

If you modify unit statistics (so certainly "combining" multiple units in one), it will create a mod that can only be used in multiplayer if the opponent has the same mod. And of course, this mode will have to be balanced from scratch again, including all bugs that accompany balancing. However, it should be possible to improve the performance a lot by using simple models and textures. F.e. turn every tree into a green, tall pyramid; remove all details from buildings and bring them down to the essence (blocky fortress, house with a few tris, ...). It should be able to use this mod to play against someone who plays the main game (with beautiful graphics), but such a low-quality mod should still have some serious performance benefits.

We bundle our own SpiderMonkey (from Mozilla) with it. So the difference shouldn't be big. Though of course it will use different compilers on different OSes.

You're probably looking for the Trigger component: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/components/Trigger.js

Animations are planned (but they depend on new unit models). That should make capturing less static and give more visual feedback. What other usability improvments do you want?

To attack buildings (if they are well-defended), it is advised that you use siege engines (rams, catapults, ...). You can normally train the siege engines from the fortress, or for some civs, from a special building. Units can also attack buildings, but they aren't nearly as strong. The effect you saw when capturing was probably because it was garrisoned. Every unit garrisoned in a building counts to defend the building against capturing. And the military units inside the building also raise the arrow count. So a fully-garrisoned CC is indeed very hard to capture. But if your enemy doesn't pay attention, and doesn't garrison its CC, it's quite easy to capture one (and hold it if you defend it well). Make sure your strategy is balanced. Attacking only with siege engines won't work either, as siege engines are very weak against attacks from soldiers. So if your enemy sees you are attacking his CC with your siege engines, he could come out of his CC, and capture all your siege engines quickly.

It's getting a bit hard to answer here. I guess it would be better if you joined us on IRC. Then we could answer one question at a time.

We can't use native time in JavaScript because clocks aren't synchronised. cmpTimer keeps track of the game time, and takes things into account like slower or faster play or pauses, or even saved games. And it is guaranteed to be the same for all players. Btw, "getTime" isn't a native function in JS. You can use the Date object to retrieve the local computer time. But as said above, that will not by synchronised amongst players. And you also use some strange terminology: The components aren't triggered, they are queried (or requested) by the engine call (Engine.QueryInterface) You can call a method (or function) of a component (f.e. you can call cmpTimer.getTime() ), but calling a component is strange (and unclear) terminology. That's not even a thing. There are components that belong to the system entity, and functions in those components.

cmp stands for "component". cmpTimer is a component that keeps track of the time, and you can also use it to register certain timing events. It's similar to cmpTrigger, which is a component that looks after the triggers, and fires them when some change is noticed. Both cmpTimer and cmpTrigger belong to the SYSTEM_ENTITY (and are some kind of global components), but most components actually belong to other entities (like units or buildings). For example: all units have a cmpIdentity component, that you can use to get their name, or their classes. Units that can attack also have a cmpAttack component, that stores that attack statistics and executes attacks (calculates the damage to the enemy). For these other components, you need to call them on the entity id instead of the SYSTEM_ENTITY. To get data from the components, you usually have to execute functions on them. Like to get the time from the Timer component, you should use its GetTime() function ( http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/components/Timer.js#L17 ). And the reason why the triggers don't offer many filters (and you have to filter it by yourself), is that we prefer to not have hard-coded id filters (directly referencing the entity id), but we prefer softer filters (your function gets the entity id, and can then, via cmpIdentity, query the classes or the name of the entity). The problem with directly referencing the entity id is that the entity id isn't as stable as you would like. F.e. when a unit promotes, it is actually replaced by a different entity (with a new id). Or if you create a skirmish map, the skirmish structures are replaced by civ-specific structures which all get a new id. But also if you save the map, the ids can change. So it's better to not use the ids directly in your script. To see examples, it's best to look at the available triggers. Normally all *.js files in the scenario and skirmish directory are trigger scripts. So you can see how these are made and what the result in-game is.

The data for the RegisterTrigger is just a boolean to enable (or not yet enable) the trigger. See the "accepted data" on the table of the triggers page. Only some special triggers require extra data. And you also didn't put the data inside the function call. So you have to make a trigger that listens to every ownership change (note that this also includes creation of new units, as they change from no owner to a valid owner). Then in that function do the checks you want based on the returned data (the data you have as function argument). That data will include the entity id (which you can compare with a hard-coded ID, or query other things from it). And also the from- and to-ownership. In the function, it will also not know about a time variable. Perhaps it's better to only enable the trigger after a delay (so first execute a delay function, then register the capture trigger in that delay function). Or you can query the current time from cmpTimer. So something like var cmpTimer = Engine.QueryInterface(SYSTEM_ENTITY, IID_Timer); cmpTimer.GetTime();

0 A.D. speed is limited mostly on the CPU side (unless you have a really bad GPU). As 0 A.D. doesn't use multiple cores yet (at least not for the intensive tasks), you only can count the speed of a single core. And in your case, 1.7 GHz isn't that much faster than 1 Ghz. I think it would run very well on an old pentium IV, as they had up to 3.8 GHz.

You're always welcome on IRC to ask direct code questions: https://kiwiirc.com/client/irc.quakenet.org#0ad-dev The first remark is that everything with Trigger.prototype.xxx = function() is just defining functions under a namespace (so they don't collide with other functions), but these functions don't get executed yet. As such, you should always define these at the top level of your file, and not inside other functions. Secondly, you're missing something to boot your triggers. You can either listen to various messages (the ones defined in the reference table), or you can start them from the beginning. Take a look here: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/maps/scenarios/treasure_islands.js#L99 The function "IntroductionMessage" is started after a delay of 2 seconds in the game (which gives the game enough time to render the first things). And you can use this delay trick for every next function. But f.e. the function "TreasureCollected" is only fired when there is an actual treasure collected (so triggered by some user action). They also keep a certain state and count under the cmpTrigger variable (referred to as "this" for functions belonging to the Trigger prototype). The values you store under cmpTrigger are saved when you save a game, so you can load it again like you left it. As for your problems, the part of the JSON you show is correct, but there's likely something wrong with the surrounding code. JSON fields need to be separated by commas, so if you add a new field (TriggerScripts), then you need to put a comma after the previous field. About the ownership thing, the Gaia player exists to make no exception for a lot of code. F.e. the colour of the selection ring is derived from the player data, but if something doesn't have player data, it would be an exception. The owner can also send commands to the units. You can think that sending a command to a tree isn't very useful, but in the past, it has been very useful to change perspective to the gaia player, and send a delete command to some tree or other object that was blocking the AI (and a blocked AI could cause nasty lag). For adding an icon, you could try by using our GUI code directly, but I'm not sure if it will work.

In the last team meeting, we've decided to put the string freeze for A21 on Wednesday March 16th. That's the final date for new maps to be added to the next release. Can someone make a list of maps that should be good enough for inclusion?

I've tried your first map, and without triggers it isn't a lot of fun indeed. Red and orange start a lot stronger than blue. This will be a very hard map to balance, even if you find a way to limit the powers of red and orange with triggers. Another thing I noticed: you should watch the ownership of stuff. There are multiple fish, goats, chickens, ... that are owned by a player. And sometimes they give that player "vision" in enemy territory. It should be best if you can just make them gaia-owned.

ArferBrick, it's better to create a simple mod than to modify the public.zip. A mod can overwrite any file in the public.zip by its own version, you only need to place a file with the same name and path in your mod. The advantage of making a mod is that it's clearly split from our code, and you can enable and disable it through the game. The only thing you need to make a mod is a mod-description file (like public.json, but with altered parameters, take a look at some active mods to see the json file), and the files you want to overwrite. Doing it like you do now is also possible, but will cause more problems when upgrading (an upgrade will replace the public.zip), and it will also not allow you to play multiplayer (you'll have a different version of the game, and will immediately get an out-of-sync error).

For triggers, you'd best start with reading this page: http://trac.wildfiregames.com/wiki/Triggers , and also take a look at the existing maps with triggers (like the trigger demo). Then if you've been able to reproduce some basic triggers, you can look into creating the exact behaviour you want. For the question on how to find entities. We've made it easy to find trigger points by their reference letter. And when you have that point location, you can look for entities a certain distance around it by using the range manager (which you can filter by class or component f.e.). So it should be quite easy to filter the "nearest CC to trigger point A", and then you can still easily edit the map by just making sure the CC and trigger point A are always close enough together.

I've tried out this map, it's quite nice, but I do have some issues. The CC of player one is too close to the cliff of the river. A unit can spawn between the cliff and the CC, and get stuck on one of those tiles. Either the impassable tiles should overlap a bit (so units can't spawn on passable but unconnected tiles), or you should make sure the CC is far enough from the edge so units can pass. Secondly, I'd also like some more shores to place docks. A surprise attack over the water would be quite nice on this map, but you have to search really long to find a piece of shore where you can build a dock on.

There's a bit of documentation missing about modifications to Auras (as done in http://trac.wildfiregames.com/changeset/17809/ ). But the modification of auras also deserves a good warning, as it can cause a cascading effect of modified values, which can cause a lot of calculation in one turn and a lag spike (when you try to set an often-used aura). Apart from that, it looks to be up-to-date.

The image should be a square image, with binary size (32x32, 64x64, 128x128, ...) and the size of the map is deduced from the image size too. I have no idea how hard it is to edit that Atlas code (never worked a lot in Atlas), but I'll ask trompetin17, who should know more about it.

The heightmap tool just takes a greyscale, square image, and interprets the grey value as a height. But there are no settings on it, so you need to find a good greyscale image that has the right grey values, or do many iterations of fixing the image and importing it again. Of course, you need to find a heightmap image first, or create one using a renderer and height data (like NASA SRTM). And then you just have the heights and still need to texture it. So it's not a tool that you just click and it works, you also need to invest a lot of time into it. The times I tried it, I always felt the tool was putting too much false detail in the map, and creating some sort of sawtooth relief, with a flat view when looking from far, but with every tile impassable. Then again, as you say this is done by hand, it makes it even more impressive.

That's a very nice map again. Are you drawing that all by hand, or are you using the heightmap import? I can't remember our heightmap import to be that good, and neither is it easy to get black-and-white heightmaps (though that shouldn't be such a big problem for someone who prefers OSM over Google Maps). For campaigns, the main problem is that they're not designed yet. If someone would come up with a good first storyline, and a good GUI design, I think it would be enough to kick off the implementation. But I guess that most campaigns would need good triggers, and we're still a bit experimental when it comes to triggers (we don't know yet which ones work well and which don't).

I took the liberty to split the AI lag issue off to its own thread: https://wildfiregames.com/forum/index.php?/topic/20552-lag-with-ai-players-split-from-new-scenario-map-malta-island/ Your map is very interesting though. It's nice how you got these almost perfect shorelines.

Achie, welcome to 0 A.D. That ticket sounds like something doable, but the description isn't completely correct either. Moving it to the Damage (or Armour) component won't help, as that component is part of the damage receiver. But the damage receiver isn't known until the arrow lands (the arrow has a pre-calculated path, but the unit can move out of that path). So you can't call the damage component of an unknown unit. Next to that, some projectiles (like ballistas) can deal damage to multiple targets. The discussion on IRC is clearer in that regard: turn the damage helper into a system component, and make it keep track of the projectiles. If you have questions, please join us on IRC (as bb said), then we can explain the structure of the project better, and perhaps show you some good JS resources.

The main way to expand territory is by building a new CC in neutral territoy. To get access to the CC, you must first upgrade to the town phase though: building 5 regular buildings (like 5 houses, or 3 houses and 2 dropsites) unlocks the town phase. the town phase can be researched on your first CC (Click on the "II" icon you see when selecting the CC) after reaching town phase, you can build new CCs in neutral territory

Normally, when the team feels there are enough new features (or the release is taking too long), we make a decision to wrap it up. At that point, we set the date in the roadmap to some date by which we think we should have finished most features. However, the date in the roadmap is only the date of the feature freeze. After that, there's some testing, a commit freeze, and final testing. The testing is normally just a week or two, but it has happened before that we ran into serious bugs that caused a big delay in the actual release (and a very long feature freeze).

Attack and defense statistics are defined in the simulation. See http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/components/Attack.js , http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/components/Armour.js and http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/helpers/Damage.js