Changelog:

*** Vendetta 1.8.231.1
- Fixed Windows Updater problem.

*** Vendetta 1.8.231
- New visual effects for Mining Beams.
- Fixed Linux joystick calibration menu.
- Fixed rare "invincible" Hive Queens.
- Fixed common case where Linux crash-reporter would fail to appear.
- Orun Collectors in the training sector no longer leave.

Woot, new beams. :D

I like the tiny rocks that come off the roids now. Nice touch. :)

Sick new mining effects :)

The new mining effects are awesome. :)

Thanks Devs!

I mine a lot so thanks for the new mining effects. :)

> - Fixed Linux joystick calibration menu.

I still have a little problem with my "ACRUX USB GAMEPAD 8116" as reported by the game: whenever I move the analog stick for the X axis too far to the right it suddenly goes left. It seems to be a problem with linux itself as I can see the same Phenom in the tool jstest. Any idea?

Have you tried using jscal?

Thanks for fixing the Hive queens!

> Have you tried using jscal?
Yes but the problem persists. The tool can't even calibrate the joystick properly because the joystick or the driver is giving out fishy data (I believe it's the driver though as I have this joystick or rather game pad 4 times for some old school snes multiplayer sessions in an emulator). I start to realize that this forum might not be the right place to discus my problem. Thanks anyways.

That sounds like some kind of significant hardware or driver problem, beyond anything the game could do to provide a workaround.

Nice update, I do like the mining effects.

> That sounds like some kind of significant hardware or driver problem
I agree here with you, but the problem is the same on all 4 game pads I have here (they are of the same type, they were sold for 5 eur each so I couldn't resist ;D …). So it seems to be a generic problem with the design of the hardware or a bug in the driver.
As far as my knowledge goes any hardware is bugged like sh… and it's up to the driver to work around those issues.

> beyond anything the game could do to provide a workaround.
I disagree here. The most clean way to fix this issue is to fix the driver, apparently. Vendetta though already provides the option to limit the axis' range. The dialog is hidden behind the calibrate button for each axis.
I can't clearly see how the range limiter is supposed to work but could you fix/extend this little range limiter so the game ignores any value outside of the as white marked range? That would be real awesome.

EisenSheng,
Even if you set the in-game saturation lower on the faulty axis, it's still going to reverse and cause problems. There is nothing VO can do to work around a malfunction like that.

> There is nothing VO can do to work around a malfunction like that.
Don't make me to consult famy please.

the axis is not entirely wrong.

The axis' value is expressed in a number space between -32768 up to 32767 or to make it more clear from 0x800 to 0x7fff. When I move the knob from the center position to "pretty much right", jstest reports:
> Axes: 0: 32767 1: 0 2: 0 3: 0 4:-32767 5: 0 6: 0

This value is equal to 0x7fff and when I move the knob a little bit further until it hits the edge, it suddenly goes to
> Axes: 0:-32767 1: 0 2: 0 3: 0 4:-32767 5: 0 6: 0

which can be expressed as 0x8000 so my theory is that the driver or the device supports a higher precision than supported my the whole evdev stuff (this error pretty much smells like int -> short cast). The axis' error can be avoided by clamping the value instead of scaling.

In pseudo code:
if xaxis < user_defined_min_threshold then
ignore input
end if

Potential problem with that:

user_defined_min_threshold = -200
js_min = -300
xaxis -150.

User quickly moves device toward minimum.

Game sees -150, -165, -180, -195, -210, -225 ....

Currently, it does something like this:

if xaxis < user_defined_min_threshold then
xval = -1
else
xval = -1 * xaxis / user_defined_min_threshold
end

and xval ultimately == -1, which is what the user wants (maximum leftward rotation).

With your way, it will be stuck with the last valid value seen, -195, which would mean xval == -0.975, which is not what the user wants.

I'm perfectly okay with your version as an optional thing though, so long as it's disabled by default.

Oh, and don't bother arguing "It should detect when it makes a huge leap and ignore it then!", because that would break valid control mechanisms that can move instantly. I don't know if any actually exist, but they should be supported because there is no reason they couldn't or shouldn't exist. For example, if I had a touchscreen that registered as a joystick rather than as a pointing device, I could instantly switch from touching at the right to touching at the left (via use of multiple fingers). Even if something like that doesn't exist, it would be trivial to create one. Or for that matter, I could make a joystick with an "invert axis" button to let me instantly reverse my rotation.