dvangennip

I get an error similar to the one by zoot above with the current SVN version: ERROR: Failed to compile shader 'shaders/glsl/sky.vs': ERROR: 0:10: 'assign' : cannot convert from 'attribute 4-component vector of float' to 'varying 2-component vector of float' If I try to view the sky (with alt+Z) it turns out completely white. Also, now the blackness that should cover everything I have not yet explored is not completely black, but rather 10% transparent or so. I can thus see the features of the terrain (but not any building or other entities). Upon launching it is ok, but when I reveal the map (with the developer panel) and then turn it off, it never goes back to completely black. This was not the case last time I used it (not too long ago).

From my little testing the increased visual quality affects the performance not that much, because it is mostly handled by the graphics card. Otherwise, it is easy to turn off. The lag/slowness is mostly due to the CPU having a very hard time, for the reasons given above.

I guess the simplest solution is to use a page on the 0 AD website which lists all known mods in a table, with the latest version of the game known to work (e.g., the Rise of the East mod may no longer work now textures are handled differently). From this page you could link to a mod webpage. Installation is not too difficult, and handling it automatically may be a bit more involved at this point (no complete, playable mods are available). It would however be nice to simply enable installed mods from without the game, by scanning the /mods/ folder on launching the game.

Hi, the lag is a known problem with the game. Basically the bots take up too much time to make their decisions, plus the pathfinding is not yet optimal. I think a new bot to be included with Alpha 11 might help a little towards the lag. One other problem is that the game is single-threaded, so only one core is used. With a quad core processor it means there is a lot of processing power which could be thrown at the aforementioned problems, but the game is not yet ready to do that

Yup, ships can garrison even battering rams Not sure about elephants though, at the very least Hannibal cannot be garrisoned aboard a quinquereme.

I have noticed the same black health bars and black minimap a few days ago. Moving the view usually did away with the effects, unless I moved back to the old position. I did not check the water, as far as I noticed it didn't occur on the water (or this was not in view when things went black). I used a Macbook Pro 15" from 2007, so a quite different system (Nvidia 7800GM GPU), so it is indeed probably not a driver issue. This was with preferglsl=true, as well as the other relevant settings set to true.

I have noticed this as well, usually with quite a few units tasked to build. A simple fix in game is that you set those units to move away, and then task one unit to build. After this, it should work, perhaps because no units are now blocking the foundation as suggested by historic_bruno.

I just ran into an error, which might have been mentioned before, but anyway: here it is. It happened after half an hour (maybe shorter) of gameplay, and I think it had something to do with my Roman cavalry finally going after the chickens near the civ center (lazy bugger ). It seems related to this ticket (crash upon selecting an entity), although I am not entirely sure (perhaps it is only superficially similar given the same error message). - Error creating initial buffer !! ERROR: error loading sound: pathname=audio/actor/fauna/animal/chicken_13.ogg, error=Function failed (no details available) (same messages for chicken_12, chicken_11, and chicken_10) Segmentation fault The first few lines of the OS X 10.6 crash window log look like this (the rest seems not particularly interesting): 0 pyrogenesis 0x00000001001ce9ed CSoundGroup::UploadPropertiesAndPlay(int, CVector3D const&) + 125 1 pyrogenesis 0x00000001000b3bce CCmpSoundManager::PlaySoundGroup(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, unsigned int) + 1374 2 pyrogenesis 0x00000001000da8d7 int ScriptInterface::callMethod<void, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, unsigned int, &(class_ICmpSoundManager), ICmpSoundManager, &(ICmpSoundManager::PlaySoundGroup(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, unsigned int))>(JSContext*, unsigned int, unsigned long long*) + 439 I was not able to reproduce the error, although I have seen this problem before. The audio files mentioned do exist and I can play them. Even in-game there was no problem when I tried the same setting once more. I used an up-to-date version based on the current SVN source code.

There is always a simple way to access the inner contents of an app bundle on a Mac. Ctrl-click or right-click on the app, and select 'Show contents.' Then navigate to binaries/data/mods/public. I am not sure whether Atlas actually saves the data there, or rather in the paths that zoot suggests above.

I guess that would be very hard on the player who cannot see where any (silent) attack on its walls come from, plus this player cannot take action against it by sending out a bunch of units against the sap point. This point could theoretically then originate inside a fortified area owned by that player, which makes it very hard to counter. My point is that it would unbalance the game situation.

This is normal, because the textures are converted in the background. For regular (Alpha) releases such things are pre-processed, now your system has to do it once the texture is requested. So nothing to worry about

You can start the game with a debugger, like this: terminal$: gdb pyrogenesis (some stuff happens) gdb > run (game should start) If a crash happens, usually you can type 'bt' to get more info (a stacktrace). Stopping the program is done with 'kill,' and quiting gdb with 'quit.'

A minor thing: I noticed the camera always had the same (default) angle. Perhaps changing it for some shots gives a somewhat different, and probably more dramatic effect. The only downside is that at the end of the map everything is black (there is no horizon or sky).

Perhaps those were Scythian mercenaries? According to WikiPedia the standard recruitment onboard a trireme was 10 hoplite Athenian marines, plus 4 Scythian archers. I have read flaming arrows were indeed used by such archers on ships, but I am not sure which civilisations did this. Anyway, it happened well before 1 AD, so historically there is no objection to have those in the game. I believe the flaming arrows are actually available in game, but perhaps no unit uses this type of arrow?

I just came up with a reason to have use for it -> if a multiplayer lobby is added, it could be a good way to find people nearby (if that is someone's preference). Also game statistics could be helped by this.

Google does it as well with their Chrome app. But the problem is code signing. From OS X Mountain Lion on, applications that are not from the App Store or signed cannot be installed on a Mac, unless the user has changed her default security settings. I guess changing an App Bundle would break this signing, which is probably based on a signature of the contents. If this is true, there could be a way around by having the 0 A.D. app being very simple, namely just an updater that puts everything, including the actual runtime application in /User/name/Library/Application Support/0ad/ and run it from there. The first time it gets started it will simply download everything, and as soon as that is done it acts as a shortcut to the real application.

I do have a an error that, at least in my case, is reproducible. Start any game, and simply resign. It gives the error pasted below on the command line. vfs.cpp(203): Function call failed: return value was -110101 (VFS file not found) Function call failed: return value was -110101 (VFS file not found) Location: vfs.cpp:203 (GetRealPath) A more complete crash window feedback was given by OS X. The full details can be seen in the attached text file. Hopefully this helps in debugging. Edit: I tried again with gdb, and it gave this stacktrace (better info compared to crash log of OS X): #0 0x00007fff895fd0b6 in __kill () #1 0x00000001003e90ff in VFS::GetRealPath (this=<value temporarily unavailable, due to optimizations>, pathname=@0x1436b49c0, realPathname=@0x7fff5fbfd3f0) at ../../../source/lib/file/vfs/vfs.cpp:203 #2 0x00000001001bf608 in CSoundData::SoundDataFromOgg (itemPath=0x1436b49c0) at ../../../source/soundmanager/data/CSoundData.cpp:99 #3 0x00000001001bfb54 in CSoundData::SoundDataFromFile (itemPath=0x1436b49c0) at ../../../source/soundmanager/data/CSoundData.cpp:78 #4 0x00000001001bdd73 in CSoundManager::LoadItem (this=0x10165aa30, itemPath=<value temporarily unavailable, due to optimizations>) at ../../../source/soundmanager/CSoundManager.cpp:143 #5 0x00000001001c608c in JMusicSound::Play (this=<value temporarily unavailable, due to optimizations>) at ../../../source/soundmanager/js/JMusicSound.cpp:40 #6 0x00000001001c726f in CNativeFunction<JMusicSound, false, bool, &(JMusicSound::Play(JSContext*, unsigned int, unsigned long long*))>::JSFunction (cx=0x102241ba0, argc=0, vp=0x12c22d318) at ScriptableObject.h:188 resign_CSoundData_VFS_error.txt

Well, especially archers tend to have difficulties with hunting chickens. They miss most of the time, probably because chickens are so small. It is a bit odd to see a hero archer take half a minute to kill a chicken. So, in that case archers could switch to a close-range knife (or some solution like this).

Well, maybe you can upload the texture here, and perhaps a screenshot of the result? Hard to judge for people without visuals I have not tried it in 0 A.D., but I have done similar stuff for a virtual reality application. It can indeed be a little tricky at first.

I know this can be filed safely in the category, but anyway: have you tried recompiling everything or do you use the automatic builds of Atlas? Maybe some recent graphics changes have altered something which makes an older build of Atlas trip.

That would negate the difference between support citizens (females) and citizen-soldiers (males trained at civil centre). Because support units are much cheaper (only 50 wood), their capabilities should reflect this. A better solution would be to have those weak units flee the scene. Currently they let themselves get butchered. I believe there was a discussion on this not too long ago, so there might be progress on this in the future. Spartan female units DO have some attack capabilities though, which is why training them costs 60 wood. Without sufficient attack strength and armour being able to defend themselves is only a stop-gap measure, I think. Eventually they would have to be moved to safer locations (or buildings) anyway, if the enemy attack involves more than just a few weak units.

I have tested both the GLSL and ARB shaders. Apart from the aforementioned corral + black square issue I have experienced no problems with the GLSL shaders (I used the regular SVN version). All the effects look good, there are no problems. Everything looks good, the LOS moves smoothly and responds well to being toggled by the developer panel option. ARB appears to work as always, I have not noticed anything odd. Well, there is something that is odd: last week I posted some issues with flickering, probably related to normals and my macbook's drivers. I have really tried to trigger this flickering with the current GLSL code, but I guess I have to accept it is gone Now, I did run into a problem when setting the renderpath to fixed (with preferglsl, gentangents, and smoothlos set to true, quality level 10). This gave a problem related to the LOS, I think. Setting smoothlos to false circumvents the problem. Maybe the smoothlos setting should be ignored if the renderpath is fixed (or there may be a fix, I don't know). A stacktrace can be found in the attachment, the crash happens right after pressing Start Game. Let's end with positive news. Importing a height map works as advertised Nice! It may be a good idea to specify in the Atlas manual page what kind of image size equates what map size. I tried a 1000x1000px image which seems bigger than the giant setting. P.S. Perhaps the second Mars temple actor can now be removed, and its textures added to the regular Mars temple? los_shader_error.txt

Would pontoons really add something to the game? I think that quickly building a dock by some of the civ-soldiers, and then having a ship shuttle troops across the water would result in the same thing. Actually, a simple but not super pretty solution would be to model a pontoon that is more or less as wide as a river. If the pontoon acts as a non-moveable ship you can move units cross by garrisoning them in the pontoon, and then ungarrison on the other side It could work as a 'specific scenario only' thing, although it is a bit dirty Otherwise the pontoon has to notify the pathfinder of being traversable, a much more difficult thing to do. Not that I am saying a pontoon should be in the game, though.

Unfortunately switching fullscreen is not possible on OS X, due to some weird behaviour. Sound may arrive soon to Macs, some people are currently testing this

Check the front page of the 0 A.D. website, it shows a teaser video of working gates