Ykkrosh

That file is just the compiler output, it's not something we distribute, so either your compiler is generating infected files (which seems quite unlikely) or the antivirus software is getting confused (in which case maybe they have a service where you can report apparent false positives).

Hmm, first time players probably won't want to worry about micromanaging combat to the extent of separating differently-ranked units, and currently they won't understand what the rank icons mean anyway (we'll need some kind of tutorial to teach them about experience and ranks etc). I've disabled the rank icons for now, to avoid the visual clutter - probably would be good to revisit it once ranks are an important part of gameplay and once we have a way of explaining them to players. Ah, I forgot about that problem, and it's a large enough majority that it seems important to address. Maybe this is a case where a configuration option would be worthwhile, so we can default to the cleaner style but have a higher-visibility alternative. Regardless of outlining, is the green-on-red health bar a problem for red-green colour blindness? (If so, maybe we should adjust the brightnesses or put a black line between the two segments or something.)

I updated the copy of Boost in SVN (used when compiling on Windows, to avoid the pain of people having missing/outdated dependencies) to 1.44 (previously 1.35), so that it should be compatible with VS2010. Does anyone have VS2010 to test it in, and/or are there new problems in any other version?

The patent covers both encoding and decoding. I believe Mesa doesn't include a decoder. main/texcompress_s3tc.c just imports fetch_ext_rgb_dxt1 etc implemented by libtxc_dxtn, for when it needs software decoding. force_s3tc_enable works because all GPUs support S3TC decompression natively and Mesa simply has to pass the compressed texture data blindly to the hardware. I don't see any colour differences in those screenshots - the matching areas (adjusting for rotation) look identical when I toggle between them, and seem to have very similar RGB values, so I'm not sure what problem you're seeing.

(I saw it in the scrollback and wrote down a reminder, but didn't have time to fix it until now.) Agreed - done in r8343. I think comparing names is not a good solution, since it's inflexible (maybe we'll want a treasure chest you have to destroy before gathering its contents, etc) and introduces unpredictable side-effects when changing names. Better to add an independent flag to trigger the hunting behaviour.

NVTT FAQ: which I believe means Linux distros providing NVTT packages would be covered.Most distros already seem to provide packages for DevIL, which includes a S3TC compression algorithm (which would be affected by the same patents as NVTT) and isn't covered by any form of patent license, so they should be no less willing to provide NVTT. Debian apparently dislikes only actively-enforced patents, and I don't believe the S3TC patent is enforced in this context (only in GPU implementations). If the patent is a real problem, dropping NVTT wouldn't help the game anyway, since we have our own S3TC decompression algorithm in the engine (to decompress the textures at runtime when the user doesn't have S3TC support). We'd have to remove that too, and then the game would totally fail to run for most Linux users.

The non-crashing error messages are all data file errors, I believe - the 'projectile' ones should be easily fixable by adding a projectile prop to the actors.

Time doesn't matter to me (as long as it's before something like 2300 UTC). (By the way, it looks like DST stops around the end of this month in most places, so we need to be careful about that when suggesting times.) I find it very valuable to have your contributions whenever you're able to have time, so it'd be good for me for the time to be convenient for you

Yes. (And it's only precompressed textures because including both versions would substantially increase the download size, and most users will never want the uncompressed ones, and it should be easy enough to find the uncompressed ones via SVN.) Yes. No. We want to support mods well, which means the game still needs to handle dynamic conversion of textures even if the standard bundled ones are preconverted.

Hmm, it really ought to be detecting the right library and switching automatically. I've got no idea why it's not

configure:12691: c++ -o conftest -fno-strict-aliasing -pthread -pipe -lpthreads conftest.C -ldl -lm 1>&5 /usr/bin/ld: cannot find -lpthreads collect2: ld returned 1 exit status That seems to be the eventual cause of the error. The first signs are where it says configure:9449: checking for pthread_create in -lpthreads gcc -o dummy dummy.c -fno-strict-aliasing -lpthreads -ldl -lm configure:9577: checking whether gcc accepts -pthread configure:9695: checking whether mmap() sees write()s configure:9738: gcc -o conftest -fno-strict-aliasing -pthread -lpthreads conftest.c -ldl -lm 1>&5 /usr/bin/ld: cannot find -lpthreads collect2: ld returned 1 exit statuswhereas on my (Gentoo) machine it says configure:9449: checking for pthread_create in -lpthreads gcc -o dummy dummy.c -fno-strict-aliasing -lpthreads -ldl -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lpthreads collect2: ld returned 1 exit status configure:9472: checking for pthread_create in -lpthread gcc -o dummy dummy.c -fno-strict-aliasing -lpthread -ldl -lm configure:9577: checking whether gcc accepts -pthread configure:9695: checking whether mmap() sees write()s configure:9738: gcc -o conftest -fno-strict-aliasing -pthread -lpthread conftest.c -ldl -lm 1>&5 configure:9763: checking whether gcc needs -traditional So it looks like your system is accepting the "-lpthreads" command the first time in the dummy program, but not later when it tries to actually use it. Do you have a /usr/lib/libpthreads.so and/or /usr/lib/libpthread.so? What version of GCC do you have?

Someone (from OGA) said So I was thinking it might be good to move this list and the relevant pronunciation information onto the Trac wiki, so they're public, and see if some people can do some recording. We don't need voices urgently but we can make use of them now - if they're good quality then they'll add some nice variation to our current lone Greek male, and they don't need to be perfect since we can always replace or add to them later if we change the list of phrases.

Should be fixed. (This will slightly change the pathfinder behaviour, so the replay will be invalid now and can't be used to verify that the bug is fixed, unfortunately.)

That usually means you're passing it an incorrect filename (e.g. one with "~", or writing "-replay foo" instead of "-replay=foo", etc). (This isn't meant to be a widely-used feature, which is why it's not at all documented or user-friendly )

Thanks, I get the error with that. Will try to debug it later today. You can run the replay with: ./pyrogenesis_dbg -replay=path/to/commands.txt(but don't use "~" in the path).

The game should create a file ~/.config/0ad/logs/sim_log/${PID}/commands.txt each time you run it, which can hopefully be used to reproduce errors like this. If you can find one that corresponds to a run which produced that error, could you upload that (and say exactly which SVN revision you're running)?

Hmm, actually (after painful investigation) it's a bug in NVTT, which peculiarly seems to be triggered only by that specific version of GCC, as far as I can tell. I'll patch our bundled copy of NVTT tomorrow, which should fix this texture thing for you. (The shadow issue is completely unrelated, though.)

Aha, I can seemingly reproduce the texture compression if I compile with GCC 4.4.4, but not with 4.3.4 or 4.5.0. (This is on Gentoo amd64). So it looks like a GCC bug. But since Ubuntu defaults to GCC 4.4 I guess it's a bug we have to find a workaround for

Oh, interesting, it looks like the artifacts are introduced by the texture compression process, not by the rendering.In that case: If you delete ~/.cache/0ad/ then run the game again, does it still have those artifacts? Are you using the default bundled copy of NVTT, not a different version (installed into /usr/include/nvtt etc)? What's the output of the "Building NVTT..." section when running update-workspaces.sh? What OS and CPU architecture are you on?

Actually there's no need, I reproduced it myself - it fails when the vertex buffer allocator happens to allocate the final index of a buffer (which is why it seems random), since we pass the wrong end value to glDrawRangeElements. Fixed.

Hmm, looks like lots of artifacts to me . Should look like this - there's a big quality difference in the face, the grass, the back of the shield, etc. Just to check it's not a bug in the texture compression code, could you upload the file ~/.cache/0ad/art/textures/terrain/types/grass/grass1_spring.dds.*.dds ? Can you reproduce it often enough that you could catch it in a debugger? (Put a breakpoint on _mesa_warning, I think, then do a "bt full" if it hits it.)

Hmm, looks kind of like a bug in the driver's S3TC handling, but I'm not sure why it only affects that texture. Maybe because it's scaled up, and/or has no mipmaps? Do you see similar texture issues anywhere else, e.g. if you do shift+D and disable "restrict camera" and zoom in so other textures get scaled up? Does it change if you edit binaries/data/mods/public/art/textures/ui/textures.xml to say mipmap="true"? That looks like the shadow map is getting generated correctly, and the horse's shadow is faint but clearly separated from the edge of the shadow map, but in the main display the dark edge cuts through the middle of it. So it seems the problem is somewhere between the generation of the shadow map and the application of it. I'm afraid I don't know enough about the rendering code or OpenGL or potential driver bugs etc to understand the problem more, though (By the way, another useful console command is "?gameView.lockCullCamera=true", which locks the position of the camera used for shadow generation and lets you move around and see it from other angles. Probably won't help much here, though.)

I added rank icons too. Do they work okay?

It's not just blurred, it's got patches of black and blue that really shouldn't be there.

Does the unit's icon (in the bottom/center) really look like in the screenshot? (That looks rather ugly - it shouldn't be like that...) When you have the shadow problem, could you press "g" to disable the GUI and "`" to open the console and enter "?renderer.displayFrustum=true" ? That should make it render the shadow map in the top left corner, which might help show something about the problem.