next »

[AotFSteven]

Hey guys, I am trying to implement an point and click structure with the BSPLoader.  I want to be able to click on the ground and have the avatar move to that position.  So the first thing that I need to be able to do is pick a particular point on the floor.  I was think that this would be done by just applying a grid of some sort to the floor where each square in the grid could be picked.  I am not sure how to do this, and I am also not sure what to do when there is an elevation difference...any help would be appreciated.

Pandaemonium, I know that you have been working on a similar set up have you had any luck with this?

Marvin, I saw the PointAndClickTest and this will be very helpful once I can figure out how to pick the ground.  However, did you know that after the view goes to the target if you click it again the screen just goes gray.  I have experienced this behavior some other times by moving where I can see both targets and clicking on while moving to the other.  It doesn't happen all the time in this situation but it does seem to happen all the time in the situation that I first mentioned.

[Marvin Fröhlich]

Hey guys, I am trying to implement an point and click structure with the BSPLoader.  I want to be able to click on the ground and have the avatar move to that position.  So the first thing that I need to be able to do is pick a particular point on the floor.  I was think that this would be done by just applying a grid of some sort to the floor where each square in the grid could be picked.  I am not sure how to do this, and I am also not sure what to do when there is an elevation difference...any help would be appreciated.

Well, the position you picked on can be read through the PickResult. there's a getPos() method, that contains the exact 3D-position.

Marvin, I saw the PointAndClickTest and this will be very helpful once I can figure out how to pick the ground.  However, did you know that after the view goes to the target if you click it again the screen just goes gray.  I have experienced this behavior some other times by moving where I can see both targets and clicking on while moving to the other.  It doesn't happen all the time in this situation but it does seem to happen all the time in the situation that I first mentioned.

If you regularrily keep using the FPIH while you manipulate its position and orientation, you might get such behavior. You seem to do this. I have never tried it. But I would simply suspend the FPIH while the automovement is runnung and unsuspend it after it is complete (like in my testcase). If you want to cancel the automovement, you should first cancel it and then unsuspend the FPIH.

Marvin

[AotFSteven]

Well, the position you picked on can be read through the PickResult. there's a getPos() method, that contains the exact 3D-position.

Thanks that is very helpful.  I thought that there would be a problem grabbing the correct 3D coords from a 2D interface but I guess not .

If you regularrily keep using the FPIH while you manipulate its position and orientation, you might get such behavior. You seem to do this. I have never tried it. But I would simply suspend the FPIH while the automovement is runnung and unsuspend it after it is complete (like in my testcase). If you want to cancel the automovement, you should first cancel it and then unsuspend the FPIH.

Okay, I will look into doing this.  Also note, that this was using your test case that I ran into those problems.  I have not started looking into this except to run the PointAndClickTest.

[Pandaemonium]

Pandaemonium, I know that you have been working on a similar set up have you had any luck with this?

Yes, I have my point and click movement done. However, my current code base is broken as I decided to move away from the FPIH and to create my own CustomInputHandler, CIHConfig, KeyCommand, KeyCommandListener, etc. I'm hoping to have my customized input handler done very soon.

Well, the position you picked on can be read through the PickResult. there's a getPos() method, that contains the exact 3D-position.

Yep, I'm pretty sure that's how I determined the location on the floor/ground where the player clicked.

[Marvin Fröhlich]

Yes, I have my point and click movement done. However, my current code base is broken as I decided to move away from the FPIH and to create my own CustomInputHandler, CIHConfig, KeyCommand, KeyCommandListener, etc. I'm hoping to have my customized input handler done very soon.

Is it code, that you could share and contribute to the xith codebase? Or is it too specialized or even copyright protected?

Marvin

[Pandaemonium]

Is it code, that you could share and contribute to the xith codebase? Or is it too specialized or even copyright protected?

Sure, I can contribute. So far, it's not terribly specialized. Once I get it fully functional and working I'll refactor.

Right now, I'm having a problem with the mouse wheel events, as I have:
mouse wheel up -> mapped to discrete zoom in
mouse wheel down -> mapped to discrete zoom out

However, in the FPIHKeyStatesManager, I am finding that the only possible state for the mouse wheel is UP (and it is always UP). Is this a bug or by design? Ideally, I'd like to use this key state manager (or similar manager) to handle events as they come in from the mouse, especially zooming in/ zooming out with the mouse wheel. Once I capture the event, I want to notify the listeners as per the normal event/listener model. The current implementation of FirstPersonInputHandler doesn't follow this model, even though it seems to imply it by the use of: 

Code:

// in FPIHKeyBindingsManager
DEFAULT_KEY_BINDINGS.bindKey( MOUSE_WHEEL_UP,             KeyCommand.DISCRETE_ZOOM_OUT );
DEFAULT_KEY_BINDINGS.bindKey( MOUSE_WHEEL_DOWN,           KeyCommand.DISCRETE_ZOOM_IN );

Thoughts?

[Marvin Fröhlich]

Sure, I can contribute. So far, it's not terribly specialized. Once I get it fully functional and working I'll refactor.

ok, cool.

Right now, I'm having a problem with the mouse wheel events, as I have:
mouse wheel up -> mapped to discrete zoom in
mouse wheel down -> mapped to discrete zoom out

However, in the FPIHKeyStatesManager, I am finding that the only possible state for the mouse wheel is UP (and it is always UP). Is this a bug or by design? Ideally, I'd like to use this key state manager (or similar manager) to handle events as they come in from the mouse, especially zooming in/ zooming out with the mouse wheel. Once I capture the event, I want to notify the listeners as per the normal event/listener model. The current implementation of FirstPersonInputHandler doesn't follow this model, even though it seems to imply it by the use of: 

Code:

// in FPIHKeyBindingsManager
DEFAULT_KEY_BINDINGS.bindKey( MOUSE_WHEEL_UP,             KeyCommand.DISCRETE_ZOOM_OUT );
DEFAULT_KEY_BINDINGS.bindKey( MOUSE_WHEEL_DOWN,           KeyCommand.DISCRETE_ZOOM_IN );

Thoughts?

Well, this should work. If it doesn't it's a bug.

Right now I am writing a new input system, that will more easily allow plugging in your own input system (like a JInput based one) which will still cooperate with Xith's IS. One more feature will be, that KeyCodes and Mouse buttons as well as mouse wheel events will be handleable through the same object type, which is needed to more easily implement things like the above in the input handlers.

As you will already have seen, I created special pseudo-KeyCodes for the mouse buttons and the mouse wheel to make it usable for generic input events. This will be much simpler.

But don't worry. You don'T have to rewrite your whole InputHandler . The code will be quite simple except for these improvements and some package names.

Marvin

[Marvin Fröhlich]

Hmm... I read your posting a second time. What different key-states would you expect for the mouse-wheel? Actually it is never up or down. It's state is undefined. There's just an event when the wheel is moved.

The current implementation of the FPIH checks this separately. But the new input system implementation will allow for this to be handled the same way as the regular keys.

Marvin

[Pandaemonium]

The current implementation of the FPIH checks this separately. But the new input system implementation will allow for this to be handled the same way as the regular keys.

Awesome, that's exactly what I'm after.

What different key-states would you expect for the mouse-wheel? Actually it is never up or down

Well, up and down makes sense to me for the mouse wheel (a different up/down context from the other keys). I tested on printing on a MouseWheelEvent, and when delta > 0, wheel was moved up, and when delta < 0, wheel was moved down. If this action could be mapped to the KeyStates, that'd be perfect.

[Marvin Fröhlich]

Well, up and down makes sense to me for the mouse wheel (a different up/down context from the other keys). I tested on printing on a MouseWheelEvent, and when delta > 0, wheel was moved up, and when delta < 0, wheel was moved down. If this action could be mapped to the KeyStates, that'd be perfect.

Hmm... In this sense the wheel would have three basic states: none, up and down. When the wheel is polled, the state would be up, if delta > 0 and down, if delta < 0 and none, if delta == 0. Actually the wheel is more like an analogue axis regarding its state, but can generate events like a button or key.

So the KeyStatesManager cannot currently handle the wheel state, since it works on boolean arrays.

I'm still not totally sure, how I will do it to make it usable the same way, but I WILL do it, since I need it myself in some way in the FPIH .

Marvin

[AotFSteven]

I am grateful that you both are working on this .  I was about to start trying to create a PointAndClickInputHandler but I was feeling really uneasy about trying to accomplish this.  I guess I will just wait for the new changes and work on something else in the meantime.

[Pandaemonium]

Quick update, I have my CustomInputHandler (which I think I'll rename to PointAndClickInputHandler) completed. It provides an implementation that is a combination of the FPIH and ObjectRotationInputHandler. The handler handles input that will move an avatar to a particular location upon a mouse click and allows zooming in/out through the mouse wheel. The user is free to rotate the camera in an orbital path around the avatar using the keyboard.

This handler is still a bit bloated and I'm currently fixing a bug with zooming. Marvin, have you given any more thought about the correct implementation of a mouse wheel up and down event in the KeyStateManager? This feature would help this handler to become more modular.

Sorry for the slow update, but a co-worker convinced me to try out WoW. Such a time-sink. 

[Marvin Fröhlich]

Great to hear, that you're still working on it.

Marvin, have you given any more thought about the correct implementation of a mouse wheel up and down event in the KeyStateManager? This feature would help this handler to become more modular.

Well, looks like I have to be sorry for the slow update. I am still working on the new InputSystem. I haven't had that much time and motivation in during the last days. But it's close to being finished. I hope to finish it till the end of the week. Then I will tell you, how the new way looks like.

Marvin

[Marvin Fröhlich]

Hey guys

Since we were getting off topic here (which was mostly my fault) I have split this topic here to have a separate thread for the new InputSystem.

You can find it here.

Marvin