More controls.dat posting....

[Howard_Casto]

The other thread was gettin a little beefy again so I decided to start a new thread.

Ok as promised I am posting a rather short list of the games I have so far.....

http://www.oscarcontrols.com/lazarus/files/filledcontrols.dat

The klov parser was a success but not a total one.  Although it filled in the games it had with joysticks and standard controls, the others didn't always turn out so good.  So I am manually checking the dat it made one game at a time.  Not very thoroughly, but just enough to make sure the syntax is right and that the parser formatted things correctly.  These are the ones that I have so far....  

Within a week or so I should have all of the joystick games the parser could find in this dat.  That should be at least 500-700 games that are very accurate.  After that I will publically post the left overs so you guys can help me.  If the klov parser could find a game then it put all of the data in the game's entry, but if it wasn't a simple joystick setup then it got confused and outputted it in the wrong fields. So we will have a lot of games like that, in which I have extracted all of the data we need, but the actual entry needs to be worked on.  I will also post those and hopefully you guys can pitch in so the work will get done faster.  There are also several games that the klov parser couldn't find but are on the klov site.  This is because klov doesn't use the same names for games that mame does and the parser got confused.  These games will have to be done manually.  

So long story short... At the end of about two weeks we will have three dat files circulating around.....  One will be farily accurate but could be in need of a look over and contain most of mame's games.  Aonther will contain data that needs to be formatted properly. This one will need more work but will still take shape farily quickly.  The third dat will be a skeleton dat containing all of the games that the parser missed.  

After all of this is done we will have to discuss the naming conventions of the "controltype" entry I discussed.  It will very much be a new standardization so it will require a lot of thought. Once it's decided upon I can write some code to replace the klov style syntax with whatever we decide upon.  It will still need a once-over though.  

I am being optimistic here, but if eveyone pitches in with the work I would guesstimate that we would have a 99% complete, 90% accurate controls.dat after only a couple months!  This is really shaping up guys I'm glad so many people are on board.    

Oh and konobunk... I know you have a lot of entries already... if you have  a list of the ones you have completed with button labels and all, I will filter those off so that we don't redo work.

 

[SirPoonga]

That;s cool.  Want to add in the other player control, for player2, player3, and player4?

You may not use it, you have your idea of an algoritm, But I have other ideas on how this could be used too and that will make like easier.  The values can be left blank, that works you great


Plus the controls probably should be something like JOY8WAY.  Short, consise.  I know you are grabbing directly from klov.  Though when you are finished it'd be easy to make a perl script to go through and rename everything.    As you said, wait until done.  A perl script and regex can fix any problem:)



BTW, just skimming through, I am going to have to play this game, to understand the controls!!
[armora]
Description=Armor Attack
numPlayers=2
alternating=No
P1ControlType=Buttons: Rotational (left, right)
P2ControlType=Buttons: Rotational (left, right)
P1_JOYSTICK_UP=Up
P1_JOYSTICK_DOWN=Down
P1_JOYSTICK_LEFT=Left
P1_JOYSTICK_RIGHT=Right
P1_BUTTON1=Forward
P1_BUTTON2=Fire
MiscDetails=
[end]



Oh, 49way joys, hmmm, how should that be handles, also hall effect?  JOY49WAY, JOYHALL?  The FE would have to know what to do with those?

[Howard_Casto]

Yeah I agree on the klov entries... they sorta suck...  The reason I left them in is because they are more descriptive on the special case games.  Battle shark, for example is labeled as a periscope instead of a analog stick.

As for player 2 3 and 4 I don't think it's necessary to add them in.   I was thinking that whenever a game had different control layouts for each player we could tack on a /NS (non standard) at the end of the contol type for all players that have diferent controls.  Then we put in the p2 p3 and p4 inputs.  This just makes the file a little smaller and the parsing a little faster.

Klov did give ma an idea of how to do things though....  Have you noticed where they put Joystick:  8 way instead of 8-way joystick?  That actually makes sense for non-standard controllers.  

Like For dot the entry would be something like.

Trigger Stick: joystick +1button/Clickable Spinner: dial + 2button

This give a very accurate descripton of the real type of controller used and would make things easier when it comes time to make a graphical representation..... Example:  You make a trigger stick graphic and give it the controller type of Trigger Stick....  When it gets to an entry that contains trigger stick in the control type it not only knows to use this graphic but reads all of the inputs that make up this graphic.  So it knows that a trigger stick will have p1up/down/left/right and a button input associtated with it.  But that's all up in the air right now... just thought I would share a possible route.

Oh and yeah... that game is an example of one where klov contradicts mame.  Mame says it uses a 4way joystick which driver wise i'm sure it does, but klov says that it actually used  left/right buttons, similar to asteroids.  Games like that will have to be looked over.  I left both parts of the entry in because I wasn't sure how to do it.  It looks like mame assigns the keys to the joystick, so we would probably want to use those input names, but it also looks like that the actual game used buttons.  So a big ?!?!?!?!? from me.
   

[SirPoonga]

As for player 2 3 and 4 I don't think it's necessary to add them in.   I was thinking that whenever a game had different control layouts for each player we could tack on a /NS (non standard) at the end of the contol type for all players that have diferent controls.  Then we put in the p2 p3 and p4 inputs.  This just makes the file a little smaller and the parsing a little faster.  

Yeah, well, it does hurt.  Imean, if the P2, P3, P4 isn't defined then use your style of algoritm.  I just see problems in the future not allowing that.  

Plus, for making an easy to use API it will make life much easier.

[Howard_Casto]

??

But you do allow them with that method... If you want to put them all in you just go

p1contoltype=joystick /NS
p2controltype= joystick /NS
p3controltype= joystick/NS

p1-button1=
p2-button1=

ect...

sorry not correct syntax but you get the idea.  

Maybe I don't understand what you are getting at, but what is the point of duplicating the entries for player 1 and 2 when they have mirrored layouts?  And since you are still allowed to put in player 2's inputs seperately then how would that be restrictive? I need some more explaination and an example so I know what you are getting at.  

[SirPoonga]

everyone else reading this, I exmplained to HC what I meant in chat.

Pretty much an oversystem.

Like
[mygame1]
PLAYERS=2
P1_BUTTON1=Fire
[end]


[mygame2]
PLAYERS=2
P1_BUTTON=Fire
P2_BUTTON=
[end]

[mygame3]
PLAYERS=2
P1_BUTTON=Fire
P2_BUTTON=Bomb
[end]

IF player2 controls are defined, use those, otherwise use player1 defs.  So, in the first 2, P2_BUTTON is either not there or left blank, therefore the label to be used will end up being player1's.  In the third since player2 is defined you will just use that.


BTW, I'm making an activex dll that does all the dirty work of loading, parsing, and using this data.  It would be easy to transfer to a java class also for you java devs.  There will essentialy be a controls object.  that object will contain a load function, which will load a file into the object (alot like how XML 4.0 dll works).  Then all the info you need, and utility functions will be in the object.

[SirPoonga]

I was thinking about what controls exist out there.

What other weird things are out ther.  The dat file will have to handle
Joysticks (2,4,8,analog,hall effect, rotory??, joysticks with buttons))
mahjong conrols
steering wheels (270, 360, optical, analog)

Anything else?


BTW, what do you think about this idea for the dat file.  I see issues with the fact that  dial is generic in mame.  And I plan on having multiple panels.  So dial will be a spinner, steering wheels, replacement for paddle games.

[mygame]
P1_CONTROLS=DIAL
P1_CTRL_LABEL=360OptoWheel
[/end]

The labels would have ot be standardized for ease in FEs.

[Howard_Casto]

Klov has two designations of steering wheels
(optical, analog), analog pdeals, digital and analog shifters.. (two way all the way all the way up to 6 shift positions)  two types of rotary joysticks (optical, digital)  spinners paddles, positional guns and light guns, yokes, trigger sticks, precise spinners (for 720 and other 1=1 games) , clickable spinners, trackballs, analog sticks, pressure sensitive buttons and 2/4/8 way joysticks.    and misc analog/optical controllers, which are given first a name based on what they are molded to resemble, and then designated by the type of electronics inside ...
(for battle shark they call it periscope/positional gun as it looks like a periscope but is actually a glorified analog gun)  

And these are just the one's I can remember.  Btw klov doesn't bother with mahjong games I think and I honestly don't know if we should either.  .... I don't know of anyone actually going to the trouble of building a mahjong panel, so I assume those that play them use a keyboard since the buttons are a-m.  Perhaps for those games we could show the function keys (pon, reach, ect)  mappings and leave the rest up to chance.  

I think that if we had a controller name/type for each of those listed above that we would have one heck of a start.  There are some odd variations though...  For example, the positional gun can have up to three buttons, so there are actually 3 positional guns out there.  The analog stick can also have up to three buttons.  I believe all of the yokes have 2 but somone might want to check on that.  Shifters are in the low/high toggle variety and in several other multiple gear configurations.  Not all games with wheels have pedals and not all that do have two.  Afterburner and Afterburner 2 both have throttles with an "afterburner" button (obviously). The sensitive buttons come in a 2 way and 3 way variety.  Hang on has a motorcycle yoke which is slightly different than a tradtional one.  Some of the football games have a kicker controller which is spring loaded and thus the y axis acts funny.  And then there is qbert, which shoudl definately have a notation that the joystick is at a diagonal.  There are also a very few spinner/trackballs, which look like a trackball but are actually only 1 axis like a spinner.  And this isn't even a list of the "odd" ones.  

Whew ok time to rest.
 

[SirPoonga]

I think that if we had a controller name/type for each of those listed above that we would have one heck of a start.  There are some odd variations though...  For example, the positional gun can have up to three buttons, so there are actually 3 positional guns out there.  The analog stick can also have up to three buttons.  I believe all of the yokes have 2 but somone might want to check on that.  Shifters are in the low/high toggle variety and in several other multiple gear configurations.  Not all games with wheels have pedals and not all that do have two.  Afterburner and Afterburner 2 both have throttles with an "afterburner" button (obviously). The sensitive buttons come in a 2 way and 3 way variety.  Hang on has a motorcycle yoke which is slightly different than a tradtional one.  Some of the football games have a kicker controller which is spring loaded and thus the y axis acts funny.  And then there is qbert, which shoudl definately have a notation that the joystick is at a diagonal.  There are also a very few spinner/trackballs, which look like a trackball but are actually only 1 axis like a spinner.  And this isn't even a list of the "odd" ones.  

Right, there are weird controllers out there, like enduro bike and paperboy:)
Should those be represented in te dat, like that format I posted?  It wouldn;t be hard for FEdevs if the list of labels is standardized.  It;s jsut a lookup table.  The end user would also have to define default controls.  Like all DIAL and PADDLE games in mame are handled by the spinner.  That's the default value if nothing else applies.  So, IF the person put steering wheel, in the FE that will be registered somehow to use the standardized label (ex DWHEEL or OWHEEL), but for someone who doesn't have awheel it will use the defult spinner.  Just an example of what I mean.  It would allow for more accureate representation of te person;s actualy CP in the FE.

[Howard_Casto]

I think that we should have a standardized descriptive name, followed by the axis/inputs it has

so for an afterburner controller it would be
p1controltype=Flight Stick/axis:2/buttons:2 + Throttle/axis:1/buttons:1

This way we know that the throttle had one button on it and the flight stick had 2.  And below we would have the acutal mame inputs grouped via the ctrlr file naming conventions.

I think this is necessary because another important role of this project is to preserve the original cp layouts of these games.  Although no one in their right mind would build all of these odd ball controllers, it's nice to at least get an idea of what they were and how they were used.  


So long story short, I think at the least all of the speical controllers need to have unique names... eg don't call a steering wheel a dial.

[SirPoonga]

I think that we should have a standardized descriptive name, followed by the axis/inputs it has

so for an afterburner controller it would be
p1controltype=Flight Stick/axis:2/buttons:2 + Throttle/axis:1/buttons:1

That's a what I am getting at, but you still need the mame control label too.  Like 360WHEEL is DIAL in mame.
Though a lookup table portion of the dat could take care of that.

[SirPoonga]

Hey, how do we handle robotrom, wher ethe entire joystick is labels move and fire.  Not just directions.

[Chris]

There's also the strange Wizard of Wor stick that had the half move/full move thing... and the Space Wars keypad... I didn't see anyone mention yokes yet, either...

[SirPoonga]

There's also the strange Wizard of Wor stick that had the half move/full move thing... and the Space Wars keypad... I didn't see anyone mention yokes yet, either...

In mame yoke is labeled as a STICK.

[u_rebelscum]

... and the Space Wars keypad...

Um, is the project going to try to presever the orginal button arrangement?  If not, the Space Wars keypad is just 9 buttons, no?

On the other hand, a bunch of the modern (unemulated) arcade games out there now also have a keypad for on-line saving and stuff (SF Rush, for example).  Maybe one of the weird devices could be like: p1controltype=keypad/buttons:9

[Minwah]

Hey, how do we handle robotrom, wher ethe entire joystick is labels move and fire.  Not just directions.

Like this I think:

p1controltype=Joystick: 8-Way + Joystick: 8-Way
P1_JOYSTICKLEFT_UP=Move Up
P1_JOYSTICKLEFT_DOWN=Move Down
P1_JOYSTICKLEFT_LEFT=Move Left
P1_JOYSTICKLEFT_RIGHT=Move Right
P1_JOYSTICKRIGHT_UP=Fire Up
P1_JOYSTICKRIGHT_DOWN=Fire Down
P1_JOYSTICKRIGHT_LEFT=Fire Left
P1_JOYSTICKRIGHT_RIGHT=Fire Right

[Howard_Casto]

Yeah I'm aware of these keypads and such, that was the "all kinds of other odd-ball stuff" I referred to. When we run across it, we'll add it...  btw minwah is right about the 2 8way stuff.  Same goes for crazy climber, smash tv, ect. I think the best thing to do is make it up as needed, BUT we need to post a list of all the control types we make so that we can keep it as standardized as possible.    

[SirPoonga]

Hey, how do we handle robotrom, wher ethe entire joystick is labels move and fire.  Not just directions.

Like this I think:

p1controltype=Joystick: 8-Way + Joystick: 8-Way
P1_JOYSTICKLEFT_UP=Move Up
P1_JOYSTICKLEFT_DOWN=Move Down
P1_JOYSTICKLEFT_LEFT=Move Left
P1_JOYSTICKLEFT_RIGHT=Move Right
P1_JOYSTICKRIGHT_UP=Fire Up
P1_JOYSTICKRIGHT_DOWN=Fire Down
P1_JOYSTICKRIGHT_LEFT=Fire Left
P1_JOYSTICKRIGHT_RIGHT=Fire Right

That's the opposite of what I just said.
Not JUST the directions, the whole joystick has just ONE label.

[Minwah]

I'm not sure what you mean exactly, could you explain a bit more ?

[Howard_Casto]

Hey, how do we handle robotrom, wher ethe entire joystick is labels move and fire.  Not just directions.

Like this I think:

p1controltype=Joystick: 8-Way + Joystick: 8-Way
P1_JOYSTICKLEFT_UP=Move Up
P1_JOYSTICKLEFT_DOWN=Move Down
P1_JOYSTICKLEFT_LEFT=Move Left
P1_JOYSTICKLEFT_RIGHT=Move Right
P1_JOYSTICKRIGHT_UP=Fire Up
P1_JOYSTICKRIGHT_DOWN=Fire Down
P1_JOYSTICKRIGHT_LEFT=Fire Left
P1_JOYSTICKRIGHT_RIGHT=Fire Right

That's the opposite of what I just said.
Not JUST the directions, the whole joystick has just ONE label.

Sirp if you are getting at what I think then you are looking at it wrong...  Although minwah's syntax isn't quite what I would like he has the right idea....  

Drescripton of controls, followed by mame counterparts......  

so technically it would be.....   p1controltype=Joystick/joy8way+Firing Joystick/joy8way

In other words a control with a real life name of joystick that contains the control inputs of a joy8way and another joystick that is the firing joystick used for firing that also uses the input of a joy8way.  

For the record that has nothing to do with the labels on the controls.... you can still designate a label for each direction and call it whatever you want...

[SirPoonga]

For the record that has nothing to do with the labels on the controls.... you can still designate a label for each direction and call it whatever you want...

True, that what I meant though.  I wouldn't want to see in the FE Fire for each direction of the second joy, just one label underneith like the real cp.  SO, how would that be supported?

[Howard_Casto]

make the label = "  "

we won't trim the value that way the label would show up but it would be invsible... or we could check for a value of "null" which woudl tell us to display the control but leave the label blank.  

Also if we made skin files to go along with the special games we could get the cpo graphics, which would already have the labels on them.  

[Minwah]

True, that what I meant though.  I wouldn't want to see in the FE Fire for each direction of the second joy, just one label underneith like the real cp.  SO, how would that be supported?

Ahh, I see what you mean now.  I think Howard's answered your question

Howard:  Would it not then be better for that game to label the control:

p1controltype=Movement Joystick/joy8way+Firing Joystick/joy8way

To my mind if you state what 1 joystick does then you should the other.  Having said that, I suppose it's fairly safe to assume that just 'Joystick' means movement, since that's what it does in most games.  Just a thought...

[SirPoonga]

p1controltype=Movement Joystick/joy8way+Firing Joystick/joy8way

To my mind if you state what 1 joystick does then you should the other.  Having said that, I suppose it's fairly safe to assume that just 'Joystick' means movement, since that's what it does in most games.  Just a thought...

Should that be labeled control description??  When trying to map that to actual control on a real CP that's going to be some fanct parsing.

[Howard_Casto]

Actualy no it's not... split by additon signs, that gives you the number of controls... then split by "/" that gives you the description followed by the actual input for each said control.  We could add more fields but I just wanted to keep it sorta trim.... really doesn't matter to me as we can re-arrange things once we get everything standardized.