historic_bruno

Don't worry too much about buildings losing health in enemy territory, that's a "temporary" hack. While it has been in the game for years, so it may seem like a permanent and intended design, it really was just a placeholder. We don't have building capture yet, so the only way territories would have a decent gameplay effect was to decrease health in enemy territory, combined of course with building restrictions to make it important to expand territory - but that alone was not considered enough. I think the way it works now is decent so that most people don't complain or even think about it, but yeah, it will most likely change. The concept of territories has evolved over the years, and I'm sure it's not done yet

Sounds like you're working with a very confused build environment there, so things are bound to break The game is no longer intended to use MacPorts or Homebrew, but in this case you might be OK. I can't really say because it's not a tested or supported configuration anymore (for a lot of reasons).iconv might exist in libraries/osx, but that doesn't mean tinygettext has to use it, iconv also comes bundled with OS X - and if you have Homebrew installed, some scripts will pick up its libraries too. So unless you modified the tinygettext build scripts or Makefiles to pick up the correct iconv, maybe it's using a different one than you expect. The same goes for ICU, a very basic version comes bundled with OS X, so you would need to modify premake scripts or the Makefiles to use Homebrew's version, which could have its own dependencies in turn. Of course, it's easy to check what the compiler is doing, by building with "make verbose=1" or passing -v directly to the compiler and closely inspecting the linker invocations. __ZN4L10nD2Ev is the mangled symbol name, c++filt will tell you the human readable name. Most likely it's failing at some earlier step, perhaps an unresolved dependency, you should post the entire build log since it's easy to miss something. In fact, if you do, use "make clean && make verbose=1", to get the full verbose output up to the error. You can save it to a file with something like "make verbose=1 > build_output.txt 2>&1"

Using actual Japanese characters? If so, you won't be able to check them because our fonts don't contain them yet. As leper said, you definitely need tinygettext, which is bundled in libraries/source/tinygettext. The other dependencies I can think of which may or may not be included on OS X are libicu and iconv. So you need to build tinygettext in the correct location and update the premake script extern_libs4.lua for "macosx", probably using the same paths as for Windows, like we do for other bundled libraries. I might test it myself on OS X and if I get it working, I will push the changes. Wouldn't cmake work? It has the scripts anyway and I used them for the Windows build. Let's not require yet another build tool just for tinygettext

I was thinking so the other day and it would be my preference, but until we've migrated to git, we can't really get everyone on board with that. Especially people who rely on the Windows autobuild, they're stuck on SVN. GC is something we really need to think more about, running it every turn may not be acceptable depending on what's going on, but it should be run regularly enough that it's not too slow. It seems likely that we need to be directly in control of when GC occurs since SM's metrics won't really take into account the impact on our engine.

Has this happened multiple times? You might try deleting the temporary 0adsave file in %localappdata%\0ad\cache, to see if that helps.

Which OS are you on, which GPU do you have and which driver version? It seems there's no way to configure the game's refresh rate, but it should at least use your desktop settings.

I think that all depends on how well the "frozen" version works, and relative to how well the upgrade works. We could very well encounter new, worse bugs than we currently have to deal with. That's a risk with any library but most of the others we use are far more stable and don't have major rewrites of the internal workings and API from one version to the next, and they're more general purpose instead of having just one major "user" in mind. We've been testing 1.8.5 for years, but what are the serious issues we need to patch to resolve? There is the weird JIT OOS issue recently discovered, but we have a workaround; I'm sure the upgrade will introduce similar weird JIT OOS issues that take years to discover/work around. But I was thinking most of the issues with our scripting engine boiled down to how we're using it, rather than the engine itself, i.e. we shouldn't have code that requires hypothetical SM JIT/GC performance improvements to be feasible - that code should simply go away That's a sunk cost and shouldn't have any impact on the decision moving forward, on deciding whether it's the best option or not. Doing nothing more should always be an option under consideration. Maybe it won't, everyone was certain that a newer version of SM would bring performance improvements, but it didn't... so I'll remain skeptical for now about the GC changing for the better

Yes, it would be very hard and I can't imagine why you would want to in the first place. IMO it's enough to have one well-tested working build platform on Windows (because almost all Windows devs will be using VC++, yet they will make up only a small number of the people using the game on Windows; another build platform is a lot more code to be maintained, etc.) If you really wanted to do that, you would need to substantially alter the game's premake build scripts. Premake may have working MinGW support, but our build scripts certainly don't. They assume that Windows build environment implies the VC++ toolset. You would also need to add MinGW-specific code paths throughout the engine where it also assumes that Windows builds are on VC++, and you would probably need to rewrite most or all of the lowlevel Windows code in the engine. Not sure if all the win32 dependencies would need to be rebuilt for MinGW as well? A more useful task IMO would be setting up MSVC projects for the various dependencies of the game, so they can be easily rebuilt with different versions of the compiler (some of them are straightforward, others like Spidermonkey are not), possibly by the autobuilder itself. Even getting a 64-bit Windows build working would be more practical and interesting, but still lots of work

VS2013 isn't supported yet, one problem is the Boost static libs for it aren't included - the latest version of Boost doesn't properly support it, much less the version we're using. Once Boost fixes that, I will look into installing 2013 and building the Boost libs. Actually it would be nicer if we migrated to git first and split the precompiled libs, because it's annoying for everyone to download the thousands of Boost headers after each upgrade

Another option is to stay with 1.8.5 Has the rationale for upgrading changed since this post: http://www.wildfiregames.com/forum/index.php?showtopic=17289&p=269566 ? At least it seems we can rule out performance improvement generally, not sure about GC improvements or AI threading. Is random map generation still faster?

What's your OS? Are you using the map in Atlas or in-game? If it's freezing with no visible errors, there are still ways to troubleshoot it, see Reporting Errors

How long did it take to load? Did you press any keys or do anything while it was loading?

You won't get the debug C runtime libs anywhere (legally) unless you install the full version(s) of VS Professional, that's due to Microsoft's licensing. The express editions don't include them. The alternative is to stick with release builds instead of debug builds, which are still quite useful for debugging and much faster.

Maybe it's doing something similar to Avast, which has a kind of "cloud"-based protection system that will flag every executable as suspicious and possibly dangerous until it has been scanned enough and reported back to their servers (unless the app is whitelisted by the user). With Avast, probably only the first few people to run the game will encounter that. In fact it launches the game in a sandbox and causes an error, which we should troubleshoot sometime.

Jan has responded on the Trac ticket. The fix looks simple, so it should be in the next release Until then, you should be able to Continue or Suppress the error and continue playing the game without issues (it's more of a sanity check than some critical part of the engine).

Keep in mind the decision was made long ago and basically is set in stone, but here is an insight into why JavaScript was chosen: http://www.wildfiregames.com/forum/index.php?showtopic=15068

Jan would be the expert on this, so I've created a Trac ticket and CC'd him: http://trac.wildfiregames.com/ticket/2346

So there are two problems: your sound card fails to init, and the sound manager crashes as a result. I've made a ticket for this on Trac: http://trac.wildfiregames.com/ticket/2345

Those errors are fairly typical when trying to load a saved game from an older/newer version. That's not supported.

As a workaround, you can try starting the game without sound by passing the -nosound argument (in Windows, you can make a shortcut to the game and modify its properties to add that flag).

Thanks! Now we know it's reproducible and the important line from the log is: [4240] ERROR: Sound: AlcInit failed, m_Device=108C7F00 m_Context=00000000 dev_name=OpenAL Soft err=40961meaning sound init failed, the device was opened but the context failed to be created, the error code is 0xA001 (ALC_INVALID_DEVICE). It's not immediately obvious why the error would occur, but I notice your sound card has an accented character in its name: "AMD High Definition Audio Device; High Definition Audio-Gerät;" - maybe that causes problems.Obviously the sound manager isn't handling this error condition properly.

The registration process is weird... You need to give the username and password you want as if you were signing into the lobby, then choose to "register", where you will be required to re-enter your password. Then you will go back to login with the new username and password. This needs to be documented but really the UI needs an improvement...

At first glance, this crash is sound-related: > pyrogenesis.exe!CSoundManager::ClearPlayListItems() Line 489 + 0xf bytes C++ pyrogenesis.exe!ScriptInterface::call<void,&JSI_Sound::ClearPlaylist>(JSContext * cx=0x00ecf0c8, unsigned int argc=0, unsigned __int64 * vp=0x04990150) Line 103 + 0xba bytes C++ mozjs185-ps-release-1.0.dll!5d870d10() [Frames below may be incorrect and/or missing, no symbols loaded for mozjs185-ps-release-1.0.dll] pyrogenesis.exe!std::vector<CProfiler2::ThreadStorage *,std::allocator<CProfiler2::ThreadStorage *> >::_Umove<CProfiler2::ThreadStorage * *>(CProfiler2::ThreadStorage * * _First=, CProfiler2::ThreadStorage * * _Last=, CProfiler2::ThreadStorage * * _Ptr=) Line 1141 + 0x28 bytes C++But there's not much to go by, nor is it a likely spot for a crash. Can you run the game again, and post the new crashlog.dmp as well, so we can compare the data and see if it's the same crash each time or something random?Another thing that might help catch sound errors is running Microsoft's free DebugView tool, then running the game, and copy/pasting the log output, after it crashes. Especially if it mentions problems with sound initialization. r14385 is the revision in the Windows autobuild used for A15 It's also normal for the crash dump to refer to SVN paths from the autobuild server.

The game actually includes UPnP now, which is intended to handle the port forwarding automatically when hosting a game (obviously it needs to be enabled and supported by the router). If that's not working, it would be helpful to see the logs so we can diagnose it. If you can acquire mainlog.html from the game's log directory on a system that can't host with the lobby, that would be great: GameDataPaths Also it was suggested to have a notice about port forwarding for the lobby but I think having UPnP made it seem unnecessary.

Those last messages aren't errors and should be harmless. Please post the exact error message you're getting and full logs, see ReportingErrors and GameDataPaths. It's not clear from your report, are you trying to load a saved game from a different version of the game?