Ykkrosh

How does the user interface work in that case? Do you control just one player like normal, then click a button to switch to controlling the second player, etc? Or can control all the players' units at once? in which case how does it work if you try selecting groups of units belonging to multiple players, how does it decide between attack and repair actions when right-clicking on a building, etc? The game engine can easily support this, and it sounds like a nice feature, so I think it's just a problem of figuring out what user interface would make most sense.

Files like data/mods/public/art/textures/terrain/types/biome-desert/desert_city_tile_plaza.xml define the "movementclass" of terrain types. data/mods/public/simulation/data/pathfinder.xml has <MovementClasses> that define the movement speed and pathfinder cost of each class, for each class of units (based on their <CostClass> in simulation/templates/). Probably it doesn't work well at the moment because it's not defined for many terrain types, or for many unit types, and there's probably a bug that stops it working for groups of more than one unit. But at least the engine basically supports it

I started working on this a few days ago, by bundling a copy of ENet 1.3 and using that unless you build with --with-system-enet (similar to the current --with-system-nvtt), but I couldn't get it to work on Windows (it keeps complaining about stupid CRT manifest stuff) so I temporarily gave up. I should get back to it soon when I have more patience

Hmm, true, it would probably be legally fine, but this is an open source game project and the lobby/master/meta-server is an important component of the project so I believe it morally should be open source too. It probably wouldn't make much difference in practice since ideally only one person in the world at a time will be running the server (to avoid fragmenting the community), but it matters in principle and I'd prefer to not compromise on principles unless there's a hugely compelling reason (On a technical level, from looking briefly at the code it seems to have a fundamentally broken approach to cryptography (it uses rand() for keys and salts, which destroys any security properties it might otherwise have, and it XORs with a session key instead of using stream ciphers properly, etc) which doesn't indicate high-quality design, and it's written in C with lots of pointers and fixed-size arrays so I'd have no confidence that it isn't full of potential buffer overflow vulnerabilities etc. I think security is critical for servers (at least in principle, which is enough) and it'd likely take more effort to audit and test and fix code written in C than to start from scratch in an easier and safer language (e.g. Python). So I think there's good reasons to reinvent wheels )

Yeah, sometimes I change my mind when trying to write down summaries, but I haven't yet, and nobody else has expressed disagreement, so I've started working on porting stuff back to C++ now.

Regardless of any technical issues, that code's license prohibits commercial use ("provided that all use of the Software is for non-commercial purposes only"), so it's not DFSG-compatible open source and we couldn't use any of it if we wanted to

The Program Files directory requires admin access to modify, and the game's installer tries to avoid asking for admin access (because that's inconvenient and insecure) - it's like when programs offer an option of "install for everyone" or "install for this user", but (for simplicity) it only supports the "install for this user" option. As far as I'm aware, %localappdata% is then where per-user installation is meant to go (on Vista / Win7).

To match the overall theme of alpha 6 and a minor shift in the game's emphasis, the words should be related to lasers. I suggest Fluorescence.

It's unlikely that the final release will have significantly higher requirements than the alphas, and we'll do more optimisation work so it might even get faster

That looks like Radeon 9200 (on Windows), which was released around 2004 and doesn't support the necessary shader features, so the game will use the compatibility mode for rendering. We should probably implement particle support in that mode, so it won't work with alpha 5 but hopefully it will in future releases

Hmm, that says it's compiling amd64.cpp and amd64_asm.asm so it seems to think it's a 64-bit system when running update-workspaces.sh. build/premake/premake.lua makes that decision based on $HOSTTYPE and "gcc -dumpmachine" - what values do those have? (Our architecture detection system is definitely a bit fragile )

What OS are you using, and what graphics card and drivers? If you're on Linux with the non-Gallium-based open Radeon r300 drivers then there are various driver bugs so the game falls back to a compatibility mode which doesn't support particles. Otherwise it should only fall back on extremely old hardware/drivers, and particles should work the rest of the time.

Hmm, I don't know what might cause something like that. Could you upload/attach a screenshot of what you see? Also if you post the file ~/.config/0ad/logs/system_info.txt too that might help.

They're disabled by default on most Intel graphics devices. What is your one called? ("glxinfo|grep renderer" should say.)

Is that the first error message when you run "make"? (I'd expect it to have complained when compiling ia32.cpp/amd64.cpp or something, if it's ending up without those symbols defined.) Do you have a 32-bit or 64-bit kernel, and do you have a 32-bit or 64-bit userspace? ("uname -m" and "echo $HOSTTYPE" might say.)

Looks like that's got a UniChrome graphics thing, which only does OpenGL 1.2, which is never going to work . Probably the only way to run the game is in software graphics mode (set environment variable LIBGL_ALWAYS_SOFTWARE=1) but that'll almost certainly be unbearably slow. The game can work okay on modern Intel integrated graphics chipsets, but I don't think there's much hope without either that or a dedicated graphics card.

Some random points about the current situation: * Atlas supports some parts of the UI being written in JS instead of C++, in particular the panels on the left and bottom of the main window (and not any other parts of the UI like the menus or the toolbar). * I think UI scripting is nice primarily because you can tweak the layout coe and see the change instantaneously, instead of waiting 30 seconds to recompile and restart. * There's some bugs caused by (lack of) interactions between JS and C++, e.g. toolbar and panels not staying in sync when selecting tools. * Atlas relies on wxJavaScript to let JS create and manipulate GUI widgets. * We use an old version of wxJS which has some minor missing features (e.g. tooltips), major missing features (e.g. wxAUI which does dockable windows and toolbars and stuff, wxPropertyGrid), and various minor bugs. When writing new JS code it's fairly often necessary to fix some of the minor problems in wxJS's C++ to get it to work alright, which destroys some of the benefit of writing in JS. * New versions of wxJS seem to have pretty much the same problems, with little active development, and also have a dependency on another large library (POCO). * I'd be surprised if wxJS didn't have some compatibility problems with future versions of wxWidgets (2.9+, which is released but not common yet); it already triggers some deprecation warnings. * There's some odd bug when using wxJS with a recent version of SpiderMonkey - all the GUI widgets get stuck in the top left corner of their panel and the automatic layout doesn't occur. I spent a few hours trying to debug it and totally failed. (That's the main reason I'm worrying about this now.) * The Atlas UI currently seems to be about 17K lines of C++, 1.5K lines of JS. * Some of the JS was originally ported from the C++, so the C++ still exists in the history somewhere. I think fixing Atlas's UI scripting system to work decently would be a large amount of work: fixing the SM upgrade bug (I have no idea how long that would take - probably it's something trivial but I don't know where to look), improving the interaction between C++ and JS, and continually adding features and fixes to wxJS as they're needed. I think porting the scripts back into C++, and then deleting the scripting system, would likely be less work in the long term: there's not that much JS code, and it'd be a bit tedious but straightforward. (I'd be willing to do that work myself). The only real loss would be the speed of reloading changes, which can be alleviated by buying faster computers. The only user-visible changes should be minor improvements. (I think porting Atlas from wxWidgets to Qt and using QtScript for scripting might give a better end result but would take far too much work to be worth it, so that's not a serious option.) Thoughts?

That's normal (though arguably a bit weird) - it reports what version of the code was compiled, and on Windows it compiled the code from r9529 and then the resulting executable got committed as r9530 which is what is released.

Hmm, I have gzip 1.3.12 on 32-bit Ubuntu 8.04 which works fine, so that's odd

I've had some success using glc on Linux with the instructions here.

They're uploaded a few days before announcing the release for some quick testing and setting up packages etc, and sometimes we need to fix things and delete them and upload a newer version, so it's best not to link people to the release files before the release has been announced, but it's good to test it in advance What version of gzip do you have? ("gzip -V" should say). The .gz files are created by 7zip so maybe it's doing something unusual that certain versions of gzip don't like, or something? I think the danger of using version numbers is that they can be wrongly meaningful, e.g. 0.0.1 sounds like an extremely primitive first version, and an upgrade 0.1.0 -> 0.1.1 sounds like a very minor change, and a version 0.9.0 sounds quite close to 1.0.0, etc. I think that was why I wanted to use SVN revision numbers instead - these releases are effectively just snapshots of SVN, and we're not claiming anything about the current state or the magnitude of changes etc. They're a stupid idea since they tie us to a linear non-branching SVN-based development model, though - we can't apply a bugfix to a release if there's been lots of other SVN activity in the meantime. That's not been a serious problem yet but should probably be sorted out before starting a hopefully-more-stable beta release series (and maybe have 0.1.0 for first beta, 0.1.1 for bugfixes to first beta, 0.2.0 for second beta, 1.0.0 for first release, 1.1.0 for first significant changes after release, etc, or something like that) - I'm not sure if it's worth the inconvenience of changing now in the middle of alpha releases, but beta seems like a good opportunity to fix some of the current mess.

Ah, if it's quaternions then I think that diagram makes sense - if you convert from Euler angles with a constantly-increasing angle then the W component is a cosine curve, and the other components are sine curves scaled by some axis-dependent value. (Adding more keyframes would let it be a better approximation of sin/cos). (Quaternions are weird and make no logical sense, but they're nice mathematically). I have no idea if Blender gives the option of switching to Euler rotation, which would work with straight-line parameters instead.

I used to have that on the Linux / OS X pages, but I think I removed it because it took not quite zero effort to maintain and it wasn't clear anyone ever cared about it, and the SourceForge page will already tell you the checksums if you need (though not for alpha 5 since that hasn't been uploaded there yet). Could add it back if there's much demand, though.

Hmm. Maybe my understanding is wrong, then . I guess I need to look into more detail to figure out what's actually going on.

It's the same when training units - it picks a point just outside the building's footprint, in the middle of the side it assumes is the front (hopefully our buildings all match the same directional convention), and if that point is blocked (by another unit or building; we should check for water etc too) then it picks another point about 1/30th of the way around the footprint in one direction, and then keeps alternating direction and expanding outwards until it finds a free space (else it gives up and prints an error message). (Not sure this is ideal, but it's what it tries to do currently.)