Mala plug-in to select gamelist

[Neverending Project]

I see in the plug-in SDK that one of the messages that can be sent to Mala will have mala select the next or previous gamelist. Is there a message that can tell Mala to select a playlist (or emulator for that matter) by name (or id)?

If not, can I put this in as a feature request?

[loadman]

I see in the plug-in SDK that one of the messages that can be sent to Mala will have mala select the next or previous gamelist. Is there a message that can tell Mala to select a playlist (or emulator for that matter) by name (or id)?

If not, can I put this in as a feature request?

At the moment you can only select specific gamelists via the mouse or menu.

If you can tell me what application you have in mind, possibly I could help?

[Neverending Project]

I am brainstorming ideas to help incorporate either swappable or modular control panels. When someone plugs in a module or panel, a trigger would have Mala switch to the list of games playable for that module.

This could be accomplished a couple of ways. If there enough extra ports on the keyboard controller, you could wire it such that plugging in your module/panel would send the keystroke from the encoder. In this case, Mala would need to allow a key assigned to switch to a particular playlist. This way would be more suitable for swappable panels, where there may only be a few panels total.

A modular panel might need more than a few inputs, and using ports on the keyboard encoder may be impractical. For this I am envisioning a microcontroller in the CP wired up to the panels. Microcontrollers can be built with a few dollars worth of parts, and are relatively easily programmed. The microcontroller would look for changes to its inputs (when a module is plugged/unplugged) and send an appropriate signal to the serial port of the PC. On the PC side, a simple Mala plug-in could be written that would listen to the serial port, and send the appropriate message to tell Mala which list to switch to.

I know it all sounds rather complicated... I am just brainstorming. And with so many different types of modular CPs out there, it would be very difficult to create an all-encompassing solution. First I am thinking about how it would apply to my machine - then I can see where it would benefit others.

But on the Mala side of things, having the ability to switch to a specific playlist via keystroke would help modular owners a lot (automated or not). At the very least, they could plug in their panel and press a button on the panel to switch to the appropriate playlist.

Anyway, probably enough rambling for now... you did ask, didn't you? 

[TheShanMan]

Oooh. That might be something I'd like! I'd probably also want to be able to toggle between my panel-specific game list and my full game list with a button press. NP, I think your idea could lead to some interesting SDK possibilities. Add the ability to have a key press (or joystick or mouse movement) event and then add the ability to get and set various states of mala, like game list, emulator, and who knows what else.

[Bender]

isn't there something like that already in there for different sides of a cocktail cab?
maybe there would be a way to modify that so it will select different gamelists but not rotate the screen, and maybe  add the ability to do more than 4

anyway I agree this would be a fantastic feature

[loadman]

isn't there something like that already in there for different sides of a cocktail cab?
maybe there would be a way to modify that so it will select different gamelists but not rotate the screen, and maybe  add the ability to do more than 4

hmmm yes

I guess to start in MaLa I would have have the ability to assign a emu-list to a particular 'Switch number' (say 4 or 5 of them)
then,
*Any of those 'switch numbers' could then be called via the SDK
* Any of those swicth numbers could be allocated a keystroke

mmmm let me ponder

[loadman]

Is this the direction we want to go?

See attached pic

[TheShanMan]

Maybe it's because I'm just now having some caffeine for the morning, but I'm not quite understanding your proposal, loadman. Would you mind explaining it a bit?

[loadman]

Maybe it's because I'm just now having some caffeine for the morning, but I'm not quite understanding your proposal, loadman. Would you mind explaining it a bit?

I was kinda just expanding on my previous post.

It seems a big job to be able handle setting of a key to every Emu/ Gamelist .

So my current thinking is you could preset 4 or 5 Em/Lists in that tab (see pic in previous post).

Then you can call Hot list 1  or Hot list 2 form the Plug-in SDK and/or allocate a key/joystick to call Hot list 1-5 as well.

So in your cas I Panel would be Hotlist 1, another Panel is hot list 2 etc

[TheShanMan]

I understand now. Sounds good to me! Though for the plugin sdk might it make sense to have it a little more open ended - i.e. be able to invoke a hot list but also be able to set the game list directly? What I envision is a plugin might have a config dialog that lets you pick an emulator, then a game list, which would be applied whenever the plugin sees fit. So the plugin would need to be able to enumerate the emulators and game lists, as well as set the emulator and game list by name.

What do you think?

[loadman]

I understand now. Sounds good to me! Though for the plugin sdk might it make sense to have it a little more open ended - i.e. be able to invoke a hot list but also be able to set the game list directly? What I envision is a plugin might have a config dialog that lets you pick an emulator, then a game list, which would be applied whenever the plugin sees fit. So the plugin would need to be able to enumerate the emulators and game lists, as well as set the emulator and game list by name.

What do you think?

Sounds like lots more work (for me and the plug-in author) than the plug-in just calling a hotlist number. As it would need to allow for new emus and changes to the gamelists. 

I won't rule it out but I don't think that will be in the first incarnation. 

I mean the idea started for swapping control panels so mala would start on a appropriate game list. How many panels have you got?

[TheShanMan]

17 panels. Just kidding. I can live with that, though ultimately I'll surpass 5 panels (not currently). But you're right - a well written plugin would need to validate the configured game lists on startup. It really doesn't seem like much work to me though. I'm not sure if I'd use it at this point as I haven't thought all the way through it. But since you've made statements about the future of mala being much more plugin based than it is now, I was offering the idea up with that end in mind. The only way that can happen of course is for the SDK to be greatly expanded. But I'm sure that's not at the top of your agenda just yet - that's probably a 2.0 thing.

[loadman]

17 panels. Just kidding. I can live with that, though ultimately I'll surpass 5 panels (not currently). But you're right - a well written plugin would need to validate the configured game lists on startup. It really doesn't seem like much work to me though. I'm not sure if I'd use it at this point as I haven't thought all the way through it. But since you've made statements about the future of mala being much more plugin based than it is now, I was offering the idea up with that end in mind. The only way that can happen of course is for the SDK to be greatly expanded. But I'm sure that's not at the top of your agenda just yet - that's probably a 2.0 thing.

Well put   

I do want to make the SDk better.  My initial priority after getting my head around the code is bug fixes and small enhancements.

FYI As HeadKaze would know (my mentor) Plans for MaLa 2.0 are based on Direct 3D (to use 2D) and replace the Buggy Video Driver and use the latest version of bass.dll

[Neverending Project]

I'll add my .02, even though it pretty much echoes what shanman has said. It seems that if you are willing to (and able to) make the change, it should be done with future expansion in mind. My thought is that any playlist and any emulator should be assigned a hotkey. Whether they are assigned together or separate isn't of paramount importance... but if there are only 5 (or some finite number) of choices to be assigned, it seems that there will be users out of the gate that will be crippled. Make a way for any playlist to have a hotkey assigned to it and you are addressing any number of panel configurations. And on a side curiosity - could a playlist automatically select an emulator? It may not be necessary for separate playlist and emulator hotkey assignments if selecting a playlist automatically selects the emulator associated with that playlist.

But to answer your questions of how many panels, I will have 7 or 8 when I am done. But I have a unique circumstance... my CP is modular - so I will only be swapping a module at a time, not the whole panel. The idea with this feature update is to address whatever crazy panels people might come up with in the future, as well as today. If that takes a major 2.0 release, so be it.

And if it hasn't been said enough, a major thanks to you for keeping up the development on a great front end. It's not everywhere that you can have direct input on the features and functionality of a software package - it is very appreciated. 

[loadman]

Thanks I will ponder some more

It may well not end up being as much work as first thought.    We will see

[loadman]

I have pondered some...

MaLa needs to send the Emu and Gamelists to the plug-ins at start-up and when a list/emu is deleted or added.

What is the preferred method / format that the plug-in authors would receive a list of Emu's and lists?

also my thoughts on calling them I am thinking I assign a number to them and the plug-in just calls the number

[Neverending Project]

What is the preferred method / format that the plug-in authors would receive a list of Emu's and lists?

My preference would be to have the SDK give an enumerated list of the emulators and of the lists. Ideally, the list would have both a number (key) and the list/emu name (value). This would allow more options for the SDK that we may not be able to think of now... maybe built-in LCDs in the panels, LEDs, who knows?

[TheShanMan]

I know the SDK currently is event-centric, but I really think it would be better to allow the plugin to make a call to enumerate them (e.g. GetFirstEmulator/GetNextEmulator and GetFirstList/GetNextList). Probably not as trivial to do because IIRC there isn't any way to call into mala currently. But again, if 2.0 is going to move mala in a much more plugin-centric direction, then I think you'll need to start providing API's anyway.

However, I do think an event should fire when the emulator or game lists change.

[loadman]

My preference would be to have the SDK give an enumerated list of the emulators and of the lists. Ideally, the list would have both a number (key) and the list/emu name (value). This would allow more options for the SDK that we may not be able to think of now... maybe built-in LCDs in the panels, LEDs, who knows?

Would a comma (or other character) seperated list be OK? That way the list size could be infinate. 

MY current idea is mala is called with two numbers  emu,list

I know the SDK currently is event-centric, but I really think it would be better to allow the plugin to make a call to enumerate them (e.g. GetFirstEmulator/GetNextEmulator and GetFirstList/GetNextList).

Why do you need to do that if you gave been given the list on startup (and again if someting changes)?     

Probably not as trivial to do because IIRC there isn't any way to call into mala currently. But again, if 2.0 is going to move mala in a much more plugin-centric direction, then I think you'll need to start providing API's anyway.

Sure No call's can be made at the moment. But you can send commands allready. 

Have you have tried MaLamessages?   It is a EXE that is part of the Plug-in SDK. But you can put the message statements in a .dll/plugin.  Have a go. It is fun to remote control MaLa. 

[TheShanMan]

Why? Because with the future in mind I would imagine there will be more and more kinds of information that plugins will need to get from mala. If all of this information must be retrieved at startup and stored, it means longer startup time for mala and more memory usage. Maybe it wouldn't be huge, but it's just not optimal. Why take that approach when a plugin can just get it on an as-needed basis? SDK's just aren't done like that.

[loadman]

Why? Because with the future in mind I would imagine there will be more and more kinds of information that plugins will need to get from mala. If all of this information must be retrieved at startup and stored, it means longer startup time for mala and more memory usage. Maybe it wouldn't be huge, but it's just not optimal. Why take that approach when a plugin can just get it on an as-needed basis? SDK's just aren't done like that.

Fair enough. 

I will keep that in mind long term.

Just so you know where my head is at I am mindful that some cabs are on low end systems so I am not wanting to slow down mala's performance by having mala bombarded with calls from plug-ins (while it is scrolling through lists in particular). I kinda like the idea that MaLa is in control of when it sends messages. And the SDK using windows messages seems good becuase if mala is busy it will just igonore the message sent via windows rather than 'drop tools and listen' Once again I encorage you to have a play with MaLa messages and tell me what you think? 

[TheShanMan]

I think no matter what you do, you have to depend on plugins to be written well enough to not bog the system down. Any plugin that would require emulator and game lists whenever the selection changes certainly ought to store the data rather than asking for it every time.

MaLa will sometimes decide to ignore messages? That doesn't seem like a good idea to me. And besides, when you send a message in windows (SendMessage), it is synchronous, meaning mala would have to handle it right away. Now mala may choose to ignore it as you say, but it is still receiving and processing it.

I would like to play with the messages a bit when I have a chance. I'm overloaded as it is this week though.

Of course, you're the one doing the development so ultimately you have to choose what is best. I'm just trying to share what I've learned both as a producer of an SDK as well as a user of SDK's. And as a mala plugin author of course.

[loadman]

MaLa will sometimes decide to ignore messages? That doesn't seem like a good idea to me. And besides, when you send a message in windows (SendMessage), it is synchronous, meaning mala would have to handle it right away. Now mala may choose to ignore it as you say, but it is still receiving and processing it.

Let me rephrase. Ignore inappropriate messages like scrollup while a game is running. 

I would like to play with the messages a bit when I have a chance. I'm overloaded as it is this week though.

When you have time I would appreciate your thoughts 

Of course, you're the one doing the development so ultimately you have to choose what is best. I'm just trying to share what I've learned both as a producer of an SDK as well as a user of SDK's. And as a mala plugin author of course.

Cool   

[Paul Olson]

Not sure how I missed this discussion. I am very interested in this for my modular panel. I currently have 30 controller panels, and at least another 30 are planned, so a lot of configuration options would be cool for me.

I would like to help on this, but I will have to learn as I go. I will be taking my second c++ class this semester, and I have also changed my major to Computer Engineering. I am hoping that school will help me learn this, and also hoping that this will help me in school. As a side benefit, my cab might just work better. 

I have never used an SDK, so I will obviously not be able to do much yet, but if any of you can help me learn it, I would appreciate it.

I would also like to be able to reprogram the U-HID either in this plugin or a separate one.

ShanMan - Do you have any time to try to explain the basics to me?

Neverending Project - Do you have a link so I can see your modular panel? I'm interested to see if are projects are close enough so we can work together on figuring out what will work best for modular. We have a Modular/ Swappable group on coinopspace if you are interested: http://classicarcades.ning.com/group/modularcontrolpanel We could definitely use your input over there.

Loadman - Thank you for being so active in the new development of MALA. I am looking forward to seeing what you add to it. I am just starting my education so I don't know much yet, but let me know if you ever need help on anything.

Paul

[TheShanMan]

I'm still quite interested in this too, and I don't think it would be much effort. We just need to wait for some support from MaLa before we can proceed - I don't think there's much we can do with the current version. Paul, using an SDK is not that tough - especially MaLa's. Once you set up your project to make a DLL it's really quite simple. Do you use Visual C++? IIRC there is a sample plugin for MaLa that might be a good starting point for you - make sure you can build it into a DLL that works with MaLa. And once we have better support in MaLa for switching gamelists, we could work together if you'd like.

[Neverending Project]

The closest I have to a link for my modular CP would be here:
http://forum.arcadecontrols.com/index.php?topic=75625.0

It has been a long time since that post, but I have since built and expanded on my ideas a bit. I have three modular bays as shown in the post, and the modules can be slid into any of the bays. The modules make connections with CAT5 for lights/pushbuttons, and USB for those modules that need it. My CP is not finished yet, which is why I haven't updated the post. But now that it is very usable and I have several modules, it seems to be good enough for me for the time being. 

Here is how I would configure my modular CP, in my ideal world. Each of my modules (panels) has a number of pins which make connection to the I-PAC. I would borrow two of these pins, hook a resistor between them (different value for each panel) and reroute them to a microprocessor (Arduino). Stay with me here... The microprocessor can read the resistance value, and hence identify which panel is connected. It can also determine when a panel is inserted or removed.

OK, here is the part that has to do with Mala. Every time I remove or add a panel, the microprocessor would read which panels are currently installed and either send the information to a Mala plug-in, or write it to a file somewhere. My (magical) plug-in would take this information and select the Mala playlist according to what panel(s) are installed.

For example, my CP has three bays - room for three modules. One of my modules has a joystick and 6 buttons, another has a spinner and two buttons. When I insert the joystick module, Mala would be told that a player-1 joystick with 6 buttons is inserted, and load a gamelist that includes 4 and 8-way single joystick games with 6 buttons or less. When I insert the second joystick module (configured for player 2), Mala would then load a gamelist containing the above games, plus games where two players can play simultaneously, in addition to dual-joystick games. And inserting the spinner module would load games that can be played with a spinner.

Sound overly complicated? It is, I'm sure. But we're talking my ideal world here, right? Ultimately, I can see this that if Mala allowed direct selection of playlists, then a plug-in can be written to do some of the hard work of either dynamically building the playlist, or selecting the correct pre-built playlist given certain parameters.

Sorry if this sound too crazy or off-topic. I better go get my second cup of coffee now, and then re-read this for a sanity check.