Entraides et échanges autour de la technologie Scol - Informations and exchanges on the Scol technology
Vous pouvez changer la langue de l'interface une fois inscrit - You can change the language once registered
You are not logged in.
put the buttons with a margin, also it should not happen in fullscreen.
What do you mean by margin?
Offline
everything is working great arkeon!
i added some code to the client to make updatecursor() stop increasing fx and fy values if the cursor is no longer over the button. it does not appear to affect performance (unless i wire up the button to do text output, something i was using in figuring out how to detect the right and bottom distances of the button from x,y 0,0.)
i posted the code to ifam.net/mediaoctopus3d/restricted_feedback_button.zip feel free to alter, use, or disregard.
...tomorrow i will add an option to the editor to turn sensitivity to off button dragging on or off, a checkbox saying something like "disable off-button dragging".
i may also add a custom touchpoint image eventually, that would move to the edge of a button and no further, giving the user feedback that he/she is not changing output anymore. (a visual analogy to reaching the end of range of motion for a throttle or reaching the edge of a trackpad)
Offline
if you limit to the button size you will not always reach 1.0
did you try by just checking disable default inputs on navigation plugit ?
Offline
if you limit to the button size you will not always reach 1.0
did you try by just checking disable default inputs on navigation plugit ?
i would think you would reach 1.0 if you start swipe at bottom of button and go all the way to the top, or from one edge to another, no?
let (itof (sx - px)) /. (itof msize) -> fx inso if the difference between sx and px equals msize, you get 1.0
in any case, it's working and it's very intuitive for users unused to touchscreens or 3d interactivity in general, which is great.
Offline
Yes it should but this is not really a stick
I agree, perhaps using an offset method would work the best, where all push moves are calculated from a point in the button.
for example for a vertically shaped throttle (a rectangle that has a narrow width and a long height), you would determine fy by the difference between the present y position of the touchpoint and the horizontal center of the button when the conditions for the pushed move event are met. (when sx
so beginning your swipe in the middle of the button towards the top margin would equal 1.0, you would in effect have a slider moving up or down from the center of the button. if you start the swipe below the horizontal center of the button, and move your finger up, the fy values would only increase depending on the touchpoint's distance from the center of the button, not the bottom of the button, or anywhere below the horizontal middle of the button. you would only trigger the pushed move event however if your touchpoint is actually moving (to avoid setting the speed by accidently touching a point on the throttle, so you would still run the test
if ((ppx == sx) && (ppy == sy)) then nil elsethe downside of this is that you would be increasing speed or turning/rotating in half the distance than the way you set things up by setting the distance of the minimum button dimension as the denominator, so you need twice the space to give someone's finger the same range of movement.
thanksgiving (a u.s. holiday where americans eat alot of food) is coming up and i will test this with my family...
you have given scol coders the options to do whatever they want with buttons controlling movement values, which is great!
Offline