Ykkrosh

I just saw that gDEBugger is being released for free (currently via a license file) - it's a cross-platform OpenGL debugger and profiler, which seems potentially handy for graphics work. It can log all the GL calls, show the textures that are loaded and generated, show the current GL state at breakpoints, disable certain functions to help identify bottlenecks, etc. And it works with 0 A.D.

The engine is just part of the game, so download the game from SVN and you'll get all the code . (The engine isn't a standalone project, but it's designed so most of the game-specific stuff is in data files and can all be replaced.)

Cinematics in Atlas won't work. (I don't remember whether they're very broken or only a tiny bit broken, but I'm pretty sure they currently are broken.)

Not by default, but if you run it like "pyrogenesis -mod=foo -mod=bar" then it'll load the public and foo and bar mods (with bar overriding foo, and foo overriding public).

I think the only ones I've ever seen are this/this/this.

Okay, that's the one I expected - I think it's this bug. Have you tried disabling shadows and/or fancy water (in the in-game menu, I think)? That might help with performance. We should probably skip that warning when nos3tc has explicitly been set. That's an issue with SDL on Linux - I don't think there's anything we can easily do about it, unfortunately

If you run the game from a terminal, does it print any error messages? particularly ones saying a texture format is not supported? (I think the problem may be that the open source ATI drivers can claim to support S3TC texture compression when actually they don't.) If you create a file ~/.config/0ad/config/local.cfg containing the line nos3tc=true then does it work any better? If so, could you post the output of running "glxinfo" (so we can work out how to detect these drivers and disable S3TC automatically)?

I just mean posting the changes here on the forums, so I know what lines you had to fix. The SVN account is only needed for committing to the main repository, which I don't think we want to do now (it's better to get it fixed upstream instead).

Ah, glad you fixed it, since I wasn't having any ideas of what to do about it . Could you perhaps post your changes (via "svn diff" or something)? If so, I could send it to the SpiderMonkey developers to get Python 3 supported there.

Thanks - I've added some stuff in r8663 so it should detect the broken driver versions and tell people to upgrade.

Could someone with NVIDIA drivers (either the broken ones or upgraded/downgraded ones) post the output of running "glxinfo", and the content of ~/.config/0ad/logs/system_info.txt ? (Hopefully that'll include enough information to let the game detect these broken drivers, so in the next release we can give an informative error message to users.)

Makes sense to me - it'd probably be technically very similar to how we handle textures. Rather than adding a dependency on FLAC we could probably just put very high quality (e.g. 320kbps 48000Hz) Vorbis files in SVN, since I expect that shouldn't cause any noticeable degradation after re-encoding (does anyone have reliable facts about this?). Then we can easily experiment with different bitrates (maybe higher for music than for speech, etc) and re-encode everything automatically for distribution. Apart from the minor downsides of increased SVN download size and some more code to write, I can't think of any real problems this would cause, and it would give us much more consistency and control over release size vs quality, which would be good. Probably the best approach to getting this done is to start by telling people to put very-high-quality Vorbis files in SVN, and see if we can find higher-quality versions of the existing music tracks. The game will continue to load them as normal, and when we've got enough to make it worthwhile we can add some code to re-encode for distribution.

Yes - in the actor file, just add a new variant with name equal to an animation name (idle, walk, etc), and give it the replacement prop/mesh/etc, and it'll pick that variant when playing that animation.

Simulation scripts can use print() (goes to stdout - not very useful on Windows) and warn() and error() to log messages. I think UnitAI probably doesn't need any significant changes in direction - the HFSM design seems to work okay so far and the code just needs incremental fixes and features. But "okay" isn't "great" and there may be better ways of doing this Player AI is independent of that, and the technical design hasn't really been discussed at all. What I imagine is that it would be entirely script-based, and each AI player would run in an isolated script context (potentially in a separate thread), using something similar to what the GUI uses (components/GuiInterface.js etc) to query the current simulation state and then output a list of commands to run. This new AiInterface thing would be more powerful than GuiInterface since it needs to return details about terrain etc, and needs to provide efficient access to large amounts of data. The internals of the AI script would be entirely dependent on what the AI scripter chooses to do, so we can let people experiment with that once the basic interface is sorted out and we probably don't need to decide on a single way of doing that - it would be good enough to start with just some predefined build orders and some timers to trigger an attack on the enemy, to get the system tested and running.

No, except the shootout ones which usually seem pretty broken because they're not using comparably optimised algorithms for everything. The results vary hugely depending on exactly what benchmark you run - it's probably hard to be more specific than saying SM is several times faster (maybe 10x or so) than interpreters for other scripting languages (Perl, CPython, etc) and a bit slower than LuaJIT (which has a much simpler language to compile) and a bit more slower than Java/C#/C++/etc.

Thanks, that does help - looks like the problem is this code crashes when there's a 0-byte config file (probably ~/.config/0ad/config/local.cfg in this case). Fixed in r8634.

Sorry, forgot to reply to this earlier... If you're still around: The packages have been rebuilt a while ago for the latest release - does that happen to fix these problems? They're built by OBS, so I'm not really sure what it does in terms of dependencies or how to go about debugging it

I updated SpiderMonkey to the latest bleeding-edge version, for improved performance when we start doing more heavy calculations in JavaScript. It ought to work fine, but there's a chance it might introduce some compatibility problems - if you find any then please let me know. One issue when updating SVN is that you might get errors running update-workspaces.sh, because of a Makefile looking for files that were deleted. If you get that, try running clean-workspaces.sh (in build/workspaces/) which should delete the outdated build files and let you start again cleanly.

Better if you log in first, though - they say "guest votes only count in the event of a tie".

I'm technically able to capture 720p video using GLC on Linux, which I did for the alpha 1 gameplay video, but it takes quite a bit of time to set everything up and copy all the files around and I've got plenty of other things to do so I'm probably happier if other people can do it

In case the checkout is incomplete (it sometimes seems to abort before it's reached the end of the process), the TortoiseSVN "Update" command (when run in the top checked-out folder) should make it continue downloading the rest.

Queuing is shift + right-click, I think. Possible idea: use right-click-and-drag, kind of like bandboxing, to select a group of targets rather than individuals, and your units will each choose one target from that group (randomly? nearest? something else?). Don't know how hard it'd be to make it work intuitively with all combinations of sources and targets, though. Whatever the UI, the tricky cases are when a unit can't reach every target - melee units attacking enemies behind the first rank, units gathering trees that are too deep inside a forest, etc. It's hard for a unit to work out which targets it really can reach (it just has to pick a target and try pathfinding, and if it fails then pick another and try again, which is slow), and I'm not sure what's a good way to implement it so they'll do something sensible. The current design is that it's the user's responsibility to click precisely on targets that are going to be reachable, which makes the coding easier.

Is this fixed by the 260.19.21 drivers? They say: which sounds relevant.

There are various cases where I think it'd be quite useful to automatically collect data from the game's users. E.g.: * If we knew what platforms (OSes, OS versions, Linux distros, etc) were most commonly used, we could focus on testing and improving compatibility and packaging for those, and not worry so much about the obscurest platforms. * If we knew what graphics hardware/drivers people used, we could decide how much to worry about known compatibility problems (broken S3TC on open source ATI drivers, crashes on specific NVIDIA drivers, etc). * If we knew what graphics hardware/drivers people used, and their typical framerates, and their graphics options (fancywater, shadows, etc), we could build up a database of sensible default graphics settings to get decent performance, and work out where to focus on optimisations. * If we knew about crashes or assertion failures, we could try to fix them. * If we had data on how often people use various GUI buttons and hotkeys and gameplay features, we could work out which could be removed or should be advertised more clearly. (The last point is a bit hypothetical now - we need to finish more of the game and add a tutorial etc before we could have a clearer idea of usability problems - but I think the others would be useful during our current stage of development since they will help us deal with problems that are already occurring.) Also it would be useful to send some data back to users (without requiring them to download a new release): * If people are not using the latest release, we can tell them to download it and tell them what's new. * The game could download updates to the graphics driver database, so we can quickly push compatibility/performance fixes. What I'm imagining is that the game will include an HTTP client library. That will be used to download release news and compatibility database updates on startup (asynchronously so it doesn't slow loading, and with caching so it doesn't use much bandwidth, and anonymously) from some site that we control. For uploading, the engine will occasionally produce some data (system configuration on startup, average framerate every 5 minutes while playing, etc) and send it over HTTP to a service on our site. (Actually it'd probably save into a local log file first, and then periodically try to upload until it succeeds, to cope with offline users and server downtime without data loss.) The uploaded data would aim to be anonymous (don't include usernames or chat messages or directory names or IP addresses etc) and would use a randomly-generated-on-first-run user ID to correlate data. The user would be told clearly what data we're going to collect and asked to opt in or out before anything gets uploaded (though we'd strongly encourage them to opt in since it'll help improve the game). The raw data would be saved on the server, and I'd like to make the data publicly available so anyone can analyse it (we shouldn't be proprietary about it) if that's not too risky. We'd then develop some tools to sort through the data and try to extract useful information from it. An initial implementation of this shouldn't be particularly complex - primarily it involves adding libcurl as a dependency, writing the asynchronous download/upload system, writing the server side (probably trivial in a standard web framework), and worrying about anonymity (carefully check all the uploaded data and anything that can be derived from it) and security (probably should do everything over HTTPS and hard-code the server's public key etc). Does this seem potentially useful and worthwhile or pointless and problematic?

When reporting problems, it's very helpful to include the exact text of the error notifications . (I think in Windows the logs are saved in %appdata%/0ad/logs/, and on Linux in ~/.config/0ad/logs/, and then interestinglog.html should contain the errors, if you need to copy-and-paste.) Kieran is probably correct here - I've started the autobuild update so it should be uploaded within an hour and will hopefully work better.