Forums » Community Projects

DroidButtons plugin

Jan 16, 2021 draugath link
version 2.1.1
Fixed the long-standing issue with touch-to-target.
Mar 23, 2021 draugath link
draugath said:
This is the second time I've heard of problems with turrets and DroidButtons. The first time I wasn't given any specifics, and when I jumped into an NPC Constellation to test them, I didn't notice anything being wrong. Could you elaborate on what is wrong fields and turrets?

RRuslan1999 said:
draugath, When entering a turret, the DroidButtons' field aim is inverted. This problem was with me, as well as with many of my friends. I tried different versions but the problem was not solved. There is also a problem with distance control during strafe. I'm sure I set everything up correctly.


First, a little history. I've never played on a mobile device -- outside of what was necessary to ensure things weren't broken with DroidButtons. When I originally created DroidButtons, I was creating a tool that would provide much-needed control customization to mobile players. I didn't, and don't, know what combination of button/field parameters would work best, or might be necessary in specific circumstances.

Recently, and most notably, I've received some reports that Fields don't work well with turrets. This actually brings up a couple different points of note. First, everything is working as the game is designed to. The problem appears to be rooted the way the API defaults were established, and how certain command options behave seemingly opposite of expectation. There are also some other differences in the way the default UI behaves as default which isn't necessarily in opposition to how DroidButtons operates.

Aiming controls:
The API establishes non-inverted flight-aiming controls to be airplane controls. The default UI has inverted this so that swiping a direction aims in that direction. Interestingly, the +LookX/Y joystick commands also share the same behavior as the default UI, instead of using airplane controls. This is important, because +LookX/Y are the commands used on Fields when in a turret. Since there is no assumption of intent taking place, and the parameters are being used explicitly as set, we wind up with turret controls that are inverted from flight controls.

Another parameter that makes sense in turrets, but not for flight, is the "Mouselook X/Y" parameters. These make the controls more tolerable when in a turret, but make it basically impossible to fly otherwise.

Part of what needs to happen is a consistent level of control behavior needs to first be decided upon. It makes sense to me to mimic the default UI control behavior in this regard. This would marry flight and turret controls to behave identically.

Turret controls would need to be further automatically adjusted to apply "Mouselook X/Y" to provide sanity to the turret controls.

Would it be useful to have a separate turret inversion toggle for people who prefer one type of flight controls and the opposite for turret aiming?

Beyond these things, I'm not sure what else might need to be considered for change or evaluation. There might also be other bugs I'm yet unaware of.
Apr 11, 2021 draugath link
Version 2.1.2
Normalized field control directionality with the behavior in the default touch interface.
Added support for newer sensitivity options
Added visible toggle to buttons.
Added support for Accelerate (Touch). This supports backward movement when F/A is on.

This new version changes the data structure of the config a little. The first time you start up, it will adjust the saved data by adding new fields with default values or removing a now unused value if present. A backup will be created before the operation in case something goes wrong or you want to revert to the previous version.
Apr 11, 2021 draugath link
Fixed an error when adding a new field region.
Jun 22, 2021 Silverback Prime link
Hello everyone. I recently got droid buttons but in the midst of setting up, i left a blank button. Now i can't access db and an error about iua 200 comes up. Please help
Jun 24, 2021 draugath link
Without more detail, it's hard for me to make a definitive call on what the problem is. I did find a bug where if you create and save a button with a blank title and then try to create and save another button/field it may start generating errors.

The bug I discovered can be worked around by adding a title to the button you're working on and then using Close to bring up the "The current tab has unsaved changes." dialog box and then pressing Save from there. It should be possible to go through and either delete or rename offending buttons using this method.

Unfortunately, the only current way to do a hard reset on the plugin, if necessary, is to go to the <vo directory>/settings and into each character folder and delete each copy of system37643notes.txt

I will work on getting a fix to this, but at least it appears there may be a workaround in the interim.