sanderd17

With a ladder to reach it! Nice work.

So strange, I also found that problem, fixed it (at least I thought), but it didn't change behaviour. Maybe a typo in a typo :/

Hi Clayton. Sure we can always use programmers. I suggest you look on the wiki get to know the code base a bit. And then take some task/bug/enhancement you like (http://trac.wildfiregames.com/report/1). To get feedback or help with the code, we welcome you on the #0ad-dev quakenet IRC channel. There the matters can be discussed, and if the code is good enough, it gets committed to the project. If you discover a new bug, you can always make a ticket for it, and try to fix it yourself. If you prefer an art task, please mention it here. Someone of the art team will probably drop by and suggest a task for you.

when our engine would be complete, you shouldn't need to code at all, certainly not c++ code. But since it isn't complete yet, you might need to code some additions. we like if you code something for your mod , you also mention it to us, so we can see how to get it in.

I searched for it, but didn't find it immediately (it probably needs a more awake version of me). But I logged it here so we don't forget: http://trac.wildfire...com/ticket/2106 If you want to join development, you don't have to know C++ (my c++ isn't spectacular either), you can join #0ad-dev on quakenet, where most of the discussions happen (you get to learn the source code that way). If you have a feature you want to implement, or a bug you want to solve, please also ask for some input on IRC. We'll be happy to help you (and our future selves).

Thanks for reporting this, we are looking into it. It's probably some typo somewhere. Now to find where ... For the ships names, we'll also look into making them better. Thanks for mentioning it.

Currently, ships don't move by themselves to let you garrison units. You need to move the ships by themselves. There is a patch that would take care of that, but there are still problems with it (the ship takes the wrong shore, the computation is very heavy etc), so it could still take a few iterations before it works. Until that, you have to guide your ship to the units and back.

The AI can, and should be in a separate thread. But for developing purposes (which is still rather important, since it's an alpha), it's better to have it in one thread (easier profiling, less problems with multithreading ...) the release (and maybe the beta versions) should have it in multiple threads. Even for those who should be able to solve it, it's a very hard task as nobody on the team owns a mac with a retina display. It's very hard to develop for something you don't own.

If you want to mod on the game, the best is to work with the svn version, so you always have the latest files (and you can notify us when something is going wrong with your mod). Here's the process to get the SVN version http://trac.wildfiregames.com/wiki/TortoiseSVN_Guide After that, creating a civ requires two main steps. One is modelling, texturing and animating new units and buildings. That requires that you know your way around with blender. Once you're able to make textured blender models, you can probably ask help of an artist to get it exported to the game. The third main thing is that you need a template for each unit with their gameplay values (armour, health, attack strength, speed, size ...). That's all told how to do more or less in the wiki. If you find out something new that could be handy for a newbie modding, you're also welcome to add it to the wiki. But as it's such a big task, if you really want an original civ (with original buildings and units), you probably need to be part of a team.

Can you describe the exact steps you followed to garrison the troops in the ship (pressed button A, clicked on icon B, etc)? I don't recall we've ever seen a bug report mentioning that.

The garbage collector is the one from the JS library we use, Spidermonkey. That doesn't cause a lot of lag normally, spidermonkey is quite clever with it. Are you sure it's not the AI itself you're experiencing? When the AI makes a plan (f.e. around turn 1000, it plans to launch an attack), it takes a lot of time, and can cause a lag pike. The goal is to only have our non-speed important parts written in JS, the rest is in C++. Consequently, it wouldn't need a lot of garbage collecting as it contains highly static things. Writing the entire game in C++ (let allone C) would cause us to program a lot slower.

AI players indeed can't handle naval maps. The only difference with this release is that the errors are shown instead of hidden (so you know your game has no point anymore). Although in this case, they did start to attack each other. But while they're trying to attack someone on the other side of the water, their game (and also their economy) is stuck for a while until they start a new plan. The real bug here is that the Nile map is not classified as a naval map, while it should. Not all players can reach each other over land.

You sure have a tendency to ask for stuff that no developer thought about implementing before.

Gameboy is talking about that new AI (in the zip) which is still in heavy development, so still has some errors in certain cases (I also reported some to wraitii). But that's normal for something in heavy development.

Well, IMO, it's mainly their cav champion skirmishers that are massively strong. But if you know that as opponent, you just train a lot of spearmen

Day-night would be easier to implement, seasons would need different textures per building, tree and ground surface (snow versions, autumn trees ...) so cost a lot of work. Wrt gameplay, IMO any such cycles should be decided by the map designer on how long they should take, and even if they should be implemented.

For the buildings, we will probably look into that, as upgrading the visual state of some buildings when phasing up would be nice, and upgrading individual buildings for a cost would also be nice (which are sadly enough two different things). I don't think we should care about building size, successive templates should just have the same obstruction size already, otherwise it becomes messy. But it will only be implemented when someone likes to do that, so it might not be for immediately. WRT you models, I don't think the size should be any bigger than the current CC model. If we ever implement building upgrades, I think the current CC is suited for town phase, something smaller (but with the same footprint) could be made for village phase, and something bigger (but also with the same footprint) for city phase. If you have a definitive name for your mod, I think we can move it, but as Linus says: To get a patch (you are using svn, right?), you should just execute "svn diff" from the svn root directory, or there should be something available in tortouse svn too (if you use that). For your code, some comments: Don't leave old, commented-out code in your files, like lines 104 and 107 Don't copy entire blocks of code like you did around line 324, working with logical operators can save you a lot of copy work. Our code conventions require you to use tabs, no spaces: http://trac.wildfiregames.com/wiki/Coding_Conventions, you changed the entire file to spaces. This messes up the patch (every line has changed), and is a pain to fix, as you even used a different number of spaces for indentation. It's better to have positive conditions (e.g. if (msg.from == -1) instead of if (msg.from != -1)) when possible. This makes code reading easier. The only reason to have negative conditions would be when there is no "else" block following. On the functionality, did you test it? I don't think it does what you want. It also requires build time and costs resources. I think at least the buildtime and resource costs should be set to zero. Btw, if you don't have enough resources after creating a building, it won't deploy any units.

It's not the cost of the server we're worried about (I think), it's just the maintenance. Btw, if you have experience in the field, I guess you can always contact Philip (always online on the #0ad IRC channel, though not always active). But some of the problems are passwords that shouldn't get shared etc. So only contact him if you have experience in the field (as Philip also has a lot of experience, so he normally knows what to do).

Sure, one zip is doable. 5 zips is less easy.

Wraitii fixed it: http://trac.wildfiregames.com/changeset/13782

It looks like the food type of the whale is simply set to food.meat instead of food.fish. And the fishing boat can only gather fish. Maybe it has to do something with the "land units should be able to fish" discussion? Edit: found the source of the problem: http://trac.wildfire...changeset/13749 The food type of the generic whale template has always been food.meat, but both whales that were in game have overwritten that template with their own food.fish resource. Due to cleaning up the whale templates, the food.meat mistake has become visible. I'll commit the fix ASAP. If someone can fix that, please do (I'm on tethered internet),

Just the same as someone destroys your houses when you're on the max population cap. You units won't die, but you wont be able to create new units until you're below the new population cap again. But you're right that it's not documented in the right places (and not even consistently).

If you look at the game, you see that Mauryans and f.e. Romans already have a different field. There isn't a lot more variation because using 3D models for this was/is hard.

You should normally see an error that the productionQueue (and everything following it) can't be read. Something like asdasdasd isn't valid JS code. To print warnings and error messages, you have two functions available: warn("message") // will print "message" in yellow error("message") // will print "message" in red To see how an object is structured (f.e. what the msg you get looks like), you can do warn(uneval(msg)) which will show you a string representation of the msg object (as long as it isn't too large). Also see http://trac.wildfiregames.com/wiki/Logging But please, for more direct feedback, join the #0ad-dev IRC channel on quakenet.

Where on the UI exactly? For random maps, you can only choose one population cap for the entire game. I just think it should be mentioned in the history or something a certain civilisation gets a +10% pop cap bonus, or a -10% pop cap penalty. But filling the UI with extra (mostly useless) numbers is not good IMO. There is no way to achieve subtle differences like a +10% difference. Sure, you can make all swordsmen take 2 population slots instead of one, but nobody would use swordsmen in such a case. Hmm, that's a different issue than we thought. Do you train in really big batches? If you train a batch of 30 units, and you only have 25 open slots, the batch won't be trained until you have enough space. Note that some units take up more (like a battering ram typically takes op 5 population slots), so in those cases, smaller batches even cause the problem (for a batch of 5 battering rams, you need 25 open population slots). You can see how much population a unit costs in the tooltip.