sanderd17

These should be fixed now.

The first one has "all rights reserved". So you must ask written permission before you can do anything with it (even sharing on this forum is forbidden if you follow the license strictly). The second one has "royalty free use", but that's still too much restrictions to be used in combination with the other artwork.

I'm wondering, if you do a lot of querying, maybe it would be beneficial to have a real database. Something like an SQLite DB in the RAM. Working on the native side could make it a lot faster. And to avoid transforming everything to JS vals every time (which takes time), it could return iterators as query result, and only convert the values when they're needed.

Making a mod isn't that hard (or shouldn't be, if you have other questions, you can always ask them). But spreading is harder, it requires users to find your mod, download it, and extract in the right place. After that, 0 A.D. needs to be launched with the right cli option. This process could be made easier. As easy as an in game download and use button. When mods get more exposure, more people will install them, and more will start to mod.

We ought to make mods easier (have in-game download manager and stuff), and the mods where you only add a civ, and don't change anything to the gameplay code are very easy to make. So we hope there will be plenty of them. But I don't think that this dynasty will ever make it to the main game.

There is a patch to display recordings, but it's very hacky. It's like you're in a normal game, the units just move automatically (by recorded commands). So you can influence the recording and see something different, which isn't really a wanted feature. Before it gets included, the patch needs some work done on it (and maybe a gui, but that's optional for the first version).

Glad to have someone working on sound again. The others we've had so far weren't bad, but they had little time available. That said, I think time is the most important thing you need to work on this game. Since you're from Australia (and most activity is during European evening), and since nobody else is actively working on sounds. You'll also have to be able to work rather independently (learning to work with our sound system). You won't be added to the team immediately (nobody is), you'll first have to show how you work in all aspects (quality of work, communication, ability to get something done ...) If you have technical questions, you can drop by on the #0ad-dev IRC channel on QuakeNet (again, there's more response during European evening). EDIT: just heard the sound. Good start. The pitch is a bit high though, and I wonder if a single sound wouldn't work better in game than those two clicks.

Ctrl+right click for the attack move. You can read the tutorial (learn to play) for other hotkeys.

Selling CD's of 0.A.D. on eBay is legal while following the licenses, as long as you also provide the source code, the license, let users share those CD's, and mention us as authors. I see no reason to grant all rights of translations to WFG. I'm also still owner of the source code I contributed. So the project can't be closed down. Not owning the translations shouldn't limit the project in any way.

A translation is seen as derived content. Derived from CC-BY-SA content, so your translation automatically comes under CC-BY-SA and can be used by us. Though I agree, we should probably make it a bit more clear. It also means you stay the owner of the translation, we can't use it in a non CC-BY-SA-approved way without the approval of all translators.

Normally, it's the work of the language coordinator to decide on those things. But I know you've added a lot of translations, and I haven't seen problems with your translations, so I just added you to the reviewers list. I also added wraitii to the coordinator list, as I think it's strange when there are no team members in the coordinator list, but there are team members who have that language as their native language.

It's not for thread safety, as the aiInterface already clones this variables. This means that there can only be unsafe threads between different AIs, if you edit values needed by both. Also, in js, everything is a reference. So if you edit this.entities, it's a reference to sharedAI.entities, and so you have lost thread safety. Because it's not doing any cloning here, this also isn't a slow method. The code is merely for shorter reference, as this.entities looks better than this.sharedscript.entities, and it's also a tiny bit faster to evaluate (every reference evaluation costs a bit of time).

Rise of the East mod: http://www.wildfiregames.com/forum/index.php?showforum=423 This looks best to me too IMO. We don't care enough for modders, as we may edit the source. So there are sometimes problems we don't know how to solve without editing the main source. Like you can overwrite the UnitAI file to have different unit behaviour. But you probably only want to differ it on one part, and if new UnitAI commands arrive in the main game (like conversion, capturing, patrolling ...) you probably want to inherit that. Without having to manually merge UnitAI with your own version on every commit. Doing this requires a well thought-out mod structure. The fact that we don't have these problems means also we have no practical solutions for it. And if some programmer really wants to help modders, we're also in need of a centralised mod download system + some settings to enable or disable mods without CLI options.

You can already make maps from heightmap imports (and there are many ways to render a heightmap from NASA data). So what we mainly need is a way to connect maps. Resource distribution will always need to happen manually, as it's a quite important game aspect.

There's no reason why you can't be on the team and work on a mod. RotE was mainly formed by team members. Though sadly, quite busy members.

The Math.random() is in fact our own implementation of it. So it is seeded and deterministic.

If a patch is not in game yet, there is no hurry. It can really take a few months before it gets fixed. I suggest, if you want to continue testing patches, you try a different patch (from a different ticket).

Yes, but it's not for tomorrow

Yes, the order of execution is fixed. Human messages are always applied either before or after bot message, so if a human is unable to place a field due to a bot that just did it, this also happens in the other computer. Or when the AIs will run a separate thread, only the calculations will, the sending of the commands will still have a fixed order to solve collisions in the same way everywhere. For local network games, if al textures are cached, you should be able to run two games simultaneously, and let them connect to each other. Though not all network problems can be found this way. You can't give two commands in the two instances at the same time (not easily at least), and some problems just arise from platform differences (f.e. different rounding in 32 vs 64-bit). If you use SVN, you don't have to download 5GB every day. You only download the differences between the files. Which is usually a few kb per day, but it may be bigger if there was a big art commit, or a new library added.

Next alpha should probably be in a few weeks (end of March, though more likely in April). And a bot must indeed be deterministic. The scripts are executed on all participating computers, and the results should match. That's also why serialisation is handy. The states can be compared, so if enough data is serialised, you can see the problem earlier. In past OOS problems with the AI, we only saw a difference in the simulation (due to the AI giving different commands). The position of some units differed a minimal amount (but enough to cause an arrow miss, and mess up the entire game). If a big part of the AI state would also be comparable, tracing it back is easier. As for the rejoining, when you rejoin, the player that is disconnected receives the serialised state on reconnection. That state should contain every part of the dynamic state, so when the bot gets the next turn update, it can just continue as nothing happened. If you don't serialise anything, there also shouldn't be a dynamic state (everything needs to be calculated from scratch every turn).

The bot gives the same result for every turn, no matter if it has been playing before, or it comes from a saved map? As that's what happens when the network connection of a player dies, and he rejoins.Serialization also makes it possible to research the source of oos problems in a much nicer way. For the ticks, don't you get a tick every turn? And for the planning, we will release v1 when ready, there's no schedule for it.

Normal infantry shouldn't be able to attack walls in the future. Next to that, wall towers are way cheaper. I dare you to build a number of wall towers for the same price as a castle, garrison them, and see what's stronger.

1. Only keep actively developed bots around, and give bot-developers the ability to change the api ^ What we do now, sort of. As long as the API itself hasn't reached some state where the most important features are implemented (s.a. serialisation), that's the only way to go I guess.

It's not the plan for the main game (like we have it now). But there are some loose plans for a "campaign" mode. Such campaigns would require much longer to play, and thus have bigger strategic maps (though they will look completely different). But this isn't planned for part I. So it will take a while.

Huge games (as in for 100 players or so) won't ever be possible due to the design (it needs to load the entire map into the memory before it can do something). And you should note, every time you double the length of the sides, you square the number of tiles (and typically, the number of objects too). So maps won't get much bigger as the current big maps, but they might become playable at best.