historic_bruno

Typically the lag is due to pathfinding and AI. I would expect Belgian Bog to be especially hard on the pathfinder because it's full of narrow passages and complex terrain, and qBot would make it worse as its military formations recalculate the path from time to time. You can access that with F11 and then view source/tools/profiler2/profiler2.html, if you're curious about what's causing the lag. There's been some vague discussion in the past about collecting more detailed profiling data from users but we haven't gotten to that point yet. I think we're still trying to manage the data we already have I think AIs and possibly pathfinding will benefit the most from multithreading, but they still need to be optimized for single threading first

Just figure out a new default for simulation\data\player_defaults.json.

By request: r11660 development version

Avast! has starting doing the same thing, either halting the application or forcing it to start in a sandbox. You can get 4-5 popups just while compiling the game. It seems any EXE that's not popular will have this problem. I think it's counter-productive because people will start ignoring these warnings when they know the application is safe as second-nature, and potentially dangerous ones will leak through.

It will always be a little slower, but make sure you're in a release build instead of a debug build (debug build disables optimizations which is good for debugging but bad for playing). Builds from SVN will be slower loading textures the first time compared to the release package because they aren't pre-cached.

The last crash looks like the one when using a saved game from a different version of the engine, we don't handle that cleanly If you want to test that, you'll have to revert to the same revision as Alpha 9, r11339.

Are you familiar with using Visual Studio's debugger? Try running the game (release version is fine) and attach the VS debugger to the pyrogenesis.exe process. Then continue reproducing this freeze or crash, and once it's there, go back to VC2010 and break the process (Ctrl+Alt+Break). Then find the call stack for the main thread, so we can perhaps see what's going on. Of course if you want to try building from SVN, that would determine if the bug has been fixed already, and it makes it slightly easier to debug.

Which version of the game were you using?

Have you changed any settings in your config file? You might have disabled shadows by accident.

I would add zsol under programmers.

That page basically says Atlas doesn't have proper mod support yet (which is true), what it doesn't say is that releases often store data in an unwritable location (like a .zip archive or outside the user's home directory). There are technical reasons why it fails and why the files end up in cache instead, it has to do with the inner workings of the VFS. The cache is actually intended for files that are loaded from other sources (like textures from PNGs), they get converted and stored in cache to reduce load time on the next use. The cache will never ever be officially intended for doing what you're doing, it's a temporary hack because of some missing VFS functionality and mod support This changed according to the discussion we had here. Cache should go in local app data instead of roaming, which is a useful distinction for users on domains. It's pretty standard behavior for modern Windows apps. See the link for details. #1145 was only intended to shuffle existing data paths, not fix the broken VFS However the description in the ticket is slightly outdated, as the comments explain, the original planned locations were changed due to feedback from others. I just forgot to update the description for Windows. Fixing mod support in Atlas and generally is a problem for another ticket (#889 is somewhat of a placeholder for that). Understand the VFS as a means to translate a game path like maps/scenarios to a real system path on your computer. Actually there can be multiple real paths per a single VFS path, such as if you have multiple mods installed. Now for reading files that is OK, you can have different priorities and pick the file from the mod with highest priority. But for writing files, as Atlas does, there should only be a single real path which is known to be writable. The VFS lacks that currently, but in the future we will have a single "user mod" directory in a standard location, and Atlas will always save maps there. I'm not sure why hotloading of random maps is broken for SVN versions, I think it's a separate issue from the above.

That's not really a custom content path, it's the cache path. I suspect when you modify those files you're working around a bug in the hotloading system (I don't know which bug or why what you're doing is working).

r11502 disables some optional NVTT dependencies including OpenEXR, this may help you compile.

For future reference, see Reporting Errors Which version of the game are you using? This problem should be fixed in SVN and so will be fixed in the next release (Alpha 10).

The likely culprit is that there have been some map and template changes since Alpha 9 (not sure if anything else has changed). Try Alpha 9 instead of SVN.

Yes, that and other game setup options are planned

The old pmd2collada won't work for skeletal models which are the only PMDs left, and even with the new converter, you won't be able to import them correctly into Blender. Blender DAE import is just broken. However, if you still want to try, download the converted DAEs here

Atlas crashes when saving maps

Yeah, the same thing happens on other OSes, as a symptom of not having proper mod support in Atlas. One thing you can do to save maps: extract the public.zip in 0ad.app/Contents/Resources/data/mods/public, then you'll be able to save maps inside there. That's bad behavior though, we shouldn't write anything inside the app bundle, but currently there's no other choice.

Here's some hotkeys I could think of related to gameplay: Select building Cycle through buildings by type (civil centre, fortress, market, dock, etc.) Cycle through buildings by event? (last attacked / constructed) [*]Building commands Train unit(s) Research (not yet implemented) Ungarrison unit(s)? Destroy (Delete) [*]Select unit Cycle through idle workers (.) Cycle through idle warriors (,) Group selection (0-9) Other keys to cycle through heroes / champions? Cycle through units by event? (last attacked / trained) [*]Unit commands Attack move (not yet implemented) Attack ground (not yet implemented) Build Garrison (Ctrl+Right-click) Run (not yet implemented) Charge (not yet implemented) Select formation Select stance Kill (Delete) [*]Camera commands for entities: Follow selected unit (F) Focus on selected entity (not yet implemented) Focus on rally point See also http://trac.wildfiregames.com/wiki/HotKeys

Committed path and bundle improvements (same ones used in the Alpha 9 bundle). Next I'll make a patch for the build system changes.

I forgot this, but you can change the renderpath setting to "fixed" and particles will be turned off (but also shadows).

Not yet, but we should have that option at some point.

Those aren't related to shadows, it's more likely a driver issue. Can you check if there's a newer graphics driver available for your GPU and OS? There was a discussion here.

Thanks, it seems to work perfectly