Forums » Community Projects
version 2.1.1
Fixed the long-standing issue with touch-to-target.
Fixed the long-standing issue with touch-to-target.
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.
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.
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.
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.
Version 2.1.2.1
Fixed an error when adding a new field region.
Fixed an error when adding a new field region.
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
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.
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.
I found a bug, I'll just copy this from another thread... Sir, VO has a new touchlook system for mobile which works similar with mobile FPS games and I have a bug to report. The thing is, the touchlook doesn't work properly when you remove the HUD using the DB. But the touchlook works when you dont remove the default HUD. Hope you can find a fix to this sir.
That's not a bug. That's, unfortunately, a side-effect of the default removal. I don't yet know how to recreate it, or I'd allow it.
I've almost got Touch Look Mode working satisfactorily. General response from testers has been positive. There is one last wrinkle that I'm working on ironing out at the moment. I hope to have it released within a week, with or without the wrinkle.
Version 2.2.0 has been released on VOUPR.
It is now possible to utilize Touch Look Mode.
Enable Touch Look Mode in VO options (Options > Advanced > Controls > Touch). After doing this, you will need to create a field that has "Turn" and/or "Pitch" as the axis commands. Touch Look Mode works beset with a large field size. As a reminder, there is a Visible toggle to hide the field.
Added a toggle for Lookspring in turrets.
Added a toggle for displaying Tracking Circles in fields.
Fixed a bug when deleting multiple buttons in ascending order.
It is now possible to utilize Touch Look Mode.
Enable Touch Look Mode in VO options (Options > Advanced > Controls > Touch). After doing this, you will need to create a field that has "Turn" and/or "Pitch" as the axis commands. Touch Look Mode works beset with a large field size. As a reminder, there is a Visible toggle to hide the field.
Added a toggle for Lookspring in turrets.
Added a toggle for displaying Tracking Circles in fields.
Fixed a bug when deleting multiple buttons in ascending order.
Version 2.3.0
Added inflight, configurable buttons. These buttons can have up to 5 options that can be remapped in flight.
When 2 or more options are configured, long-press the button to display the options, and slide over the new one you want to happen on a short press.
Added inflight, configurable buttons. These buttons can have up to 5 options that can be remapped in flight.
When 2 or more options are configured, long-press the button to display the options, and slide over the new one you want to happen on a short press.
Version 2.3.1
Fixed an issue with long-press buttons being released early.
Fixed an issue involving buttons not being cleaned up properly during docking and undocking.
Fixed an issue with long-press buttons being released early.
Fixed an issue involving buttons not being cleaned up properly during docking and undocking.
After building basic controls, Half the time it doesn't respond to input & when it does, many times it does something else than what it actually is supposed to do..... Example - you try to accelerate but it will turn your ship right.......
What type of controls were you creating? Buttons or fields?
If it was a field, did you apply the correct commands to the correct axis?
Also, Touch Look Mode will change the behavior of the Turn and Pitch commands if is turned on. If it's turned on, you generally need to make the field much larger than normal to get some reasonable movement out of it that's not too sensitive.
Please be more specific when submitting a bug report. Multiple people use these features already without issue. My own tests show no issues with general button usage (either buttons or field). So at the moment, based on your report, and with no further details to go on, I have to assume it's user error.
If it was a field, did you apply the correct commands to the correct axis?
Also, Touch Look Mode will change the behavior of the Turn and Pitch commands if is turned on. If it's turned on, you generally need to make the field much larger than normal to get some reasonable movement out of it that's not too sensitive.
Please be more specific when submitting a bug report. Multiple people use these features already without issue. My own tests show no issues with general button usage (either buttons or field). So at the moment, based on your report, and with no further details to go on, I have to assume it's user error.