historic_bruno

Random maps don't have a pmp. But other than that, I like the suggestion of storing the data "together". The main problem is going to be when people start modding the game and creating new scenarios, random maps, and campaigns left and right, who wants to unpack 3 files in 2 different locations for every single map? OK maybe we can automate that with a content downloader or some kind of self extracting package, but that's still not perfect. Or we could do something like zip up the map files and distribute them that way. No unpacking required by the user, they stick the map zip(s) in the "user mod" maps/ directory. Doesn't get much simpler than that. I don't know if our VFS allows this and if not, how difficult it would be to add it.

Wow - does this actually work or is it just in the prototype stage? At least in the screenshots the data is fake. If it works, let's get some devs to start testing it In addition to the filters, I think equally useful is a way to sort the game list by each column. This might be slightly clunky with our GUI engine, but perhaps an ↕ or ▼/▲ arrow button next to each column's text to sort them alphanumerically. That has the benefit of allowing the player to "filter" the list while seeing all the available games.

Oh, that could explain what happened You might not have built wxWidgets with the GL libs, I believe it's optional (--with-opengl to ./configure?). Actor Editor doesn't use the GL canvas so it would work, but Atlas needs the canvas to display the game view. I didn't think of that possibility. FWIW, the full command we use in extern4_libs.lua is "wx-config --unicode=yes --libs std,gl", so if you leave off the "gl" it won't list it either.

Indeed I've thought about allowing random maps (particularly their JSON file) to override default settings and provide their own new ones, like if you want to adjust a map's ratio of land to water, or tree frequency, etc. In fact it's buried in this ticket's description: http://trac.wildfiregames.com/ticket/812 Technically it's not too much of a challenge.

/usr/local/lib seems like one of the standard search paths, it might end up there by default. The actual path of the wxGTK 2.9 libs should come from "wx-config --libs". But note that the absolute path typically gets built into wx-config (same as e.g. sdl-config), so if you move the libs after building, it will reference the old paths. I don't know if that happened, but just throwing it out there

We can turn it on by default on GPUs verified to work well with GLSL. It's actually very easy to do that, see hwdetect.js. We also have data like http://feedback.wildfiregames.com/report/opengl/ (much more privately collected and unanalyzed) which can help. Then it would be a matter of finding a good baseline of default effects for high(er)-end GPUs with GLSL support.

ERROR: DllLoader: dlopen(libAtlasUI.so) failed: libwx_gtk2u_gl-2.9.so.3: cannot open shared object file: No such file or directory; dlopen(libAtlasUI_dbg.so) failed: libAtlasUI_dbg.so: cannot open shared object file: No such file or directory; TIMER| LoadDLL: 109.79 ms Atlas.cpp(46): The Atlas UI was not successfully loaded and therefore cannot be started as requested. The Atlas UI was not successfully loaded and therefore cannot be started as requested. Location: Atlas.cpp:46 (ATLAS_Run) Call stack: (0x805fda) ./pyrogenesis() [0x805fda] (0x7abd71) ./pyrogenesis() [0x7abd71] (0x7aca4e) ./pyrogenesis() [0x7aca4e] (0x58e0c1) ./pyrogenesis() [0x58e0c1] (0x58e198) ./pyrogenesis() [0x58e198] (0x41c977) ./pyrogenesis() [0x41c977] (0x4135d7) ./pyrogenesis() [0x4135d7] (0x7f158bef276d) /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f158bef276d] (0x41c105) ./pyrogenesis() [0x41c105] errno = 0 (No such file or directory) OS error = ? Aborted (core dumped) At first glance that doesn't appear to be a wxGTK 2.9 problem. Did you have both 2.8 and 2.9 installed? Did you do a clean-workspaces.sh and clean build after upgrading? ldd might be useful to see where libAtlasUI.so is expecting to find wxWidgets. The correct path should be injected by wx-config when Premake is run (update-workspaces.sh).

Was it the same error you posted in the hdr/bloom/ao topic?

Wow, I really didn't expect it would and thought we might have to redesign the logic We still might, if lots of people are using wxGTK 2.8, but at least there's a workaround.

Integrating with Atlas would be nice, I think they should be rescaled to whichever power-of-two size we choose to prevent the preview images from growing too large - perhaps 512x512. We also need to decide how to reference the preview images. The most obvious way is by filename (Foo.pmp matches Foo.xml and Foo.png), if so we'll probably want not a single map previews directory, but one that mirrors the maps file layout (textures\ui\global\previews\scenarios\, textures\ui\global\previews\random\, etc.) The advantage of that is it doesn't require modifying the map data to reference the preview and also eliminates file name conflicts, if a scenario and random map are named identically.

Not at all, the ugliness is in the graphics rather than the concept. Hmm, unless we had better UI input handling. It could remember input focus was on the dropdown, then the arrow keys would still control the map list. Most decent UIs support that. Not sure if anyone cares to implement that for our GUI engine There is actually more extra clicking required in Spahbod's design, because the only way to compare player assignments on different scenarios is to open the map chooser (which replaces the player assignment layout), choose a map, confirm the map choice to return to player assignments, and repeat. Luckily that's avoided quite easily, by leaving everything on a single screen the way it is now

Don't suppose you could test how it goes with a newer (2.9.x) version of wxWidgets?

Please read or search the forum before creating a topic, an almost identical question was asked only days ago

Thanks! I spent some time debugging this (you need a debug build to see the actual error), the problematic part of the DAE is: ... <scene> <instance_visual_scene url="#"></instance_visual_scene> </scene> </COLLADA> Note the url attribute in instance_visual_scene. According to the COLLADA spec: It doesn't say the ID is optional and FCollada assumes that's an error condition. Seems like either a bug in FCollada's importer or the FBX exporter (Blender manages to import the DAE, so OpenCOLLADA must have some logic to handle this case) Either way, all you have to do is change "#" to "#Teapot001" and it imports cleanly

Which version of wxWidgets?

AoK had all the map selection and game options in one column. It was ugly, but I never had a problem using them. That's what I was thinking. If map selection is separated, it should be a "pop up" window and it only needs part of the screen. Of course separation makes the game setup code more complicated, as the values have to be passed from one page to another. If the only difference is hiding the map list as on Spahbod's mockups, we could just as easily put the map list into a dropdown and keep it all on a single page. (What's the difference between a "Choose map" button to open a map list and a dropdown map list?) We should also try to improve the layout in higher resolution and widescreen layouts, compared to what it is now. Using more relative positioning might help. There's a lot of empty space in the player assignments area in the current UI.

Do you mean the COLLADA 1.4.1 spec? Blender exports DAEs of that version and it seems to work. I don't know about our compatibility with the 1.5.0 spec. Can you provide an example DAE which doesn't import into the game?

Soon

Horses are due to be remodeled and animated, but adding missing animations is higher priority.

The exporter for Blender 2.6x is working fine, at least well enough for our purposes, that's how all the recent ship rowing and animal animations for 0 A.D. have been made It's the importer that's broken, not an issue if you start with the model in Blender.

Random/scenario/campaign could be selected from the main menu, before getting to game setup. I wouldn't mind hiding the full map list in a dropdown or new window. There's clearly some wasted space in multiplayer because only the host can choose the map (currently) but we display the list for everyone. If we have a map preview, it would still be nice for all players to see it and the description, so they could ask the host for a different map if it looks terrible. Not sure how valuable that is in practice True, random maps are different because of that unknown factor, but the details on most of our maps look terrible when zoomed out. They aren't as presentable as Mythos' examples: http://www.wildfiregames.com/forum/index.php?showtopic=15562#alpinevalleys If you mean showing a preview of the actual map to be played, that's problematic because map generation is very slow. Who wants to wait 10-15s for a normal sized map to preview (some maps are much slower) and that's on a fast new computer A single representative image would be sufficient IMO...

What about Blender's sculpting tools? http://wiki.blender.org/index.php/Doc:2.6/Manual/Modeling/Meshes/Editing/Sculpt_Mode Might be more natural for shaping organic forms.

It should consider movement too, so if a unit is far away from the target or it takes some time to reach due to obstacles or slow speed, the unit won't get 95% to its destination, timeout and head back to base I seem to remember him saying reachability testing will be much more efficient than it is now, but I don't know if that was terrain only or all static obstacles.

Sounds good, because it annoys Philip, and every time the config system's ugliness annoys Philip, it increases the chances that he will replace it (He's complained about it for a long time) Though anyone else is free to work on it if they can improve it. It's especially awkward for renderer config as you may have noticed... As Erik said, it's not essential to have options for everything in the initial version, but I think eventually we will want them IMO numeric values are nicer for things that can't be expressed as distinct features, like quality and detail level of Effect X.

Why not in the bottom left corner, where the description is now? The other layouts disrupt everthing at 1024x768. Alternative 1 - description is moved into an info tooltip over the map preview: Alternative 2 - description is dislayed above (or below) map preview. In this case the map list shrinks somewhat at 1024x768, but gets expanded for everyone else, so the difference should not be noticeable: Obviously I'm a big fan of creative, artistically selected map previews While it's slightly more work, it will give an impression that an automatically generated or whole map screenshot could never provide. I think it's nicer not to show the players everything before they start, that's what exploration is for, right? We could think of map previews as showing the most important feature(s) of the map and some of the biome(s). Here's the preview I chose for Punjab 1, it took me about a minute to make it, an artist could probably do better: