Ykkrosh

Fixed. I'm not sure particles really make sense for waves, but if someone wants to experiment then feel free . I'll see if I can write up some basic documentation tomorrow.

Field is signed char and field is -1, so min/max will be -128/127 and it'll get printed as unsigned(-1) == 0xFFFFFFFF.

. system_info.txt

I don't have a /sys/firmware/efi on my Linux machine (probably since I have no EFI support), so it looks like dmidecode does its "Fallback to memory scan" thing. But it fails when run as non-root ("/dev/mem: Permission denied") which doesn't make it sound especially feasible for the game

(The check would have to be at runtime anyway, since you could build the game then upgrade your kernel to a buggy one, or could run a copy of the game that was built on a different system.)

"SyntaxError: JSON.parse: parsing JSON data in civs/noldor.json" means there's a syntax error in civs/noldor.json, so you should fix that . Unfortunately it doesn't say where the syntax error is, which is a pain...

You probably need to edit binaries/data/mods/public/simulation/components/Identity.js and add the name and code to the list near the top.

It's possible the enemy could build a building in the FoW, and (once we've fixed some more FoW bugs) you wouldn't see it and could still try to build on top of it. Maybe it'd be adequate to just turn red and forbid placement if there's any building obstructing the location, even if it's not a visible building, i.e. ignore the FoW entirely - advanced players could use it as a kind of radar to detect newly-constructed enemy bases in FoW but that doesn't sound like a necessarily detrimental feature. (Similarly they could detect if the enemy has chopped down a forest in FoW, because it would no longer block the construction, even though the chopped-down trees should remain visible until you explore that area again (once we implement that feature)). Alternatively, we could create the foundation and then have it self-destruct when the builder reaches it if there's an unmoveable obstruction (e.g. enemy building) in the way, but I don't really like that since it's probably got fiddly edge cases (e.g. maybe you could build on top of an enemy's foundation and destroy their foundation before their builders have reached it, or e.g. your foundation might be entirely inside an enemy building and unreachable so your builders will never get to it). Done (but autobuild required).

Yeah, from the debug output it looks like it's only compiling the shader once now, and it's not doing that bogus one with the "none.0000" which the breakpoint was for, so I guess they've fixed whatever that particular bug was With FOW we don't render units that are hidden in it, so you shouldn't be seeing those, but we do render all the terrain regardless. I don't think it's a significant performance issue since if you're looking at a totally black part of the map you won't notice the framerate anyway . Better to optimise the worst case (visible map with lots of units) rather than the best case. Also there's a danger of graphical glitches like shadows suddenly popping into existence, if there's a mountain which we don't render until a unit gets close to it, so it seems safer to stick with always rendering it.

I tried this: * Opened that .blend file in 2.56a. * Renamed "Armature" to "ArmatureLion". * Exported to a .dae file in meshes/ and again in animation/ * Added the attached bits of XML into skeletons/skeleton.xml. * Created an actor with the mesh and animation. * Viewed it in the actor viewer. * Clicked "play" to animate it. * Saw it animate like it should lionskeleton.xml

Do you have an example of a file that causes errors? It sounds there's going to be a non-beta release of Blender 2.5 pretty soon, so I'd imagine it makes more sense to focus on supporting that (and doing any necessary bug-fixes) so we can stick with it for the next couple of years and not worry about changing again or getting too outdated. Hopefully its current problems aren't fatal and impossible to fix

When zoomed out on Belgian Bog, replacing all alpha-blended textures with 1-bit alpha-tested textures gave a 100% framerate increase on my Intel 4500MHD and 50% increase on GeForce 8600M GT, so it's a significant difference, but the trees looked really ugly . Compare e.g. alpha-blending vs alpha testing. (Also you typically don't get antialiasing when using alpha-testing, so edges in the texture even look worse than real geometry edges). So I think it'd require a redesign of the trees (probably not just minor tweaks) to make them look good (and consistent) without relying on alpha blending, just using 1-bit alpha and more polygons. (Polygons aren't cheap enough to model each individual leaf, but I think we could safely stretch beyond the ~100 polygons per tree that we currently have. I suppose I should do some testing to get some rough numbers that are slightly less entirely guesswork, but maybe somewhere between 100 and 1000 would be plausible.) If art people are willing and able to do that and make it pretty then that'd be great - it'd give a huge performance improvement when there's a lot of trees.

(There's been some relevant discussion elsewhere but it probably makes sense to move it here to avoid clutter.) I tried exporting a simple skeletal animation from Blender 2.56a Beta, and it seems to work. There's an armature named "Armature", with bones named "Bone" (the root), "Bone.000", "Bone.001", "Bone.002", "Bone.003", and a mesh with an Armature modifier and some weights painted on. The mesh is just a subdivided cube with UV unwrapped. The bones have some Rotation keyframes so they animate over 30 frames. The exported .dae file says things like <visual_scene id="Scene" name="Scene"> <node id="Armature" type="NODE"> <node id="Armature_Bone" name="Bone" sid="Armature_Bone" type="JOINT"> <node id="Armature_Bone_000" name="Bone.000" sid="Armature_Bone_000" type="JOINT"> ... Then I added a bit to art/skeletons/skeletons.xml: <standard_skeleton title="Blob test" id="blob"> <bone name="root"> <bone name="r1"> <bone name="r2"/> </bone> <bone name="l1"> <bone name="l2"/> </bone> </bone> </standard_skeleton> <skeleton title="Blender blob test" target="blob"> <identifier> <root>Armature</root> </identifier> <bone name="Bone"> <target>root</target> <bone name="Bone_000"> <target>r1</target> <bone name="Bone_001"> <target>r2</target> </bone> </bone> <bone name="Bone_002"> <target>l1</target> <bone name="Bone_003"> <target>l2</target> </bone> </bone> </bone> </skeleton> The <standard_skeleton> is just needed because this doesn't map onto pre-defined ones like "Standard biped". (Any new bipedal skeletons ought to use "Standard biped" so they can share animations/meshes from 3ds Max and XSI, and change the <target> names in the <skeleton> so they map the Blender bone names onto the Standard Biped bone names.) The <skeleton> uses <identifier><root>Armature... to match <node id="Armature" .../> (from the name of the armature in the Blender scene). (Ought to rename it in Blender to "ArmatureBlob" or "ArmatureBiped" or whatever so the different shapes are distinguishable). Then it uses <bone name="Bone"> and <bone name="Bone_000">, because that matches the Collada file's <node ... name="Bone"> and <node ... name="Bone.000"> with the "."s replaced with "_". (To be precise, all characters in the name except for a-z, A-Z, 0-9, "_", "-" will be replaced with "_". I think the Collada importer library the game uses is unnecessarily strict, but that's what it does, so it's probably easiest to put up with it and remember to do the character replacements when writing skeletons.xml, or perhaps avoid using names containing "." inside Blender.) Then I copied the .dae file into animations/ and meshes/ (because in this case it contains both parts), and set up an actor with it, and looked in the actor viewer and clicked "play" and it ran the animation properly. So I think there's nothing fundamentally broken here in Blender or the game (except for our general lack of documentation of this process). Has anyone else managed to get this much to work and then failed with more complex things, or not even got this far?

Would 1-bit transparency help in that case? That's not currently supported but should be easy to add, and it's about as cheap as solid textures. (It's just the blending of 8-bit alpha channels with partially-transparent pixels that's the problem, and which I'd be happy to minimise except where it's unavoidably necessary.)

Yeah, the Actor Viewer just counts the number of triangles that were rendered, which includes the extra rendering passes for shadow map generation and silhouettes and (if enabled) reflections and refractions, so it could be 5 times the basic figure. (And if you have transparency then I think it'll do another 3 passes on top of that. (Transparency is evil because of that and other reasons - non-animated solid polygons are pretty cheap (I can seemingly get about 10 million terrain triangles per second on rubbish Intel graphics, so hundreds of thousands per frame would be fine) so they're probably one of the less important things to worry about.))

It will display in Atlas in the "play" mode; otherwise all the animation is paused, which includes particles (and there are zero particles before they've animated long enough to emit some). But I changed it now so they should animation even when paused in Atlas - does that work a bit better? Also they were broken in the Actor Viewer so I fixed that. (...at least after the autobuild, which should be soon.) I also added some dust particles on construction (though I only bothered for the 3x3 foundation - try building houses). Also I added some kind of yucky way to make the number of particles increase as you task more builders onto the building - I think it's possibly a nice effect but the implementation needs to be redesigned eventually.

Maybe it'd look okay for highlights to still be in the diffuse texture, enhanced by the true specular lighting, or maybe that'd look ugly. I really don't know - as far as I'm concerned it's just an art problem Don't know - that's a code problem but it's beyond my graphical knowledge. (Well, anything is always possible, but I don't know what the performance impact would be, and don't know whether it'd fit with our current renderer design or would introduce a load of new complexity.)

Performance is the same for any blend mode. Currently there's "add", "subtract", "multiply" and "over". The tricky one is "over", which is the standard alpha-blending thing - it'll use the colour from the texture, with the alpha channel determining how much to show of the texture vs the background. The problem is that "over" is order-dependent - to be correct you have to draw the furthest objects first, so you can draw the closer ones over them. (The others are all order-independent: A+B+C = A+C+B, A-B-C = A-C-B, A*B*C = A*C*B, etc). Currently the system sorts each separate particle emitter by distance (so the furthest get drawn first), but sorting every single particle by distance would be relatively slow and complex, so it draws particles in some arbitrary order instead. So you need to be careful when using "over" - if the particles have high alpha then it might look a bit wrong when viewed from certain angles. But in some cases it might look okay, particularly for low-alpha textures, so you just need to test it.

I don't think footprints would really be related to particles - they're probably more an application of decals, since they need to sit flat on the terrain. (I think the defining characteristics of particles are that they are camera-facing sprites and that they are continuously moving/rotating/fading/etc. Anything like that should probably be handled by the particle system (maybe needing extensions beyond its current functionality); anything else probably shouldn't be.) Yeah, that'd be nice once we have promotion. Spectral like these guys? If you mean specular, that should be handled by creating a new texture map to represent the shininess of the current diffuse textures, and it should be relatively easy to extend the new shader-based renderer to make use of that. If you think it looks better then please do . I just drew the smoke myself with some splotches in Gimp, and derived the flame from here, so they're certainly not ideal. By the way, there's some old particle images in here which apparently came from CheeZy so I expect they should be fine from a licensing perspective if we want to reuse them for anything.

We've only had about four independent attempts at particle systems for the game, which isn't nearly enough, so I started a new one yesterday that actually integrates with the game and committed a mostly-working version now. There's a fire effect to demonstrate it - you create a particle definition file, and a special actor file, then you can use the new actor as a prop attached to any point on an existing actor. A particle editor GUI is an explicit non-goal, since it's a load of effort and I don't think it's that useful - the XML files support hotloading so you can easily tweak and test changes, and we won't have hundreds of different effects so it'll likely be less aggregate effort than writing a GUI. I think the current system basically works okay for fire (though it could probably be much improved artistically), but will need extensions for some other effects (e.g. one-shot emitters instead of continuous emitters, and gravity, and maybe more randomness in the emission rate, etc). What kind of particle effects would people suggest adding?

I see no measurable difference in load times, when running from SVN (no public.zip) with hot or cold cache. Could we just apply this patch with a "#if OS_LINUX / #define DISABLE_AIO 1", at least until some time in the future when nobody is still using the buggy kernel and there's a measurable performance impact? aio is presumably very rarely used (else someone would have likely noticed the bug before releasing the kernel), so avoiding it is good for compatibility.

Broken by da48524eb20662618854bb3df2db01fc65f3070c. Fixed by 243b422af9ea9af4ead07a8ad54c90d4f9b6081a. 2.6.38.2 has the first commit, not the second. (2.6.38.1 has neither). I don't know if anyone is going to backport the fix into a 2.6.38.3 or something. There's no possible user-space workaround, except for not using glibc aio at all.

I updated to kernel 2.6.38 (from 2.6.36), and now I get this error, so it definitely seems kernel-related.

They probably round their numbers upwards - our data says ~80% of all users have nearly 2GB which probably means they nominally have exactly 2GB before deductions. (Also Macs are much higher-end than typical Linux machines (which make up most of our data).) I don't think the data would be useful enough to be worth any non-zero effort. The game itself shouldn't care about RAM, so it's only relevant for drawing this kind of graph and figuring out whether we should set minimum requirements to around 1GB or 2GB etc, for which the current data is sufficient.

The game works fine for me when Gamin is missing. I'd guess the problem might be when using a 2.6.38 kernel, given it's only started recently - I can try testing that myself when I next reboot. Has anyone run on 2.6.38 without getting this error, or has anyone got this error on earlier kernel versions?