Read evmapy files about evsieve HOT 4 OPEN

I've had a look at evmapy. As of evsieve 1.3.0, it does not seem possible to convert evmapy files to evsieve scripts due to evmapy having some features that evsieve doesn't, so this feature needs two parts:

• I'll need to extend --hook to be able to do everything evmapy does;
• Then either evsieve itself or a helper script needs to read evmapy files and convert it to evsieve arguments.

Unless there is a really good reason not to, the evmapy script runner should use the same features as the ones available through evsieve's standard CLI UI in order to minimize bloat and maintenance burden. That, by consequence, means that all features that are going to be added for the sake of evmapy compatibilty are subject to UI design scrutiny.

One option that particularly stands out is the "mode": "sequence" option that evmapy actions have, which triggers an action if it receives the a specific set of events in a specific order, and no other events in between them. (There is an example called "Send ALT+CTRL+DEL when you make a circular, clockwise motion with an analog stick" in their README.)

The "no other events in between the events of the sequence" part is a problem. Evsieve handles more events than evmapy does: for example, evmapy ignores events for movements in the absolute axes unless they reach their minimum or maximum value, whereas evsieve handles an event every time an axis moves, even if by a tiny amount. Evmapy also ignores all events not of type EV_ABS and EV_KEY, as well as all key repeat events. Finally, evsieve is designed to be able to handle multiple devices in the same script, whereas evmapy has a different script for each device (which may or may not be executed by the same daemon; the scripts just semantically do not interfere with each other.)

If a sequence can be broken up by any event, then in evsieve it becomes far easier to have a sequence broken because of some sporadic event that does not lie in the sequence. If it should only be broken up by "some" events, then it is nonobvious how to decide which events should break sequences and which shouldn't.

I could program a hypothetical --hook mode=sequence that has the same semantics that evmapy has, and then it would be possible to convert evmapy scripts to evsieve scripts by using --block to discard all undesirable events that evmapy does not consider to exist. The problem with this approach is that this --hook mode=sequence would then not interact nicely with the rest of evsieve; it would practically be only usable in scripts that were converted from evmapy scripts.

So first I am going to need to come up with a UI design for something that can emulate "mode": "sequence" from evmapy and also interacts nicely with the rest of evsieve.

On another note, I've tried googling for evmapy, but while I can confirm that it is being used by some emulators, I cannot find anyone posting their evmapy map files online for others to use. Maybe they are calling them something different, not mentioning "evmapy" in their post? Would you happen to have a link to where I can find these community evmapy scripts?

from evsieve.

Hi Karl,

First, thank you very much for your detailed answer.
evmapy files are used by various retrogaming distributions / firmwaren especially Batocera.linux.
Here is an archive for example of evmapy files used in batocera, as you will see it's pretty simple and no sequence seems used.

https://drive.google.com/file/d/1MCbu58lCYjwbIG8SC2vta-ARq3TViecN/view?usp=sharing

I think a parser converting evmapy json commands to evsieve arguments and exiting with failure code should be enough if encountering some unsupported features like sequence mode should be pretty enough for most use cases :)

Let me know your thoughts, and thank you again for taking the time investigating this possible enhancement.

Best Regards,

from evsieve.

It looks like those config files are not valid configuration files for evmapy, but for a patched version of evmapy maintained by batocera.

Some structural things I noticed about the above config files:

• For some reason, they all contain a list called actions_player1 while evmapy expects a list called actions. I am not sure what the reason and consequences of this are.
• Moreover, none of the scripts have a "buttons" or "axes" list, which the documentation of evmapy appears to require. Without a button table I can't really make sense of what the "hotkey" button is supposed to be. I wonder if the above config files are meant to get preprocessed by some other part of batocera to dynamically add the buttons and axes depending on which device the user is running batocera on?

About the content of the files:

• None of the scripts have sequence or hold parameters, which is good because those are the two evmapy features that were not implemented in the evsieve main branch yet.
• On the other hand, several of them do have a "mouse" type action which is not part of the standard evmapy config format and introduced by batocera in this patch.

The "mouse" type seems to convert a joystick to a mouse and applies some acceleration on top. It seems to be pretty important for batocera to function, so an batocera-evmapy interpreter isn't going to be useful until I implement that.

Unlike sequence triggers, it shouldn't be that hard to implement a --joystick-to-mouse argument that is both compatible with batocera-evmapy and interacts nicely with the rest of the evsieve system, but similar to issue #3, I am not yet sure if it is desirable to add a bunch of single-purpose arguments instead of a more general solution. For example, if I were to add something like a --modulate argument and allow more generic computations in the value part, the joystick-to-mouse mapping could be implemented as something like:

`# --modulate: reports the state of an absolute axis every _period_ seconds` \
--modulate abs:x abs:y period=0.006 \
--block abs:x:-5~5 abs:y:-5~5 \
`# x in the value position of the output event refers to the value of the input event` \
--map abs:x 'rel:x:x*(|x|+1/|x|)' \
--map abs:y 'rel:y:x*(|x|+1/|x|)'

That said, this generic solution is not trivial to implement and I do have a couple of higher priorities right now, so I can't say when or if this will be worked on.

from evsieve.

First of all thanks for the clarification @KarsMulder ans detailed analysis.
I totally understand you have much to do and I want to state how good this project is (and we'll maintained).

Let's keep in touch on the subject and let the issue open if you don't mind.

Maybe I could write a JSON reader and evsieve argument generator on my side as a starting point handling basic stuff.

Best Regards,
Romain

from evsieve.