historic_bruno

The original, never implemented idea was http://trac.wildfiregames.com/wiki/Random_Map_Scripting_Interface#BiomeReference which is at least more descriptive, but not much more flexible. Ideally, biomes would be complete packs of textures, actors, entities, and perhaps in the future, sounds, that would make sense for each biome. It should be an extensible system with minimal hard-coding, so new mods could easily add biomes. I don't know whether that would be some data (JSON) or scripts or a combination. And if we're going for realistic maps, there should be ways of specifying relationships between biomes on maps where several might be mixed or overlap. Obviously there wouldn't be a hard transition line between two biomes but a gradual transition and that's where texture blending comes into play. If random maps don't use texture priorities yet, consider that as well. The current biome "system" should go away as soon as possible

Great find, thanks! I had not seen that document before, but indeed it seems to confirm our suspicions and the general direction the pathfinder, AI and RMS are moving in.

We have the chat notifications already, but they are disabled by a config option. If you want to see them, set gui.session.attacknotificationmessage to true. I think a different sound for each civ would be nice, as long as they were similar in theme, because we will have several alert sounds and don't want them to be confusing. To experiment with this, change the <attacked> sound group in the entity templates for the civ in question. Note also that each entity template can have its own different sound.

Is that the only output?

A mod selector UI wouldn't need to be in the public mod. It wouldn't necessarily need to be a mod at all, but I think it would be easier. Remember that we can load multiple mods at a time, so there could be a pre-public mod that includes only the mod selector. There are other reasons to want mod switching/loading in-game, such as integrated updates or mod downloads for multiplayer games (e.g. your friend has a cool mod they made, and you want to play against them, it's annoying to have to distribute the mod and restart to load it, and you get into version mismatches; so match setup could look up that info and download it to a temp mods directory before starting the game). But we need some engine work to make that happen, to ensure reloading mods at runtime works seamlessly - it already should in theory with our VFS, but every system needs to support it. I think it would be less work to fix that than to write a separate cross-platform launcher tool that will probably be throwaway code.

Does it seem like http://trac.wildfiregames.com/ticket/1763 ?

Some updates on the OS X build front. I've decided the way I was doing SDK builds wasn't entirely correct. I was building against the SDK of the oldest version of OS X we want to support (currently 10.5 or 10.6). That is easiest in some ways: it locks the API in, so you don't have to worry about weak linked symbols crashing at runtime if you don't check them, and you don't have to worry about lack of backward compatibility on some system libraries. The tradeoff is you are using an old API which may have less features or may not work correctly with new Macs. I think this is the case for Retina displays (unconfirmed), as the graphics APIs are being limited to 10.6 features. To remedy that, I have been adding proper, runtime weak symbol checking whenever there are API differences between OS X versions we care about (typically 10.5 -> 10.6, or 10.6 -> 10.7). The code becomes a bit yuckier, because you have to do compile time checking (to avoid compiler errors) and run time checking (to avoid loader failure or crashes). I have also stopped using the Apple-provided zlib, curl and libxml2, and added those to the OS X library build script. Now I have a patch that makes it possible to build with 10.5 support in the 10.8 SDK and beyond, for both 32-bit and 64-bit builds. This means the bundle build process is easier on my end, I only need a single Mac and if it's 10.8 or newer, we benefit from the latest APIs but keep support for the oldest OS X versions we want (hopefully with little or no additional work). This also means it's possible to have a universal app bundle, with both 32-bit and 64-bit binaries combined, so it should run well on *any* Mac with OS X 10.5 - 10.8. So here is a universal test bundle I made based on SVN r13920, what I would really like is some users with Retina displays to give it a try and see if it improves the game in fullscreen mode. But anyone with OS X could test if it runs normally: https://docs.google.com/file/d/0B-qlXhiirMW3ZVh4ZkNHNEFjVkU/edit?usp=sharing One known regression is Atlas won't work on 10.5 due to some STL template issues that I fixed in the engine but not in wxWidgets (dyld will say it failed to load due to a missing symbol).

Did your SVN working copy update fully and cleanly? Did you have any local changes to source files? Maybe try reverting everything to make sure you have a clean working copy. I would try a clean build, use Build > Clean Solution in VS before building again.

Couldn't a decal be used to blend the grass texture for the hill to the surrounding terrain? Try using some of the game's existing grass/mud/dirt textures and see how it looks. It could use random texture variations. Might need to play with the concept a bit, add paths leading around to the top of the hill, etc. so it looks a bit more interesting. I think the biggest issue will be that it's a grassy hill structure, but units can't walk on it.

You can try the daily builds now: http://builder.blender.org/download/ In brief testing, I was able to import several of our animations and models successfully in the latest build. A few of the animations (camel and one of the infantry fighting) looked good, some (deer running) did not. I'll leave it to people who actually understand Blender to do more testing

To expand slightly on Erik's response, the reason we don't show the sky by default is that it isn't visible at "normal" camera angles. You can always change the camera settings in the config file or disable camera constraints through the developer overlay (Alt+D) in-game. There is also a "showsky" config option, if you want it permanently visible for some reason.

If anyone who has received this error can provide the commands.txt file matching that game (in the sim_log directory inside the game's log path, they are organized by process ID), it should be easy to reproduce using replay mode.

Thanks for providing the crash logs. The call stack indicates a crash in CPatchRData::BuildWater, which is related to water rendering. There's already a ticket for this crash: #2114, but no steps to reproduce it yet. What are your config options like, have you enabled any very fancy water settings? If it happens consistently with your map and not others, please attach it here (both the .xml and .pmp).

IMO we shouldn't drop ARB support at all unless someone is really overhauling the rendering engine in such a way that supporting both is too much of an obstacle (not simply an inconvenience). I don't think that is likely, but we can cross that bridge when we get there. The way to proceed with GLSL is to clean up its existing code, make sure we detect GLSL support properly (not a config option), begin enabling it on supported systems and noting which drivers and GPUs have GLSL support but perform poorly or are buggy, and fall back to ARB on those systems, the kind of thing we already do in HWDetect.

Excellent overview, GunChleoc, I think that informs us of the kinds of things translators want and find most helpful

There was an idea (Michael's?) to redesign the human models, to have better looking models and animations, and also to have different sizes. Heros could be larger for example. Obviously that hasn't happened because of the amount of work involved, but this question reminded me of that Edit: found the suggestion: http://www.wildfiregames.com/forum/index.php?showtopic=15552&st=140#entry237155

Max FPS probably isn't the best measure of what's going on with 0 A.D., I can get 80-100+ fps depending on the map (a few are much lower for technical reasons, e.g. lots of transparent objects like trees) and I don't have the latest greatest hardware. But in some game situations, frames take far too long, whether it's pathfinding or AI, resulting in choppiness and lag. An uneven high framerate is more annoying than a lower smooth framerate. On the other hand, when I play multiplayer games without AIs, it does tend to run far more smoothly. We will continue working on the performance, meanwhile if you haven't tried the AI-less multiplayer experience, you might be pleasantly surprised

Never seen a dangling pointer, double free, heap corruption, memory leak or platform specific compiler error? Lucky you! But this discussion isn't really productive, nobody is offering to write the AIs in a different language, and even if they could, without a solid design we would run into the same problems, and others that are more annoying to troubleshoot thanks to C++. If you think C++ is always "fast enough", take a look at our pathfinder. Bad algorithms give bad performance, it doesn't matter the language or the hardware involved Because of JS garbage collection and the fact it's slower than native code, we know we shouldn't be processing a lot of data in JS. That's possible to solve, and we can still get the benefits of a.) new AIs and mods not requiring rebuilding the engine (even if you made them modular, in C++ they become unportable binaries), b.) possible AI script hotloading, change a script and it could instantly reflect the change in-game, c.) lower learning curve to begin developing AIs, if you have a text editor and basic programming knowledge you're ready to go and unlike C++, you don't worry about the machine the code will run on. Based on contributions to 0 A.D. that I've seen over the years, people find JS (as a scripting language) more approachable and comfortable than C++, and that drives AI, random map, gameplay and UI development more than one guy who knows everything about C++.

Check out Modding Guide and Finding Your Way around. Most of the data files (XML, JS, JSON) can be edited with a text editor, I would recommend Notepad++ on Windows.

You can still run Atlas, but you won't be able to modify it unless you follow the other steps (building wxWidgets, etc.)

It's a script that creates the files needed to build the game. The path "build/workspaces/update-workspaces.bat" is relative to your SVN checkout of the game. If you don't see this file, then maybe your SVN checkout didn't complete successfully, and you should do an SVN update to continue it. After you run update-workspaces.bat and open "build/workspaces/vc2010/pyrogenesis.sln" in Visual Studio, you will see a "Debug" dropdown in the toolbar. You will want to change that to "Release" most of the time. It looks roughly like this: http://social.msdn.microsoft.com/Forums/getfile/69721 That compiles the game, you can either press F7 or use the Build menu. You can't do these steps until you have completed the first ones.

The way rubble is implemented now, it can't be more than a visual effect. That could be changed, but personally I am glad not to have to worry about mining rubble, even though I can see how it might appeal to some people But I would say it's hard to notice looting, so it's not surprising that people don't know about it. There's no looting animation and it's not indicated in the UI. What if we added some visual indicator when looting happens (we could do the same for XP gain), maybe a brief particle appearing above the rubble or some kind of overlay, showing the amount and type of loot? Like: "+10"

Hi, are you following these build instructions? If you have already checked out the game from SVN and installed VC++ 2010, you're most of the way there Maybe you can explain a bit more which part you don't understand or what is going wrong?

Until the patch is updated, I can't say what is fixed, but there were some serious release blockers found only a few days ago. Philip has updated his gerrit server (http://86.137.32.221:8080/1) with the latest megapatch, I would suggest giving Philip some time to review it (because he is most likely to find errors that aren't trivially reproducible from e.g. compiling and loading a game for a few minutes), and that we review it as much as possible as a team before it's committed - so far I think only Philip and I have commented on it. It's actually a nice system for code review and much easier than dealing with such a huge patch on Trac or reviewing after it's committed.

Hi, first thing to make sure of is that all players are running the same version of the game (e.g. Alpha 14 release). Then, are you playing with AI players? OOS with AIs in multiplayer games is a known problem we're working to solve. If anyone rejoins in a multiplayer game with AIs, it will also cause an OOS error. When the game goes OOS, it creates an oos_dump.txt in each player's log directory. These files are a text dump of the simulation state at the time of the OOS error. By comparing them, it is sometimes possible to discover where the problem is. Can you collect those files and post them in a Trac ticket for analysis?