historic_bruno

We've found the problem, an unforeseen change in the build system has caused the error, but only on certain Linux distros. Expect a fix soon

Even though this is from Fedora documentation, it looks relevant: https://fedoraproject.org/wiki/UnderstandingDSOLinkChange So basically, our build system is doing something that was allowed in the past, but has now broken (e.g. libX11.so.6 was being linked from some other lib, but no longer). I guess we need to add an explicit link for libX11? The test-related problems are just warnings so I'm not as concerned about them.

Output of otool -L for pyrogenesis, test, ActorEditor, libAtlasUI, libCollada: Notice the minimal number of dylibs they link against What I don't know is if Apple plans to maintain compatibility with the 10.6 SDK going forward, nothing they do would surprise me, we'll just have to wait and see. It would be annoying if e.g. Mountain Lion ships without some system dylib we depend on.

By the way, my test build works on both Lion and Snow Leopard, the only thing I don't know is if it will work on Mountain Lion You're quite right about that, and I also like the idea of a shared directory, so I'll work on that

OK, should be fixed now in r11104

I have no idea why that would be failing. You're not testing anything related to Android are you? Can you try ./clean-workspaces.sh to force a clean rebuild?

Does art/skeletons/skeletons.xml exist? Edit: nvm I see what's going on

Ran into a few tricky problems while working on the script. I couldn't figure out why it kept linking to the wrong version of libpng (the one bundled with OS X Lion, not from my script). It turns out a bunch of system search paths get added before any of the game's bundled library paths, and they'll be searched in that order. So I'm thinking we should move those to the end of the search list. I don't know if this causes problems on other platforms, but it shouldn't? Seems like all that's needed is factoring out the few offending lines into their own function and calling it in the correct order. Also Premake needs a "sysroot" option to handle SDK builds, otherwise you have to define environment variables like CPPFLAGS every time you build, which is less than ideal. This would also help the Android cross-platform build if I'm not mistaken. For OS X specifically, we need to handle the minimum required version parameter, as that tells the compiler how to link certain parts of the API depending on which version of OS X introduced them. Perhaps a "min-osx-version" option, or it could be done with an environment variable, but an option is more explicit and better documented. Both "sysroot" and "min-osx-version" would be set by update-workspaces.sh for the convenience of OS X devs (defaulting to /Developer/SDKs/MacOSX10.6.sdk and 10.6 respectively) Atlas - yes, sound - no. It doesn't change the sound problems, but if there's no other solution forthcoming we could always add OpenALsoft to the script.

It matters if you want to run the tests, but they are not required to run the game Try running "./update-workspaces.sh --without-tests" before rebuilding, and confirm that the build finishes with no errors. Still it would be nice to troubleshoot why the test is failing to build, if indeed the rest of the game is succeeding. When was the last time you did a full checkout of the source?

OK, now it's time for you Android fans to take over the work Nope, it will need gestures for this, see http://trac.wildfiregames.com/wiki/AndroidPort#Userinterface Official developers probably won't spend much time on it, other than what's been done, possibly applying patches. It's up to the community now.

Well the library build script has nothing to do with Premake, but of course the results are used by Premake when building the game, so I did have to modify it a bit (mostly extern_libs4.lua). Now I just need to make sure I can copy a build from Lion to Snow Leopard, if it works I'll be happy, attach the script and hopefully we can get the ball rolling on this I don't know if the change will be made for Alpha 9 as that's less than a month away. I think the libraries could possibly be organized further as you say, but that's not really my goal. For instance, there's a lot of Windows dlls in binaries\system that have no use except on Windows, it would be nice to do something about that. Some day

OK, my libraries build script is nearly done. The game libraries directory will change to look like this: (edit: updated per Philip's corrections) libraries \-- source (source, headers, and build scripts shared between different OSes) \-- cxxtest \-- enet \-- fcollada \-- nvtt \-- spidermonkey \-- valgrind \-- osx \-- build-osx-libs.sh \-- win32 \-- bundled static libs and headers for Windows builds, with wxWidgets included "source" is used to avoid duplicating the same files on different platforms, since our NVTT and FCollada are highly modified from the official releases. Its contents are shared by Unix-likes, OS X, and Windows. "osx" will contain only a build script, used to download all dependency source tarballs and build them in one step. 64-bit Windows and 32-bit OS X are not supported, yet. The way of making this clear, I believe, is to have an empty "libraries" directory in SVN, with a readme that explains the further process. You will need to do a separate checkout of the libraries for your OS of choice (separate from the rest of the source code). This also has the benefit of reducing clutter and the checkout size, since Linux users won't be downloading prebuilt Windows libs. Of course BuildInstructions will be modified to reflect this change. Every new OS X developer will run "build-osx-libs.sh", make some tea/coffee, wait maybe 10-30 minutes until the script finishes, then have all the dependencies necessary to build the game, without needing Mac Ports, though Xcode may still a dependency to get the Unix build tools (there's probably other ways to get them if someone is so inclined, but we're not supporting that yet). Currently it only builds static libs, I see this posing the least difficulties in creating a portable version of the game. For simplicity, this will be the only build method for OS X, unless we want to complicate things with one or more of the following: Support Mac Ports / other package managers - this would require a lot of conditional handling in Premake because search paths are different and pkg-config would be needed Offer prebuilt libs in libraries\osx as we do on Windows - would save some time in the build, especially on slower computers, but again requires lots of special handling in Premake and hardcoding the results of sdl-config and wx-config (similarly increases maintenance for us) Build dynamic/shared libraries instead - not difficult to do in the build script, but it does require the extra install_name_tool steps. Benefit would be people could swap different library versions in a bundle without having to rebuild the whole game, in case of incompatibilities. Is this is a reasonable concern? I don't know And finally here is what the script builds: SDL 1.2.15 Boost 1.48.0 wxWidgets 2.9.3 libjpg 8c libpng 1.5.8 (the reason for this is even though it's included on Snow Leopard, its version 1.2 is ancient and the game won't build with it due to missing some API features. Seems like less effort to just build it ourselves, unless someone is familiar with libpng development) libogg 1.3.0 libvorbis 1.3.2 libxml2 2.7.8 (this is also bundled with SL, but I need xml2-config from a consistent version, I think, so that's why I'm building it. Other suggestions welcome) ENet 1.3.3 Spidermonkey 1.8.5 NVTT (custom) FCollada (custom) All these libraries are built as 64-bit against SDK 10.6 with minimum required OS X version 10.6, since we're not supporting 10.5 yet (if ever). They are make install'ed into the local directory, so no root permissions are needed, but again this means the absolute path gets built into the *-config utilities. Even moving your build directories will require a full rebuild.

That's interesting, which OS are you on? Can you provide the system_info.txt generated by the game (in user the logs directory)?

Which error, precisely? (the last post is just a warning)

Would it? Particle systems have a fixed emitter, which would move along behind the boat maybe, but even if the emitted particles remained static behind the boat I don't see how it would look realistic while moving. If I'm not mistaken, animated textures was an idea thrown around in the past. Kinda moot point if we don't have animated textures Maybe some shading effect?

This patch should help a bit, it adds pre-converted models and animations to the archive (public.zip) so you won't need the converter

iOS support shouldn't be too hard, Apple has done a decent job of integrating the APIs for OS X and iOS (from what I've seen). Supposedly this will get even better, if we can create a bundle for OSX, it's feasible we can create an app for iOS, but I have serious doubts about whether it would qualify for the App Store. I would say focus on OS X and completing the game generally, then that will attract people with iPhones and iPads and whatever else, who can work on porting it. Although just having the basic Android demo is really exciting I agree, this would be a good feature not only for mobile devices but desktops as well. We should be able to detect supported resolutions and offer them as choices. It's easy to do that, but a functioning in-game options system needs to be designed first/concurrently.

Please post the errors you're encountering. You can find them in the error log %appdata%\0ad\logs\interestinglog.html

For those interested, it looks like this page is the place to go for the latest status of Blender's COLLADA support and plans for the future. They've also collected known open importer/exporter tickets, because their issue tracker is not pleasant to use

They are both slightly screwed, that's the problem, and why recently I've seen rumors that Blender may reconsider their support of COLLADA. Everything I know of that uses COLLADA is at least slightly buggy and sometimes completely broken. But anyway the 2.6 importer is definitely broken for skeletal models, and the 2.5 exporter is definitely broken for animations.

There weren't any errors but it looked terrible in actor viewer.

Yeah, even my test of a cube with a handful of bones was botched. I have multiple copies of Blender, I don't install them, but run the portable versions This is how it looks in 2.59: I don't know if that's correct or not so I'll attach the .blend as well. It doesn't seem to work when exported from 2.6 back to a DAE and tested in Atlas, so it may be another dead end m_tunic_short.zip m_tunic_short.zip

Yes. Sounds like the same type of issue as for shadows, the model is arbitrarily culled at a certain distance outside the camera view, which doesn't always look correct

Yeah, I think it might be a workable method for new models. If all we want is a Blender rig compatible with existing ones, why not just import the DAEs or converted DAEs as applicable? I converted all PMD models to DAEs, the skeletal ones haven't been committed yet but are available here (the horse model was about the only one I couldn't recover as a DAE, unless we convert them from .max they are essentially lost). Blender 2.6 DAE import is slightly broken, I think the biggest problem is the bones are rotated incorrectly. I've also tried importing the same DAEs into Blender 2.5 and the bones look much better, maybe even correct (I haven't tested), so would it be feasible to import the DAEs as rigs into Blender 2.5, save as a .blend, then work with them in 2.6?

Nice I'd also be interested in attempting this step: because that sounds like it would generate less awful DAEs and leave out the unused bones. This is good though, sounds like we've discovered a process for using Blender Rigified models in game, what did your final skeletons.xml entries look like, Wijitmaker? If this really works, it can be added to the art design document and maybe as a topic on the public forums (removing all the failed attempts and filler).