historic_bruno

That seems mostly to deal with entity templates, which are certainly one part of the translation issue, but not all. We'd still have to come up with custom solutions for JS, JSON, and GUI XML? Personally I'm leaning toward the approach taken on http://trac.wildfiregames.com/ticket/67 that uses existing libraries, tools, and data formats. I don't have experience translating software, but if someone who does says that's a common approach, it's a major consideration. If the tools are out there to do what we want, why reinvent the wheel? It's true that this: at first glance seems less friendly than this: but I'd be wary of spending time to solve problems other people have already solved over the past decades. It seems tools are out there to work with .po files, sourcing them from files in multiple languages. Writing a tool to parse our own custom translation format is yucky enough, do we want to be doing the same for entity and GUI XML, let alone arbitrary JS scripts and JSON data files?

And would said lawyer spend their resources to defend us/the project from lawsuits? It's less even about what's legal than how much you can afford to defend. Everything associated with Tolkien's name is huge business and getting bigger, and I doubt we or anybody else could stand against that. I know we closed the forum, we should also remove all references to TLA from our main site wildfiregames.com, of course we can't stop others from working on TLA, but I would strongly prefer it not be managed on our Trac or website.

Couldn't the actor use the "float on water" property, it should then be able to walk on land and float on water? It wouldn't look perfect, especially without animations and improved animal AI, but it would be a start

Hi, the out of memory errors likely aren't related to your system memory, but the hard coded JS runtime size. Which map(s) are you playing? If they are in fact random maps, which ones and which sizes? We need as much info as possible

Excellent work, Micket! You don't happen to know any animators who can help us out, do you? (Preferably using Blender) I'd like to see a crocodile, it would really be different than the animals we have so far.

Great, glad it was resolved!

In an ideal world, sure, everything would be perfectly organized and always updated, but we have to deal with reality, which is that people have limited time and not everyone is equally organized We're all volunteers here and it's a community project, which means as part of the community you're welcome to step in and update or provide documentation you feel is appropriate. You'll learn what's missing and help others in the process, that would be awesome It's one thing to notice problems and another to help fix them. Until recently, art discussions all occurred on private forums, so it was a huge step and adjustment just moving them into the open here (and it took quite a bit of prodding, believe me). The next step will be using Trac more for organization, but artists tend to find it less friendly. Nothing else is stopping anyone from using it, however. The list I posted was just examples, I didn't say you had to work on those animals, of course you should always check SVN (we recommend that any contributors use SVN so they work with the latest assets, and it makes committing changes easier for us) and for now, the two topics currently listing animals, it shouldn't really take that much time to figure out. Again it's not an ideal process and anyone is welcome to step in and improve it.

In fact, I don't think it needs much discussion. It just needs someone to take the time to rip out the old AIs and convert the ones we keep to the newest API. Since we're still in alpha and nobody outside WFG maintains 0 A.D. AIs as far as I know, I don't care in the least about supporting old APIs. We should keep a minimum of AIs to ease maintaining and improving them.

I take it this problem still occurs? I'm curious which graphics card you have and are your drivers up to date?

I'll reply about it in that topic.

Which species of Oryx, out of curiosity? It may be one is more suitable for 0 A.D. than others (even if similar in appearance we do typically consider such things and also historical species/locations, since this was thousands of years ago)

According to the unofficial sample roadmap, priorities are: 1. Elephants 2. Huntables/Gatherables -- Wildebeests, Goats, Aurochs, etc. 3. Dangerous animals that attack the player's units, like tigers, crocodiles, hippos, etc. 4. Cosmetic animals, like hawks and rabbits. If you want to work exclusively on assets not currently in the game, you could start modeling missing animals from categories 2-4. Elephants are already modeled AFAIK and only need to be animated. I would think also animals that appear in the most different biomes here, since they would be most generally useful.

Looking at this document, for example, I think it's pretty clear how advantageous it would be to have someone actively in charge of the sound department. Look at all the work that went into that Excel spreadsheet. Even with everything done to this point, it remains a huge task, not only defining and recording new sounds, and replacing old ones, but telling the programmers what is needed to use them. It's not surprising if new sound contributors disappear because nobody's there to keep them motivated I don't know if it's as important as an art department leader, but a sound department leader is very important.

Hi, the animals list was in a hidden staff forum but has now been made public: http://www.wildfiregames.com/forum/index.php?showtopic=15686 Hopefully it is not too out of date. If I may say so, we always have a need for talented animal modelers and animators

If you mean the issue with an SVN or release version of the game, it may be fixed indirectly by moving to SDL 2.0 on Windows. But I was actually referring to a bug specific to using official SDL instead of our emulation in Windows - which nobody does, so it shouldn't apply to you I mean you should be able to compile against SDL 2.0 right now with no problems, just set up premake to find the correct libraries Any bugs you find should be fixed, because eventually everyone will have SDL 2.0, but obviously we still support 1.2 in the meantime (there are a bunch of preprocessor macros in the engine to handle the different APIs).

More sound requests: Gate lock/unlock Animal death sounds and more variety (low priority)

The new warnings are expected debugging messages while we troubleshoot some other problems. It looks to me like you have the buggy version of OpenAL Soft 1.15 and it needs to be updated to 1.15.1 to fix it. I would report this to your distro's support or whoever manages the OpenAL Soft package, they may be able to release an update. The 1.15.1 version was released literally within days of 1.15 IIRC, so people may not have even noticed it.

Something wrong? Thanks for reporting. That message has been added for debugging purposes, because stereo sounds won't respect entity position, most of them will be fixed by r13450, but not all. There will be a few more fixes before it's all sorted out.

We already have decent SDL 2.0 support, though I've only tested on Windows and OS X (briefly) so far. I have a patch for using SDL 2.0's color cursors, that fixes a conflict between SDL and our hardware cursor implementation on Windows, I will try to post that soon. Progress has been tracked somewhat on #935.

Which version of OpenAL-soft are you using? That error looks like the regression introduced in 1.15 which was fixed in 1.15.1 (assuming line 342 of CSoundBase.cpp is responsible, since it retrieves the source AL_GAIN).

If we're going to upgrade SM in the first place, we need a justification. If there's no performance benefit, no GC benefit, why should we take the trouble of upgrading and losing compatibility with the 1.8.5 packages out there? So I'm fine with looking for a version that offers one or more significant benefits, I think it's worth investigating. Can you also summarize the non-performance improvements we would get from V17+?

That wouldn't address the problem in this ticket or Mythos' suggestion, it would only be a minor visual enhancement. Wraitii is correct that it has never been implemented since the simulation rewrite. Building placement is buggy all around, walls are maybe the worse case, because they need to reach otherwise impassable terrain to seal it off (not only cliffs but shorelines). And there's a ticket for it, so we only need someone to work on that http://trac.wildfiregames.com/ticket/1610

The other thing you can do is view the pathfinder overlay, that can reveal how tricky the terrain is and also what the pathfinder is doing.

Actually I would say it is a pathfinding issue. It's stuck in the "approaching" UnitAI state, so that's an indication. One of the reasons for redesigning the long pathfinder is that units get stuck in certain situations, places they can get into but not out of with the long pathfinder, though the short pathfinder can sometimes get them out, this could be one of those bugs. I would advise altering the terrain if possible to make pathfinding easier on your map.

I believe it was implemented with footprints because (typically) they more closely match the visual appearance of actors than do obstructions. Basically we use footprints for a bunch of things, at least the following: Projectile detection Selection overlays Unit spawning Rally line rendering Building restrictions Whereas obstructions are mostly used for pathfinder related stuff. The problem is there's not a 100% match of requirements between obstructions and the above tasks. The easiest solution would probably be to split selections off to some other concept outside the simulation (footprints and obstructions currently affect the simulation, selections should have no effect).