Page 1 of 3

Macros/Modifiers special code

Posted: Wed Jan 09, 2013 12:57 am
by Zero
Hello Matlo,

First and foremost, happy new year! :)

Now for some background on why this thread was created.
Recently (with the new year holiday) I've had some additional free time and have started playing some BF3.
I've tried to play jets and have came up with an idea on how to add a particular "probably usefulness" feature to compensate for the way the mouse works.
So I use the mouse to steer the jet but in dogfights I have to switch to keyboard because I can't move the mouse in one direction for an extended period of time.
What I was thinking is a button that while hold would "lock" the value of a stick axis to the max value based on the last direction the mouse was moved.

So picture the scenario when you hold one of the mouse side buttons and slightly move the mouse like you would the stick in one particular direction.
The output would be the highest value for the axis based on the vector the mouse was moved towards, as long as you hold the side button.
You should be able to move the mouse around to change the vector but the vector would always result in the max values for the particular controller stick.
So you can't normally go to the (0,0) value unless you release the key and the input would then be processed normally.
That way you should be able to somewhat effectively dogfight and when you have your enemy in sight you can release the button and fine tune your aim, arguably more so then with the controller joysticks.

A small side note that could be taken into consideration is another feature that would be useful in fighting games. If macros could be processed for specific values based on a specific state.
Ex of a trivial "magic" combo in a fighting game where you need to do: Down + Backwords+ SomeOtherKey, Backwords would change based on the players position (left or right).
It would be nice if you could simplify that action with a macro like this: Forward (assumed direction towards the player) and the MACRO_KEY ex:

MACRO MACRO_KEY
KEYDOWN Down
KEYDOWN {{NotDirection}} // direction would be automatically replaced with the last Direction you've imputed, "NotDirection" would be the oposite direction making "Left" into "Right"
KEYDOWN SomeOtherKey
... ... ...

That would make it simple to execute "smart macros" that modify the output based on the state of the system.
In the scenario presented all I would have to do is push the direction toward the player (the system would store that as the last state) then execute the "smart macros".

--------------

Now for the technical part ... a few questions on how you see this being implemented and other similar questions.

1) mainloop.c, why are there 2 similar files with mostly the same code for linux and windows? I see you've started to refactor/change these quite recently ... wip?

2) can the macro_process() function be called last, or more precisely, after process_event(event) but probably before macro_lookup(event) that way implementing "smart" macros would be possible, it would execute on the most "up to date" state

3) the key that changes the behavior (for BF3 jet fights) can probably be considered a macro? .. but It would be useful if it was called based on a specific active profile (because I would like the side button to not do that if I'm playing infantry not jets). Or probably there should be a execute_modifiers(event) function after all other processes that executes specific behaviors and change the outcome of the system?

4) why is there a core2? Is that an attempt to re-write the core of the application, a major refactoring?

Thank you for your input.

Re: Macros/Modifiers special code

Posted: Wed Jan 09, 2013 8:45 am
by Matlo
Hi,

Happy new year!

I think a solution to your first issue (driving vehicles with the mouse) is issue 199.
It would be more precise as it allows to reach and keep each stick position (not only the max ones).
I was thinking about adding a "driving mode" check-box in the axis tab.

Your second issue (about macros and player direction in fighting games) can already be worked around using a different set of macros activated by the direction buttons. This is possible due to issue 192. There is an example there.

-----

Now for your technical questions:

1) Yes, most of the work I did lately is for the GIMX 1.0 version. The goal of this version is to give better performances on all Linux targets, specifically on small or old Linux targets. I ended up making different files for Windows and Linux for specific parts of the code. I could have kept the same file using ifdefs, but this would have made the code harder to understand.

2) macro_lookup() is now called inside process_event(). macro_process() is called at the beginning of each period (which is not necessarily at the beginning of the while), and it queues events for pending macros.

3) If you think issue 199 is a good solution for driving vehicles with the mouse, a specific profile will be enough.

4) I added a new directory because it took me some time to work on issue 197. I wasn't sure about how much time it would take. The goal was to have a copy of my work in the svn repo without disturbing people using the svn repo.

Re: Macros/Modifiers special code

Posted: Wed Jan 09, 2013 11:34 pm
by Zero
Wow that's quite interesting (199). Fascinating idea, that would really make it a lot easier in flying planes.
So basically you'd be emulating a joystick with the mouse.
The only downside I see to this is the fact that you can't effectively switch back to normal if its permanently the behavior of a specific profile (you'd probably need to switch profiles and that would complicate things quite a bit) ...

So the main mouse advantage over a joystick as in it dose not need to pass throw a "null" zone were input would be considered 0.
I can "instantly" input a opposite vector by moving the mouse in the opposite direction with ought going throw null. That and the fact that you control it with your entire hand makes the mouse superior in precision over joysticks.

It would be nice if the behavior described in 199 could be toggled, or activated on the same profile as long as a key is pressed. That way instantly one could release the button and adjust the vector absurdly fast.

I'll start looking into this next weekend see if I can code something up then I'll share the code here.

I do have one more question tho ... where do you create the definitions for C_TYPE_DEFAULT or C_TYPE_JOYSTICK or E_SHAPE_CIRCLE? Eclipse complains on the fact it can't find them

Re: Macros/Modifiers special code

Posted: Thu Jan 10, 2013 3:42 pm
by Matlo
I believe the Axis tab is too much complicated, adding more columns is not a good thing.
What about a "Mouse options" part between the "Profile trigger" and "Axis intensity" parts in the Overall tab of gimx-config?
It could consist in a table containing:
Mouse (name+id) / Init mode (aming or driving) / Alt mode trigger (name+id+button)
It could also include other mouse-specific stuff such as smoothing.

The definitions are in include/emuclient.h.

Re: Macros/Modifiers special code

Posted: Fri Jan 11, 2013 5:38 pm
by Matlo
FYI, I replaced the core directory with the core2 directory.

Re: Macros/Modifiers special code

Posted: Sun Jan 13, 2013 10:24 am
by Matlo
Hi,

FYI, I started writting GUI stuff for issue 199.

I decided to add a mouse_options_list element between the trigger and intensity_list elements:

Code: Select all

<mouse_options_list>
  <mouse_options>
    <mouse name="" id="0"/>
    <mode init="Aiming"/>
    <toggle type="" name="" id="" button_id=""/>
    <smoothing buffer_size="1" filter="0.00"/>
  </mouse_options>
</mouse_options_list>

Re: Macros/Modifiers special code

Posted: Thu Jan 17, 2013 8:11 pm
by Zero
Interesting, so its per config. That's cool. I'll have a look at the code. Sadly my plans got shot last week due to work, what I wanted is to figure out a pipeline for handling input that would be easily extended and maintain in the future.
As the code is now all handling of events is done in the config.c file (1068 lines of code :O). To me its extremely difficult to determine where to add some functionality as different as the 199 without branching the code off another if condition or so, making the code even more harder to maintain.
I imagine something like a list of input handlers that process the input and change the controller data. Stuff like motion or keys would be handled in one or more handlers and a global configuration service that provides information on how the handlers should work and holds the data for each controller.

for ex:

<Inpuit Event> -(foreach handler send input)-> [Macro Handler] ----> [Movement Handler] ----> [Key Handler] ----> [Other Handler1] ----> [Other Handler2] ----> ... ----> <controller data is sent>

Its a bit more costly performance wise but that way the extensible and maintainability is off the charts and you could apply all sort of composite effects like depending on the profile config some handler could be disabled.
Its just a thought ...

Re: Macros/Modifiers special code

Posted: Fri Jan 18, 2013 8:15 am
by Matlo
Mouse vectors are accumulated into a global (per mouse) vector by the cfg_process_motion_event() function.
Before the report is sent, cfg_process_motion() updates controller statuses according to these global vectors and the calibration values.
This last function could also check the mode (aiming/driving) and act accordingly.

Re: Macros/Modifiers special code

Posted: Sat Jan 19, 2013 7:39 pm
by Zero
I've been trying to setup eclipse so that it will register breakpoints to easily debug the application. Never in my life did I have to spend so much time trying to make the debugger work :shock:
In the end I think I will give up on trying to make the debugger work. On your station, presumably running linux, do you have any issues with running the application in debug mode?

Re: Macros/Modifiers special code

Posted: Mon Jan 21, 2013 10:18 am
by Matlo
Most of the time I'm using gdb from the command line, but I'm quite sure it can work from eclipse (I'll check tonight).

To keep debugging symbols in the binaries you have to change this in the Makedefs:

Code: Select all

CFLAGS=-Wall -O0 -g
LDFLAGS =