Hey all. Sorry for the slow response. Reading over some of the comments, it is true that when a thumbstick collides with a "Touch X" actor, it starts to constrain to that corresponding actor's touch coordinates. And its true that the Touch X actors are not correctly resetting their positions via the touch coordinates.
I'll be fixing this soon. Or at least posting the solution here so you don't need to wait for the next build with the fix.
Thanks for taking a look at it - if it's not too much bother, can you post a bit of info about the solution when you have it? While I'm very happy to hear it getting fixed, I would like to learn from the solution too, as any attempts of my own to fix it have been fruitless
On a quick glance, it looks like the "Touch X" actors are not kicking in the ResetPosition rules.
If I put the 3 Change Attribute Behaviors (Change Attribute: game.Touches.Touch #.X, Change Attribute: game.Touches.Touch #.Y, and Change Attribute: self.ResetPosition) inside a Timer that runs every .01 seconds and runs to completion, that makes sure that the attributes are reset.
I'll keep checking but if that fix works perfectly for you all, let me know here.
Edit: It still needs more work. More info to come.
@codemonkey glad i could help debug the problem - hope it isn't a nightmare to solve!
@3xL even on single stick the problem still occurs, i think a lot of games have shipped with this bug :S It just depends on the game really how often it could occur (i.e. how many controllable objects are on screen, other buttons etc
The funny thing is that this bug has been there since the beginning lol but there wasn't too many dual stick GS games been made it seems
I had trouble with the dual stick controls (or a single controller with multi-touch) from the beginning, so I created an alternate way to do it... without the invisible sensor actors... this makes the controls more reliable.
Basically, I use rules and otherwise statements. If touch #1 is within the area of the controller... then do something... otherwise... is touch #2 within the area of the controller... nope? How about #3... #4 or #5? The rules start to look like the pyramids in Egypt, but there's less chance of jamming.
I used this style of control in BOT, and I think it worked out great!
I'm still not a very advanced user, and I've come to the forums with my (way back) original question because the joystick has overwhelmed me a bit. I might give your way a shot over the summer when I don't have school in my way.
I'm still not a very advanced user, and I've come to the forums with my (way back) original question because the joystick has overwhelmed me a bit. I might give your way a shot over the summer when I don't have school in my way.
Well, it is very easy. I'm a little bit surprised that GameSalad didn't switch to my method. Only one actor is needed.
The funny thing is that this bug has been there since the beginning lol but there wasn't too many dual stick GS games been made it seems
I had trouble with the dual stick controls (or a single controller with multi-touch) from the beginning, so I created an alternate way to do it... without the invisible sensor actors... this makes the controls more reliable.
Basically, I use rules and otherwise statements. If touch #1 is within the area of the controller... then do something... otherwise... is touch #2 within the area of the controller... nope? How about #3... #4 or #5? The rules start to look like the pyramids in Egypt, but there's less chance of jamming.
I used this style of control in BOT, and I think it worked out great!
Oh man I gotta try that. I've been taking a interest in your book. I haven't needed it cause I get great help here, but Im sure up your book has a more in depth look into the system. Honestly tho, I see my self buying your book in the future. I just don't NEED it right now. Judging from the screenshots, it seems extremely valuable.
Thanks for that - great to see different approaches and their use. I'm going to have a bash with it later, but in the meantime - how does this approach handle multiple touches being within the joystick area (which is what kills the other one)? Does it just use the most recent touch to enter the collision area, or only the first perhaps?
After reading through your breakdown of it, it does seem odd that the official template uses all the touch actors, when there is a simpler method that doesn't rely on actor collisions.
Hey all. The version I have didn't make it in the release put out yesterday. It needs more testing and when I thought I had it working, there were other issues that came up. As there is always more than one way to solve this issue, I encourage you to be creative and come up with other solutions.
When I originally created it, my thought process went this way: 1) Figure out which is the first touch on a thumbstick. 2) Constrain the thumbstick to that touch's coordinates. 3) Figure out when a specific touch is no longer active. The reason for the invisible touch actors are there is to know if a touch is inside the actor, and if not, reset that actor's coordinates via corresponding touch coordinates. 4) Try to keep it simple on the number of conditions per rule and have it relatively simple to follow.
And as was mentioned before, the touch coordinates weren't being reset.
My first attempt to force the reset came with an issue that if you start and hold a touch outside of the thumbstick base, the forced reset kicks in if the touch doesn't get moved after a certain time. That would be bad if you wanted to mix in a drag and drop system in addition to the thumbstick controls, so I didn't want to let that go out without a solution for that too. Then I got stuck trying to figure out how to fix that.
If Photics' solution works for you, great! I will continue to work on getting this fixed when I can.
@CodeMonkey I know that this is a veeeery old topic, but it appears that the tamplate has't been fixed so far. People are still using it (including me), and we are getting feedback from our customers about occasional stuck of thumbstick... it also affected few reviews
Comments
I'll try to do some debugging within the next couple of weeks but an expert would be awesome.
Regards,
Jack McGraw
I'll be fixing this soon. Or at least posting the solution here so you don't need to wait for the next build with the fix.
Yes that is correct. Thanks for looking into this!
Jack McGraw
Thanks for taking a look at it - if it's not too much bother, can you post a bit of info about the solution when you have it? While I'm very happy to hear it getting fixed, I would like to learn from the solution too, as any attempts of my own to fix it have been fruitless
Cheers!
If I put the 3 Change Attribute Behaviors (Change Attribute: game.Touches.Touch #.X, Change Attribute: game.Touches.Touch #.Y, and Change Attribute: self.ResetPosition) inside a Timer that runs every .01 seconds and runs to completion, that makes sure that the attributes are reset.
I'll keep checking but if that fix works perfectly for you all, let me know here.
Edit: It still needs more work. More info to come.
I cannot thank you enough for this. The joystick glitch is the only bug in my game!
@3xL even on single stick the problem still occurs, i think a lot of games have shipped with this bug :S It just depends on the game really how often it could occur (i.e. how many controllable objects are on screen, other buttons etc
Cheers, thanks for taking a look at it
It's posted in The Unofficial GameSalad Textbook.
Basically, I use rules and otherwise statements. If touch #1 is within the area of the controller... then do something... otherwise... is touch #2 within the area of the controller... nope? How about #3... #4 or #5? The rules start to look like the pyramids in Egypt, but there's less chance of jamming.
I used this style of control in BOT, and I think it worked out great!
The textbook looks great, but I don't want to pay $25 to fix a bug that is in a basic GS template. I appreciate the heads up though.
@CodeMonkey
As @allornothing said, any progress here? It seems you lost interest in trying to fix it...
I'm still not a very advanced user, and I've come to the forums with my (way back) original question because the joystick has overwhelmed me a bit. I might give your way a shot over the summer when I don't have school in my way.
Thanks for the help!
Jack McGraw
Perhaps I should post a template on my site.
That would be fantastic!
http://photics.com/gamesalad-template-dual-controllers
Thanks for that - great to see different approaches and their use. I'm going to have a bash with it later, but in the meantime - how does this approach handle multiple touches being within the joystick area (which is what kills the other one)? Does it just use the most recent touch to enter the collision area, or only the first perhaps?
After reading through your breakdown of it, it does seem odd that the official template uses all the touch actors, when there is a simpler method that doesn't rely on actor collisions.
When I originally created it, my thought process went this way:
1) Figure out which is the first touch on a thumbstick.
2) Constrain the thumbstick to that touch's coordinates.
3) Figure out when a specific touch is no longer active. The reason for the invisible touch actors are there is to know if a touch is inside the actor, and if not, reset that actor's coordinates via corresponding touch coordinates.
4) Try to keep it simple on the number of conditions per rule and have it relatively simple to follow.
And as was mentioned before, the touch coordinates weren't being reset.
My first attempt to force the reset came with an issue that if you start and hold a touch outside of the thumbstick base, the forced reset kicks in if the touch doesn't get moved after a certain time. That would be bad if you wanted to mix in a drag and drop system in addition to the thumbstick controls, so I didn't want to let that go out without a solution for that too. Then I got stuck trying to figure out how to fix that.
If Photics' solution works for you, great! I will continue to work on getting this fixed when I can.
@CodeMonkey
Did we ever get a resolution to this problem?