wraitii

There's a weird "elongation" effect on the front leg (particularly visible on the right one), but other than that it looks pretty good.

Tried again with 2.69. There's definitely an issue with our existing animations. New armatures now export more correctly, there is however still an issue with branching bones (see picture). This usually will break IK. This is probably the thing that makes importing our existing armatures slightly broken, too. Animations would probably work mostly right, but because of above weirdness it'll bug. This might be a limitation of the Collada format, though…

Concerning the fishing boat: I'm definitely able to commit it. However the animations might have to wait a bit.

I kinda likes the old one, it was very reminding of AoE 1 (ah, the power of nostalgia)... BUt it's probably not the most realistic, and those look very good too.

I've failed to compile 0 A.D. against the 10.9 SDK (Mavericks), apparently because there are some issues with Boost and some fundamental C++ library files in "Graphics"... (note: this was compiling using Xcode, not the script. Also I'm still under 10.8 so this might be linked).

Okay, the new version has been committed to SVN. Again, no real log changes, but tons of behind-the-door changes, so it needs testings, and I also need feedback: do you find it harder/easier than before? What should it do differently? Stuffs like that. Hopefully it's a little faster than it used to be, I'm not really sure. No naval support or savegame support as of yet.

Sorry guys, I've been a little stopped this WE (had a very fun WE with fellow students, but I had to rest for a bit). I think I'll be able to work on 0 A.D. properly this WE though.

I'm opening a topic at last for an issue that we discovered a long time ago and that might finally be resolved (opening it to remember to check that it's actually fixed). The issue is that our old collada armatures don't load up nicely in Blender. A change in 2.68 should have fixed this, however now 2.68 can't load those old armatures. A ticket for that has been opened on the Blender Bug Report. Latest update is that it's been closed after a report that "I was getting the same crash with 2.68 on linux64 (whichever revision was packaged with Fedora 19), but the same model imported fine with the latest nightly build. So this issue has probably already been fixed." Ticket is here. I recommend we try again with Blender 2.69 to see if: A- our armatures load up B- they load up nicely.

It looks disabled to me too. I would suggest trying a marble-like texture?

The might might look better centered in that. Perhaps.

You could check that by activating the developer overlay (alt+d by default I think) and checking "reveal map". As for the new AI, I've fixed an important bug regarding naval transport this week but have lacked time. I'll try to work on it more tomorrow, and try to commit it sometimes next week. We'll see.

I think fixing the range manager will fix this definitely (the entity map patch)

It appeared that without any particular reasons, GLSL was much slower on some computers, so it at least seems worthwile.

In the interest of releasing A15 quickly, it would probably be good to commit this as soon as possible so it can be debugged. As far as I know, we've reached a fairly acceptable level of "it works" on most compilers/systems in the early testers. Though I think it still needs some UTF8 support and stuffs?

I can't recall if I've added some tech checks for units in A14 for Aegis, but Aegis definitely shouldn't build stuffs from town phase/city phase if it's not phasing up.

I don't remember exactly how the whole things read, but it's very clear now.

I think it will be released in a few weeks from now. Historic_bruno, just to be clear, are your issues with the SVN AI or my beta above?

Sounds like it's getting stuck on something... I'm afraid this is a "wont fix", I've changed this logic in my repo already so the error is about 100% non-reproducible.

Difficulty modes (Alpha123 is right in that medium, hard and very hard use the same logic while easy is a little dumber and sandbox will never attack) -Sandbox: 50% of the resource actually gathered are added to the resource count (in effect, gathering is twice as slow) -Easy: 66% -Medium: 100% (normal speed) -Hard: 133% -Very Hard: 166%

Just to be clear, it works now? We don't have very good support of external screens yet, as we're using an older library. But we're working on improving that.

Hi raymond, Do you have a Retina computer? There is a known issue with those. I think playing in windowed mode fixes it. edit: this post might be of interest to you.

Thanks for reporting this, I will look into the issue and it will be fixed. Edit: beyond what Sanderd said, there still should be no errors in such a case. I had forgotten this was a naval map.

Hi Don, those questions are actually perfectly valid and are some things that I should improve someday. There is a do-nothing AI, which is the "base" in the common-api folders. In the common-api-v3, this is made slightly more complicated by the presence of a "shared script", ie something that does computations for all AIs (and which is basically compulsory at this point). Another "do nothing" AI is scaredybot, which you can check in the AI folder (it's declared as hidden in its data.json though), it uses the common-api-v1. I don't think you can write on in C++ now, so you have to do it in Javascript. However we're planning to move some things to C++ for performance, so there might be a day when this is possible.

Okay, self-replying for a more detailed explanation about how entity collections work. First, this all happens in shared.js, which is the core of the shared component. Shared.js stores a list of all entities in an associative array [key] = stuff, which is like an even more flexible and slower version of an std::map. There is also an entity collections of those entities. It also stores entity collections in 2 ways: as an array (somewhat similar to an std::vector), under the name _entityCollections, and as an associative array of arrays ([Key] = [vector]), under the name _EntityCollectionByDynProp. Now what happens when we run ApplyEntitiesDelta()? There are 2 cases: -If the message is "Create" or "Destroy", ie if an entity has been created or destroyed, we will loop over all entity collections (using _EntityCollections) and either add it if it fits, or remove it if it was present. -If we are dealing with a state change, we will loop over all entity collections that have registered for this state change. If for example the change is a change in position, we will access _EntityCollectionByDynProp[position] and we will loop over the array of entity collections. Same deal, we'll check if we need to add/remove. Now this doesn't sound too bad. However whenever we check if we need to remove an entity, we will have to check if the entity is listed in the collection. And the collections store their entities as an associative array. Thus we need to do something pretty similar to a "find" for an std::map. And we do this a lot. Same for state changes, as we need to know if we need to check wether to remove or add then entity. Put together, this gets way too slow. To complicate things further, we often iterate over entities of an entity collection. And iterating over an associative array in JS is really slow. Now the proper way to deal with this would be to realize that entity collections are reaaaally often created by filtering other entity collections. Thus there is a "natural" tree here, and we could use this property to speed things up. Something to keep in mind though is that an entity collection would not be fully defined by its children. At the most basic level, we have all entities. THen we have entities for each players, including gaia. Gaia is special-case, since it's basically mostly resources. However for players the enxt level of division is generally structures and units. And in units, support and the rest (which ban de further divided in infantry/cav/siege…) With a tree, when we receive a "Create" message, we'd start from the top and see if the entity can be added to that collection. However if we check starting with the "all entities" collection, that's always a yes. We should probably start at a lower level, like which player. Then we'll check children of that collection. Thus we would only check a little more than what we need, and not all entity collections. When we get a destroy message, the procedure would be somewhat similar. if the parent doesn't have it, the children won't either. State changes are a little trickier. The best guess is probably to register the first collection in a branch that needs this state change, and check its children if an update for the parent was required. This would also help with making Filters more hierarchical, because obviously it's better to check if the entity belongs to the right player first then do some more complex calculation than the opposite. I think this would help improve the efficiency of entity collection filtering in JS. It might not be much faster though, because JS sucks for looping over associative arrays and arrays in general. Needs some thinking. And it definitely needs a C++ architecture to be efficient, in my opinion. (if only because the entity collections themselves are inefficient). Edit: some more notes. ApplyEntitiesDelta also changes the entity in the _entities associative array. Which is also a fairly slow operation. This is about 100% similar to the issue with the range manager and its entity maps.

RedFox/Yves: porting the existing stuff to C++ is a little bit like shooting a bullet in our heads. BTW Redfox Length is never recomputed, it's actually done only once and the counter is incremented/decremtned. The check for "this.length === undefined" checks if the object has ever been initialized. Anyway as I've said the whole architecture needs to be rethought. Currently entity collections are a bit like std::map, only less efficient. We loop over then entities a lot (for filtering, with "ForEach" and we actually very rarely need to call a particular entity in those at all (for that we use a call to the "big" std::map which stores all entities). So an std::map is probably the worst thing you could do. Secondly, the use made of those is dumb: most entity collections are created by filtering from another one. We could thus see them as some sort of tree, which would help "ApplyENtitiesDelta" because we could, with much less work, eliminate entity collections that won't accept this entity. I don't think this last point is 100% clear, but I'll get back to it later (with some graphs and all), I don't have the time right now.