from what I understand is that the easyrpg player doesn’t support patches that have been applied onto the rm2k and rm2k3 games.
But what about the limitations of variables, pictures and keys?
For example, if I change the dialogs of the RPGMaker-Editor (not the RPG_RT.exe), so that I can use more than 5000 switches and variables or more than 20 pictures, the RPG_RT.exe will obviously not handle it by the standard.
How does the EasyRPG Player handle a rm2k or rm2k3 game thats using variable #7500 or picture #345 (above the standard but created without a patch)?
Another problem are the keyboard keys. The RPGMaker2003 only supports a few numbers, Return and Space (likewise) and returns a number from the function that listens for key presses. Would it cause much efford to make the EasyRPG Player also return other keys?
I am imagining this as followed.
I am using the RPGMaker to create a game that uses the command for listening to a key press. Supported are all numbers, Shift, Return and Space but the letter “K” is not supported for example.
The function is set so that it doesn’t wait for a keypress and it returns values for all supported keys.
Right after the check of keys, there is the evaluation of the returned value. Here I am checking if the returned value is something else, something that the RPGMaker command wouldnt normaly return but the EasyRPG Player does (“K”=50).
Here the EasyRPG Player could hopefully notice that the check of keys is being used and extend the supported keys with return values for all the unsupported keys.
That way the EasyRPG Player would extend the standard function of the rpgmaker for checking the keyboard keys.
We don’t have picture or variable limitations. Well we have, but they are very high ;).
Well in theory an extended KeyInput function shouldn’t break any games. We could just return the key scancode. Normal key input only returns values up to 29 (?). So that would be save. This would break compatibility with the Android port (needs more keys then), but that’s a different problem
Sweet.
Allright, i might as well just try to set higher picture numbers and see how the player will react.
The key return values would be a point for the wish list, right?
Basicly this is what the RPGMaker is supporting:
Rm2k:
Down (return value = 1)
Left (return value = 2)
Right (return value = 3)
Up (return value = 4)
Decision (return value = 5)
Cancel (return value = 6)
Rm2k3:
The same as the Rm2k but also
Shift Key (return value = 7)
Number Keys 0-9 (return values =10-19)
"+,-,*,/,. (return values =20,21,22,23,24)
For every unsupported key that is pressed the RPGMaker function would ignore it.
The Player however would return a value for every other key too, which can be checked by RPGMaker condition function. Maybe the return value for any unsupported key could be the scancode plus 1000 to avoid returning something that the rpgmaker game could misunderstand for another standard key
(RPGMaker “Return” = [color=#0000FF]5[/color] vs Ascii “Return” = [color=#FF0000]13[/color] vs RPGMaker “3” = [color=#0000FF]13[/color]).
Do we got a wishlist for the Player here in the forum somewhere or could you point me there?
I’m afraid I dont have the sufficient skills nor time to work myself into the code^^"
Actually some games search for key combinations like shift+9 so adding an extended support and storing these extended keycodes in variables will probably break some games.
I think one should be very careful with such additions because you’ll have to support them in the future. You’re basically defining a new public interface, and if in the future you decide to change this to something better, you’ll have to support both ways (‘this one’ and a ‘better one’) to return keys codes.
So I think that if this interface will be introduced, it should be turned explicitly, e.g. by something like this in RPG_RT.ini:
[EasyRPG]
FullKeyboard=1
Also, the way you suggest (just returning arbitrary keys) will probably be impossible to emulate in devices without keyboard, so I’m not sure if we need it at all?..
In general, I think the best solution would be to emulate an existing interface. There must be some patches to allow full keyboard input in RM2k[3], right? Maybe you can do what they’re doing?
You’re basically defining a new public interface, and if in the future you decide to change this to something better, you’ll have to support both ways (‘this one’ and a ‘better one’) to return keys codes.