historic_bruno

You're correct, this is reproducible on a test map without AIs. I'm not sure it's fishing boat specific though. The problem seems to be when a unit is gathering from a resource supply such that the gatherer reaches max capacity at the same time the resource supply becomes exhausted - which is quite likely if there's a single gatherer and the supply is an integer multiple of that gatherer's capacity (multiplied by the gather rate?). The gatherer never becomes aware that the supply was exhausted (which would cause it to give up on the current target) so it enters the infinite loop of gathering "near" the last target, which of course no longer exists.

What does this mean, are you saying it's fixed or not?

Yeah, why not create one or two new message types and have CmpVisualActor subscribe to them. The message data could possibly be a list of variant strings, this is assuming the variant system gets "upgraded" to support applying only one variant at a time instead of replacing the entire list. The only thing to avoid is using model data to affect the simulation but it doesn't sound like you're wanting to do that.

Pretty sure that's http://trac.wildfiregames.com/ticket/1604 - if you can, undo that update to continue playing 0 A.D., while we work on the fix.

. I agree with others that there never really were "sea walls" but rather walls built upon jetties or along the shore. I think we should allow walls to be built into shallows so that we can properly close off a beach to enemy units. Right now, it is impossible to build walls out far enough to do this. Walls need slightly looser build restrictions compared to "normal" buildings, IIRC the problem is a technical one: how to specify this in terms of (pathfinder) passability classes. If there's not a ticket for it, I will make one.

That's a known bug, Deiz is looking into it, but the solution is a bit tricky: http://trac.wildfiregames.com/ticket/1600

It may be caused by using a script to launch the game instead of running it directly, though that should work and seems to work for other distros. Does the error not occur if you run /usr/bin/pyrogenesis directly? Any chance you could use gdb and inspect some of the variables in e.g. Paths::Root() and sys_ExecutablePathname() (especially path)? It's harder to know what might be happening without any more data.

Release blocker: http://trac.wildfiregames.com/ticket/1604

Erik is correct, make sure the model is a single mesh or it won't import into the game.

Thanks, that's very illustrative What's with the AO(?) artifacts on the farmstead though?

Hi, to use props you need to define "prop points" in the parent model. For static / non-animated models that's easy, just create an empty object in Blender and give it a name starting with "prop-" or "prop_". Position the prop however you want it to appear in-game. The engine will see those objects during model import and create prop points for them, which can be referenced in the actor XML files.

For now, performance testing shouldn't include AIs because they are a known cause of problems. That aspect won't be much changed in Alpha 11, maybe slightly improved. We haven't really focused on performance for this release, but rather getting major new features in (improved sound system, graphical enhancements, gates, etc.) So I'd expect Alpha 11 performance to be roughly similar to Alpha 10, hopefully no worse and perhaps better

I think we're ready for feature freeze at least

Enrique's problem was also resolved, his default.cfg file was outdated due to SVN conflicts. r12458 provides some defaults for misconfiguration, other than complete silence

Oops, looks like I built a debug lib by accident. Try this one OpenAL32.dll.zip

I wouldn't call them "sparkly" though, more like fireflies rising from the mine or something. OK it makes them stand out, but it's not what we wanted originally Specular is probably not noticeable enough for small flecks, but what about adding a new shader effect that reuses the specular map? Something that can add an occasional glint or bling to arbitrary objects, noticeable at distance (enabled in the material of course, as an addition to specularity). It would look nice on spear tips, swords, helmets and such. Replicating that with particles would be difficult, we'd need to actually add prop points all over the different models.

At first I thought I agreed with this after using the new DLL. But after minimizing distractions in the room and doing a comparison, I can't hear any audible difference between using the different DLLs. Of course that's on my system and it could well be different on someone else's. However comparing the new sound system with Alpha 10, you're right - the music sounds quite a bit different, it seems less dynamic and "rich" now. It doesn't seem to be only a difference in volume. Could it be a difference in how the OGG file itself is handled and played? Maybe we set some parameters before to boost the sound. Anyway I'm glad to hear it fixes your crash

If anyone wants to try something, download the attached file and copy it to the game's binaries/system directory, replacing the old one. This only applies to Windows users of course, I'm curious if it will solve any of the problems or create new ones. OpenAL32.dll.zip

Again, http://svn.wildfiregames.com/docs/writing-components.html mentions pretty much everything being asked and unlike half the stuff mentioned here, it's actually up-to-date. It's not the "friendliest" document to read, but it works.

Continuing to delve into this. Apparently the OpenAL32.dll we bundle with the game is in fact OpenAL Soft as of r7279. If you download the latest OpenAL Soft win32 binary, the accompanying readme has this notice: We do the latter, not sure how relevant that is to the current problems. We could at least update the OpenAL Soft lib to the latest v1.14.

Just so you know, between Xcode 4.1 and 4.3 there have been significant changes. Whereas before the command line tools were bundled with Xcode, now it's a separated ~160MB download available through Xcode preferences (or you can download them freely from ADC if you have an Apple ID, but I would recommend using Xcode so it will properly integrate). I think 4.2 is late enough that GCC was no longer bundled, but if say, you upgraded from an earlier version, then you might have fragments of GCC around in addition to LLVM. The process could be even more confusing if you upgraded from Snow Leopard. Also, installing a new Xcode won't clean up the old pre-4.3 developer tools (in e.g. /Developer) nor will removing the old app bundle, so you'll have to run the dev tools uninstall script - I would do that before upgrading. One nice thing about upgrading is that Xcode updates are now incremental, instead of requiring a new 3GB download every time, you can upgrade components via download preferences. Also if you'd like to try Git and have an itch for a decent OS X build environment for the game, I've been working on a Github fork. I use it to build the official app bundles we distribute. I'd love to know how it handles your build environment at any rate and if the graphical defects disappear, as other people report similar problems when using Mac Ports and Homebrew, but not with our bundles, so I'm also inclined to blame a faulty build environment and the mercurial nature of Apple's dev tools.

That's a known problem, but this topic isn't for reporting bugs or performance issues

I think your build environment is slightly confusing or confused. It's quite possible to build the game on Lion with Apple's llvm-gcc, the only thing you have to do is define CC=gcc and CXX=g++ before update-workspaces.sh, since Spidermonkey's config script defaults to looking for gcc-4.2. I wouldn't go mixing compilers at each step though, just pick one (preferably Apple's latest command line tools for Xcode) and do a clean build.

We've been discussing this a bit in IRC today. I did some investigation into the old snd_mgr and the new, the big difference I see in OpenAL initialization is that previously it occurred on demand, when a sound was first opened, now it happens early in the game's init process. I also dug into the SVN history and couldn't find any reason for the on-demand init, other than maybe a slight decrease in the game's startup time. But maybe if that code hadn't changed in at least 8 years, it was covering up some other problems we are now encountering? It works for me too, both on my old 32-bit WinXP and my new 64-bit Win7 PC. I also tested on OS X and it works fine.

That's weird, it should be a Mach-O type. It seems there was a problem building that library, assuming it even came from Mac Ports, I thought Mac Ports used /opt/local for it's files?