next »

[SephirXV]

I'm trying to build the GUI that creates/edits my input bindings; I'm not using the provided class for bindings/management/handling, but that shouldn't affect my question.

I have the Swing component(s), and seems to work fine, but there is the part where the user is supposed to press/click the key/button that they want to bind, and that event needs to be from Jagatoo and I really don't want to generate code to convert from one to the other, it would never endure changes within Jagatoo.

What I'm hoping for is that the Swing input system and the Jagatoo one can both receive events without affecting each other. Then I can make an eventCapturer which always listens to the Jagatoo events, but normally ignores them. Then, when the user triggers a binding capture, the gui calls a method on the eventCapturer which sets a flag which causes the capturer to process the next event it gets, extract the InputDevice and DeviceComponent from it, and store them, then set the flag back to ignore. Then my GUI could retrieve the stored event and alter the binding map.

Can anyone tell me what might go wrong with this approach? Also, it would be ideal if I could do this outside the Xith environment, can Jagatoo be tricked into running on it's own just to interpret input?

My next question involves how to store a binding to a file, which is really all about how to store Key's & MouseButton's (not Keys & MouseButtons). Using the String that the Key / MouseButton was constructed from doesn't seem to be an option. The best I can come up with are

Code:

Key k = KeyID.valueOf("").getKey();
    k = KeyID.values()[0].getKey();
MouseButton mb = MouseButtons.getByIndex(0);
//where "" & 0 are just placeholders for the appropriate label/index

MouseButton doesn't give me any choices, but Key has two possibilities; Assuming both of them work, which is more resistant to change, the textual description or the ordinal?

[Marvin Fröhlich]

I see no problem with your approach. It should work. Though I don't see the point, why you want to do that in a swing environment. Do you really want the input bindings to be configured in a swing environment outside of your game Isn't this quite uncommon? And you already seem to know the existing InputBindingsManager and the HUD MenuSystem Menu implementation for that. Well, it's your decision...

Also, it would be ideal if I could do this outside the Xith environment, can Jagatoo be tricked into running on it's own just to interpret input?

You don't need to trick it. Everything in JAGaToo is meant to be used by any implementing environment. So nothing is Xith specific. Especially the InputSystem is very easy to be used in any environment. You just need an implementation of InputSourceWindow. There's a testcase in JAGaToo's test directory, that demonstrates most of the InputSystem's features. And it doesn't use xith at all.

My next question involves how to store a binding to a file, which is really all about how to store Key's & MouseButton's (not Keys & MouseButtons). Using the String that the Key / MouseButton was constructed from doesn't seem to be an option. The best I can come up with are

Code:

Key k = KeyID.valueOf("").getKey();
    k = KeyID.values()[0].getKey();
MouseButton mb = MouseButtons.getByIndex(0);
//where "" & 0 are just placeholders for the appropriate label/index

MouseButton doesn't give me any choices, but Key has two possibilities; Assuming both of them work, which is more resistant to change, the textual description or the ordinal?

Yes. This is the way to go. The labels will never change and the ordinals should also never change. But since they are auto generated, I cannot really promise anything here. It's anyway better to have readable names in the your config mapping file.

Marvin

[SephirXV]

Do you really want the input bindings to be configured in a swing environment outside of your game? Isn't this quite uncommon

It is almost entirely unheard of, but I actually do want the ability to edit bindings outside the game environment, possibly in a totally different VM.

You don't need to trick it...You just need an implementation of InputSourceWindow.

Does implementing that window handle the updating with the current nano time, as mentioned in Chapter 1 of the JAGaToo doc?

It's anyway better to have readable names in the your config mapping file.

That depends on whether you want users able to mess with it. Some bindings you might not want them to alter (parts to work something outside the main game). Of course if you don't want them in there, obsfucation won't slow them much.

Alright, I'll look into implementing the InputSourceWindow and we'll see how far I get.

[Marvin Fröhlich]

Does implementing that window handle the updating with the current nano time, as mentioned in Chapter 1 of the JAGaToo doc?

No. This has nothing to do with it. You still need some kind og game loop, that calls the InputSystem's update() method, just as xith does.

That depends on whether you want users able to mess with it.

Sure. But AFAIK engines like the Quake ones have proven to be quite popular because of their ability to be modded. And this is not at least because of the readable config files.

Some bindings you might not want them to alter (parts to work something outside the main game). Of course if you don't want them in there, obsfucation won't slow them much.

That's true. But if you put some unreadable numbers into the config file, people can still find a way to map these numbers to what they actually represent. So this is not a protection against cracking. You would have to write encrypted binary config files. And this is nothing, that would help you or your users. I would always prefer human readable config files.

Marvin

[SephirXV]

But if you put some unreadable numbers into the config file, people can still find a way to map these numbers to what they actually represent. So this is not a protection against cracking. You would have to write encrypted binary config files. And this is nothing, that would help you or your users. I would always prefer human readable config files.

Really? Perhaps I misunderstood what you were saying here:

... And each "layer" or properties should be binary-safeable and sealable. So this would be a combination with mbussi's idea.

I assumed those had to do with encrypting or some sort of checksum to detect, if not prevent, tampering.

[Marvin Fröhlich]

Really? Perhaps I misunderstood what you were saying here:

... And each "layer" or properties should be binary-safeable and sealable. So this would be a combination with mbussi's idea.

I assumed those had to do with encrypting or some sort of checksum to detect, if not prevent, tampering.

Well, it depends. The input config is nothing, that needs to be encrypted. Let's say, you have a savegame or something like that and you want to avoid cheating. Then you might want to encrypt the stored savegame. But input config is nothing, that aloows for cheating not there is another reason to encrypt it. But that's just my 1 cent.

Marvin

[SephirXV]

Roger roger

[SephirXV]

Well, I've given thought to what Marvin has said above, and went back to the drawing board and revised my design needs some. I decided it would probably be easier to make a skimmed down Xith environment just to wrap a 'self-contained' editor in then get JAGaToo running how I wanted then without Xith at all. Either way, my editor will run in (some form of) a Xith env.

I looked though the UI/widgets provided but didn't see anything approaching a table, so I went back to JTable because that's what I knew. I've got TableCellRenderers for my InputAction derivative as well as for DeviceComponent, and a TableCellEditor for DeviceComponent. That cell editor passes out a JComponent that implements JAGaToo's InputListener, my InputSink. It does as described in previous posts, listens to but ignore's all input events, unless it has been enabled, in which case it stores the next event it hears and then disables itself again, allowing upstream code to retrieve the DeviceComponent representing the keypress or mouse click, and store it back into the InputBinding.

I've run it in it's own window along with a small (working) demo that allows user to walk around a cube, but there the real and theoretical issues arise. First, when I click the cell as if to edit it, it clears what was there (temporarily), but doesn't change color, the component I pass is supposed to have a different color so I could tell it was working. It also apparently doesn't receive events, the listener method is never fired. It didn't really occur to me, but I guess that's because it's listening for events on the demo, but I'm not clicking or pressing buttons in the demo? Last, I guess I need to alter the InputSink so it notifies the editor that it's done; say the enable method includes a reference back to the editor, an InputSinkListener if you will, so the InputSink can capture an input, disable itself, and then notify whoever cares that it has an event stored.

Anyway, I'm wondering if anyone has even approached this issue, letting users specify bindings by pressing the appropriate key/whatever, I plan to submit mine when I get it working, that way others can have it, and fix the oversights and assumptions I make. I find it hard to believe that I'm the first, but even so, if anyone could give me some hints on what I'm doing wrong, I'd appreciate it.

Edit

Alright, it would have saved me time if I had a) used my brain or b) paid attention to the color of the triangles in Eclipse: green means override. JComponent (which InputSink extends) has a setEnabled(boolean) method already, and I forgot to enable it because something else was doing it for me (meaning the enable on JComponenet). So I changed my method and then called it from the editor when it passes it out to a table, and low and behold, it works better. It also helped to call my editingStopped/Canceled listeners.

So I know the editor is having it's getValue method called as long as the input was done with the demo window in focus, but then I get an exception and can't see if the table it updating or not.

(I've excluded everything below the input firing)

Code:

removeCellEditorListener()
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at sephirxv.input.binding.DeviceComponentTableCellEditor.stopCellEditing(DeviceComponentTableCellEditor.java:59)
at sephirxv.input.binding.DeviceComponentTableCellEditor.useInput(DeviceComponentTableCellEditor.java:79)
at sephirxv.input.binding.InputSink.onMouseButtonPressed(InputSink.java:68)
at org.jagatoo.input.devices.Mouse.fireOnMouseButtonPressed(Mouse.java:492)
at org.jagatoo.input.impl.lwjgl.LWJGLMouse.collectOrFireEvents(LWJGLMouse.java:199)
at org.jagatoo.input.impl.lwjgl.LWJGLMouse.update(LWJGLMouse.java:277)
at org.jagatoo.input.InputSystem.updateMouses(InputSystem.java:1125)
at org.jagatoo.input.InputSystem.update(InputSystem.java:1168)

I assume that it's conflicting with the editingStopped/Canceled notification of listeners (specifically the for(class instance : Vector<class>) iteration). It does the same thing if I just click the cell again, or another cell (cancelling the edit) or press an arrow to navigate to another cell, but not if I press Escape. I'm guessing it's the 'fail-fast' of lists because I'm removing an element while something else is iterating. So I need to delay the removal somehow.

Even if I comment out the listeners.remove(listener), no exception, but the model isn't updating. Anyway, anyone know why setting the color of my component doesn't affect how it's rendered? Does JComponent not even have a working paint method?

Edit

Okay, apparently asking on a forum is the only way for me to figure stuff out myself. I hadn't implemented the setValue method of my model. So as far as the JTable is concerned, it works (mostly). However, I have two issues. One is that even though I unbind any prior bindings to that DeviceComponent before I bind it to the new on, the table doesn't show any changes but to the current cell. I'm guessing it's a listener not setup somewhere. The other one is that when I edit a binding that should involves an unbinding, the demo starts moving by itself, and I can't stop it. Let me guess, need to edit a binding I'm not currently using, right?

BTW, if anyone thinks this belongs in one of the other categories, I'd probably agree. We left the realm of something internal to Xith a long time ago.

[Marvin Fröhlich]

Anyway, I'm wondering if anyone has even approached this issue, letting users specify bindings by pressing the appropriate key/whatever,

Actually I have . The InputBindingsSettingsMenu provides this approach.

I plan to submit mine when I get it working, that way others can have it, and fix the oversights and assumptions I make.

That would be cool. Having an editor like this in JAGaToo is certainly a good thing.

Marvin

[SephirXV]

Actually I have . The InputBindingsSettingsMenu provides this approach.

Really? How does it operate (user POV) compared to mine?

[Marvin Fröhlich]

Really? How does it operate (user POV) compared to mine?

Just have a look at HUDMenuSystemTest in xith-tk (ui package) and select Settings->Movement.

There was a little timing bug. So please update before you test it.

Marvin

[SephirXV]

After seeing yours, I'm not sure what new functionality mine has to contribute. It uses a fancier table, that's about it.

[SephirXV]

I fixed all of my issues except one: my swing window doesn't catch JAGaToo inputs, I have to focus a Xith window first. I looked at the SwingIntegration/Overlay tests, and I'm curious whether one of those would work. All I really need is a window where swing components work (relatively quickly, but nothing break-neck) and when those components have focus, JAGaToo still generates fires listener methods.

I'm beginning to think that a better use of my time is just to make a Swing-ish table (scroll optional) using the HUD/widgets available, that way it's usable regardless of GL/peer interface.

[Marvin Fröhlich]

After seeing yours, I'm not sure what new functionality mine has to contribute. It uses a fancier table, that's about it.

I am a little bit surprised, that you didn't know that menu, since I already told you about it and you said, that you didn't want to use it.

Marvin

[SephirXV]

I am a little bit surprised, that you didn't know that menu, since I already told you about it and you said, that you didn't want to use it.

I never looked into it, I think when you say 'Menu' it totally through me off as to how it worked.