sanderd17

And what's the problem with it? There are so many ways to cheat in a single-player game. Why would we have to limit cheating by the AI player? As long as we don't include cheating AIs in the main game, there's no problem. A single player can't patch his AI to cheat, as the AI computations are double-checked with the other player.

I believe in a more genetic approach. But for that, you first need a hard-coded example that works good. Then you can turn more and more parameters (attack times, male/female ratios, building orders ...) into genetic ones. Until the point that the AI doesn't know about everything in game (it doesn't know about ships, healing, garrisoning to fire arrows, trading, ...), there's no point to make it genetic, as it's all connected (if you use one resource to create a unit, you won't use it to create a healer or a trader).

We do, but just females.

That doesn't need paid development. It's just not done because it makes debugging harder (and we're in alpha after all). But a big part of our code is thread safe. So things like the pathfinder and AI could be threaded rather easy.

A tournament would require we have two different AIs Currently we only have one hard-coded AI, so no way to create a tournament. But indeed, if someone ever makes a genetic AI, then tournaments are the only way to improve it (though tournaments against humans, and with all features enabled would result in the best final AI).

That's what we want to achieve. The real cost of farming should be the space it takes. So farming should be hard on islands, or other sparse-spaced maps. On those maps, you should use other food sources, s.a. corrals.

In that case, I wouldn't advise you to program for 0 A.D. without upgrading or cleaning your computer first. 0 A.D. takes a lot of HHD space on its own. If you want to work on the gameplay, you can also start with working on the JS part we have, and then switch to the C++ part. The code structure is very alike, the JS gives you less side problems.

The problem isn't a troop doing a mile detour. But say you have a round shaped lake. People can walk in the shallows, but that's slower. When you task them to go to the opposite site of the lake, the pathfinder will take the shortest way and not the shift the path a few meters to the solid ground to have a faster move speed. If you want that faster move speed, you'll have to command it by hand. Approaching round shapes with straight lines is always cumbersome.

Your skills look good, but I must agree with Prodigal Son that the style and/or time frame doesn't match 0 A.D. The city of Athens could be useful for the campaing maps, but they aren't planned for the near future. I suggest, if you want to share your buildings with everyone, you can upload them to a site like DevianArt under a free license (like the CC-BY-SA we use).

Very interesting, can you elaborate a bit more on how you see it? How to add a friend, remove a friend, use it in general ... Yes, we're a bit short on moderators for the lobby. I'm a moderator, and often online in the lobby, but mostly inactive, so I only see the problems too late. Maybe you can help us getting a list of potential moderators (people who don't spam, and are often online)?

RedFox didn't want to work on it any more, not for such a short period. So we either need to find someone else, or use the money in a different, but still honest, way. For the moment, nothing of the money is used, so if you think you know someone who could do the task, you can propose him. We can't force someone to work on it either, that would be counter productive.

Giving different speeds per terrain type would be possible, however, the new pathfinder wouldn't be able to handle it. It was foreseen in the old pathfinder, but as everyone knows, that's too slow and had more serious problems too. So certain features had to be taken out of it, the main one is different speed according to terrain. This means that your units won't follow the fast terrain, but will still go in straight lines over different terrains. This will cause more micro (people trying to avoid slow terrain), and thus is something we want to avoid.

Those companies that claim to look after copyright holders often cause more trouble than help. Like we have SABAM, as copyright holder of some original work, you can register it with SABAM, and SABAM will take care of all legal and illegal activities done with your work, and pay you (at least in theory). But SABAM is known to be a bad payer. It has kept lot money meant for the artists in their own pockets. The distribution of the money didn't follow the actual usage, but rather the cultural direction of the leaders of the organisation (schlager-like songs). SABAM also visits about every party, and asks the playlist and the number of people there to demand an amount of money, but it failed to check the playlist with the actual list of artists it had to protect. There are verified stories of artists bringing their own work (own lyrics, own composition, ...), and still having to pay to SABAM. The only way to get a part of their money back was registering their work with SABAM, or starting a trial. But yes, your work is completely protected by law without registering it, though you'll have to do your own protection. When you register your work somewhere, they're responsible to protect your work. Whether they always do that is a different question.

Yes, it was done to improve memory allocation IIRC. With growing lists, you need to allocate an increasing amount of memory, and each time you allocate memory, it costs some time. Hard to tell. Once enough memory is allocated (after a maximum number of units passed on those tiles), it won't improve performance. And on the other hand, with the limit in place, it will always allocate the same amount of memory. So in the most cases, you'll have wasted a multiple of the needed memory. It's quite hard to find decent profiling of it too, because of all the discussion around it.

I guess you mean this: "SpatialSubdivision Query too large. Results truncated."? If you don't provide any logs, please try to keep the capitalisation and spacing of the original message. It makes it so much easier for us to search. This is something RedFox introduced some time ago. The old spacial subdivision used variable-length vectors (so there was only a hardware limit on the number of entities per tile you can place), while after that change, there's a limit of 1024 units per subdivision (I don't know exactly how large a subdivision is). Later on, it was doubled to 2048. It probably means you have placed your trees or other entities too dense for RedFox' limits. I also remeber there was a quite heated discussion on the fixed limits those days.

Promotions aren't meant for this. You can edit most stats via technologies, and a tech to modify the look of the unit is in the pipeline too: http://trac.wildfiregames.com/ticket/2243 You still won't be able to change the name, icon and similar stuff, but this is something we'll never support, as it can cause confusion for the users. Of course, the promotion system and the gui is moddable, so you can change those things if you want, but it's not intended that way, so it will be hacky. Health is decimal, so you'll end up with 97.3 hp, only in the GUI, it's rounded to 97 or 98 hp. I don't remember if it's mathematically rounded, or always up or always down, but that shouldn't matter too much I think.

Well, you can compile some code via empscripten to JavaScript, if you compile to asm.js, it shouldn't even be that slow. But it will still be a lot slower than the current game, practically unplayable. If you just want to port it via empscripten, you'll find yourself in the strange situation that you're compiling the javascript engine to JS, as we're having that engine as one of our libs. Next to that, the entire JS base we use now should also be corrected. We use some features that don't run in all browsers, supporting more than just FF would cause a lot of work.

Should be fixed now: http://trac.wildfiregames.com/changeset/14726

Wraitii, do you edit formations directly? Or could there be another reason some entity is a formation member, but without valid formation controller?

Mythos, I wasn't saying you were wrong. I don't see anything wrong there (though I don't know a lot about HIV specifically). Romulus, I suggest you read this article: http://en.wikipedia.org/wiki/List_of_common_misconceptions

Wrong. Viruses mutate always, iregardless of medicine. While malware writers search for specific exploits.

Well, it isn't used in any case. All entities have 65536 as weight. The only exceptions are the special territory_pull and *_block. And the campaign demo cities. None of which are actually used. @Mythos_Ruler: I suggest, if you want to use it, you don't enlarge the weight of the well entities (there's lack of an overflow check in the code), but halving or quartering the other weights might work well.

Oh I was wrong, there's no problem with Atlas, the scrips are saved just fine. Also, the triggers component would be able to listen to many existing messages (player defeated, ownership changed, entity created/removed) without touching other parts of the simulation code. For some triggers that can't be caught by existing messages, you could still have other components (like the promotion component) call a function in the triggers component to execute all registered triggers that should be handled. So in the map, you'd have some simple functions as OnCivCenterCreated(SendResouces, {wood: 100});Then, the global helper functions look like this: var OnCivCenterCreated = function(action, actionData){ var cmpTrigger = Engine.QueryInterface(SYSTEM_ENTITY, IID_Trigger); var ccAction = function(actionData, msg) { // check if the entity in the msg is a CC // check the owner in the cc // execute the action for that owner } cmpTrigger.RegisterTrigger ({trigger:"OnOwnershipChanged", action: ccAction, actionData: actionData})};var SendResources = function(actionData, msg){ // get player defined in the message // send player the resources defined in the actionData};And the Trigger component just Listens to the OnOwnershipChanged message, and executes the ccAction function with the msg and the action data passed on.

we don't need a lot of infrastructure changes. It is already possible to run simulation code from the map file (just open the units demo, or the huge combat demo). But those maps don't work with Atlas for two reasons. They influence the map before the first turn. This can be solved easily by working with timers that would only run on the first turn. But I think Atlas also overwrites the JS code, which is a bigger issue, as you can't edit the map after putting a script in it. This way, triggers can use everything in simulation (also setting up timers for later execution), but as a framework to make triggers easier, I suggest a trigger component, where you could execute cmpTrigger.RegisterTrigger({trigger: "timer", triggerData: {time: 300}, action: defeatPlayer, actionData: [2]}). Then the triggers component would make a timer for you, and when the time had come, execute the right function. Next to that, there should also be some helper functions for common triggers and actions. This would make the syntax easy enough for the common cases, and it would make it easily interpretable for an Atlas GUI in the future.

It's indeed great to review models from new contributors. No reason to post screenshots from all angles.