historic_bruno

I don't think the props need to be 100% realistic, IMO it's more important that the player can see what they're carrying at normal camera views.

Glad it's working again. Did you change anything to fix it?

AFAIK you couldn't view Chinese characters without the East Asian locale mod applied, or at least some modification of SVN They all appear as <?> in SVN, this is relevant information. The error is that it's out of memory: "Unhandled exception at 0x5e340a4a in crashlog.dmp: 0xC0000005: Access violation writing location 0x00000000.*D:\16009\binaries\system\msvcr100.dll: Out of memory.*C:\Windows\System32\ntdll.dll: Out of memory."How long had the game been running when this error occurred?The call stack shows the crash in texture converter, but it could occur almost anywhere in an OOM condition: > msvcr100.dll!__VEC_memcpy() + 0x51 bytes pyrogenesis.exe!CTextureConverter::ConvertTexture(const boost::shared_ptr<CTexture> & texture={...}, const Path & src={...}, const Path & dest={...}, const CTextureConverter::Settings & settings={...}) Line 460 C++ pyrogenesis.exe!CTextureManagerImpl::ConvertTexture(const boost::shared_ptr<CTexture> & texture={...}) Line 307 C++ pyrogenesis.exe!CTextureManagerImpl::MakeProgress() Line 372 C++ pyrogenesis.exe!RendererIncrementalLoad() Line 261 C++ pyrogenesis.exe!Frame() Line 321 C++ pyrogenesis.exe!RunGameOrAtlas(int argc=1, const char * * argv=0x0204e160) Line 511 + 0x5 bytes C++ pyrogenesis.exe!SDL_main(int argc=1, char * * argv=0x0204e160) Line 555 + 0xd bytes C++ pyrogenesis.exe!main(int argc=1, char * * argv=0x0204e160) Line 140 + 0xd bytes C pyrogenesis.exe!wmain(int argc=1, wchar_t * * argv=0x0204eb78) Line 380 + 0xa bytes C++ pyrogenesis.exe!__tmainCRTStartup() Line 583 + 0x17 bytes C pyrogenesis.exe!CallStartupWithinTryBlock() Line 397 C++ kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes Possibly it was converting a huge East Asian font texture and it ran out of memory (due to fragmentation or leaks).

There was no crashlog.dmp? Also the crashlog.txt says "OS: Vista SP 2 (6.0.6002)", not Windows 7.

Here is the call stack: ig75icd32.dll!631e6258() [Frames below may be incorrect and/or missing, no symbols loaded for ig75icd32.dll] > pyrogenesis.exe!CPostprocManager::ReleaseRenderOutput() Line 391 C++ pyrogenesis.exe!CRenderer::RenderSubmissions(const CBoundingBoxAligned & waterScissor={...}) Line 1567 C++ pyrogenesis.exe!CRenderer::RenderScene(Scene & scene={...}) Line 1870 C++ pyrogenesis.exe!CGameView::Render() Line 489 + 0x3c bytes C++ pyrogenesis.exe!Render() Line 229 C++ pyrogenesis.exe!Frame() Line 369 C++ pyrogenesis.exe!RunGameOrAtlas(int argc=1, const char * * argv=0x027115e8) Line 511 + 0x5 bytes C++ pyrogenesis.exe!SDL_main(int argc=1, char * * argv=0x027115e8) Line 555 + 0xd bytes C++ pyrogenesis.exe!main(int argc=1, char * * argv=0x027115e8) Line 140 + 0xd bytes C pyrogenesis.exe!wmain(int argc=1, wchar_t * * argv=0x02716c18) Line 380 + 0xa bytes C++ pyrogenesis.exe!__tmainCRTStartup() Line 583 + 0x17 bytes C pyrogenesis.exe!CallStartupWithinTryBlock() Line 397 C++ kernel32.dll!@BaseThreadInitThunk@12() + 0xe bytes ntdll.dll!__RtlUserThreadStart() + 0x24 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes It could be an issue with post processing initialization that is fixed for A18, though your GPU is definitely new enough that it supports FBOs. At least in the crash dump, pglBindFramebufferEXT is a null pointer, though it indicates the crash is occurring inside the driver itself. If enabling GLSL per Loki1950's suggestion doesn't help, then I would try updating your drivers.

Thanks! Any chance of posting the commands.txt from that game?

Can you describe what you were doing when the warnings occurred? Do they occur in-game, or Atlas, and on which maps, etc.

It might help to use a debug build, which will disable optimizations and give you a better chance of finding the variable you want. That's still hit or miss though, so a good fallback is to use some form of logging. Just general advice, not really even specific to 0 A.D. More about debugging in the context of 0 A.D. which may or may not be helpful http://trac.wildfiregames.com/wiki/Debugging

Art sources are supposed to be in this SVN repo: http://trac.wildfiregames.com/browser/art_source/trunk but I don't know if what you want is there (yet).

It's annoying to update most library binaries on Windows and just not much of a priority for our Windows devs. That said, you should create a new Trac ticket for it. There was an old one, but it was fixed, I would just create a new one with your list. Also, if we're going to start requiring VS 2013 in the future, they should be rebuilt for that, which can be mentioned in your ticket. It took years to bring things up to date before, just a warning What we really need to streamline the process is a build script for all the Windows binaries, so we can update the versions or compiler, and kick off the script. It's a lot of manual work now, and in many cases, you have to research the exact procedure and fix bugs to even get them to build. Sometimes you need CMake, sometimes you need the MSVC command line, sometimes it has its own bootstrapping, sometimes you need to build a bunch of dependencies first, sometimes you need to alter the project build settings (almost always, to get them to end up the way we want).

You mean in Premake build system? The version used there doesn't matter too much, you could request it upstream though. It would be better from 0 A.D. perspective to update to a newer Premake version.

That bug is known and already fixed for A18 (r15905)

That's strange, you're using A17? It runs perfectly for me on XP SP3, so I wonder if it only happens on some other error condition? We never call that function in our source code, so it must be some other library, but we need more information to debug this. Is there anything else mentioned in the error message? Is it reproducible on every attempt to start the game? Do you have user feedback enabled in-game? There are no crashlogs in your logs.zip, it would be helpful to run the game in a debugger, either Visual Studio or WinDbg as described here.

Fixed in r16129.

Did you set the CHECKOUTPATH variable? If you read the top of 0ad.nsi, it has an example command to use.

You will also need to download and compile wxWidgets for anything related to Atlas, including ActorEditor. There aren't a lot of instructions on the wiki about that, but there is http://trac.wildfiregames.com/wiki/BuildInstructions#BuildingAtlas I guess if you try and have any specific questions, ask them here.

It should mention which script the warning occurred in, please attach the interestinglog.html from the game's log folder, and it might help if you attach the saved map that causes the problem (archive/zip it first), so we can attempt to troubleshoot it.

I think this is intentional, it seems most (or all) helmed units remove their helm when shuttling a resource. I don't know why it's only when carrying the resource, possibly it should be when gathering as well, to indicate they are not ready for combat.

Fabio is correct, we need to see the build log to help any further, clearly it failed.

Strange, I was suspecting A17 would be the problem as that's when we switched to SDL2 on Windows. It sounds like an SDL bug, but I can't think of anything relevant we've changed since A17. Did you have a Windows or driver update or something? Maybe try A17 again to confirm.

The crash is definitely related to graphics card/driver described here, but it's already fixed for the next release. Edit: should mention that you can use the SVN dev version of the game until A18 is released, if you want to play the game in the latest state, though it won't be compatible w/ A17 in multiplayer.

If it's installed into User1's home directory, you should only run it from User1's account. Otherwise, there is a good chance that permissions will be incorrect. If you want both User1 and User2 to play the same install, you should install it somewhere that both can access. I don't know why that would cause a problem with cursors though, or if it would.

Which version of the game was the last to not have this problem? Is it in A17?

Philip's work-in-progress pathfinder had a fairly efficient reachability test, so that certainly could help, and there does need to be a limit to how often a unit can request a new path.

What would you suggest replacing it with? There will always be an artificial point at which the "land meets the sky" or the game world ends, and having a visible sky complicates this (besides not really enhancing gameplay or visual quality). There's a reason it's hidden by default. In some 3D environments, I've seen them reflect the terrain, trees, etc. out to infinity with filters in place. That's probably a better solution for a first-person view, not a top-down RTS like 0 A.D. The issue is the diversity of maps we have and the possible camera angles, so no one solution seems like it would work.