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 which mode it is at the moment and then the system distributes the input accordingly (e.g. to the CEGUI or to the whatever, I haven't thought about this very clearly yet).

ii) Input listeners. The issue is that OIS can only have one listener for each device. So we would have to create a mid-way manager that can handle multiple listeners (exactly like the class InputManager in src/orxonox).
This approach however has the obvious disadvantage of the listeners behaving "politely" in order to prevent a chaos.


For my taste, the second approach sounds better since the input manager has less responsibility. So whenever the Orxonox mode switches from game play to GUI, the input switching has to occur in the GUI or game play.

So far I have coded the basic construct for the InputHandler.

What I'm going to do next:
Capture all the input and then either plug it into CEGUI OR encode the keys (like up, down, a, s, d, enter, etc.) into 'orxonox actions' like MoveForward, Fire, ShowMenu. Each of them has an integer number assigned.
To actually get these messages, any class can (via Listener) register an object in the InputHandler (multiple listeners allowed).

That of course means that every part of the program who wants input needs to encode the actions (instead of keys) once again. But I don't see a problem in that.

Now I've got a serious question for the network guys:
Am I doing things in a way that it works with your network support?

As far as you have explained to me, you have already programmed such a scenario.

Seems like you have done most of the input handler work already. In case you are not finished, look at the old Orxonox source, there is a Input Handler and EventHandler class, that will do exactly what you proposed.

oh, thanks for the reminder that we've already got a lot of source code. I think I've never had more than a glimpse at the old code..

I've just had a quick look at EventHandler and EventListener in the old orxonox code. But as far as I can see an object had to subscribe for every event it wanted to capture.
I was rather thinking of something like the inter process messages. In that case every object receives all the events (key binding independently) and can choose which to process.
This would also simplify network communication.

1337 wrote:Now I've got a serious question for the network guys:
Am I doing things in a way that it works with your network support?

As far as you have explained to me, you have already programmed such a scenario.

Everything should be possible so far The question is, whether the chosen solution will also be the best (fastest, most stable) solution ...

I might have found a new problem. This is the line we inserted in the InputManager to resolve the linux OIS crash problem when key repeat wouldn't work anymore:
However, it's not without side effects: Last time I tested the new console on tardis, the key repeated in orxonox when holding. And on windows they wouldn't.
That of course messes with KeyPress and KeyRelease events...

Maybe, I can find another solution for the OIS problem, but the only thing I can think of is the signal handler.
So, I've written a ticket to extend the SignalHandler. Unfortunately I have absolutely no idea about signal handling...

I've just found this link. It's not directly talking about your problem, but it's something about tcl and autorepeat, maybe there is some input you could use... http://wiki.tcl.tk/20299

Thanks, I read part of it. But as I see it, this is more low level than we have. We would have to fiddle with OIS internals (compile our own OIS) if we were to to apply the suggested methods.

This problem has to be solved in another fashion.

Some time ago there was a problem with the OIS specific code.

Today, I've updated my libraries to ois 0.7.2, 1.0 and 1.2.0. I was hoping to make all three of them run. However, 0.7.2 makes problems. As soon as the mouse is moved I get a segfault. Somehow, the event argument seems to be empty, i.e. not allocated.
Spending some time on google and the ois forum, I have decided that it would probably take too much time to make the input system work with OIS 0.7.2, so I'm not going to support this version.

That means, running orxonox would require OIS version 1.0 or above (only 1.2.0 currently), but the tardis boxes are already prepared.
I don't think that old versions should pose a problem: 0.7.2 is dated mid 2006 , 1.0 December 06 and the brand new 1.2.0 is only 5 weeks old.

I hope those of you wither older versions (if any) can update without trouble.

Another matter: Does anyone have 2 joysticks? I would be very interested to see whether my plan to support n joy sticks actually works.

ois 1.0+ is no problem. why supporting outdated versions

and no, i don't have a joystick. but what's with gamepads? they usually have two analog sticks. oh, and we should support racing wheels
no, just joking.

I think that game pads qualify as joy sticks in OIS. If not, well then there is no support.
And thanks for the reminder, there happens to be one of these somewhere in my house catching dust...

I've got OIS v1.0 release candidate in my package repository with Ubuntu 8.04, so this should be okay when we do not support that old of a version.

I like the gamepads. In the Ogre forums they use OIS or SDL to make them work.

beni wrote:I like the gamepads. In the Ogre forums they use OIS or SDL to make them work.

hmm, I would really like to see orxonox being played with game pads one day...