Ykkrosh

Probably would be nice . #664.

File formats may be slightly relevant (but not very). Non-skeletal meshes typically just have the automatic "root" prop point and nothing else, which is what you see in those files. Skeletal meshes have arbitrary user-defined prop points, and we support (and use) that in DAE files (as well as in the old PMD files). Non-skeletal meshes also support arbitrary prop points - I think that's not used by current files, and it's barely been tested (I only used it for importing meshes from Spring as a joke), but it should work.For non-skeletal meshes, I think the structure you need is <visual_scene id="Scene" name="Scene"> <node id="Cube" type="NODE"> <translate sid="location">0 0 0</translate> <rotate sid="rotationZ">0 0 1 0</rotate> <rotate sid="rotationY">0 1 0 0</rotate> <rotate sid="rotationX">1 0 0 0</rotate> <scale sid="scale">1 1 1</scale> <instance_geometry url="#Cube-mesh"> <bind_material> <technique_common> <instance_material symbol="Material" target="#Material"> <bind_vertex_input semantic="UVTex" input_semantic="TEXCOORD" input_set="0"/> </instance_material> </technique_common> </bind_material> </instance_geometry> <node id="prop-main" name="prop-main" sid="prop-main" type="JOINT"> <translate sid="location">0.002287388 4.07996e-4 4.418324</translate> <rotate sid="rotationZ">0 0 1 0</rotate> <rotate sid="rotationY">0 1 0 0</rotate> <rotate sid="rotationX">1 0 0 89.99999</rotate> <scale sid="scale">1 1 1</scale> </node> </node> </visual_scene>(untested). In particular, you need a <node> called "prop-something", and it needs to be nested inside the main mesh node (the one that contains <instance_geometry>). Then you should be able to use attachpoint="something" in actor XML files. I think it doesn't require type="JOINT" on the prop node - it can be a type="NODE" if you want. If I remember correctly, Blender has some not-entirely-obvious 'link' command which can be used to set up hierarchies that will be exported to Collada like this. Skeletal models are very different - they need a skeleton (lots of type="JOINT" nodes) plus a skin (which is some complex controller thing in Collada). Then you add prop points by having prop-* nodes as children of the skeleton's joints. But the game won't let you have a skeleton without a skinned mesh, so you have to do the non-skeletal approach instead.

As far as I'm aware, that error happens when the game has previously crashed while writing some cache files (particularly due to NVIDIA driver crashes). You can fix it by deleting the ~/.cache/0ad/ directory and starting the game again. (The latest version of the game in SVN should handle this error more gracefully.)

(Nobody's disallowed from doing anything - the technical problem is that non-rubbish first-person control is incompatible with the engine's design (it would have terrible lag, coarse collision detection, etc, as well as the poor texture quality and rendering performance) since it was designed as a top-down RTS engine, and I'm not very interested in working on inevitably-poor features when there's plenty of other things to be working on instead. Also nobody's going to be strongly motivated by someone who spends half their time on IRC demanding that people implement their pet features and the other half insulting them.)

You should also add "fancywater=false" into the local.cfg file (just in case it's managing to use that mode), and maybe experiment with reducing the resolution (put "xres=320" and "yres=200" or whatever resolution you want), and you could also try "renderpath=fixed" and see whether that makes any difference. I used an Intel 945G some years ago and I think it's always going to be quite slow, though

Re wacko's changes on Github (readable diff here skipping spurious line-ending changes (clearly Git is inferior to SVN )), which updates the configuration system: I think it's useful first to look at what we actually need from the config system. A random collection of things I think are needed: * Key/value string pairs. (In particular we haven't wanted to extend it to support complex value types, nested sections, etc, so the simple approach is still fine.) * Clean integration with engine code that uses configured values (simple type conversions, some mechanism to ensure consistency when a value used by various things changes, etc). * Default values for everything, specified in a human-editable (i.e. containing comments) config file. The file will be shared by all users so it has to be a read-only file. * Per-user non-default settings, edited through an in-game options screen or by hand (in case they can't even launch the game). * The options screen allows changing options (usually(?) without them having immediate effect), then clicking "ok" (which applies changs and saves to disk immediately) or "cancel" or "restore all defaults" or "restore this particular setting to default" etc. * When changing video mode, if the game fails to set the new mode then it should revert back to the old working mode (so it needs to support some kind of simple rollback operation). * Some options can be changed outside of the options screen, e.g. using alt+enter to toggle fullscreen mode. Those changes probably(?) shouldn't get saved to disk. * When a user installs a new version of the game, they shouldn't lose their custom settings, but they should get our new default values (e.g. if we change a default hotkey then they should be using the new default unless they explicitly overrode it before). * We want powerful modding support, and mods may want to add hotkeys but probably shouldn't change any other options (since the other options are engine things, not gameplay things; gameplay things need to be network-synchronised instead of loaded from config files). So mods at least need a way to define their default hotkeys (in a way that supports multiple mods being active at once). Users should be able to enable and disable mods, and to override the mods' default hotkey bindings. I'm not sure if I'm missing lots here, or if some of these aren't really needed, but I think they're probably reasonable. My main concern with wacko's changes is that they help satisfy a couple of these requirements (which is good) but appear to ignore the rest (any may need to be largely rewritten to support them). (Also, looking at implementation details, we ought to be trying to minimise use of singletons and global variables (mainly since they make unit testing much harder - better to be explicit about object lifetimes and entry points when possible), and I'd prefer to avoid using ScriptGlue.cpp and CJSObject and ToPrimitive etc (I've been migrating code away from them in the hope of eventually deleting them entirely, to simplify our C++/JS bridging). Also there's various trivial issues, like code in lib/ is meant to be independent of the game and shouldn't depend on code in ps/, and like using strtol (unsafe since it depends on locale - probably should use/extend our existing code that handles these things more safely already).) Anyway, I believe it's important to fix the current config system (since it certainly doesn't handle the requirements above and it has similar implementation problems), which probably involves largely rewriting it - I just don't think this patch is really the right direction to go in. I don't know exactly what is a right direction, but I'm happy to discuss it and help work out what's needed.

It should work fine from SVN without -writableRoot. Could you try running it in a debugger to see where it's failing? ("gdb ./pyrogenesis_dbg", "r", wait for the segmentation fault, "bt full", "q")

Qt may be a better choice now, but wxWidgets was the only cross-platform toolkit with an acceptable license (before we were GPL (and before Qt on Windows was even available as GPL)), and porting all the existing code to Qt would be a great deal of work for relatively little gain.

Lighting is primarily a renderer issue - currently the engine only supports a single directional light, and adding additional directional lights or non-directional point-source lights would likely need a lot of changes (and may hurt performance). But it shouldn't really be complex (lighting is a well-understood problem), and it would be nice to have. I'd be happy to add it to the editor if someone adds it to the renderer

Could you run "glxinfo" from a terminal, and copy the output here? (That should indicate what graphics drivers you're getting the problem with.)

Firebug disables the JIT, so its measurements are pretty meaningless (at least once the game's able to use the JIT properly). (The SpiderMonkey developers have some plans to make their debugger API compatible with JIT, but I don't think they've even started implementing that yet.) About RangeOp: Hmm, looks like that's mostly used by TileClass::countInRadius. If the tile sets are usually very sparse, it could possibly be much more efficient if implemented as a quadtree; or it could test distance to clumps rather than to individual tiles, or maybe it could precompute some kind of influence map, or something. Probably lots of ways to optimise it

Hmm, it ought to make a significant difference if it's working (it should inline all the stuff in inner loops and it sounds like that's the bottleneck here) so I guess something is stopping it from working (the tracing JIT is apparently quite fragile and will fail if things aren't set up exactly right). If you have a runnable patch some time I'd be interested in playing with it to see how to take advantage of the JIT. There's a binaries/system/rmgen.exe in SVN so you should be able to simply run that version, I think.

You could possibly see if JS execution speed is the issue by uncommenting JSOPTION_JIT in ScriptInterface.cpp (it was disabled since we haven't needed the speed yet, and there's less chance of hitting bugs when not using the JIT). Profiling C++ is usually easy with e.g. Valgrind's callgrind tool (on Linux); I'm not aware of any decent tools for JS, other than writing explicit timer code to figure out what's slow, or using the F11 in-game profiler (which should record JS function call times when running in Debug mode, but might not be easy to use in this case). For typed arrays, I guess we should do something like this (using the not-quite-public-but-not-really-private APIs from jstypedarray.h) in ScriptInterface::FromJSVal<std::vector<u32> > and similar overloads, to specialise them for the appropriate typed array type.

Sounds nifty . That implementation approach seems sensible to me. I know nothing at all about actually writing RMS scripts, so I can't say anything useful on that - hopefully there's plenty of people with RMS experience in other RTS games who could suggest what'd be good. Where does the map format get involved? Do you actually generate XML/PMP files and then load them in? (It sounded more like everything was loaded from the JS data structures, not via an intermediate file format, in which case I'm not sure how the map format is part of it.) Progressive loading sounds like unpleasant complexity here - RMSs will often be written or modified by inexperienced users, so I'd probably be happier to keep the script control flow as simple as possible. If it takes a non-negligible amount of time, we could perhaps run it in a separate thread to avoid freezing the progress bar.(Incidentally, if you're not doing this already, the RMS should probably be run it its own unique ScriptInterface (not the simulation's one), so it has independent RNG state etc and so there's no danger of unexpectedly influencing the simulation state. Then we could move it to a new thread without any chance of upsetting SpiderMonkey.) Yeah, SpiderMonkey nowadays is hugely faster than when we started, so I'd expect performance to be fine. If not, we could publish our slow code as a JS benchmark and let the SpiderMonkey developers optimise their engine for us Moving the C++ code into JS seems to have a lot of benefits - it'll be more secure (less chance of e.g. buffer overflows when running untrusted RMS scripts), less buggy (less chance of e.g. GC errors), simpler (we can avoid the complex JS/C++ object bridging code), more flexible, etc, so I think it's worthwhile. (Also I've thought for a while that having a web-based environment to run RMSs would be quite nice - it'd be a quick way for people to develop new maps without the bother of running or even installing the game. If most of the RMS system is already rewritten into JS, then we can emulate the C++ engine API (just rendering the map as a 2D top-down view of the world or something) and it may not be too hard...)

It crashes when running 0 A.D., therefore it is definitely related at least to that extent . But I agree it's sounding like a driver bug we can't avoid (except by telling people to use other drivers), if it affects other games too (that's useful information), and other distros, and when definitely not using CUDA (so pretty much the only 'unusual' thing we're doing to potentially trigger the crash is putting some CPU load onto an unrelated thread).Since we seem to have lots of Ubuntu users hitting this problem, is there a good way we can recommend to them to install older working drivers (presumably better using the proper package manager rather than manual installation)?

I think I can fix that fairly easily - most of it can stay the same, it just needs to interact properly with GUI pages and scripts. (Should be able to start that tonight.) r8444 should fix the problems I'm aware of.

r8440. (Haven't changed any of the other sheets (in session/icons/sheets/ for formations and resources etc), since they probably need manual work rather than an automated script.)

More resource notes. One thing that I haven't seen a design for is the UI: how does a player know when/where they need to build more dropsites? E.g. when you tell a unit to gather some trees that are out of range, what happens? (Error message? Pick the nearest in-range trees? Shade the out-of-range trees in red and/or display range circles around dropsites, when selecting a gatherer and moving the mouse over resources; or display nothing, or something else? What if there's too many gatherers for a given dropsite? What should gatherers do when their dropsite is destroyed? etc) I think I can fix that fairly easily - most of it can stay the same, it just needs to interact properly with GUI pages and scripts. (Should be able to start that tonight.)

This could be related to the texture compression which get executed only the first time the game is run. This is a specific problem of the Ubuntu package, see: http://www.wildfiregames.com/forum/index.php?showtopic=13670 Hrm, I hadn't thought of that. If that's the case, deleting ~/.cache/0ad/ should reset the game to its initial state (where it crashes immediately on startup). If so, the proper release packages shouldn't crash (since they don't do runtime texture conversion) but we still ought to understand and avoid the problem. Texture compression shouldn't be system-dependent unless it's using CUDA acceleration via NVTT - see Compressor::Compressor() in libraries/nvtt/src/src/nvtt/Compressor.cpp for the detection. Can anyone tell if the game has compile-time and/or run-time CUDA support? (Apparently running the game in gdb typically causes it to work without crashing, so it may be tricky to reliably debug this.) If that's the problem, can someone trying editing source/graphics/TextureConverter.cpp around line 517 (immediately after "nvtt::Compressor compressor;", before "compressor.process") and add the line "compressor.enableCudaAcceleration(false);" and see if that makes any difference?

This seems to be a common problem with the NVIDIA drivers on Ubuntu 10.10 - I don't know if we can do anything about it ourselves.

Yeah, that seems correct . I don't know why it's the wrong data files.

It should be pretty straightforward to generate a stats table from the game's XML files - there's already some Perl scripts in source/tools/entity/ that compute the stats for a unit (accounting for template inheritance), and they could easily dump it as a simple non-inherited XML file that could be transformed into an online database.

Looks like the OOS was just caused by using self-compiled vs autobuild exe. Got a rough profile graph, but SpiderMonkey ran out of memory at the end (there seems to be something pretty broken in its GC).

Screenshots via F2 are saved in ~/.local/share/0ad/screenshots on non-Windows

I changed it to 500ms for multiplayer (it's best to be a factor of 1000 to avoid drift with some 1-second timers). What SVN revision (of .exe and data files) was this?