sanderd17

Note that for lots of art stuff, the source files are not available publicly yet (or even completely lost). That means you won't find blender or photoshop files, but png and dae files. This is being fixed by adding a new art_source repo (http://trac.wildfiregames.com/browser/art_source). But it will take time to fill the repo. We currently also have an art repo that can't be made public because it also contains copyrighted reference material (which may not legally be spread publicly).

Files in mods overwrite files in the public mod. So it won't change if the public file changes. But JS is very modular. The OO paradigm it uses is based on prototypes, which means you can extend the prototypes in other files too. F.e. if you want to have a separate attack function, you can just have a file with Attack.prototype.newFunction = function(a) { /* body */};You can use the above thing also to just redefine an existing function when needed. In this case, you don't have to copy the entire file from the public mod, and you'll automatically inherit changes from there, as it won't overwrite existing files, but only extend existing prototypes. When a change happens to a function you've redefined, you will have to update that manually. But there's nothing we can do against that. The only thing you have to watch out for is that your file is loaded after the file in public (else it would try to extend a prototype that doesn't exist yet, and crash badly). The files are loaded alphabetically. So you could either append something to it, like call the file "AttackMyMod.js" (the 'M' is sorted after the '.'), or use lowercase letters (lowercase is sorted after uppercase IIRC).

Ah, just found this video you posted. It's very handy, as I can immediately see it's related to promoted units. Fix will be in in a few minutes.

Did it happen immediately when switching formations? If not, can you describe what happened? (maybe with a commands.txt).

We must always watch out with including "new" stuff in a large code base like 0 A.D.. That new stuff can get abandoned quickly, and our work based on it would be completely lost. Next to that, I don't see how noFlo would help. As our code base is so big, it would be just as difficult to browse through the graph as it is now to browse through the code. And our code blocks are also made as "sharable" as possible, with all extensions that came to our mind in the implementation. So I see no use in it for modding. However, I do see a use of flow-programming when it comes to triggers. The first version of the triggers will be purely code-based. But it should be possible to generate trigger code with an easier interface. Such a flow based interface might work better. Whether noFlo is suited for it or not will have to be researched.

I don't think you need an entire orchestra, but you would need multiple instruments, and people who can play them. You can read the music blog posts by Omri here" http://play0ad.com/category/team/ (scroll down a bit, I can't find a good filter to show them all at once).

Ah, it indeed works with chromium. Thanks. That music is quite dramatic. While we have no real drama in our game. Only violence and peace, sometimes revenge. The "Main Theme" you made is more useful I think. But it's still a bit too electronic to fit the game. Our music now is quite acoustic, and I think it would be best to keep it that way, to represent the ancient music. Most of your music sounds very electronic, and thus not really fitting our needs. I don't know if you want to work more acoustic. Basically, yes. Make something we will probably like. If it fits with the style we want in 0 A.D., it can be used in the game. Otherwise it's just something for your portfolio. When you make some good stuff, and you can cooperate with Omri when needed, you can get part of the team (basically get commit access).

Hmm, I can't listen to your work examples. I can see them, but clicking play doesn't work for some reason (maybe soundcloud is temporarily down). Anyway, I don't think you're applying for "sound lead". We split the "sound" and "music" parts of the game. Sound is about sound effects (battle sounds, shouts, animal sounds ...) while music is about the background tracks (in the menus and in the game). We have an active composer (Omri Lahav). He's quite busy but still manages to create new tracks every now and then. But you can either try to cooperate with Omri, or work on yourself. If you make good tracks (note that this includes the composing and the recording of the music), those should be added to the game. Most songs from Omri have a theme (normally a combination of a civilisation with peaceful and violent variants) because our in-game music selection system can automatically pick a track from that. For menu background music, you don't need a theme off course. Thank you for wanting to help out.

That's not good. And as long as it keeps going at this slow speed, we can cope with it manually. The only thing we can do is improve our captcha or other test when they create an account.

Which is exactly what Yves said. We need to investigate if these warnings are bugs or harmless. This may take a few days. Now I suggest to get back on topic. Which is discussing the new Petra AI, without the saved-game issue, as that's an issue that's a problem for all AIs.

Hmm, I was browsing from my phone, I missed it. I'll take a look and commit it if it's good enough. EDIT: On a second thought, it will collide with the i18n branch. And every collision is extra work. So I'll wait until the i18n branch is in.

The minimum resolution this game must support is 1024x768. If you have a smaller screen, do you really want to play an RTS? So, I'm not against it. If someone creates a patch for it, it can be committed imo. But I won't invest time in it either, as Pureon is still working on the ui redesign.

Yes, this is something that needs work. Enrique also had problems with it when doing his fields. The problem is that in the code, the prop hierarchy is lost when picking the variation. It just compiles a set of random variations. F.e. when you have a first choice between a, b and c. One at random gets added to the set (f.e. 'b'). But it doesn't remember which point the change comes from. So when you have subsequent choices of the same variation possibilities, you get a set that contains all possibilities (a, b and c). Which means it will always take a for all props. When you're lucky, it's possible a never got picked, and you'll end up with the 'b' choice for everything. But it will always be the same.

Philip is still around. So you can still ask him questions (though he's not very active on the forums, mostly on IRC). But as he has a different job now, his time is limited, and he can't do big features.

Fixed again (thanks to Philip).

leper already messaged Philip. Now wait for an answer and/or fix.

We're open, you can always start to work on it

It seems to happen when the Ptolemies have player3 on Gallic Fields (skirmish map). There's still place to build foundations, but there's no single open space. Together with the quite large, but only 5-pop houses of the ptolemies, this can cause problems I guess. Though even when they cut down trees, and thus an open space appears, they don't place buildings. Possible strategies would be phasing up as quickly as possible to expand, or trying to cut down strategic places of resources that obstruct building (a single tree doesn't take long to take down). Mimo already said that saved games aren't supported, just like with Aegis (as it's based on Aegis).

It went well until they got rushed by the opposing AI. From that point they stopped building. I was playing on Gallic Fields, against the Romans. There was still enough space on the map to build houses, though when switching perspective, I sometimes saw those "failed to build ... on top of another building or resource" messages. I saw it for both players, but the Romans eventually found space to build, while I had to place some house foundation myself as the Ptolemaic player to get them going again. I'll try to reproduce it.

I'm testing it a bit too. I started a 3-player map (gallic fields), and killed all my entities to resign. I got this warning a few minutes later: WARNING: no position for rushTargetFinder 0That's most likely related to my resign.So far, I really like how the two AI players don't attack each other at the same time (which was rather silly with Aegis, as one then cancelled the attack and rushed back home). I also like how they react to attacks. It would also be nice if it could build houses a bit sooner. Now I think it only builds houses when the population cap is reached. I think adding a margin on that to account for the build time would help. Certainly during the first phase. It also got stuck on the Ptolemies. It reached a 35 units pop cap, but refused to build houses (while it kept collecting resources). The position you pick to gather your army before attack can also be a bit better. I saw Petra sending all rams to the opposite part of the terrain to gather. Maybe pick the center point of your slowest units? And I also saw the rams sometimes idling in the middle of an attack. I think they were either trying to attack humans (which isn't possible), or some unreachable building. I think in that case, they should just pick the closest target and attack it to create space. I'll keep on testing.

Our main menu isn't very functional, so I don't see the need to have such an easily reachable hotkey. We do have F10 as hotkey. Our current pathfinder supports this, but it is the source of a lot of performance problems. So with the pathfinder redesign, we opted for a faster algorithm (A* + JPS). This algorithm expects a uniform cost grid. So no faster or slower places. It could maybe be modified so a map could have a few different speed regions (like define the center of a map as a slow swamp), but it won't be precise enough to have roads. Bridges are also something unsupported. The pathfinder only works on a 2D grid. While bridges would allow some unit to pass under it. To the pathfinder, they would have the same position, which isn't true. That's a matter of map design, and it differs from map to map. The expected time a game will take is under an hour though. So most maps don't provide resources for more than one hour. Then I fail to see the use of the territory system. It's made to stop players from growing too fast, or rushing with buildings instead of units. There are special buildings here and there that can be build in neutral or enemy territory, that's enough I think. Do you mean as a technology? Technologies can change speeds of units, so that's no problem. There are some mockups to improve it. There is some capturing functionality planned, which will go together with a unit morale system. We don't use "iron", but "metal" as a general collection of all metals (gold, silver, iron, bronze ...). You will see that you pay mercenary soldiers with metal (you hire them with some currency), while native soldiers cost food and some other material to represent their equipment. There's also looting available in the game. Though it's not visually implemented yet. But when you kill a soldier, or tear down a building, you normally receive around 10% of the original cost. Those last two are planned more or less.

The Celts (Gauls and Britons) talked something that mostly resembles the current Gaelic (though most written resources are Latin). Persians talked Farsi, Indians talked ancient variants of that region (Magadhi Prakrit, Sanskrit, ...). Egyptian names are in some Egyptian language for which there are few written resources, let alone we know how it's pronounced. Maybe we should try to get the specific names to use the local script (so Greek letters for Greek cultures, instead of using the Latin alphabet). But our font system currently only supports unicode characters from the first unicode plane. While most historical scrips are in other planes (like Egyptian hieroglyphs). This still wouldn't be possible for the Celts (as they didn't have their own script). But it would work for most other civilisations I think. For now, I advise you to not translate it (unless the specific name is English, i.e. not specific enough).

If someone is planning to work on this, you can take a look at ps/gameSetup/GameSetup.cpp. That's the point where the VFS (virtual file system) gets initalised and where the different mod directories get added. Maybe this method should be changed to only load the public mod, make sure the public mod loads the mod-selection screen, and after that mod selection screen, load the other mod directories to the VFS. This should work together with some settings that remember your previous mod choices, and make it possible to start the game without showing the mod manager.

This is because we have no permission from Microsoft to distribute the debug dlls (which the 'd' means). But you should be able to find it directly from Microsoft. (Since we can't distribute it, I don't think posting a link here would be a good idea either).

That seems correct. If you only want to edit a small part of the heightmap, it's better to modify it on the existing object. If you need access to parts of the old data, copying that to a new map before changing it would do the trick. As you don't have to copy everything, it would be a speed gain.