Are they not available for pennies any more? "Compatible" Windows/PC things were going for next to nothing at one point and the script/3d in general does benefit from the kind of input those things can give vs hoping keyboard and mouse does what you want (though at the same time some of that does appear to be a concession to them not doing wonderfully for all aspects).
Most people were also all about having their joysticks appear as mouse and keyboard for things that did not support them but you can probably find something to go the other way and have a virtual joypad.
Anyway had a quick scan. If you are big enough and ugly enough to wind up on the issues page of a source repository then you can probably muddle through remapping/redoing for keyboard input for some of this.
https://wiki.desmume.org/index.php?title=DeSmuME_Manual_for_the_Windows_port
Has the DS specific stuff, most of it is based on the fceux take on the matter (as opposed to the TAS videos efforts)
https://fceux.com/web/help/Commands.html
http://www.lua.org/manual/5.4/
https://www.tutorialspoint.com/lua/index.htm if you wanted a more general intro to programming (not my favourite but it works for this, if you find another works better for you then by all means, sounds like you already have this as a project to deal with).
Most of the heart of the script you can probably leave alone and instead look at the inputs.
I am not sure how much detail to go into.
In schoolboy maths concerning 3d spaces you will probably have been introduced to the option to move things (translation), rotate things (rotation) and make things bigger or smaller (scaling). In not always in schoolboy maths you would then be introduced to matrices and vectors which work wonderfully for a lot of 3d things as well. This looks fairly independent of the control aspects you likely care about in this. Curiously rotation is limited to two axes (this script using the pitch, yaw and roll convention, or I guess pitch and yaw as there is no roll option) but I guess free look Dutch angle is probably just going to confuse things and there are not really enough analogue inputs to do it well so best to skip it.
There is a scan through all the IDs of controller and a check to see if it has the required axes (someone might be using a N64 controller, old school joystick or similar). Can probably lose this if you wanted.
Left and right bumper appear to be used to set a global scaling factor (think DPI switch on a gaming/graphics mouse) which you will probably want to keep in this if only because some games operate on some odd scales.
Dpad then gets used to set the independent movement and rotation scaling factors.
Code:
if(math.abs(key.x)>0.25) then --Left Stick
MoveRight(-key.x * movscale);
end
This might benefit from some unpacking.
if then end are part of the if loop in this language (sometimes also seen as IF ELSE in other things), that is to say IF this thing happens THEN do this other thing. Loops will be covered in any programming language course but they are usually joined by While loops (while this is the case then do this, usually ending when something trips a flag) and FOR loops which are a bit more advanced in their setup but allow you to do a more repetitive task on a whole series of data.
abs refers to absolute which as a crude explanation makes things positive. When a joystick is in the middle it is typically referred to as 0,0 and will have negative numbers in one direction and positive the other.
-- is Lua's way of comments in code it seems. Something there to help explain code and thus can be ignored for this.
> is greater than (is the left hand part greater than the right), which serves two purposes here.
https://www.tutorialspoint.com/lua/lua_operators.htm
1) As a crude dead zone -- analogue sticks wobble, send out noise and more besides. To that end most code using them will ignore things coming out unless it is beyond a certain threshold.
2) Accounts for human factor -- as a mighty gamer of many years I can send a stick down the exact path I want but not everybody can, this then means it only registers and activates when you go beyond a threshold and don't find your up on the stick movement slightly moving to the left as well unless you intentionally move the stick to a more diagonal position.
MoveRight is this script's confusingly named means of horizontal (think strafing) movement (recall the positive and negative thing from before). Anyway if the conditions above are met (i.e. the stick is moved a suitable amount) then it will take the negative* of the value the stick provides, multiply it by the movscale factor (dpad stuff) and pass that onto the MoveRight function.
You would then have to pick a number to substitute when it is pressed, or maybe even clone the function for a different key to have one move left and the other move right. Can also lose the dead zone check if it is going to keys, or better yet change that for the key press of your choice instead.
*this is also how you invert sticks if you wanted that (disgusting behaviour if you ask me but maybe you are into flight sims, exception for left-right which is a funny prank to pull on your friends), and also fiddling here is how you can swap what stick it looks for/passes data to if you wanted say forward/back and rotation on the one stick).
Similar things exist for the other aspects of the script, you getting to devise keys for them, assuming you want to keep them that is (you might not want the reset commands).
)
