sanderd17

I edited the prop at the "projectile" attachpoint, and it works for me. Are you sure you're editing the right file?

The xml files are sound attributes typically for the game (like you see the distance, some small variations and stuff). These attributes need to work on an actual sound file, which is usually encoded in ogg format.

In [MOD]/simulation/data/technologies, you have the files where the technologies are defined. Per technology, you can add a different sound under the "SoundComplete" name. The sound has to be defined in [MOD]/audio as an xml file to handle certain variations of the sound.

I believe it's meant to happen in multiple threads, but as developing is easier in a single thread (you can e.g. profile the time the pathfinder needs), it's left this way. If you think you can help out, I invite you to the #0ad-dev IRC channel on quakenet. Philip is working on the pathfinder, and you can always find him there online (though he isn't always active).

It's easy to test it out. The Health component has a RegenRate variable. That's the number of HP the health will increase per second when damaged (can be a decimal value).

You don't need an SVN account, but it's best to download the SVN version of the game (it's publicly available, no account needed). Just to work with the most recent code and art, so you don't make duplicates. The task list is more about 3D work. Though there's also some texturing work, but it's best to do this after making the model. And there isn't a lot of texturing work to be done if you don't want to model. We do need a lot of 2D artwork for the unit portraits as Enrique mentioned (about every unit gets a different portrait, currently around 600 units, minus some duplicates). Currently, most of them use just screenshots from the game, but we want something more unique. LordGood has been making unit portraits lately, and since he started out, he made a lot of progress in quality, so you can certainly check out this thread: http://www.wildfiregames.com/forum/index.php?showtopic=17148 Take a look at the evolution, and try to see what we want for those portraits. After that, you can just take a civilisation (apart from Carthago, almost none of the units have portraits), and try to draw them. When you have some results, post them here for critique, and if they're good enough, they're added to the game.

I like the schwung LordGood gives to the project. It goes really fast, and that's a driving factor for other members. I believe in a development of iterations. As for the models specifically, when I look at the ptolemaic demo map, it looks quite good IMO.

Interesting, I never thought about a technology that enlarges initial stuff.

I have found this file by accident myself. It looks like it happens after the map initialisation (which is why that maps hangs a long time on 100%). I don't think you can use it for random maps, maybe via some ugly meta-scripting, but nothing nice. Apart from that, I think you'd want it to place the entities on the map, but that's not a very good idea, as the AI will be seriously confused when it starts its first turn without entities.

The looting is already in game, but it's very small (mostly like 10% of the cost of the unit/structure, check the Loot part of some generic templates). But we can make it bigger for vikings.

As I mentioned before. Looping sounds are global (so always heard, even if you're not focusing on the battle). If you want local sounds, they have to be rather short, and happen only once. But there needs to be enough variation. We can set up a different short sound for every action you can think of (like something the guys shout when you order to attack, when they run to a new target, when they're hit by a certain weapon ...). Currently, every action will cause a sound, though you can add variation by including different sound files. You also need to take into account that generally, multiple sounds will play together (if you order 10 units to attack), but with a few ms delay. I think we should complete that code a bit by including frequencies for those sounds (currently, every variation of the sound is played equally often), so it would be nice if only one hit in 10 will cause an "auch", and the others will just be "kling". EDIT: if someone is interested in adding frequencies to files, it's possible and I have a patch ready.

Is this one sound loop, or is it a combination of small sounds? I hope it's the latter, because we want sounds to sounds real. Like an attack shout when the unit is running etc. If those are small sounds, it's also important that they're tried in game. F.e. units don't run that often, so the charge shout can be made more prominent etc. I like how the battle sounds. I'm just worried if it's going to sound the same way in the game too.

You can just copy the SVN directory where you checked out 0 A.D.. SVN should be flexible enough to catch up with it.

If you use one of the older AI APIs (only Aegis uses the most recent one), there are more of those exceptions. Like the ability to build buildings before the needed upgrade. But the more recent the API is, the less of those exceptions there should be. Now, I don't think you want an AI, I think you really want triggers. We don't have triggers, and nobody is working on it. But in fact, it would need little less than a trigger editor. The maps can already contain scripts that can trigger events. If you take a look at the Units Demo map. That map only has an XML file, but almost the entire XML file is JavaScript. The interesting part is that you can access the components. You can f.e. access the timer component and let it spawn some units 10 minutes after the map is loaded. But as I said, we're not prepared for this. It would need a general design on how to structure the wanted triggers, probably in a trigger component. This method is different per map though, but I think that's positive, as otherwise you could spawn your units in not-allowed places. You'll have to watch out for Atlas though. I've never tested what it does with in-map scripts. But I wouldn't be surprised if it just deletes the script when you save the map with Atlas.

Canonical mostly takes their list from Debian. So you'll first have to lobby in the Debian community. And they have quite severe requirements on quality.

Certainly do a lot with boats. They had the fastest ships, and used them for trading and war. So probably also a sea trading bonus? For their plundering, what about a technology that enlarges the loot they get from killed soldiers. Some other nice thing, their ship could be made a resource droppoint. Which would be nice on island maps. Just garrison some units on a ship, and plunder all resources off the island without building a single structure.

We can't put anything in the Ubuntu Software Center. It's canonnical that chooses which programs to include.

What about a tech that reveals the entire map, but requires you to defeat the player in 5 or 10 minutes. If you don't defeat the opponent in that time, you lose.

We just need to limit ourself. Otherwise, part I will never be finished. We didn't really plan part 2 so far though, only moved some nice features that would ask too much time, and aren't really necessary, to part 2. But part 2 will probably be an extension to part 1, so using the same code. That would mean, that part 1 will also keep updating, and any feature that's added to part 2 will also be a post-release feature for part 1.

Either, you have a suggestion with code ready, or something you want to do yourself, then you can open a ticket, and we will guide you further. Or it has to be a feature really wanted by the design team (which Michael is a member of, but also quantumstate and alpha123). If a feature is neighter of those, it will just be closed as invalid. Believe me, we have enough suggestions. We just lack people working on the implementation. If you really want a certain feature, you'll have to start working on it yourself, so that you can present us with some results.

Take a better look? it's there.

For me, the Scarabee schield "bugs" me a bit. It's like there isn't enough space between the crate and the table for it to be there. And although they are convex, I think it's quite difficult to see. Maybe they're not convex enough?

We should really remove the ConquestCritical flag from units.

If the hieroglyphs are present in Unicode, we'd only need a compatible font that renders it, and build the hieroglyphs for that font. We should be able to render unicode signs.

It's because the SelectionGroupName is set to the same name in the template. So they are grouped on selection. You can just remove that line in the marian legionnaire if you don't want it.