Ykkrosh

Better to have bug reports before it's released than after $ ls -l 0ad-r09530-* -rw-r--r-- 1 philip philip 5917753 2011-05-17 14:31 0ad-r09530-alpha-unix-build.tar.gz -rw-r--r-- 1 philip philip 4167180 2011-05-17 14:16 0ad-r09530-alpha-unix-build.tar.xz -rw-r--r-- 1 philip philip 168552462 2011-05-17 14:38 0ad-r09530-alpha-unix-data.tar.gz -rw-r--r-- 1 philip philip 142931332 2011-05-17 14:21 0ad-r09530-alpha-unix-data.tar.xz -rw-r--r-- 1 philip philip 169845547 2011-05-17 14:27 0ad-r09530-alpha-win32.exe $ sha256sum 0ad-r09530-* 713ce7f7f3a140b7a8b020af9acb991512f477620520fee8fd4d6e7bd76b1ed4 0ad-r09530-alpha-unix-build.tar.gz 4cbad45b085b412b48c4f3e27e8d808ff64d51d3ae479fd2ac108768af6a5336 0ad-r09530-alpha-unix-build.tar.xz c59c78e16260a401467a4b11c228a803fdd103f444a6dfe30dee321d45665153 0ad-r09530-alpha-unix-data.tar.gz 646f79b17f92872ff9a67d80ee5702d07219f8b3e3c91b438ce79fac2c33ed14 0ad-r09530-alpha-unix-data.tar.xz d6d3ea27ec04841f9a695fefdd98e5987f5b77928c16275df943fe19e759ccea 0ad-r09530-alpha-win32.exe They all seem to extract fine for me.

I happened to notice one TODO comment in the code which might potentially explain some problems with modifying skeletons.xml: when the game first successfully loads a .dae file it converts it to .pmd format and then caches the result (for efficiency); if the .dae file changes then it re-converts to pick up the latest changes, but if skeletons.xml changes then it doesn't notice and doesn't re-convert the models and will still use the old cached .pmd (which was built with the old skeletons.xml). You can delete the cache by deleting ~/.cache/0ad/ (on Linux / OS X) or %appdata%\0ad\cache\ (on Windows) which will force it to re-convert everything, or you can modify the .dae file (e.g. just export it again to update the 'last modified' time) to force it to get reloaded. (It would certainly be better if the code handled this properly instead of requiring manual deletion, so that ought to get fixed some time.) Technically it's not the Collada conversion that's the problem (I think), it's the way the engine handles looped animations. If the animation has keyframes A,B,C then the engine interpolates between A and B, then between B and C, then between C and A, then starts from the beginning again, in order to loop smoothly. There's no way it can handle a continuously-spinning wheel since that requires a sudden jump from one keyframe (360 degree rotation) to another (0 degree) when looping. The Collada converter assumes the input animation has keyframes A,B,C,A (which seemed to be how at least 3ds Max tended to handle looping, I think), so it always drops the last keyframe to get it in the format the engine expects. Maybe it'd be possible to change it to stop dropping the last keyframe, and stop the engine interpolating from the last keyframe back to the first (for models exported in the new mode), to let it handle this better. (Just to be clear, by "keyframes" I don't mean the keyframes used explicitly in the animation program - the importer flattens everything into 30 frames per second, which the engine then treats as the keyframes it interpolates between (to ensure smooth animation at >30fps).)

So you're building it yourself, but it fails until the not-built-yourself autobuild is updated? Sounds like you're not running the one you built yourself, in that case. Maybe something in the VS2010 project upgrade process breaks so it's not putting the compiled .exe in the right place, or is not compiling the .exe at all, or something?

Updated the autobuild now. (The SVN checkout has reached 2GB which was the size of the disk on the autobuilder, so I turned on NTFS compression to let it work for now). Do these errors still occur?

Done. The screenshot looks like alpha 4, and I think that framebuffer error on NVIDIA cards has been fixed, so hopefully it'll be okay in alpha 5.

The autobuild is out of date and will give the deepcopy errors - I'll try to get it updated today but it'll take a bit of effort since the autobuilder is broken (apparently it runs out of disk space when committing, or something). If you compile it yourself and make sure you definitely aren't accidentally running the old autobuild .exe instead, it really should work, since r9506 added deepcopy, and it works fine in my testing (on Windows and Linux). Looks like the autobuild will be causing "Function call failed: return value was -100303 (path contains both slash and backslash separators)" warnings too - a newer build should fix that.

What version of the game are you running, and what OS and graphics card? (There some known problems with that in alpha 4, but I thought they'd been fixed now.) That seems to be a harmless warning - I think it means the mesh had no material, but we don't use materials anyway so it doesn't matter. I should probably just disable that warning (it affects some of our existing models too). (To be pedantic, that's not a difference in the file formats, it was just a bug in the .pmd exporter. Same effect, though )

Yeah, someone added libcurl4-openssl-dev to the wiki but it looks like it's only installable as an alternative so we shouldn't list both. I'll fix that soonish. The gnutls one is probably better from a licensing perspective (Debian people have worried about the openssl one being GPL-incompatible, I think), but either should work technically (and we don't use the SSL feature at all anyway). Probably for the next release - I think the easiest approach is probably to bundle ENet 1.3 with the game, for distros that only have 1.2 (which should disappear over time), but use the standard system library when available, so it just needs a bit of fiddling with the build system to support that.

For a non-prototype implementation, the rendering should probably be handled the same way that selection rings should be handled (i.e. something new that's more efficient for moving objects than the decal system, and that can do the relevant colouring, and uses textures instead of thin lines - that's not supported yet but probably shouldn't be too hard, and I think it's necessary for non-ugly selection rings anyway). Is there any way to make hero units sufficiently visually distinctive without using special effects, like making them taller or with thicker armour or something so that their silhouettes stand out?

Cartoonish effects are usually more complex to render than the very simple approach 0 A.D. takes, so that's not particularly surprising One thing I remember quite liking was having tooltips on loads of world objects (not just GUI objects), to tell you the brief important details of what things are or what actions you can take, without having to learn special icons or to click on units and search through the UI panels for important details.

That should be easy to do - just edit the entity template XML files and remove the "Builder" and "ResourceGatherer" components (and probably get rid of any "ResourceSupply" etc too), and the units will be unable to build or gather anything. About unit movement: the formation behaviour is pretty much all handled by scripts, so those could be changed to make each unit in a group move independently. Improving the behaviour of two groups of units travelling through each other in different directions is probably more complex and would need changes to the C++, but we probably want to improve that for 0 A.D. anyway. The unit movement code is probably the most complex single feature of the gameplay code (it's something like five thousand lines in total, including pathfinding and formations etc, with lots of subtle interactions between different parts), so it's certainly not straightforward to make major changes to it, but I think it should be possible to build what you want by reusing much of the existing code (particularly the pathfinders) with some effort.

I've never played Myth and don't really know what's involved, but I'd imagine pretty much all the gameplay changes could be done in JS (perhaps after some minor fixes to the engine to expose stuff like terrain data to scripts - I'd be happy to do that if mods need it), though in some cases it might be impractical due to performance issues or wanting to reuse existing C/C++ libraries (especially for physics etc). Implementing new gameplay features with C++ isn't hugely harder than with JS, though - they both use the same extensible component system, where features can be added without impacting on any of the other features, so you can make changes without incompatibly forking the engine. Probably the biggest pain is with distribution (a script mod is much easier than binaries that have to be recompiled for every platform), but I think it'd likely be possible for the standard 0 A.D. distribution to include some components that aren't used by 0 A.D. itself but can be used by mods, if there were some that were useful and mostly complete, so hopefully that wouldn't be a serious issue in practice. Writing a game is still a huge amount of work even when building on a usable engine (which is why we haven't finished 0 A.D. yet), but I don't see any fundamental problems that would make it harder to build on than many other engines

Particles only work in the shader-based rendering mode, so I guess you're getting the non-shader one (which should usually only happen on extremely low-end hardware or non-Gallium ATI drivers on Linux). It should be possible to make them work in non-shader mode (though it's more code and less efficient) so we should probably do that.

I think that's just a harmless notice rather than an error, so it should work anyway. I guess those .save files probably exist because you ran add-apt-repository multiple times and it saved backups of the old files - you can clean them up with "sudo rm /etc/apt/sources.list.d/wfg-0ad*.list.save"

simulation/components/interfaces/Identity.js doesn't exist (since r9443), so you've probably got an inconsistent SVN state if it's complaining about that. (That will lead to all the other errors - at some point in the future we should probably be better about aborting the game load on fatal errors instead of carrying on blindly and exploding.) The "global["IID_" + name] is read-only" test failure is caused by the SpiderMonkey binary on Windows being slightly out of date; it'd be nice to recompile some time but the bug is harmless in practice (and I can't recompile myself since I currently have no working Windows hardware).

r9451 fixed this.

I do all my development work on a laptop with Intel GMA 4500MHD (an earlier generation than Intel HD Graphics), on almost Core 2 Duo 2.16GHz (technically a Pentium Dual-Core) and 4GB RAM. I think it was £400 when new, and it seems perfectly adequate. The game usually runs at somewhere around 20-30fps at 1024x768 (windowed) with shadows/fancywater disabled, which is not ideal for smooth playing but is fine for development and testing, and the graphics drivers on Linux seem stable enough (I've not tried running Windows).

Looks like lots of people have used the feedback message box on the menu screen of the last release (578 messages in about 2 months), and I think now's a good time to try to summarise it and see what we can learn. (The original messages are here but only accessible to WFG people - it's meant to be an anonymous feedback system, and some people have sent their email addresses etc, and also I don't want to encourage spam, so I don't think we can make the raw data public). We should probably make Trac tickets for any sensible bug reports or good design suggestions, but I'm not going to bother doing that myself now since I'm lazy Some common comments: * Vast numbers of people saying how totally awesome we are for making the game. * Lots of users want saved games. * Some common reports of known bugs/feature requests: Ships moving on land; ships unloading into water; gates not working; wall placement; camera altitude problems; control groups; campaigns * Several people want to zoom out further. * Some asked for visual feedback when clicking to order units. * Several complaints about multi-monitor fullscreen covering both screen. That's a known problem with SDL on Linux; not sure if we can work around it somehow. (A couple mention NVIDIA TwinView but seem to be on Linux too.) * Lots of users (more than a dozen) complained about the mouse being too slow. One complained about it being too fast. All seem to be running Ubuntu (not all the same version). One said "i made adjustments in Ubuntu's mouse preferences, and it made mouse speed fast everywhere else on the desktop except within the game". Some kind of Ubuntu-related bug where fullscreen SDL is ignoring the standard mouse settings? * Minimap problems: "Is it possible to make the coloured dots on the map more distingishable? Some of the colours are too similar, ie. red and orange."; "The mini map could scale; too small to see anything on it."; "It's hard to see Player 2's buildings on the mini-map." * Feedback system: "I just wrote a bug / improvement suggestion here, and then I selected it and pressed a key on the keyboard and it was gone. Please enable / add a way to undo?"; "It would be nice if this feedback box were available in game using some key combination to enable it mid game."; "i wish to know how to remove this window asking me to add some feedback"; "it might be neat to add this feedback box in-game, with a capture-screenshot function for those of us who always forget, or even in the post-game menu." * UI design issues: "the kill troops button should not be so close to the garrison button, it gets annoying if a missclick is made. maybe make a larger gap or make the icons larger or even swapping positions of the buttons around would work."; "Cannot see a Quit option in the main menu (on the map), even though there is a Quit button"; "When in a game, the menu is a bit confusing, instead of having two options next to each other saying "Quit" and "Close" I would have: "Quit" and "Back" or even "Back to game"" * UI ugliness: "The GUI (map, building, etc etc) felt kinda cheap. Needs a better texture in my humble opinion"; "The background for the popup UIs doesn't look very nice IMO. I think it would look a lot better with a different one. The background for the loading screen looks good, though; very sleek and professional."; "the UI standard background image is too busy. Either the texture needs to be toned down in the form of some heavy smoothing, or the UI elements between it and the text need their opacity increased." * Sound volume: "Music (all sounds) should stop in pause mode (ie: on the phone, boss coming...)"; "NEED TO TURN DOWN SOUND TOO LOUD TO PLAY WITH" Misc suggestions: * "When hosting a game, it would have somewhere to write you IP adress, that you can easily send to another players." * "Why would I make "normal people" when I can make fighters that can gather food... and build things?" * "Why can i not make slaves of captured peoples?? Slavery IS a huge part of our human heritage." * "Why do the buildings and lands not have a measure of culture to overcome after my insurgence? Obviously, the people's lands and and their buildings have their cultural mark and inheritance to overcome." - I'm not really sure what that means. * "Why can i not capture buildings? Why do i have to raze them? If i can capture lands... why not all the possible buildings?" * "I played your game for the first time and right off I didn't like how only the women were villagers and the men were military. I think it would be better to have male and female villagers and have the option to later spen additional resources to convert those villagers into military units." * "About constructions, it could be great when you try to place them, that the game blocks it nearby an other construction. For example: near a house, block the one I am placing so I can built it with no space between each other." - maybe they meant "so I *can't* build it with no space"? * "Hi I have some ideas about the soilder ranking system, one idea would be to let every soilder of the same type start with a random piece(s) of equipment(s) and when they die they would drop it so other soilders can loot it automatically when not in combat(you would still need to click on the corpse for them to start looting the corpse and other corpses near it) (if it is a weapon it must match the type of the unit in order for the unit to be able to loot it). Another version of the idea would be to let every soilder of the same type start with the same equipment but when they die they would drop random extra or upgraded equipment(s) for other units to loot. Thanks P.S. I think 3 ranking systems are way too few. I would suggest 8-10 ranking systems because it would really add to the atmosphere of the game. If you want to see a small example of what I mean try the demo of the game Overlord and watch the minions equipping themselves with various items." * "The names for the units are too complicated. I am Greek and even if they are historically accurate and it's my native language (meaning I know these words and I can pronounce them) it was really annoying for me to read through these names. They need to have simpler yet accurate names, so that players can distinguish them by their names. Otherwise all units will have a strange uncomprehensible name for them, they cannot remeber or pronounce. If you would like, I can help with the unit names providing suggestions or alternatives." * "If I select mulitple buildings and create a number of units only 1 building will make them. It would be great if by making 1 unit when you have more of the same kind of building selected you would make 1 in every building not just in 1 of the buildings." * "When we scroll the map with the mouse on the borders of the screens, the direction of the scroll must depend on the direction of the vector formed by the center of the screen and the position of the mouse. Currently, the maps scrolls only left/right/up/down, imo the player should be able to scroll in any direction with the mouse." - I happened to play Sol Survivor (demo) yesterday which seems to do scrolling like this, and it felt pretty weird (though I didn't spend long trying to get used to it) - I don't think I've seen it in any other games. Misc bugs: * "I have to monitors, which leads to me not being able to scroll in the direction of my second monitor, because the mouse-pointer is not captuured (it mvoes to the second screen and therefore I can not scroll)" (on Windows). * "This game does not recover from sleep on my laptop." * "if you garrison units into a siege ram and don't unselect them befor garissoned your not abel to control/select any other units or buildings" * "I paused the single player game and left for 45min. When I came back, the game was unpaused and I was defeated " * "Gaul towers (not outpost) do not fire and an error message appears" * "After I installed the game, I chose to run it right away. I was given a notification that there was unsigned driver that was installed. You may want to look into this, if you haven't already. I am running Windows 7 x64." * "Doesn't seem to support the use of Wacom tablets very well... (the cursor jumps all over the place)." * "Assertion failed: "GetLastError() == 0" Location: wutil.cpp:512 (wutil_AppWindow) Call stack: 01347D5F 013491C8 0131F27B 744A1CFC 0131F684 0131F85E errno = 0 (?) OS error = 487 (试图访问无效的地址。 )"

Most of the code for saved games already works, but there's some fiddly details that need to be sorted out (particularly saving the AI player state) which is why it's not usable yet. It's definitely an important feature, so hopefully it can be fully added in the next couple of months or so

It's triggered manually. (It takes about ten minutes to convert the current amount of data into efficiently queryable form, so I don't want to stress the server by doing it too often, and also it's fragile and could get broken by bogus data, so I prefer to keep an eye on the conversion process). I retriggered it now and the RV530 page seems to have your new data (and I probably need to find a way to make the column headings less ugly...)

Change CGameView::defaultNear in GameView.cpp, though reducing it decreases the z-buffer resolution and can cause z-fighting errors with distant objects (which is why it's the value it currently is).

Do you mean you've changed it to static void al_check(const char* caller, int line) { alGetError(); ALenum err = alGetError(); if(err != AL_NO_ERROR) al_ReportError(err, caller, line); } or something like that? In that case the first line will capture any real error that has occurred, and then ignore the return value, and the "ALenum err = alGetError()" will always return no error because the error state was cleared. So this will just hide any real errors that occur - I don't think it'll ever really fix anything. (We should never trigger any OpenAL errors so it shouldn't be necessary to clear the error state at all, as far as I'm aware.)

Fixed the stretching. (It didn't like rotation unless it was around the Y (vertical) axis). But it still wobbles as the associated prop point moves and rotates, since that's what decal props are meant to do. I don't think the current decal system is particularly appropriate for this - it's designed for a small number of large decals attached to objects (i.e. the bits around buildings), whereas this is a large number of small decals that ought to be stationary. Also, maybe it shouldn't be a single decal per unit - a unit could randomly emit patches of blood every time it's hurt, and the blood disappears after some time that's unrelated to the lifetime of the unit. Similar things apply to other effects like footprints. Also the blood should probably be a graphics option, so players can disable it for performance or child-friendliness or German-censorship-compliance or whatever. Maybe it could work better like this: Have a file defining a decal type (like "blood" or "footprint" etc), which specifies the texture and the decal's lifetime and what graphics options it depends on. Have actors specify a decal emitter of a particular type, which can be triggered by the animation (e.g. a certain point in the walk cycle) or by the simulation code (e.g. when getting hurt badly), and each time it's triggered it will create a decal of the given type at the current prop location. The decals will stay where they are until expiring. This should provide more flexibility, and it can be handled much more efficiently by the engine - it doesn't need to maintain a lot of data for each individual decal, it can just build a big array of every single blood decal and render them all at once with very little effort. (This decal type/emitter thing sounds quite a bit like particle types/emitters, which is not accidental, and it'd be nice to converge them in the future, but they probably won't share much code at first so I think it's better to design and implement them separately.)

In that case, the game can apply a special flag to tiles that are near trees (where "near" is determined by what tree density should block siege engines etc), and units can be given different passability classes that determine whether they are blocked by those flagged tiles or not. But I suppose it's bad if units look like they're standing inside tree trunks, so the trees need to act as small trunk-sized circular obstructions even to units that can walk through forests, in which case they might still be blocked by particularly dense forests, but hopefully we can simply make them not quite that dense.

Instanced rendering can't work usefully for trees, since our trees use alpha blending (which means they need to be sorted by distance, not by texture, so they can't be drawn in large batches). Also that wouldn't help if the rendering is fill-rate limited (i.e. the cost of drawing blended pixels), though I don't remember how often that's the problem. Switching from alpha blending to alpha testing (i.e. 1-bit alpha masks) would solve all those problems, but I don't know whether it'd be possible to make alpha-tested trees that don't look ugly so I don't want to claim it's a viable solution. (Also it'll take a bit of work to get that supported properly in the engine, though I'll probably try doing that soonish anyway so that it's possible to experiment with this.) A proper solution to #434 should make trees much faster, but I think ortalo's working on some stuff that's relevant to this so I don't want to interrupt that work. (With fancy water, trees get drawn 5 times per frame. That patch would reduce it to 4. Removing water refractions (which seem so subtle that I've never been able to see their effect, unless I'm just looking in the wrong place) would reduce it to 3. There might be a change to the shadow rendering that could reduce it to more like 2.5 or so.) About pathfinding: Maybe increasing the radius of trees would help stop units walking through sparser forests? Alternatively, at some point in the far future we'll probably need some kind of terrain analysis so AI players can recognise forests as simple coherent shapes (not just as individual trees) and could maybe use that for pathfinding if it'd help, but that's not going to work any time soon.