Deiz

I initially preferred the "[amount] [icon]" layout, but "[icon] [amount]" probably makes more sense as that's what the top bar already uses. As padding in the image itself would effectively shrink it in both width and height, I think that's a bad idea. A trailing space or three ought to do fine.

The UI sound issue should've been fixed in r12553. Are you sure about distant sounds? Presently I don't hear any non-selection sounds if they aren't on-screen (tested training, gathering, death).

A modifier sounds like a better idea than a small icon on each button. However, it's then a hidden feature that needs to be shown to players, particularly existing players who may not read the 'Learn to Play' dialogue every release. A separate GUI page that shows exhaustive information seems like a good idea. Ideally it should be Wesnoth-style, having a list of all of a civilization's units so players can quickly compare different units. I'm not so sure about stripping down the training/construction tooltips. I don't think it should be necessary to go view the exhaustive information simply because you've forgotten a basic attribute of a unit, e.g. which of a civ's ranged units is fastest. The current tooltips make it quite easy to determine that because the stat rows are relatively consistent and you can just move your mouse across the whole row to see the speed for each unit.

I'm not sure there is a particularly clean way to do it. The nicest way I can think of would be to keep a list of objects to update each frame in session.js, along with an anonymous function that adjusts them when needed. The objects would be inserted and deleted as necessary by unit_commands.js, resulting in something like this: var updateOnTick = { "unitQueueProgressLamp[0]": function(obj) { obj.hidden = (Date.now() % 1000 < 500) }, "unitQueueProgressSlider[0]": function(obj) { obj.hidden = (Date.now() % 1000 >= 500) } } Which session.js would invoke with something like: for (var objName in updateOnTick) { var obj = getGUIObjectByName(objName); updateOnTick[objName](obj); }

Generally speaking, the various Wikipedia projects tend to have an inherent bias against free, open-source software. Their sourcing policies are stuck in the pre-Internet era, focusing heavily on professionally-edited publications that are rare in the FOSS niche (particularly when it comes to games). The German Wikipedia is reputed to be the worst of the lot when it comes to notability, so it's unsurprising that 0 A.D.'s article was deleted. As far as I know, the project was taken over by deletionists a few years ago and they've been on a heavy-handed rampage ever since (note the huge swath of Linux distributions also up for deletion on that same archive page).

Clobber as in overwriting the old data, rather than to appending to it. Alt would do what you mentioned: It would select every idle unit that had one of the specified classes. It's really just a shortcut, as holding shift and the relevant idle selection key would eventually accomplish the same thing as alt-select (Alt being the hotkey for off-screen selection, e.g. alt + double click will select all units of a given type on the map).

Acceptable classes for 'idleworker' are ["Female", "Trade", "FishingBoat", "CitizenSoldier", "Healer"], while 'idlewarrior' is ["Hero", "Champion", "CitizenSoldier", "Siege", "Warship"]. So really, 'idleworker' is kind of a catch-all for non-military units. I think it'd be better to have idleworker restricted to builders and gatherers, with a third key for the rest, i.e. traders and healers, at present. I also don't find much utility in the current 'clobber selection with one idle unit' behaviour. I think I'll add proper hotkey support to the function, e.g. shift will add the found idle unit to the selection, alt will add all matching idle units.

Oh, whoops. I was thinking of another thread where somebody was reporting AI OOMs. Yes, the AI and RMS runtimes are separate. The RMS runtime is 96 MB, but some random map scripts still OOM frequently, even at rather small sizes. I'm not sure if it's due to massive memory usage or massive amounts of memory fragmentation (though it's probably a combination of the two).

It still ends up being a probability game, though. I've had a few transient OOMs with the 32 MB AI runtime and then it'll get GC'd back down to ~10 MB. The bump to 32 MB mostly alleviates entity collection creep (as more units exist the longer the game goes on). I think that permanently tackling the terrain analysis OOMs will require a) reworking that code to be friendlier to SpiderMonkey's mark-and-sweep GC, possibly waiting for SpiderMonkey to get a generational GC.

I don't think knee-jerk reactions are useful here. We haven't incorporated content from a billion-dollar game development company with an over-eager legal team that sends out dozens of cease-and-desist notices a day and gets its jollies kicking puppies. Rather, we've borrowed content from a volunteer-driven encyclopedia which happens to share the same license we use for our own content, and which the entirety of the game data is distributed under. We've simply failed to attribute the few pieces of content that we've used from Wikipedia. It's an unfortunate oversight, and should be rectified for alpha 12, but it's not a massive threat to the project that demands legal consultation or threatening team members with commit right revocation. Attribution on the forums is likely inadequate for content used in-game, anyhow. A better solution would be to finish the work-in-progress in-game credits display. Once that's done and we've sorted out which bits of content come from where, an list of third-party content and its authors can be shipped along with the game and viewed via the main menu. That ought to satisfy the Creative Commons attribution requirements handily. Licensing is invariably a pain. Chances are that for every project that gets it right, there are several that get it wrong. A degree of good faith must be assumed, especially between freely-licensed projects, or the entire ecosystem would collapse in a huge fireball of litigation.

You could deal with the desync by moving the population counter blinking into onSimulationUpdate. It seems odd to have the GUI flashing while the simulation is paused, anyhow. The second sprite isn't a very nice solution, but it's unfortunately the nicest solution available. Sprites aren't exposed to Javascript at all and I believe they're designed to be immutable. There is the "colour: r g b a" sprite hack that's used in a few places, but as far as I know there's no way to turn a named colour like "orange" into separate RGBA values that you can then make a new sprite with. Perhaps in the future this'll change - it's quite a mess at the moment. Your indenting in unit_commands.js is somewhat wonky, other than that the patch looks good.

I've discovered what the problem is. It turns out that most of what I've been attempting has been irrelevant: It's not a renderer bug, it's a loading bug. I was about to give up when I decided to strace 0ad while it loads with no cache, to see where it's actually sourcing files from. The reason nobody else seems to be able to reproduce this? It requires both the internal/ and public/ trees within binaries/data/mods, and it requires the former to have newer mtimes than the latter. The only real content of note in internal/art/actors are the Iberian props. They use the old texture element format, like so: <texture>props/iber_prop_shields.dds</texture> Meanwhile, the public/ version of that same file uses the newer format: <textures><texture file="props/iber_prop_shields.dds" name="baseTex"/></textures> Apparently, the "internal" mod is being loaded and when files exist in both public/ and internal/, the one with the newer mtime is preferred. If I touch every file in internal/art, all of the Iberian props are screwed up. If I touch every file in public/art, everything is fine. This has been quite the bug odyssey. I, for one, blame Mythos Ruler (he's the one who created the internal/ props, back in 2009).

As a stop-gap, I think it would be adequate to have repair function like construction. That is, once a unit finishes its current repair order, try to find another nearby unit that can be repaired. That'd at least allow you to repair a bunch of siege units with a single click, rather than needing to spread them all out and do each one manually.

I'm strongly doubting this is a hardware issue, as it wasn't present in alpha 10, I've never seen anything similar in other games, and it's heavily influenced by the actor XML, plus it occurs in both GLSL and ARB mode. One more data point: Perhaps it's AO-related? At the very least it seems tied to the new materials and/or textures. The Iberian house (art/actors/structures/iberians/house.xml) uses this material: <material>player_trans_ao_parallax_spec.xml</material>. When I clear my art cache, in both GLSL and ARB modes, the wood pile in one of the variants is covered by a stretched stone texture. Removing that material line and clearing the cache, though, and the issue disappears. I've confirmed that this behaviour is 100% reproducible on my end.

My nvidia-settings options are (to my knowledge) vanilla, and it doesn't seem that any settings fiddling changes things for the better. Some options do have visual affects, though - e.g. forcing 16x AF and FXAA simultaneously seems to make the texture mappings cycle more rapidly with zoom. My binary is definitely linked against current libraries: libnvidia-tls.so.304.43 => /usr/lib/libnvidia-tls.so.304.43 (0x00007f4842bd4000) libnvidia-glcore.so.304.43 => /usr/lib/libnvidia-glcore.so.304.43 (0x00007f48407eb000) I just noticed something very interesting: art/actors/props/structures/iberians/market_01.xml is what contains the various crates and barrels of wares that populate the market. It only has one texture, "baseTex". Simply duplicating the normTex and specTex from another actor seems sufficient to make the issue disappear (tested with a few different props). However, undoing that change and blowing away the art cache (~/.cache/0ad/art) seems insufficient to bring back the buggy behaviour, though other buggy props do persist after wiping the cache out. Is there some redundant caching I'm unaware of?