sanderd17

The concept is really rather simple. If you want to improve something, and you have the time and skills to do so, then just do it. There's no need to go @#$%ing programmers around for doing this or that. You can give suggestions, but since everyone is doing this in his spare time, you can't obligata anyone. And about being open source, that's the beauty of it, there's no way back. I contributed code to the project, and as long as I don't want to relicense it, it's gonna stay open source. Every programmer that ever contributed to the project has a veto on changing the license of the code. Just like every artist that ever contributed to it has a veto on changing the license of the art stuff. So in short, the only way to change the license is to start over. I'd appreciate it if you'd come here with a more open mind. Getting a finished game isn't a very big priority. The artists and programmers contributing here mostly do it because they like to learn stuff, improve their skills, or just like to spend their free time in this group. Making this game work is actually part of the game.

In the GUI, you should be able to use the system dependant time. So +(new Date()) should give you the system time since 1970 (I guess in seconds, but you should read the docs for that).

Just picking up random work seldomly results in good quality code. Picking a task you want to do (either one in our tickets, or one you invent) makes it a lot easier to achieve a result. As such, I don't see it as a problem when you just start creating your mod. If you need changes to the engine, we can still guide you, and then incorporate the changes if they are good. We could also incorporate some of the things you add as a mod, if they're coded decently. You'll see that all art and most gameplay code is implemented as a mod (the public mod), so if you want to create your own game using the engine, you can just replace that mod with your own mod. And either distribute it as a complete game (engine + mod), or distribute it as a mod people have to install in their 0 A.D. installation (note that people can disable the public mod, so total conversion mods are possible). I do have to warn you for the legal aspects though. If your art gets mixed with existing game art (including the GUI art), you should also distribute your art under the CC-BY-SA license. If your code gets mixed with code from us, you should also release your code under GPLv2+. About the manual, that's mostly updated, some pieces may be missing, but there shouldn't be a lot of wrong parts. If you find something wrong, just drop by on #0ad-dev on Quakenet to discuss it, and it can be fixed.

Wrt technical issues, most of them are known but hard to solve. If you find something specific you think we don't know, you can always mention it. But we should at least correct the historical issues. So if you could tell those, with some documentation/references added, that would be great. Though some inaccuracies can't be fixed due to gameplay reasons. F.e. the Celts should have sloped walls, not straight, but those sloped walls would take so much ground that it leaves no space to build other stuff.

Planned cities were often square, organic cities were often star-shaped. It doesn't depend a lot on the age or civilisation (though some civs tend to plan more, and others tend to have a more organic structure). I do think that star-shaped layouts would fit better with 0 A.D., just because the territories are more or less a circle around the base. So starting the first circular territory with civil buildings, and the subsequent with more millitary buildings, you'll automatically get some sort of star-shaped layout. So it's a good evolution. However, I do think about one modification. Normally, in star-shaped layouts, the buildings face the road or path leading to the centre, they don't face the centre directly (apart from the buildings in the inner circle around the centre). So if you know where your virtual roads are, you could rotate the buildings to that side. And a major problem with star-shaped layouts is that you always have those pointy buildings at the end. They're impossible to simulate in 0 A.D. But I guess the result would look good enough even without those pointy buildings.

In general, the fuzzy ones (without numbers) aren't real, but just planned. The bonusses with specific number (+10% gather speed f.e.) are real and implemented bonusses in most cases. It could of course be that a fuzzy description from the civ info has been implemented in-game in the meantime. But then you should probably find evidence of it in-game too

binaries/data/mods/public/maps/random/rmgen are the custom scripts used to make random maps. In your case, I guess the pathplacer just draws some stone-looking tiles on default paths between players. So it's indeed a bit of a pathfinder (to find the route between two player bases), but it's a rather simple one (since it only has to calculate a few routes, it can also be very slow). The actual pathfinder is found under http://trac.wildfiregames.com/browser/ps/trunk/source/simulation2/components it's split over multiple files (to keep them readable). So it's a bit more difficult to explain the structure.

When I implemented auras (including range auras), I also wanted visualisations (or at least that was one of the first requests). Selection rings and decals came up, but it appeared that both options would put a serious load on the processor when used on moving units. Even when used on non-moving entities, it makes the game a lot heavier, as big decals enlarge the bounding box of those enties. So this results in those entities being rendered quite often virtually, while they're not visible on screen at all. Of course, most of these concerns are theoretical, as the actual slowdown is caused by rather subtle (like depends on the number of units normally invisible, but due to the change being rendered). So the slowdown has never been actually profiled. EDIT: most of the performance doubts were raised by Philip, so I guess they're rather valid.

As development is done on multiple OS, there are also multiple IDEs used. On Windows, it's best to use Visual Studio to do the C++ development. Apart from that, IDE choices are pretty much free, and even simple text editors work quite good. I normally use gvim with some adapted settings (like using tabs instead of spaces), and it works well enough for me. About the most used languages. Generally it's C++ and JS. C++ is used for the parts that need to be fast (actual rendering, pathfinding, ...), JS on the other hand offers the possibility to be run without compilation, and thus is ideal to be used for game logic, and to be adapted by mods. The other languages used are mostly because there was an interesting library available that could be used. Like a chat library in python for the lobby, a compilation library with lua, ... These parts generally don't belong to the core game, and could rather easily be replaced by other tools in other languages.

Enabling lobby chat in the hosting screen isn't that difficult from a technical pov. It's just boringly copy-pasting the right parts from the right files into the right files, coming up with a clear UI (so new players don't accidentaly use the wrong chat), and editing a few parameters. Lobby chats are already received when you're hosting or joining a game, but they're just ignored by the UI. And I agree that it would be handy, a lot more handy than a sound (but maybe that's because I always have my computer muted unless when I need sound). In any case, you're welcom to try to implement it, it's a feasible challenge if you ask me.

It was meant as it's in the template. Ranged or Infantry. But just read the tooltips and find out (I hope I implemented those tooltips for some purpose).

There's indeed a hard-coded angle when formations are created. Formations were supposed to be created when you issue a command, it automatically creates a formation, and then the direction is known. But since that's disabled, it takes the hard-coded angle as the only option. I don't know how the software can know what angle to prefer otherwise.

Read the tooltips (hold your mouse over the shield icon), then you see how many arrows a tower fires. It's updated when you garrison soldiers, or when you research techs.

This string is indeed part of a demo. The demo is meant to show triggers asking questions to players (and reacting on it). For the demo, it just has a "yes" and "no" button, and logs what the user pressed. IIRC, you can see it by launching the trigger demo map.

What AI difficulty level are you using? In "hard" and "very hard" difficulty, the AI gets a gather bonus. In "normal" difficulty, AI units gather equally fast as human players, and in "easy" difficulty, the AI units get a gathering penalty. That being said, the AI may be very good at economy, but it's still not that good at battling. Certainly not at micro. The most important thing that you should try is to be earlier than the AI. When you attack the AI at its base (staying out of reach of the CC) you can completely kill its economy and win without too much problems. The main difficulty is microing your units around to fight the AI, while also keeping an eye on your economy (as you can't beat the AI with only an early raid).

What you're getting are the default choices for unselected things (looping alphabetical through all civs). While in reality, it's set to the choices given in the scenario file. There should probably be another setting for scenario files. Or maybe, you're just getting the info too early, before it's being set. But all by all, you shouldn't rely a lot on the civ you get, you should rely on the CC you start with to see what you can produce. Remember that mods can add civs you've never heard of before.

That's not a patch, that's in-game. It just immediately goes to your base (no shuttling needed), and we have no graphics for it. Normally, the attacker gets around 10% of the original cost of the unit killed or structure demolished.

Hmm, that shouldn't happen. Probably a messed up visibility check. Can you confirm this behaviour in certain cases? You can open the developer overlay (ALT+D) and switch the perspective to the enemy to force such a case.

I thought we discontinued the LOTR mod because of copyright issues...

On what references did you base it? I find the roof going inwards somewhat strange, no other Iberian buildings have it. The flat roofs without plank texture also look eastern to me. But if it's historically correct, it should be like that.

You have to watch out a bit with willow variants. Most willows we see now are hybrids that were only introduced at the colonial time. Like the weeping willow is a hybrid between the Chinese Salix Babilonica (from which it got it's looks, but that one can't survive in colder European climates), and in most cases (but other combinations are possible), the European Salix Alba, which isn't weeping at all. So while the model would fit for the China mod, I doubt it would fit for any map in the main game.

I'm sorry, read your script, and I had to remove it. There's really no way we can accept that script to be ran as root. As other comments mentioned, moving it to the user mod (i.e. ~/.local/share/0ad/mods/user on Linux) will also install the map. This does not require root privileges, and allows the map to stay available when updating the game. Next to being dangerous (although your code seemed to have enough quotes on first sight), it's also a bad habit to run scripts as root. We've got a lot of error reports about users trying to build the SVN, just because they build it as root. They did it out of habit, and it messed up paths and file permissions. As such, we now explicitly stop the execution of both the compilation script and the pyrogenesis executable when it's run as root. This should also be done in your script if you want to publish it again.

I think it just complains about the message containing ****, ***, and other star-like words.

Looks very good. Most houses don't have a lot of player colour. I think a single detail (one shield, or one banner) would be enough.

I think that one of the goals is to have a quite generic AI, without hard-coded expectations. This isn't 100% possible, but it's something that can be aimed for.