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?

Well, so much for that - now running 304.43 and still able to reproduce the issues. Now that we're frozen for release, I suppose time will tell whether others are also experiencing the texture mapping issue.

It could well be that Nvidia botched the 302.17 release (dates to mid-June). I'll upgrade my packages later today and see whether these issues remain reproducible.

In r12636, with shadows = false and shadowpcf = false, textures in ARB mode vary a lot with camera distance, GLSL textures are mostly gold or black stripes. Here's your second helping of "WTF": This just happened in GLSL mode. Note how the structure textures are all fine... but most of the HUD has disappeared.

I definitely did rebuild - I saw source/renderer/ModelRenderer.cpp go by in make's output and then linking proceeded without issue. Anyhow, I have a bit of "WTF" that might provide some insight, confirmed on both r12630 and current r12636: Shadow filtering makes a difference. In both ARB and GLSL mode, toggling shadow filtering without moving the camera whatsoever will result in a complete change in the texture mapping - it's clearly not just a shade change, as I've seen a rough sandstone texture be replaced by crisp grey and black lines.

No dice with r12630. In both ARB and GLSL modes, the incorrect textures change with the zoom level. There are some differences in behaviour between the two modes, though. With GLSL, the texture mappings generally change rapidly with zoom, but notably the textures are often mapped correctly at the default camera h eight. In ARB mode, I usually only have two mappings no matter how extreme the zoom level, yet both are wrong - one is either white or black and the other is usually gold.

I have a Nvidia 9600 GT and run the proprietary driver, 302.17 presently. The issue presents itself in the exact same way in both ARB and GLSL modes. For what it's worth, the Iberian Sandbox triggers the issue immediately and 100% of the time, for me.

No, that seems to drastically worsen the issue, but in a different manner - certain portions of meshes turn completely white when zoomed out, and completely black when zoomed in. Is this perhaps related to a particular material? It presently impacts most of the props on various Iberian structures, e.g. drying racks and wood piles on houses, containers in the market - but not the basic Iberian stone texture itself, nor the market canopy, etc.

My favourite texture issue is back: 1, 2.

This is probably due to r12563. Formations used to disband when the controller reached its destination, but that lead to some issues (like units staying in FORMATIONMEMBER.WALKING indefinitely if the controller never moved, or not moving properly for short walk orders). Now they disband when the controller reaches its destination and the units reach their intended destinations within the formation. The latter is also satisfied if movement fails for some reason, e.g. a unit being obstructed. You can see the latter by turning the obstruction overlay on and walking a large formation into a building; they'll bunch up but then the formation will disband when they're all done moving. I think I know what causes this, though. I made a 20-unit formation and boxed one unit in between four siege rams, and as such it failed to even start moving. So, the formation size is 20, but only 19 units actually moved, and thus 19 units stop and that's not sufficient for the formation to disband itself. Edit: Should be fixed in r12613.

This is fairly common. Units in formation are allowed to collide with each other, and formation spacing more or less ignores the formation members' obstruction sizes. Additionally, when entities are actively colliding when they shouldn't be, they're allowed to move through each other (generally to get un-stuck). It's just a sort of convergence, really. In formation the obstructions will overlap like a Venn diagram, and then you break formation by giving the units an attack order and they move to attack and end up completely on top of each other, appearing to be one unit.