Ykkrosh

Thanks, uploaded here. That sounds like useful experience! I think there's three main things we currently need: more stable textual content (so there's enough to be worth translating and so it won't all become obsolete a few months later), technical work to support translations (extracting strings from the game, making the engine use the translated strings), and organisation and management (getting volunteers to do the work and merging it all and checking quality and getting it updated for new releases etc). The first part might take another six months or so (though that's just a wild guess); the second part would probably be fairly quick once we know what tools we want to use (but we don't know yet and don't have any experience to decide what's good). The third part I have absolutely no idea about. So the plans are currently quite flexible/incomplete, and there's a lot of opportunity/work here - if you have suggestions for how we could get a good translation system running, that'd be very helpful . I don't think we're doing anything unique here, so we should just build on experience from other games and from other translation work and try to make something good.

Thanks, uploaded here. (Sorry I didn't get to this sooner, I left it open in a background tab and then never got around to handling it )

Hmm, the cursor thing doesn't sound good. Have you always had this problem? Does the mouse appear/disappear if you use alt+enter to switch between fullscreen and windowed? Do you have any non-standard cursor-related system settings?

There currently isn't any way to reset the camera - would be a good thing to add. #582. The "big screenshot" command saves into (I think) "%appdata%\0ad\data\screenshots" (enter that address into Explorer and it should open to the right place).

Sorry, I forgot to get back to this . I don't see any obvious problems, but it looks suspicious that it says WARNING: Break-in timed out, suspending. This is usually caused by another thread holding the loader lockand threads 3 and 4 seem to be blocking while requesting that lock. Thread 4 looks a bit weird, running "ScanSoft\OmniPageSE4\OpHookSE4.dll" - that sounds like some background process/service is injecting itself into other applications. That probably ought to be safe, but are you able to disable that process and see if anything is different? An alternative thing to try: can you open the folder "%appdata%\0ad\config" and create a file local.cfg containing noframebufferobject = trueand see if that makes any difference? (If it does, it'd still be nice to know why that breaks it, but it sounds like it might just be a graphics driver bug or something.)

I think it's probably best to just remove our code that uses libbfd, to avoid this kind of problem - filed as #581.

Yep, the PMP is the terrain heightmap and texture data, the XML is everything else. For map data that is just used by GUI scripts or simulation scripts (and eventually by the map editor too), the XML file contains JSON data in a <scriptSettings> element, so it should be straightforward to add player data into there.

Actually that's not quite why - the rmgen tool is an external executable that creates .pmp/.xml files in a slightly old format, and the engine should still be compatible with that old map format. The problem is mainly that it's an external executable, which makes it a pain to build and to integrate with the game engine. Also it's got a lot of C++ code exposed to scripts, which is not great for flexibility or for security (I doubt it's impossible to crash, and it'd be nice for RMSs to be perfectly safe to download). I think the best approach would be to rewrite most of it, putting a minimal layer in the game engine and then porting all the interesting functionality (the algorithms for terrain generation and object placement etc) to pure JS. (JS is fast nowadays, and SpiderMonkey provides typed arrays that can efficiently represent terrain heightmaps, and we could probably do nice stuff like provide a browser-based development/debugging environment for RMS.)

Welcome The problem with changing civs is that it doesn't really make sense for static maps - they're created in the map editor with specific buildings and units for each player, and there isn't a 1:1 mapping onto equivalent units for different civs so we can't easily change them automatically, and in some cases they'll be history-based scenarios so changing the civs would be illogical. It'd work much better with random map scripts, since they can programmatically construct whatever starting units are suitable for each player based on their civ selection and other parameters, but we don't currently have a working RMS system . The current vague plan is to try to get RMS running properly some time soon (i.e. within the next several months, when someone has time to do it) and then have it integrated with the GUI for civ selection. Nobody's currently working on any of that, though.

Hmm, so I looked around a bit and found a clever idea for improving the pathfinder performance. The search algorithm finds all the objects near the moving unit, and looks for a path to the destination going between the vertexes of the objects. When it looks at some vertex X, it wants to find all vertexes Y that it can reach in a straight line without intersecting the edges of any objects. The original implementation looped over every Y, and looped over every edge to look for intersections with the line XY. With N objects that's O(N^2) intersection tests, repeated for O(N) vertexes. Rather than do that, it's possible to effectively map the two endpoints of each edge onto two angles relative to X (kind of like polar coordinates). When looping over Y, you can then compute the angle of Y relative to X, and only edges whose angle-range overlaps Y's angle need to be considered for intersection testing. Finding the overlapping ranges can be done in roughly O(log N) time using an interval tree, which improves on the O(N) cost of looping over every edge. (In practice there's a lot of lower-level optimisations - edges are split according to the four axis directions, and then instead of computing angles like tan^-1(y/x) it just uses the value y/x (represented as a fixed-point rational), since tan is monotonic over the relevant range, and the interval tree contains enough data that the intersection test can be reduced to a single coordinate comparison. The interval tree doesn't need dynamic updates so it just generates a balanced binary tree inside a std::vector so there's not a lot of memory allocation.) The only problem is, in all my testing, it's never better than about 50% slower than the naive O(N^2) method . I don't see any obvious bottlenecks, it's just a high constant overhead from sorting lists and setting up the interval tree and searching down the tree. Then I realised that although the current implementation has lots of optimisations for axis-aligned shapes, our trees were (unnecessarily) set up as non-axis-aligned shapes, so I removed all this new algorithm stuff and changed one line in a data file and then a bunch of units walking through a forest became 6x as fast as before

I added some. Thoughts? Bugs? Missing features? etc

Saving shouldn't be technically difficult, since the simulation engine already supports everything that's needed (I think) - it'll just take some time to write all the code for saving all the data (currently only perhaps half of it is saved), and some effort to test it all and make sure it's reliable. The same code is useful for other features (multiplayer sync-checking/resyncing, playtesting in Atlas, replays, etc) so it'll be good to get it working soonish.

I'm not aware of any advantage of using V8 over SpiderMonkey (and it'd be a lot of effort to change between the two).

I'd usually recommend using an existing graphics engine rather than writing one from scratch, and Ogre looks like a reasonable choice. There doesn't seem any point rewriting all the functionality that those libraries provide, unless you want to do something radically different or boundary-pushing. But in our case we already had a custom renderer working before anyone seriously suggested using Ogre (which was ~5 years less mature than it is now), and it's always seemed easier to incrementally improve our code rather than switch everything to a new graphics engine. I think our current renderer architecture is good enough (though certainly not fantastic) for what we still want to add, so it's probably not worth the effort and disruption of switching.

I think the glwprintf error is because vswprintf on OS X doesn't like non-ASCII characters when running in the default locale - it's not a fatal problem but it makes characters like “ and ” on the menu screen fail to render. It causes a test failure when you run ./test too. (I don't know what the right fix would be.) (I don't know what's up with the 32/64-bit thing either )

Have you tried Blender 2.5? It looks like that's had a lot of Collada-related changes, and in the long term it's probably much more useful to support that rather than 2.4. (I still don't know whether it'll work perfectly out of the box - I noticed a few importer problems but haven't tried exporting.) By the way, converting to triangles before exporting shouldn't be strictly necessary now (I re-enabled code in the engine's importer to automatically triangulate meshes), but it's probably still best to do so - the automatic triangulation might do unexpected things (there's more than one way to triangulate a polygon) so it's safer to convert it and check it in the modelling program.

The Unity player survey is interesting (particularly compared to the Steam survey - the Unity data is probably biased much more towards casual players). 1024x768 seems pretty common.

Command queuing was in the first alpha release - hold shift when giving orders and it should work (I think). Maybe displaying something like a quick animated circular pattern on the ground when you give a move/attack/etc order (with different colours for different orders) would be good, for immediate visual feedback. Should be easy to implement if we have the art for it.

That's already implemented . You can put XML files in a directory, saying what settings (DXT mode, mipmaps, etc) to apply to its files. When you edit the settings it'll automatically reconvert all the affected textures (which means we don't have to get it right right now, we can tweak it later). It'll automatically switch to DXT1 if the texture is entirely alpha=255, so normally you shouldn't need to worry about specifying that mode explicitly.

Yes - we use OpenGL, not DirectX

I delete the spam topics whenever I see them - any ideas on how we could better prevent them in the first place?

Should be fixed now.

I see the cause (I used the sem_init function which apparently isn't supported on OS X). Will fix soon.

/usr/lib/xorg/modules/dri/r600_dri.so is the graphics driver, so it sounds like the bug is there. Several people have reported problems with the drivers for ATI hardware - I think they were fixed in later versions, so upgrading things like Mesa (maybe to a git snapshot, I don't know if it's in a stable release) might help. Otherwise you should probably report it as a driver bug.

What version of the game is this? Can you run it in a debugger? ("gdb /usr/bin/pyrogenesis", "r", wait for crash, "bt full")