historic_bruno

Hi! Some details about your system would help, can you attach the system_info.txt from the game's log directory? Recently there were improvements to the game's multi-monitor support, but it also depends on your OS.

You could do that in-game as well, by disabling Restrict Camera in the developer overlay (Alt+D), and you could hide the GUI with Alt+G. Atlas is probably more convenient though

The floating panels are nice for a demo, but IMO they should be docked more like the current Atlas UI by default. I can see in the previews that it was necessary to move the panels around a lot to work on the terrain or whatever is behind them, which would be annoying if it was the default behavior. Otherwise, let's get it reviewed, tested, and committed

Is there a local but not a .local directory? I think that should be ~/.local/share/0ad/, unless it's different on your Ubuntu for some reason. That is the correct place to put your mods, don't put them in cache or config (nothing good will happen if you do).

Also, in case it's relevant, multiplayer is slightly broken in Alpha 18 for OS X 10.7-10.8. For 10.7, it will instantly crash, and for 10.8 there will be an instant OOS. Newer versions should be fine though, and these issues will be fixed in the next release.

I like that idea! Need to pass it along to trompetin17, who is working on a variety of Atlas improvements.

I don't use Fedora, and different distros use different naming conventions, but it's listed as a package here: https://apps.fedoraproject.org/packages/nspr-devel Also on CentOS, which also has yum, I typically use "yum search <<keyword>>" when I want to find a package. "yum search nspr" might find it for you.

Any reason why you would want that and not fully random maps? Skirmishes/scenarios are going to be mostly static by design, introducing randomness to them feels like they are becoming a random map instead. That being said, the old RMGEN tool had a way of loading scenarios into the map generator, so it is possible to have random maps based on static maps, and manipulating things like the environment or terrain. The API for that doesn't exist yet, but would be possible to add.

Probably an oversight, I think previously it was assumed system SM (libmozjs) would be used by default with those commands but the situation changed since the upgrade to SM 31. Still, libnspr4 is listed as a dependency for all distros.

Cool! It would be nice to have a mode where the camera rotation will interpolate along the path, too, rather than having to hardcode all the rotations. It could point tangentially along the path or whatever looks best. Does that make sense? Maybe it's too much for the first version of the patch.

You don't say exactly what you need: a detailed guide on how to write an AI in 0 A.D., or a very basic skeleton of an AI where you insert whatever logic you imagine it needs? Do you need a very high level API that has most of the functions already implemented, or a low level API that provides data and you implement the rest? For 0 A.D.-specific questions, you could ask one of the other AI devs.

It works on XP SP3, though in A18 it's necessary to patch the broken AtlasUI.dll file (see this post). In A19 it won't be necessary.

Yeah, you shouldn't have a problem finding a decent, cheap PCI-e graphics card that works with Linux. Years ago, I upgraded my old computer from a GeForce4 Ti (pre-shaders) to a GeForce 7600 (one of their last to support AGP) and it really helped game performance, even though the overall system became too unstable to use anymore.

Hmm, it doesn't list PCI express (PCIe), maybe they didn't include one on that motherboard, though it's advertised as a feature of the chipset... Care to open the case and take a look at the PCI slots? This image shows the different types side by side: http://en.wikipedia.org/wiki/PCI_Express#/media/File:PCIExpress.jpg

That is an integrated graphics card from the Via chipset. For some reason, Debian has chosen or defaulted to a software driver for you. You may have a few different options. First, you need a better driver, and surprisingly there is a project called OpenChrome that works to develop open source drivers for your Via. If you want to try installing the driver, it's available as a Debian package: xserver-xorg-video-openchrome. I don't know what performance you will get with that, probably not worse than software rendering, but it might not work at all or it might have a lot of bugs (it's always a risk with drivers). I'm no expert with Linux drivers. The next option would be to buy a better discrete graphics card. According to this page, you have a PCI express slot, which is good - that would let you buy just about any graphics card from the past 7-8 years (I wouldn't spend much though, and you would have to check your power supply's max output). Please post the full output of running "lspci" to confirm this.

Are you running in a VMWare virtual machine? That wouldn't be a good idea on your system. In any case, it's using software rendering, which will be extremely slow even on brand new computers. If you're not using a VM, you need to find better graphics drivers. What is the output of this command: lspci | grep VGA

Can you post your system_info.txt from the game's log folder (see this page)? That should give us an idea of whether your system can run 0 A.D. well. Another thing that might help is a profile capture with Shift+F11 when you notice the game is very slow. Please attach those files in a reply.

If the game process is hanging, please run it in gdb and then break into the debugger and find the backtrace with "t a a bt full" (see this article for more details)

I agree with what Alexander says, and if that doesn't fix it, maybe the download was corrupted?

Sorry, I've been quite short on time lately and didn't have a chance to follow up on this. I'm attaching a fixed version of AtlasUI.dll, which you can copy to the install binaries/system folder. I have tested and it fixes Alpha 18's Atlas editor on XP SP3 for me. AtasUI.dll.zip If you still need it, that should do the trick for you

That's really interesting, I never imagined people would use games that way, much less 0 A.D.

It wasn't an easy decision to drop older OS X support, but there wasn't much choice, once we decided to use C++11, that restricted us to libc++ on OS X (libstdc++ didn't have adequate C++11 support), which in turn limits us to 10.7+. I will discuss it again with leper, r16226 might have broken the libstdc++ build, but I was never sure why that was necessary.

Note that it is currently possible to impersonate other players by sending network messages (commands) on their behalf, and that is something that should be fixed. There is a TODO in the server code about that. I think that would be a reasonable place to start.

If someone makes the animations, you will see that

Which version of the game is this? Did you build it yourself or is it from a package? Which map? It might help to provide the commands.txt for that game, from the game's log directory. According to the profiler snapshot, most of the time is spent in "unlogged," which is interesting.