Orxonox

Recently I have been thinking a little bit about the input system. First of all, the basic concepts are of my major concern. I've got two different approaches: i) Write an input manager that can handle different input modes, esp. game play and GUI. That means we would have to tell the input system w...

I just ran across spirit, a parser generator. http://www.boost.org/libs/spirit/doc/quick_start.html It very much reminds me of regular expression, but i think it can do more than regex when it comes down to storing the information. For instace the vector parser would have been quite easy with spirit...

As far as I'm informed, the boost libraries are quite lpowerful. They might help in more than just the multithreading section. For instance, the visual studio declares the f_open command as 'outdated, insecure', and complains with a warning. The boost libraries have safe and platform independant lib...

x3n wrote: (I'm not sure if the circle is good - if you try to adjust your orientation just a little bit, the ship won't react...).

Hmm, personally I think it to be a good idea under one condition: The player has to actually see the mouse cursor and the little circle. Then it makes perfect sense.

Hmm, I guess your idea is probably a good idea since our steering is implemented exactly (except for the little circle, which is yet to come) like you proposed. The actual problem is the implementation. E.g. where to write things down. It's most certainly gonna be in the Ship class. Another problem ...

Yeah... I don't think the ticket system works too well for that purpose...
You cannot discuss a subject effectively, as an example.

I hope you don't mind if I add all the input into the first post in order to compile a list.

This thread is supposed to be a discussion about the major concepts and "think-abouts" in orxonox. And of course if that involves larger problems, these are also to be addressed here. (reto) - Steering wit key-bindings, etc. (x3n working on it after the exams) (reto) - Sever/Client concept in cooper...

but before you start thinking about putting orxnox.cc into the src folder, you need to get rid of the back dependencies first. Still, I have no idea, how we're going to do that. There are a lot of hacky ways, but we develop orxonox ;) btw: Would it be helpful to create a thread listing all the major...

Someone will have to think about the whole steering thing anyways... Right now, our current steering is inside SpaceShip, since x3n did some work during a very lengthy night before the presentation... ;) I'm not even sure, if we have to extract that. We could just define a BaseShip with a basic stee...

with the sarcasm or the folder structure? :D Well, it wasn't me, btw. x3n did the work, again. Right now we have: audio loader network orxonox core hud objects weapon particle tools util tinyxml which is almost exactly like my last proposition, except for the loader. But that is a temporary subject ...

I've just seen that a new version of ogre has been released. I'm currently downloading...

http://www.ogre3d.org/index.php?option= ... Itemid=132

The core IS orxonox, so: audio network orxonox core (loader) hud objects weapon particle tools util tinyxml I would remove the hud and particle folder for now. I'm not even sure if there will ever be more than 2 files in these folders.. Anyway, if they exist, they better be placed in orxonox, not in...

I have come to see that the core is more or less completely independent of everything else (except the forward declaration of BaseObject, which is no matter at all actually). And moreover I suggest making the orxonox folder one single executable. This of course increases link time, but I have realis...

I see your point. As the project develops, the structure with the orxonox folder might be better. The question is of course: will it ever be possible to actually have something like a separate library? With the network: yes. But with what else? And having this structure just because of the network l...