Orxonox

The libraries should work with all flavours of Visual Studio. Especially the Community version has most features of the full version available, I think. Googling a bit, it seems it's not recommended to mix debug and release builds, but some libraries (e.g. tcl) are used only in their release version...

Phew, everything is working now and the new package is uploaded. Would be good if someone else could test it, I may have overlooked some DirectX dlls. The main dependencies should be ok though.

Ok, thanks for that. I think I have most things sorted out now. The Visual Leak Detector should work too, just for good measure. The only thing left now would be cegui. There's no way I'll be able to port everything to the new version, so I'll try to compile the older version soonish. Btw, do you wa...

Ok, that was less painful than I thought. I can now compile everything fine with only three small changes. A few problems/questions remain, though: Are the poco libraries actually required? Poco linking gets disabled if the dependency package has version 7 (PackageConfig.cmake), but that version get...

Looks like implicit conversion an get<T> work now! I made only some simple tests, but all compiled. Guess I'll get back to trying to compile Orxonox when I have some more time.

Maybe a bit late, but here's what I found out: MultiType has overloaded conversions for std::string and char* (witch <class T> operator T*). You can assign both string or char* to a string, and that's where the ambiguity is. This also explains why a.get doesn't work (returns *this) but a.getValue do...

Yes, compiled libraries are not compatible with other versions of MSVC. I'll upload them if I can get orxonox to compile and make sure they actually work, too. I searched around the net and tried out some suggestions, but there doesn't seem to be an option to disable certain language features, excep...

Okay, I guess I'll end up doing some vector math, then. I'm still not sure if the turret should be allowed to roll, though. I mean, a 90° rotation of the pitch is the same as 90° roll and then 90° yaw, right? My idea was that it shouldn't rotate around itself (like a gatling gun, if you know what I ...

I finally got all the dependencies compiled, and am now trying to compile orxonox with MSVC12 (yeah, the numbers don't match). But apparently it doesn't like multitype, specifically reading it as an std::string. This compiles fine: #include <iostream> #include <util\MultiType.h> int main() { orxonox...

getOrientation returns a quaternion, and on that I use getYaw/Pitch/Roll. I don't use the actual values of the quaternion, if that's what you mean. I read up about quaternions and how they work and whatnot, but in the end I still have to somehow have angles, or something I can compare, to see if the...

Okay, so here's a breakdown on what I wanted to do: - Save the rotation of the turret as soon as the level loaded - When the turret wants to rotate, check if it's allowed to do so (i.e. keep the pitch/yaw/roll within some arbitrary interval) - If the current pitch/yaw/roll is too far away from the o...

getOrientation is used quite heavily in all the higher classes (Pawn+), but only deals with the quaternions. I found only two cases that actually use the values for pitch/yaw/roll, but also only very briefly (I think it's the fpsPlayer and the rocket). But I don't think they have the same problem, b...

So, I'm working on the turret and I ran into some problems. Depending on how the turret gets rotated inside the level file, getOrientation returns different values for yaw, pitch and roll. Here's a beautiful picture to illustrate what happens: http://oi60.tinypic.com/ngsh81.jpg The values to the lef...