sanderd17

You can start with a few try-outs, and post here for commentary. Note that audio equipment, voice tone and pronunciation are all important.

Did you try the biggest ones in game? Eire and Albion is pretty big (but contains no stuff like trees, to make it still renderable). And the PNG import demos are also pretty huge (but also without objects). They're all under the demo maps. Most computers already go quite slow on those (even without additional objects), so that's why we don't make those (not yet at least).

Power of two to be more exact. So 64, 128, 256, 512, 1024 ...

There are certainly plans to implement it, but nobody is working on it yet. Saving it as a scenario won't work. You'll lose a lot of info. F.e. scenarios don't save garrisoned units (they just won't be there when you load the game), and dynamic stats (like health) would just start again on the original (max) value.

I was talking about recreating it

Also, if it's software made, we should be able to do it too (inside our code, so without extra download). I think we only plan to include some more textures created by artists (when they are needed). We should also think about file size. I think there are a lot of people who don't like to try it now, because it could be a huge waisted download.

Restoring the health will be rather hard to do. It also lessens the punishment for going out of the supply range, while it enforces micromanagement (getting your people back into the supply range at the exact right time). So I think you can guess what my opinion is With number 1, you mean an immediate subtraction of the health (as in a single subtraction of 20hp for example)? I think that's not very nice for the users. They can walk out of the supply range by accident once (or multiple times), while it hardly punishes the player when they deliberately leave the supply range. For a degeneration rate, you can set the regenRate in the Health component to something negative. The XML tags are defined in the component's schema (the first few lines of every component script). And when the component is initiated, the information is available under the this.template variable (as strings). So to add new XML tags to an existing component, you need to adapt the schema. If you add a new component, you automatically have the base tag (with the name of the component), and you can add sub-tags in the schema of that component.

It has been "near to finished" for a long time. But with every bug that's found, we get nearer to the finish. One of the main problems is the UI. Lots of buttons are given a certain size, so the English string fits, but in a lot of other languages, the size becomes too small to hold the text. Another problem is our fonts system. We support most characters that are based on Latin, but for other languages (Arab, Chinese, Hindi, ...), we don't have the right fonts, and it just get rendered as a bunch of question marks.

In the main menu "Tools and Options" > "Language"

There's an ownerShipChanged event you can check. When the ownership changes from invalid (-1) to something valid, you know a new entity has been created. You have to prepare for ownership changes anyway, as we will include capturing in the future. The ID is only known by the engine when the unit is spawned. keeping track of all future id's isn't possible. The human player can create a new entity in one of his buildings, and it can finish faster than your creation. So the id's will be reversed. The AI can show chat messages (it's done when an allied AI attacks). It has no mouse, and generally can only communicate through predefined commands. nope, we want the AI to run in separate threads. So it will have to copy the data in some way, to not edit the simulation data live.

The problem is that everything can be done outside the game. The commands.txt is a separate file, and you can read it with a modified version of the game to give you a visual replay. There's no way we could stop the game to be modified if it's ran separately. We could stop writing the commands.txt (not for now, as it's very handy for debugging), but even then, they could read the network traffic, and the game wouldn't notice it. There isn't really a lot we can do against it. The map info is on your computer, and gets send around, so if you put enough effort into it, you can read it.

The game is already pretty anti-cheat. Any cheat that changes the simulation side is blocked, as all players calculate all simulation events. Next to that, we also plan to compare the hashes of the binaries, to see if they're not modified. The remaining cheats are stuff like revealing the map (reading commands.txt, and replaying it in real time), or faster clicks. Though the game is more about tactics than fast clicks. Those apps you mentioned, they won't work against revealing the map either. So we're on our own there.

Having an old 4gHz single core processor currently runs 0ad better than a quad core 2gHz. Just because we're only using one core. Though you're right the problem is with the engine. It scales very poorly (having some O(n^4) loops and even worse). Also, irregardless of the lag, it will always use 100% of one core, as it just calculates more frames in that case.

See http://trac.wildfiregames.com/ticket/2338 for a workaround. Does require compilation from source.

I think you'll have to go via blender (export it from 3ds Max to blender), or find it out yourself. There's nobody currently active on the art team using 3ds Max.

#0ad is very empty these days (since the lobby). So you can just as well use that. If you don't want, the IRC channels are just registered with quakenet. But there are many services that offer channels (like freenode for open-source stuff).

That's right. By posting or broadcasting a message. Posting sends it to a specific entity. Broadcasting sends it to everything that listens (every entity that has a component with the right On... method).See AuraManager.js:49 Or if you use the AruaManager for the caching, you can also use it to send the messages I guess. Via the rangemanager component. In the rangemanager, you can register a query, and it will advertise any changes to the right entity (via the OnRangeUpdate message).See Auras.js:130 and 201 Euh, Every script in the simulation directory is ran on the start of the game. This means, for normal components, that the functions are initialised at that point. To use the functions, it needs to be called by other functions, or listen to messages. I mean in simulation/helpers/ValueModification.js. That file just contains 3 functions that are used to call the technologies and aura modifications. Including yours there isn't that hard.

I believe Idanwin is using A15, so that wouldn't matter. Though maybe you've found a new problem indeed.

User names are case sensitive. So Sanderd17 and sanderd17 are different names. But currently, you can also /nick a name. Like if I registered under Sanderd17, and you under MMMTheGamer, when I'm not online, you can /nick to my name. And it will hardly be noticeable.

The CCmpTerritoryManager.GetOwner(pos, pos) method returns the player id of the x-z position you gave in the argument. So if you call it with the position of the entity you're checking, it returns the owner of the territory the unit is on. The return type (player_id_t) is a type we have defined in C++ to denoter player ids (usuall 0 to 8 for all players + gaia). When you send the message with the player ids, and listen to it with JS, JS will only see a number (0 to 8). You'll also have to decide what happens when units move out of the world (this happens when they die, or when they get garrisoned). I suggest changing it to INVALID_PLAYER as owner (which is represented with -1 IIRC). For the code, you should do something like this: CmpPtr<ICmpTerritoryManager> cmpTerritoryManager(GetGetSystemEntity());player_id_t newTerritory = cmpTerritoryManager->GetOwner(m_X, m_Z);if (newTerritory != lastTerritory){ CMessageTerritoryPositionChanged(GetEntityId(), lastTerritory, newTerritory); GetSimContext().GetComponentManager().PostMessage(GetEntityId(), msg); lastTerritory = newTerritory;}You can just include it inside the existing AdvertisePositionChanges. As it's also advertising a certain position change, and you're sure it gets called at the right times.

Yes, and the definition of the message http://trac.wildfiregames.com/browser/ps/trunk/source/simulation2/MessageTypes.h I think it's all what's needed. Then in the JS components, you can just listen to the message by implementing the On... method (like OnPositionChanged for the PositionChanged message). And of course, the arguments of the PositionChanged message are the new position (that's the data that gets send with the message), while your data should be the old and the new territory.

Yes. You need that message because the JS part can't check every turn if some unit now has a different territory under it. Adding the message won't be that much work. You can look at the PositionChanged message (ack is your friend), and try to copy it entirely. After that, you only change the condition on which the message gets send (when the territory under it is different from the old one).

You don't need auras. Auras are made to be bound to an "aura giver", like a temple, hero ... Also, the way you want it (checking the territory every turn from JS) will cause a lot of extra lag. You will have to mess with C++ to make it perform well. The best would be if from the CCmpPosition component, you check store the current territory, and compare it with the new territory every time the unit moved. When the territory changed, send a message you created to that unit. When you have a patch for this, it can be included in the main repo, as I see there's a problem now: moving entities don't update their territory decay when they move out of the territory. In the message, you can add a "from" and "to" territory, which will make further checking easier. After that (small bug for us, feature needed for you) is solved, you can implement a different "value modifying" component (like auras and technologies currently). First of all, that component needs to detect if some statistic changed. So it needs to listen to the message you created above, and for the actual stat changes, you can look at the Auras component. When there's a possibility a stat changed, you need to advertise it by sending a ValueModification message to that entity. Next to checking if the stat changed, you also need to make the new value available. All stats that can be changed to through one of the methods of the ValueModification helper script (in simulation/helpers). The ApplyValueModificationsToEntity method will be enough. You won't edit player stats (as a player has no position), nor template stats (which are used to display the stats of units in the production queue, so only when all units stats are changed). You get the original value, and you can use that to calculate the new value which you have to return. You'll certainly have to work on top of the technology change (so call your code after that), else the caching of technologies becomes useless. But you can either apply it after or before aura changes. You will also need a cache. For some values (like the attack values), the ApplyValueModificationsToEntity code is called every turn when you have a unit selected. In the technology component, the resulting value is calculated once, and cached after that. That's a good caching method for things that don't change often, and for which the base almost never changes. For your component, I suggest to use the same caching as Auras, that only caches the difference. Maybe it's possible to reuse parts of the code (like you could reuse the AuraManager for the caching, but you will most likely need a new component to detect the territory changes.

IIRC, there were also no references of Gallic or Briton defense towers. But they were just added for the gameplay. If you make towers less important in your game (I don't think they were very important in the medieval times after all), you can just let them out for this faction. You don't need to follow 0AD's list of default entities.

Please, never use sudo when compiling something.