I spent part of the playing around with Raven Shield and SWAT 4: TSS. Although to the best of my knowledge, Unreal Engine 2 did have support for joysticks, both these games shipped with that support half-assedly disabled 8=). In short, the games basically ignore all joystick input.
Never being one easily daunted, the three obvious solutions occurred: A/ configure the games for keyboard only operation and the joystick to emulate keyboard input; B/ use AHK; and C/ write a small toy to emulate a mouse by way of joystick input. I have already done A, and plan to test out B tomorrow (eh, today), if need be, perhaps play with C at some later date just for fun.
Under the Unreal Engine, or at least UE2: movement is a fairly simple thing. Basically you apply a positive or negative "Speed" factor to a given axis, resulting in some kind of movement: such as translating the players pawn(?) or moving the cursor. It's kind of simple, +/- base X and Y axises are more or less your walk. Where as the aBaseX and aBaseY axises correspond to the mouse. For SWAT, the task is basically as simple as binding a group of keys to apply +/- Speed to those axises. The bigger the speed, the more reaction you get per key press. In Raven Shield however, despite several methods tried, only positive and negative X (left/right) movement was fully working. Irregardless of change, only upward Y movement was possible in RvS \o/. After 6 years of it, I am often the first to call Raven Shield a pile of crap. Tuning my retired joystick to trigger those keys, is fairly simple: although the profiler lacks mapping JS to mouse aixses, sadly.
While it is possible to configure SWAT 4 for keyboard only operation, and thus JS based aiming; it creates somewhat of a problem. It's virtually impossible to both be able to turn/maneuver around obstacles and to aim and fire at targets. The reason for this is somewhat Unreals fault, that and the fact that "Keyboard acceleration" is not quite, eh, the same as mouse acceleration. In testing with my stick, I found values of +/- 3.75 to 4 tended to work good for aiming, where as +/- 5 to 8 work better for turning. Since a joystick should garner a form of movement more acline to that of mouse acceleration, rather than a keyboards uniformity, it causes a conflict of interest. Mouse acceleration works on the indea, of increasing the speed of mouse movement in proportion to the distance you move it, e.g. it gets faster as the further you move it; where as accelerated it always moves at a steady rate. Perhaps a good if incomplete explanation, for anyone whose played a Playstation with an analog controller: mouse = stick, keyboard = d-pad; thus mapping js to keyboard = d-pad != analog stick. Obviously to play an FPS with a joystick, you don't want it to behave like a sluggish 'd-pad'. One way to solve this, would be to dynamically modify the Speed= value used by the key, incrementing/decrementing it by some stepping per use; while not as elegant as it might sound to some, is also impossible. UE2s console and command system could only handle the ++ and -- operations by writing out the increment steppings using the pipe(|) operator, and following it up with an OnRelease operator to reset it back.
A better solution, obviously is just playing a ficken game with joystick support \^/.
As for the aforementioned method B, wouldn't you happen to know that it's already there. It would be the best solution, and AutoHotKey is a fine bit of software; one I've always wanted to find a good use for in games. Depending on how well it can be made to work at converting a JS into a mouse compatible HID, in particular with games in general, I might actually give up using the mouse for regular desktop usage. Thanks to my laptop and having encountered a fair bit of hardware in life's travels, I have no special attachment to PC mice: only hatred for ones without tails. Than again, I don't like wireless hardware for much, period.
The third method (C), well, is one that I would only consider worth the effort, because of the learning about Windows specifics that it would involve. I wouldn't be surprised if Microsoft had it as a sample app somewhere either. The libraries I rely on for input backends (e.g. in Stargella) have their own portable handling of joysticks as is, so I've no real reason to care lol.
No comments:
Post a Comment