historic_bruno

That's sounding more and more like a hardware problem. Do you play other similar 3D OpenGL games (with similar amounts of testing)? You might check the graphics card and mobo for swelling/leaky capacitors. My old computer has bad caps on the mobo and the graphics were never stable after a few years, I got some of the strangest problems, but they sound vaguely similar to what you're having, mostly texture corruption. This would only manifest with more strenuous real-world 3D OpenGL apps, no amount of simple tests would cause it.

Which different revisions? I've heard that mentioned a few times but it still doesn't make any sense. The Windows installer and the OS X bundles I built should be be using the same revision (r11863).

Enjoy it while you can, this will probably be the last release where you get to play JuBot

I might be misunderstanding your question, but work on 0 A.D. will be continuing for the foreseeable future

Hmm, according to the documentation it seems the full amount will be available to the script runtime.

Are you using a water texture? It would probably be better to use the game's water (you can raise the water level on the Environment tab). You can also adjust the water's color, transparency, etc. to find the look you want.

At a glance the crash doesn't appear to be related to sound, I would create a Trac ticket for it and attach the files, so it's not forgotten in this topic. Also if you could find and attach interestinglog.html, that could potentially be helpful.

Doesn't matter, the random map generator is limited to 96 MB currently (we could increase this if necessary, but we'd need to balance that with the consequences of the game using more memory).

You're not referring to a problem with the various overloaded Uniform() methods are you? (some compilers spit out warnings for those, related to hiding an overloaded virtual function, which is indeed an obscure problem but I couldn't think of how it would cause a problem for us in practice)

They could but they'd have to figure out which file to modify and then repackage it, judging by the quality of those eBay listings I think they would struggle with that They are probably limited to copy-pasting outdated info from our website and burning the EXE installer to a CD.

Very large or giant random maps can be very slow to generate, I would try a different random map and if that doesn't help, a smaller size. The out of memory error looks like a bug on that random map and is not related to how much RAM your computer has.

I think this could be done easily, we already have a "GetBestAttackAgainst(target)" function, we could add a special hunting case for ranged units which only get used when attacking certain animals.

Sounds good! "© 200?-2012 Wildfire Games - Download for free at wildfiregames.com"

For scenarios you can make a "fake" bridge, see the Bridge Demo map for an example. Basically there is a bridge model and you raise the terrain inside it to make it passable. Not quite the same as a real bridge, but it looks surprisingly good

Can you try reproducing this now and see if there are more helpful errors being logged?

Nice find! That's a very interesting use of 0 A.D. art, I never would have expected to see it in a racing game like that Maybe we should have a section on the new website for projects that reuse parts of our game, or a section for "Related projects".

Hello and welcome

They're a JS array stored in the map settings data, for scenarios it's in the XML and for random maps in the JSON. See public\gui\loading\loading.js for an example of how you might access the map settings.

(We don't use real SDL in Windows, but a buggy emulation of it) How did you switch to the desktop? I've seen similar errors occur when people use Ctrl+Alt+Delete while the game is loading, which changes the active desktop thread, and the game loses ability to change display settings. Don't use Ctrl+Alt+Delete while the game is loading, if you're tempted to do so... in fact I'll add this to the known problems topic.

Projectiles are mostly a visual effect, though we do care about where they start and where they end, I think what appears to happen is just an interpolation based on simulation time between frames. Where I've seen that go wrong is when the time between consecutive frames/interpolations is relatively large (maybe the simulation rate is high or the game is going very slowly). It's clearly a bug, would it ever be expected behavior for projectiles to wildly bounce all over the place or fly out of the screen?

Personally I don't see much value to that change, it just rips out a lot of the purpose of materials and shoves it into actors instead. The whole point of materials is they contain settings common to several actors, what's the advantage of breaking that relationship? The one thing I'd like to see is the ability to tweak effectsSettings on a per-actor basis - it's not reasonable to expect a single set of values will look good for every actor, nor that a new material should be created for every possible combination (even if they only differ in e.g. specular value). Whereas having a separate material for each used subset of effects is reasonable, as long as they are clearly labelled and the artists can make sense of it. It doesn't seem worth spending a lot of time on this though, it doesn't matter much if we have a few extra materials made specially for helmets, spears, and whatnot.

Like this? http://trac.wildfiregames.com/ticket/1126

Which version of the game? Saved games are typically not compatible across different versions.

Which version of the game was this?

It seems you fixed that too, thanks http://trac.wildfiregames.com/changeset/12593