@Lost_Oasis_Games Do you have an idea when CodeWizard or GS will have an update? Or is their a way I can use like the a night build to continue working on my game? Its just so un responsive that its killing me to work on my app. Thanks again for all your knowledge and help
@Socks said:
1.25.54 + COM + constrain gives fairly unpredictable results, no bug report as yet (more investigation needed to usefully describe the issue) but for example constraining an actor's rotation to an increasing value - while that actor has a shifted COM - sees it fail to honour the set COM.
Are you adjusting the com during rotation?
No, I'm simply making a one-off change to the COM and then hitting play.
I've made a quick project that highlights the constrain + COM issue, check it out if you get a minute (file attached).
. . . . . . . .
There is a yellow actor (100 x 400pixels), the image applied to this actor has a red dot that marks the bottom/centre of the actor.
I have moved this actor's COM to x=0, y-200 (the bottom/centre of the actor).
I have also placed a small blue actor behind the yellow actor, this small blue actor marks the COM the yellow actor should rotate around.
The yellow actor has a Rotate behaviour applied to it.
. . . . . . . .
Hit preview, the yellow actor behaves correctly, pivoting around the COM. Click and hold anywhere on the screen to zoom in, you can see the red dot at the bottom/centre of the yellow actor accurately sticks to the blue pivot point.
Now open up the yellow actor, turn the Rotate behaviour off, and switch on the constrain behaviour directly underneath it. Hit preview, and zoom in, you can see the red dot on the yellow actor no longer sticks to the blue pivot point.
You can correct the issue with a workaround, in the scene move the yellow actor 5 pixels left (so x=507) and then move its COM 5 pixels to the right (so change COM to x=5, y-200), the red dot at the bottom/centre of the yellow actor will now stick to the blue pivot point
The problem with this work around is that the issue is speed related, make the speed of the rotation faster and the offset will be bigger, the relationship is 'roughly' [speed (degrees/sec) / 18 = offset in pixels].
. . . . . . . .
Put the yellow actor's position and COM back to where it was (or just revert to saved) - open the yellow actor and switch on the third constrain behaviour (and obviously switch the other behaviours off) and now preview.
Press anywhere on the screen to zoom in.
With this oscillating / swinging movement you can see the issue can't always be resolved with a simple offset as the COM is now changing over time.
Unfortunately for me this last example is exactly what I intended to use the COM function for, at the moment the desired movement is being achieved with three constrains (X,Y and R) and some trigonometry, the idea was to replace three constrains with a single constrain rotation behaviour as I've got lots of these oscillating / swinging actors in my scene (a scene with 20 actors would jump from 60 constrains to 20, a really worthwhile optimization!)
But this issue means I'll have to stick with all the old pre-COM method for the time being.
I've installed the latest version on my iPad (Air2), and whereas in the past there were very few issues, if any at all, I'm having all sorts of strangeness with this new version.
For example, when a landscape project is passed over to the iPad it is displayed as portrait, even though the iPad was orientated correctly as landscape . . .
. . . I then rotate the iPad to get the GS project to rotate to correct orientation, that works fine, but if you then try and lock the iPad's orientation (swipe the iPad's control centre up and hit the lock rotation button) the GS project on screen gets squeezed vertically ! (I think by 50%) ?
The same is true of opening a project already on the iOS viewer, they open as portrait, with a bit of fiddling around and spinning of the iPad they can be made landscape, but the ability to lock the orientation (so it doesn't keep going back into portrait) is essentially now gone, as doing so squashes the project vertically !
Like I say the iOS viewer used to be rock solid and trouble free, but the latest version is pretty shaky, anyone else having any issues ?
There is a longstanding issue with GameSalad audio that I thought I may as well throw in here with the latest release.
Sound files have their attack ramped to full volume from silence by Creator, this only happens with the preview as far as I can tell (it doesn't happen on the actual target device), the fade in time to 0dB is around 1/80th of a second, but it's enough to cause issues with judging the attack of a sound, if you have correctly trimmed bullet sounds or hits, impacts, explosions or (with music apps) snares and hats (etc) this can mean the attack is removed meaning it's easy to underestimate a percussive sound's volume when on a device, something that can sound fine in Creator can clip on the device when playing with other sounds.
In the image below you can see the original sound (the middle / blue 'original' waveform) - and what Creator does to that sound (the top / red 'GameSalad' waveform), you can clearly see the sound is having a slow attack imposed on it by GameSalad.
This issue is not caused by GameSalad's audio conversion process, files prepared as OGG files externally to GS (bypassing any GS conversion) exhibit the same issue.
(the third waveform - at the bottom - is a drum break, to give an idea of how much of a percussive sound is lost by this issue).
It would be great if the next update allowed for playing sounds from expressions. I have a big word game that GS tables would be perfect to handle EXCEPT for that. looks like that might have been a long standing request.
I've found a couple creator bugs, i'll file bug reports a bit later with screens, etc.
If an attribute is in use in a large number of actors and you try to delete the attribute, the list can extend beyond what is visible on the screen (screen resolution plays a factor of course), and has no scroll bar. This means that the elements for confirming or canceling are impossible to click and the only way to exit the creator is to force quit it, and since it doesn't recognize as needing a force quit you have to use the tool in OSX or a command to stop it. In addition, if someone does this by accident, they could lose a lot of work since you also cannot save.
This one is more minor, but if you have a prototype and a unlocked instance of the prototype and you add a self.attribute to the prototype, it shows up in the unlocked actor, which is fine since you can't add self attributes to unlocked actors directly. However when you go to delete it from the prototype it doesn't update on the unlocked until you restart the creator.
@AlchimiaStudios said:
I've found a couple creator bugs, i'll file bug reports a bit later with screens, etc.
This means that the elements for confirming or canceling are impossible to click and the only way to exit the creator is to force quit it, and since it doesn't recognize as needing a force quit you have to use the tool in OSX or a command to stop it. In addition, if someone does this by accident, they could lose a lot of work since you also cannot save.
The Cancel button is the highlighted button (even though you can't see it), so hitting 'Enter' will cancel the request. The 'yes' button ('remove') is the unhighlighted button and hasn't got a keyboard equivalent, so in theory the only want to remove the attribute would be to go through each actor and remove it . . . and the very fact that the list is so long that it goes off the screen means there are going to a lot of actors to open and close. But at least you can cancel the request.
I concur with your post concerning the iOS Viewer's issues. I have seen it occur on my iPhone 6.
I can't get the iOS viewer to work at all on my iPhone 6+ . . . . it does the compressing assets bit, then when it gets to the loading game part it just crawls along, after 10 minutes or so it's got though ~5% of the progress bar, I don't know whether it ever manages to get the whole way as I give up after 10-20 minutes - the old version was trouble free, transfers would take seconds.
@AlchimiaStudios said:
I've found a couple creator bugs, i'll file bug reports a bit later with screens, etc.
This means that the elements for confirming or canceling are impossible to click and the only way to exit the creator is to force quit it, and since it doesn't recognize as needing a force quit you have to use the tool in OSX or a command to stop it. In addition, if someone does this by accident, they could lose a lot of work since you also cannot save.
The Cancel button is the highlighted button (even though you can't see it), so hitting 'Enter' will cancel the request. The 'yes' button ('remove') is the unhighlighted button and hasn't got a keyboard equivalent, so in theory the only want to remove the attribute would be to go through each actor and remove it . . . and the very fact that the list is so long that it goes off the screen means there are going to a lot of actors to open and close. But at least you can cancel the request.
Good to know as a temp workaround. Hopefully sometime they can put a proper scroll bar or split it into columns or something.
Does anyone know what the lowest supported iOS is for GameSalad now . . . . ?
. . . . . . .
Edit:
On the App Store the GameSalad Viewer page for 1.25.50 it says 'Requires iOS 7.0 or later.
✅ I have an iPad Air2 - running iOS 8.1.2 - I could update this to the new viewer without any issues.
✅ I have an iPhone 6 plus - running iOS 9.2 - I could update this to the new viewer without any issues. (although I can only transfer very simple projects)
❌ I have an iPad Mini - running iOS 9.0.2 - the 'UPDATE' button is greyed out so I'm unable to download the viewer. I've tried the updates page and the main GameSalad Inc App Store page, with both the UPDATE button is greyed out.
❌ I have an iPad 3 - running 7.0.2 - when I press the 'UPDATE' button in the App Store it simply closes the App Store and opens up the GameSalad viewer.
I've tried deleting the viewer (it's currently running 1.24.42) and downloading it again, but it just downloads 1.24.42 again
Anyone has similar issues - or know of any solutions or ideas that might allow me to get a working viewer going on an iPad 3 or iPad mini ?
I concur with your post concerning the iOS Viewer's issues. I have seen it occur on my iPhone 6.
I managed to get a simple project onto the iPhone 6 plus (4 colour square actors, no rules, no images), but it shares the same issues as the iPad, the orientation is all screwed up, the project gets distorted (way more than if you were using the Stretch option), often you can't rotate it to the correct position and so on . . . it's very hit and miss at the moment.
These are the issues I have with viewer , when i view the game on ipad 3 or iphone 5s , the game goes to portrait even though its landscape . if i preview the game once i have to close the viewer and open it again to view again , otherwise some images wont appear on scene. But it works on ipad 3 with the latest update.
Just an update as to the creator slowdown issue. Codewizard said he may have a test build today for the beta team. Will update you on how it goes once we have the test build.
I concur with your post concerning the iOS Viewer's issues. I have seen it occur on my iPhone 6.
I managed to get a simple project onto the iPhone 6 plus (4 colour square actors, no rules, no images), but it shares the same issues as the iPad, the orientation is all screwed up, the project gets distorted (way more than if you were using the Stretch option), often you can't rotate it to the correct position and so on . . . it's very hit and miss at the moment.
Hey @Socks - I flagged this issue when v.1.25.5 first rolled out.. Bug 1689.. Apparently they are working on it, but no new updates. I had the issue on my i5, i6s, and ipad Air2 using different versions of iOS (8, 9, & 9.1)..
@KnightStar said:
Hey @Socks - I flagged this issue when v.1.25.5 first rolled out.. Bug 1689.. Apparently they are working on it, but no new updates. I had the issue on my i5, i6s, and ipad Air2 using different versions of iOS (8, 9, & 9.1)..
Thanks for flagging it. Yeah the issue is seen across all different iOS versions (mine range from 7.0.2 to 9.2) and all different iOS devices. Hope they sort it out, I'm sure they will, traditionally the iOS viewer has been rock solid. At the moment I can't even download or update the viewer onto an iPad mini and an iPad3 !
Question regarding Windows updates - say we're working on a project and don't want to risk a GameSalad update breaking part of it. How do we Windows users stop GameSalad from automatically updating? Is there some other download for stable versions?
Sorry if this is obvious but after some quick looking I haven't seen a solution and on the Downloads page it looks like it's all 1 download option.
I'd assume it means that if the actor isn't being told to move, it will sleep and be removed from the physics calculations. Whenever the actor isn't being moved by the player or other actors it behaves like it is set to Moveable unchecked. The exact circumstances that will wake it up, and at what point it gets told to sleep, that's a good question. Does a ball that hasn't been touched by other actors for a while sleep? After how long? How are collisions with it then handled?
@Socks said:
Anyone got any information on the new 'Can Sleep' function ?
The only information I can find is the one sentence: "Can Sleep – This removes the actor from physics calculations if nothing is happening to it."
Does anyone know how it works and where and when might you use it ?
Any input appreciated !
From a box2d tutorial...... "The sleep parameter says whether bodies should be allowed to 'sleep' if nothing is happening to them, for efficiency. If this is set to true, bodies will sleep when they come to rest, and are excluded from the simulation until something happens to 'wake' them again. This could be a collision from another body, a force applied to it etc."
@Socks said:
Anyone got any information on the new 'Can Sleep' function ?
The only information I can find is the one sentence: "Can Sleep – This removes the actor from physics calculations if nothing is happening to it."
Does anyone know how it works and where and when might you use it ?
Any input appreciated !
I would also like to know more about this. The exact conditions for sleep to kick in and also be released.
I just posted the answer above. When the actor is at rest, aka not moving, not being interacted with, not being collided with et... It will sleep. Once it is interacted with, collided, moved et... It will wake. The sleep status is watched every frame.
Comments
@Lost_Oasis_Games Do you have an idea when CodeWizard or GS will have an update? Or is their a way I can use like the a night build to continue working on my game? Its just so un responsive that its killing me to work on my app. Thanks again for all your knowledge and help
Do you have a link to the specifics on this ?
No, I'm simply making a one-off change to the COM and then hitting play.
No link. This is what codewizard said to us in the slack beta group.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
// double post
@GeorgeGS
@CodeWizard
I've made a quick project that highlights the constrain + COM issue, check it out if you get a minute (file attached).
. . . . . . . .
There is a yellow actor (100 x 400pixels), the image applied to this actor has a red dot that marks the bottom/centre of the actor.
I have moved this actor's COM to x=0, y-200 (the bottom/centre of the actor).
I have also placed a small blue actor behind the yellow actor, this small blue actor marks the COM the yellow actor should rotate around.
The yellow actor has a Rotate behaviour applied to it.
. . . . . . . .
Hit preview, the yellow actor behaves correctly, pivoting around the COM. Click and hold anywhere on the screen to zoom in, you can see the red dot at the bottom/centre of the yellow actor accurately sticks to the blue pivot point.
Now open up the yellow actor, turn the Rotate behaviour off, and switch on the constrain behaviour directly underneath it. Hit preview, and zoom in, you can see the red dot on the yellow actor no longer sticks to the blue pivot point.
You can correct the issue with a workaround, in the scene move the yellow actor 5 pixels left (so x=507) and then move its COM 5 pixels to the right (so change COM to x=5, y-200), the red dot at the bottom/centre of the yellow actor will now stick to the blue pivot point
The problem with this work around is that the issue is speed related, make the speed of the rotation faster and the offset will be bigger, the relationship is 'roughly' [speed (degrees/sec) / 18 = offset in pixels].
. . . . . . . .
Put the yellow actor's position and COM back to where it was (or just revert to saved) - open the yellow actor and switch on the third constrain behaviour (and obviously switch the other behaviours off) and now preview.
Press anywhere on the screen to zoom in.
With this oscillating / swinging movement you can see the issue can't always be resolved with a simple offset as the COM is now changing over time.
Unfortunately for me this last example is exactly what I intended to use the COM function for, at the moment the desired movement is being achieved with three constrains (X,Y and R) and some trigonometry, the idea was to replace three constrains with a single constrain rotation behaviour as I've got lots of these oscillating / swinging actors in my scene (a scene with 20 actors would jump from 60 constrains to 20, a really worthwhile optimization!)
But this issue means I'll have to stick with all the old pre-COM method for the time being.
Any input / ideas appreciated !
Anyone else having issues with the iOS viewer ?
I've installed the latest version on my iPad (Air2), and whereas in the past there were very few issues, if any at all, I'm having all sorts of strangeness with this new version.
For example, when a landscape project is passed over to the iPad it is displayed as portrait, even though the iPad was orientated correctly as landscape . . .
. . . I then rotate the iPad to get the GS project to rotate to correct orientation, that works fine, but if you then try and lock the iPad's orientation (swipe the iPad's control centre up and hit the lock rotation button) the GS project on screen gets squeezed vertically ! (I think by 50%) ?
The same is true of opening a project already on the iOS viewer, they open as portrait, with a bit of fiddling around and spinning of the iPad they can be made landscape, but the ability to lock the orientation (so it doesn't keep going back into portrait) is essentially now gone, as doing so squashes the project vertically !
Like I say the iOS viewer used to be rock solid and trouble free, but the latest version is pretty shaky, anyone else having any issues ?
There is a longstanding issue with GameSalad audio that I thought I may as well throw in here with the latest release.
Sound files have their attack ramped to full volume from silence by Creator, this only happens with the preview as far as I can tell (it doesn't happen on the actual target device), the fade in time to 0dB is around 1/80th of a second, but it's enough to cause issues with judging the attack of a sound, if you have correctly trimmed bullet sounds or hits, impacts, explosions or (with music apps) snares and hats (etc) this can mean the attack is removed meaning it's easy to underestimate a percussive sound's volume when on a device, something that can sound fine in Creator can clip on the device when playing with other sounds.
In the image below you can see the original sound (the middle / blue 'original' waveform) - and what Creator does to that sound (the top / red 'GameSalad' waveform), you can clearly see the sound is having a slow attack imposed on it by GameSalad.
This issue is not caused by GameSalad's audio conversion process, files prepared as OGG files externally to GS (bypassing any GS conversion) exhibit the same issue.
(the third waveform - at the bottom - is a drum break, to give an idea of how much of a percussive sound is lost by this issue).
@Socks,
I concur with your post concerning the iOS Viewer's issues. I have seen it occur on my iPhone 6.
My Blog / App Store / Google Play
It would be great if the next update allowed for playing sounds from expressions. I have a big word game that GS tables would be perfect to handle EXCEPT for that. looks like that might have been a long standing request.
I've found a couple creator bugs, i'll file bug reports a bit later with screens, etc.
If an attribute is in use in a large number of actors and you try to delete the attribute, the list can extend beyond what is visible on the screen (screen resolution plays a factor of course), and has no scroll bar. This means that the elements for confirming or canceling are impossible to click and the only way to exit the creator is to force quit it, and since it doesn't recognize as needing a force quit you have to use the tool in OSX or a command to stop it. In addition, if someone does this by accident, they could lose a lot of work since you also cannot save.
This one is more minor, but if you have a prototype and a unlocked instance of the prototype and you add a self.attribute to the prototype, it shows up in the unlocked actor, which is fine since you can't add self attributes to unlocked actors directly. However when you go to delete it from the prototype it doesn't update on the unlocked until you restart the creator.
Follow us: Twitter - Website
The Cancel button is the highlighted button (even though you can't see it), so hitting 'Enter' will cancel the request. The 'yes' button ('remove') is the unhighlighted button and hasn't got a keyboard equivalent, so in theory the only want to remove the attribute would be to go through each actor and remove it . . . and the very fact that the list is so long that it goes off the screen means there are going to a lot of actors to open and close. But at least you can cancel the request.
I had this problem too so I changed the scaling of the resolution on my Mac so that I could see the whole list. That might work for you as well
I can't get the iOS viewer to work at all on my iPhone 6+ . . . . it does the compressing assets bit, then when it gets to the loading game part it just crawls along, after 10 minutes or so it's got though ~5% of the progress bar, I don't know whether it ever manages to get the whole way as I give up after 10-20 minutes - the old version was trouble free, transfers would take seconds.
Q:
Does anyone know what the lowest supported iOS is for GameSalad now . . . . ?
Good to know as a temp workaround. Hopefully sometime they can put a proper scroll bar or split it into columns or something.
Follow us: Twitter - Website
Q:
Does anyone know what the lowest supported iOS is for GameSalad now . . . . ?
. . . . . . .
Edit:
On the App Store the GameSalad Viewer page for 1.25.50 it says 'Requires iOS 7.0 or later.
✅ I have an iPad Air2 - running iOS 8.1.2 - I could update this to the new viewer without any issues.
✅ I have an iPhone 6 plus - running iOS 9.2 - I could update this to the new viewer without any issues. (although I can only transfer very simple projects)
❌ I have an iPad Mini - running iOS 9.0.2 - the 'UPDATE' button is greyed out so I'm unable to download the viewer. I've tried the updates page and the main GameSalad Inc App Store page, with both the UPDATE button is greyed out.
❌ I have an iPad 3 - running 7.0.2 - when I press the 'UPDATE' button in the App Store it simply closes the App Store and opens up the GameSalad viewer.
I've tried deleting the viewer (it's currently running 1.24.42) and downloading it again, but it just downloads 1.24.42 again
Anyone has similar issues - or know of any solutions or ideas that might allow me to get a working viewer going on an iPad 3 or iPad mini ?
I managed to get a simple project onto the iPhone 6 plus (4 colour square actors, no rules, no images), but it shares the same issues as the iPad, the orientation is all screwed up, the project gets distorted (way more than if you were using the Stretch option), often you can't rotate it to the correct position and so on . . . it's very hit and miss at the moment.
Cant generate app right now, is the server down......
Homepage: freneticgamez.eu/
https://play.google.com/store/apps/developer?id=FreneticGamez
Yes, I seen some weird behavior too. Launching my game start up in portrait mode even though it is a landscape project.
It also seems like the first time preview from GS does one thing, and starting game from inside the GS viewer "Recent game list" does something else.
I haven't looked more into it because i managed to make my game look good rotating my device a few times.
These are the issues I have with viewer , when i view the game on ipad 3 or iphone 5s , the game goes to portrait even though its landscape . if i preview the game once i have to close the viewer and open it again to view again , otherwise some images wont appear on scene. But it works on ipad 3 with the latest update.
Just an update as to the creator slowdown issue. Codewizard said he may have a test build today for the beta team. Will update you on how it goes once we have the test build.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
Hey @Socks - I flagged this issue when v.1.25.5 first rolled out.. Bug 1689.. Apparently they are working on it, but no new updates. I had the issue on my i5, i6s, and ipad Air2 using different versions of iOS (8, 9, & 9.1)..
Thanks for flagging it. Yeah the issue is seen across all different iOS versions (mine range from 7.0.2 to 9.2) and all different iOS devices. Hope they sort it out, I'm sure they will, traditionally the iOS viewer has been rock solid. At the moment I can't even download or update the viewer onto an iPad mini and an iPad3 !
Question regarding Windows updates - say we're working on a project and don't want to risk a GameSalad update breaking part of it. How do we Windows users stop GameSalad from automatically updating? Is there some other download for stable versions?
Sorry if this is obvious but after some quick looking I haven't seen a solution and on the Downloads page it looks like it's all 1 download option.
Anyone got any information on the new 'Can Sleep' function ?
The only information I can find is the one sentence: "Can Sleep – This removes the actor from physics calculations if nothing is happening to it."
Does anyone know how it works and where and when might you use it ?
Any input appreciated !
I'd assume it means that if the actor isn't being told to move, it will sleep and be removed from the physics calculations. Whenever the actor isn't being moved by the player or other actors it behaves like it is set to Moveable unchecked. The exact circumstances that will wake it up, and at what point it gets told to sleep, that's a good question. Does a ball that hasn't been touched by other actors for a while sleep? After how long? How are collisions with it then handled?
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
From a box2d tutorial...... "The sleep parameter says whether bodies should be allowed to 'sleep' if nothing is happening to them, for efficiency. If this is set to true, bodies will sleep when they come to rest, and are excluded from the simulation until something happens to 'wake' them again. This could be a collision from another body, a force applied to it etc."
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
I would also like to know more about this. The exact conditions for sleep to kick in and also be released.
I just posted the answer above. When the actor is at rest, aka not moving, not being interacted with, not being collided with et... It will sleep. Once it is interacted with, collided, moved et... It will wake. The sleep status is watched every frame.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS