historic_bruno

I suppose it goes without saying that you're using the latest SVN? Which graphics card and driver are you using?

Oops, I think it's r12173, in particular the change made to avoid adding rpath with --with-system-mozjs185. The rpath is also needed for libCollada.so. In my own build I use our bundled Spidermonkey so the rpath was set and I wasn't encountering the error. It was a rather useless change even if it had worked.

I"m suggesting that you temporarily revert to help us find the problem. We can't fix it without more information, it works fine on my Ubuntu (11.10) test system and I haven't seen anyone else mention this problem. Reverting to a prior revision is not hard, just do: "svn merge -r currentrevision#:workingrevision#" where workingrevision# is the last time you knew it worked; then you can selectively update with "svn update -r revision#" until you go from one that works to one that's broken -- that gives us something to work with. You only need to test revisions that altered build/ or source/. If you can't find a working revision, it's more likely a problem on your end. When done all you have to do is "svn update" and you're back up-to-date. You mentioned it working here: http://www.wildfiregames.com/forum/index.php?showtopic=16256 so r12147 is a starting point.

Artists shouldn't be using releases for development anyway, so it's no problem if they start working on completely new stuff in the middle of a release cycle, after all that's part of development While it might be nice to attract new contributors with fancy features like AO/normalmapping/etc, IMO it doesn't particularly matter if that happens in A11, A12 or later. And also, no one says they can't start working on AO and normal maps now and wait to see how they look in-game. I think we've shown the concept is possible and probable. As far as the difficulty of creating an SVN patch from Git, since we have to commit to SVN, someone has to go through that pain...

It was originally a single button but was changed at the explicit request of Mythos and Pureon (as I recall). I like the two-button layout myself, then you don't have to guess about whether the icon reflects current or intended state.

Nice work It came in handy (for me) very often in AoK. One reason is AIs were stupid and would often let an enemy army into my towns with their traders, villagers, or other units, at the worst possible time. Though a good enemy AI would target the gates first, so it was taking advantage of another bug or inadequacy in that case Another reason is for management of your own units passing through the town, you might want to force them to use a certain entrance, so all other gates can be locked most of the time. The real value of gates depends on what style of play you favor. If you're more aggressive then you probably won't care much for gates or walls, but if you have a defensive style, they make a big difference.

Can you try reverting to previous revisions until you find one that works? It seems like it was working here: http://www.wildfiregames.com/forum/index.php?showtopic=16256 If you can pinpoint the broken revision, it would be very helpful.

Can you please mention which SVN revision you're using when you get these errors? Also I committed a manual build in place of autobuild

Just to notify devs that as of r12183, the actor format changed slightly to accommodate myconid's rendering improvements (namely multiple textures per model). If you edit the XML by hand the following: <texture>path/to/texture.png</texture> changes to: <textures> <texture file="path/to/texture.png" name="baseTex" /> </textures> "baseTex" is the name for the base/diffuse textures that we've been using to this point. There will be other options once AO, normal mapping, etc. are implemented. Existing actors in SVN have been updated, so this is mostly for those who may be working on new actors. Actor Editor has also been updated to support the new <textures> element, I'll be updating the Trac documentation accordingly.

Hello and

First thing to check, is libCollada.so present in binaries/system?

Can we see the full log? Maybe fcollada failed to build, at least the error indicates there is no libCollada.so found.

Looks like you need an updated build. If you rely on the Windows autobuild, unfortunately it has stopped working. I will try again, otherwise we must wait for Philip to fix the problem (no one else has access to the server).

Hi, we need more information, please see http://trac.wildfiregames.com/wiki/ReportingErrors It would be helpful if you post your system specs (OS, graphics card, driver, etc.) and the game's crashlog files if possible. Also tell us about your setup, do you have one monitor, are you running the game fullscreen or windowed?

According to https://build.opensuse.org/package/show?package=0ad&project=games we don't build a Fedora 17 package yet. I'll let Philip know, and hopefully it'll be available soon Meanwhile, you can always try compiling the game yourself: http://trac.wildfiregames.com/wiki/BuildInstructions

Before the next release. It's fixed now

The originals are in SVN, you can browse it online here: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/ It's highly recommended for contributors to use SVN anyway so they're working with the latest development version of the game. If you want to checkout the repo, there are instructions for Windows here: http://trac.wildfiregames.com/wiki/TortoiseSVN_Guide

We need native word(s) for the Celtic gates. A quick search uncovered the terms "duro(n)" (Celtic/Gaulish?) and "dor" (Welsh/Breton?) for door/gate apparently related to the word "hard". From this Wikipedia artcle: http://en.wikipedia.org/wiki/Bayeux#Etymology I'm not sure about the terms of the other gates and walls. Maybe we need to revisit them now that a wall system is implemented and people will be using walls more often.

Right. It should be noted we always intended a single "Celts" faction, the idea originally was you could choose between either Gauls or Britons once you reached the city phase (we were going to do this with other factions as well, like the Hellenes). Really the only art difference we officially intended was the fortress design. Otherwise they would have been a blend of aspects of both cultures. It wasn't until recently that they were split up on a whim without a lot of discussion beforehand. I wasn't privy to the original discussions or designs, so I don't know what to tell you about why the current design was chosen, but I can say it was never on the art team's radar to redesign Celts yet again Probably this discussion should be moved to the new Art Development forum.

I'd prefer closer screenshots for scenarios, selected to show close details of each map. In other words not rushed through in a huge batch or by some automated process

Might be a good use for animated textures, especially for small pools of water, aqueducts, fountains, etc. Possibly combined with particles but I think we should not overdo particles. A similar effect could be achieved with a mesh shaped like a fountain of water, with an animated texture applied to it, animated in the direction of water flow. A specular map could be applied to it as well to give an added boost. Something fancy could be done with shaders, but then non-shader hardware misses out on this simple effect. I think this would add a lot of life to the game (water is essential for life after all). If you guys want to work on generic animated textures next, it would be great to have

That's strange. Can you make sure you have updated drivers for your Radeon HD 5450?

The error message isn't very helpful yet. Any logs you can provide would help, and also see http://trac.wildfiregames.com/wiki/ReportingErrors -- what we really need is the backtrace/callstack when the error occurs. The link describes how to find this.

A little stretching isn't going to be that noticeable and it's much less effort to put a single constraint on the images (512x512), rather than saying the result has to be 512x512 but make sure it looks OK when cropped to an arbitrary ratio that could change whenever we modify the UI (and similarly for requiring the user to "pre-stretch" the image to an arbitrary ratio which gets offset again by the engine).

The link I just posted suggests that among other things. Until it takes effect the old saying applies: "old habits die hard"