@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.
Do you think that watching for the sleep status on every frame could cause a massive slow down of my app? I have an app which produces a drawing by spawning small actors every frame. After about 5 seconds it gets really slow. This didn't happen in the last version.
@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.
Do you think that watching for the sleep status on every frame could cause a massive slow down of my app? I have an app which produces a drawing by spawning small actors every frame. After about 5 seconds it gets really slow. This didn't happen in the last version.
No as that code is scanned all the time anyway. In my custom collision shape animation method I have actors spawned and destroyed every frame as well as reading position and velocity and recognizing collisions. It runs at 60fps. It's all about how you write your code and your layer order for that code.
@Lost_Oasis_Games said:
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."
Thanks for the info . . . I'm trying to think when you wouldn't use 'can sleep' now !
I've noticed that you can no longer undo a deletion in an actor's rules !
For example, you scroll down to a behaviour or rule you no longer need, you select it and hit delete, then you realise you'd selected the wrong piece of code, so normally you simply Cmd+Z to undo the delete . . . . but undo no longer works, so you'll need to revert to saved now (assuming you'd saved the project).
Anyone else come across this ? . . . . before I log it as a bug, just in case it's only with my copy of GS ??
owen_dennisJust a guy, you know.Member, PROPosts: 236
I've noticed that you can no longer undo a deletion in an actor's rules !
For example, you scroll down to a behaviour or rule you no longer need, you select it and hit delete, then you realise you'd selected the wrong piece of code, so normally you simply Cmd+Z to undo the delete . . . . but undo no longer works, so you'll need to revert to saved now (assuming you'd saved the project).
Anyone else come across this ? . . . . before I log it as a bug, just in case it's only with my copy of GS ??
I've come across this all the time for the past couple builds. I figured it was just something wrong with mine.
I've noticed that you can no longer undo a deletion in an actor's rules !
For example, you scroll down to a behaviour or rule you no longer need, you select it and hit delete, then you realise you'd selected the wrong piece of code, so normally you simply Cmd+Z to undo the delete . . . . but undo no longer works, so you'll need to revert to saved now (assuming you'd saved the project).
Anyone else come across this ? . . . . before I log it as a bug, just in case it's only with my copy of GS ??
they had to pull it out because the code was buggy IIRC.
Undo has been missing since the fixes they did for Yosemite slowness. It's been discussed a bunch of times before. They couldn't fix Yosemite slowness without opening up a huge bug in the undo code, so they removed the undo code. This was about a year ago now. They intended to fix it but it didn't make the cut for 1.24 or 1.25. Hopefully it's something being addressed now OS X 10.11.5 has forced them to really tackle these old issues.
@strag said: @Lost_Oasis_Games Ok thanks. Maybe a re-writing of my code is in order Strange that it was fine in the previous version though.
In 1.25 layer order is now important as the scan is much faster and tighter. You have to watch the order of your code in relation to code in other actors that share the same info. Code is read in the layer from Bottom to top. Go the the begining of this thread and read Georgegs's comments on this.
Managed to eventually get the 1.25.50 viewer onto an iPad3 / iOS 7.0.2
What worked for me was - besides repeatedly trying - not using the ‘update’ button in the App Store’s Updates section (this just opens the current version you have on your device) but instead search for the app in the app store (use: GameSalad, Inc.), once located ignore the ‘Open’ or ‘Update’ button on the small page preview (this also just opens the current version), click on the icon to open the main page and then use the ‘Update’ button on that page.
If this doesn’t work at first, try it a few times, wait a while, try again, it should work eventually.
(the iPad 3 viewer suffers all the same orientation and squashed /offset camera issues as the viewer on other devices)
@strag said: @Lost_Oasis_Games Ok thanks. Maybe a re-writing of my code is in order Strange that it was fine in the previous version though.
In 1.25 layer order is now important as the scan is much faster and tighter. You have to watch the order of your code in relation to code in other actors that share the same info. Code is read in the layer from Bottom to top. Go the the begining of this thread and read Georgegs's comments on this.
Ok, thanks for the advice. Couldn't find the Georgegs post you were referring to though?
@Lost_Oasis_Games said:
In 1.25 layer order is now important as the scan is much faster and tighter.
It certainly is ! I got a game going on my iPad3 (the same processing power as the lowly iPad2) at 60fps, pre-1.25 I was lucky to get 40-45fps with the same project.
@strag said: @Lost_Oasis_Games Ok thanks. Maybe a re-writing of my code is in order Strange that it was fine in the previous version though.
In 1.25 layer order is now important as the scan is much faster and tighter. You have to watch the order of your code in relation to code in other actors that share the same info. Code is read in the layer from Bottom to top. Go the the begining of this thread and read Georgegs's comments on this.
Ok, thanks for the advice. Couldn't find the Georgegs post you were referring to though?
Oops sorry it was in the 1.25 release thread. Here it is. Even though he references spawning it relates overall to how the layer is scanned based on a frame.
"One thing to watch for in 1.25+ is how you spawn actors.
Before 1.25 the code that updates actors would count how many there were and then update that many by their index in the list. The problem with this is spawning a new actor makes that list bigger, so depending on which front/back layer/actor option you use you get different behavior.
For actors spawned behind the current actor (back of layer/actor) the new actor would not be updated until the next frame and it would stop the actor at the front of the layer from being updated that frame.
For actors spawned in front of the current actor the new actor would be updated, would be out of sync with physics, and it would stop the actor at the front of the layer from being updated that frame.
For actors spawned at the front of the layer the new actor would not be updated that frame, but since they are at the end of the list they wouldn't stop other actors from being updated.
If you spawn more than one actor a frame it just makes things more inconsistent.
In 1.25+ all actors that already existed are updated and any new actors are not updated until the next frame to be consistent and keep them in sync with physics.
We tested this in many projects and didn't see any issues, but any spawned actors counting on that first frame update happening immediately might need to be tweaked to make sure their initial state is what you want."
Would there be a possibility of the option to change an actors layer position? Not just to the back or front, but a specific number of position. Eg. Change self.layer to self.layer - 8. Might make isometrical games possible (or easier, more realistic).
Best,
Braydon_SFXMember, Sous Chef, Bowlboy SidekickPosts: 9,273
@Two.E said:
Would there be a possibility of the option to change an actors layer position? Not just to the back or front, but a specific number of position. Eg. Change self.layer to self.layer - 8. Might make isometrical games possible (or easier, more realistic).
Best,
That's been a feature request for some time now. I'd welcome it with open arms!
@whycali said:
Has anybody seen this version of GS slow down with Apple's new update of 10.11.5? My Mac updated automatically and now GS is slow almost not usable.
Hi @whycali,
The same is happening to me. @Lost_Oasis_Games, any news about the update of GS to recover from its current useless state with OS X 10.11.5?
@strag said: @Lost_Oasis_Games Ok thanks. Maybe a re-writing of my code is in order Strange that it was fine in the previous version though.
In 1.25 layer order is now important as the scan is much faster and tighter. You have to watch the order of your code in relation to code in other actors that share the same info. Code is read in the layer from Bottom to top. Go the the begining of this thread and read Georgegs's comments on this.
Ok, thanks for the advice. Couldn't find the Georgegs post you were referring to though?
Oops sorry it was in the 1.25 release thread. Here it is. Even though he references spawning it relates overall to how the layer is scanned based on a frame.
"One thing to watch for in 1.25+ is how you spawn actors.
Before 1.25 the code that updates actors would count how many there were and then update that many by their index in the list. The problem with this is spawning a new actor makes that list bigger, so depending on which front/back layer/actor option you use you get different behavior.
For actors spawned behind the current actor (back of layer/actor) the new actor would not be updated until the next frame and it would stop the actor at the front of the layer from being updated that frame.
For actors spawned in front of the current actor the new actor would be updated, would be out of sync with physics, and it would stop the actor at the front of the layer from being updated that frame.
For actors spawned at the front of the layer the new actor would not be updated that frame, but since they are at the end of the list they wouldn't stop other actors from being updated.
If you spawn more than one actor a frame it just makes things more inconsistent.
In 1.25+ all actors that already existed are updated and any new actors are not updated until the next frame to be consistent and keep them in sync with physics.
We tested this in many projects and didn't see any issues, but any spawned actors counting on that first frame update happening immediately might need to be tweaked to make sure their initial state is what you want."
Thanks for posting. Gosh...that made my head hurt!
I'm not entirely sure how this may be slowing my app down. My app is a drawing app and spawning literally thousands of actors into the scene to create a scribbled line, I think there may be an issue with the way these actors are being sorted and this is causing a massive slowdown after about 10 seconds or so. To be honest at this stage I'm struggling to see a solution ;/
@strag said: @Lost_Oasis_Games Ok thanks. Maybe a re-writing of my code is in order Strange that it was fine in the previous version though.
In 1.25 layer order is now important as the scan is much faster and tighter. You have to watch the order of your code in relation to code in other actors that share the same info. Code is read in the layer from Bottom to top. Go the the begining of this thread and read Georgegs's comments on this.
Ok, thanks for the advice. Couldn't find the Georgegs post you were referring to though?
Oops sorry it was in the 1.25 release thread. Here it is. Even though he references spawning it relates overall to how the layer is scanned based on a frame.
"One thing to watch for in 1.25+ is how you spawn actors.
Before 1.25 the code that updates actors would count how many there were and then update that many by their index in the list. The problem with this is spawning a new actor makes that list bigger, so depending on which front/back layer/actor option you use you get different behavior.
For actors spawned behind the current actor (back of layer/actor) the new actor would not be updated until the next frame and it would stop the actor at the front of the layer from being updated that frame.
For actors spawned in front of the current actor the new actor would be updated, would be out of sync with physics, and it would stop the actor at the front of the layer from being updated that frame.
For actors spawned at the front of the layer the new actor would not be updated that frame, but since they are at the end of the list they wouldn't stop other actors from being updated.
If you spawn more than one actor a frame it just makes things more inconsistent.
In 1.25+ all actors that already existed are updated and any new actors are not updated until the next frame to be consistent and keep them in sync with physics.
We tested this in many projects and didn't see any issues, but any spawned actors counting on that first frame update happening immediately might need to be tweaked to make sure their initial state is what you want."
Thanks for posting. Gosh...that made my head hurt!
I'm not entirely sure how this may be slowing my app down. My app is a drawing app and spawning literally thousands of actors into the scene to create a scribbled line, I think there may be an issue with the way these actors are being sorted and this is causing a massive slowdown after about 10 seconds or so. To be honest at this stage I'm struggling to see a solution ;/
I was experiencing slowdowns because of large amounts of spawning with the most recents builds too.
I ended up doing a major code overhaul and reduced spawns significantly/optimized them.
The things I noticed that helped the most were just reducing the spawns per frame. Consistent measured spawns is much better then trying to call a bunch of spawns at the same time.
Nested spawns (spawned actor that spawns another actor) were also giving a pretty nasty hit to FPS.
It sounds like it might be even harder for you since it's a drawing type app but look into ways to reduce the per frame stress on the cpu from spawning if at all possible.
Maybe look into just having actors on screen before hand too, like a drawing grid made up of tiny actors that respond and change based on input.
@AlchimiaStudios
Thanks for the advice.
Unfortunately I can't reduce the number of spawns per frame as it produces gaps in the drawn line. I think I will start again to see if the code can be optimized but after having a quick look it does not appear hugely inefficient to me. I've disabled all sound and unessential behaviors/timers yet it is still grinding to a halt. I'm concerned that with this new build the shear amount and frequency of spawning I need may not be achievable.
@strag said: @AlchimiaStudios
Thanks for the advice.
Unfortunately I can't reduce the number of spawns per frame as it produces gaps in the drawn line. I think I will start again to see if the code can be optimized but after having a quick look it does not appear hugely inefficient to me. I've disabled all sound and unessential behaviors/timers yet it is still grinding to a halt. I'm concerned that with this new build the shear amount and frequency of spawning I need may not be achievable.
It's not that it's a slow down. It's that if you read above if spawning is not done properly an actor's code can get skipped a scan. Gamesalad in the past didn't produce a tight reliable scan. Which allowed us to be lose about how we were layering, aka, ordering our code in relation to the layer order. This led to other issue which are now fixed due to a proper scan. Now one must pay attention to our code as a whole. Especially code that other actors rely on from other actors on the scene. When you spawn an actor on the layer it changes how the other actors are scanned and could cause actors above it in the layer to skip the scan. I know it is more complex but you have to see your code as a whole now.
@Lost_Oasis_Games
Thanks for the help. I'm currently trying lots of different layer order configurations and trying to very much simplify my code. Nothings working yet but I've already found lots of areas where I was being lazy like constraining the volume of a sound effect to a variable to control the timing of its volume fading in and out. Once I fix all these issues hopefully it will speed up a bit...fingers crossed!
Just ran a test, stripped my app down completely, a single moving actor spawning single dumb actors every 0 seconds. Nothing else in the scene.
Once the total number of actors reaches about 700 it is down to 30fps, by just over 1000 it is grinding to a halt. This is when viewing on an iPad.
This is the same whether its a timer or a loop. Layer order is not the issue as I've tried every conceivable variation of layer order. Seems it's unusable now above 700 actors. This was not the case with the last GS version.
Are the changes in 1.25.54 for both Mac and Windows creator or only Mac creator? What's the latest for the Windows version? Or is the server responsible for performance changes as long as you post with a 1.25 build.
@ForumNinja Seriously? GameSalad has been rendered unusable by an OS X upgrade for more than a week now and at the same time the CEO / CTO / 25% of the programming capacity in the entire company just left and nothing but crickets from GS. Don't you think an explanation to your customers base on this forum is in order by now? How long will you just keep silent? Anyone left over there?
@viking said: @ForumNinja Seriously? GameSalad has been rendered unusable by an OS X upgrade for more than a week now and at the same time the CEO / CTO / 25% of the programming capacity in the entire company just left and nothing but crickets from GS. Don't you think an explanation to your customers base on this forum is in order by now? How long will you just keep silent? Anyone left over there?
This is a post by SmallBytes in the 'why-is-gamesalad-so-slow' thread:
. . . . . . . . . . .
"Just got this from Gamesalad Support:
Hey there!
A fix has not been found yet, but we're actively working on it. This issue was brought about by the Mac OS X update 10.11.5.
To work around it in the meantime you can get a virtual machine that is running a previous version of Mac OS X (like 10.11.4) and work using that, or if you have access to a Windows machine, you can work using GameSalad's Windows version."
@Socks it does not answer the big question though. Why no official sticky post from someone, anyone at GS? The normal action in a situation like this is to talk to your customers in an official capacity when the news of big changes at the company have leaked out to the public. Just weird in my opinion. Wouldn't you say something if you had a community like GS has?
Comments
Do you think that watching for the sleep status on every frame could cause a massive slow down of my app? I have an app which produces a drawing by spawning small actors every frame. After about 5 seconds it gets really slow. This didn't happen in the last version.
No as that code is scanned all the time anyway. In my custom collision shape animation method I have actors spawned and destroyed every frame as well as reading position and velocity and recognizing collisions. It runs at 60fps. It's all about how you write your code and your layer order for that code.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
@Lost_Oasis_Games Ok thanks. Maybe a re-writing of my code is in order
Strange that it was fine in the previous version though.
Thanks for the info . . . I'm trying to think when you wouldn't use 'can sleep' now !
Code deletion bug.
I've noticed that you can no longer undo a deletion in an actor's rules !
For example, you scroll down to a behaviour or rule you no longer need, you select it and hit delete, then you realise you'd selected the wrong piece of code, so normally you simply Cmd+Z to undo the delete . . . . but undo no longer works, so you'll need to revert to saved now (assuming you'd saved the project).
Anyone else come across this ? . . . . before I log it as a bug, just in case it's only with my copy of GS ??
I've come across this all the time for the past couple builds. I figured it was just something wrong with mine.
Vote for Nearest Neighbor Scaling option in gamesalad! Let's make our games look truly stunning!
they had to pull it out because the code was buggy IIRC.
Send and Receive Data using your own Server Tutorial! | Vote for A Long Way Home on Steam Greenlight! | Ten Years Left
Wow, that's a pretty big deal. Thanks @Socks for calling attention to it.
Undo has been missing since the fixes they did for Yosemite slowness. It's been discussed a bunch of times before. They couldn't fix Yosemite slowness without opening up a huge bug in the undo code, so they removed the undo code. This was about a year ago now. They intended to fix it but it didn't make the cut for 1.24 or 1.25. Hopefully it's something being addressed now OS X 10.11.5 has forced them to really tackle these old issues.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I've been out of the game for a little while, hence my surprise.
Either way, now I know
In 1.25 layer order is now important as the scan is much faster and tighter. You have to watch the order of your code in relation to code in other actors that share the same info. Code is read in the layer from Bottom to top. Go the the begining of this thread and read Georgegs's comments on this.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
Managed to eventually get the 1.25.50 viewer onto an iPad3 / iOS 7.0.2
What worked for me was - besides repeatedly trying - not using the ‘update’ button in the App Store’s Updates section (this just opens the current version you have on your device) but instead search for the app in the app store (use: GameSalad, Inc.), once located ignore the ‘Open’ or ‘Update’ button on the small page preview (this also just opens the current version), click on the icon to open the main page and then use the ‘Update’ button on that page.
If this doesn’t work at first, try it a few times, wait a while, try again, it should work eventually.
(the iPad 3 viewer suffers all the same orientation and squashed /offset camera issues as the viewer on other devices)
Ok, thanks for the advice. Couldn't find the Georgegs post you were referring to though?
It certainly is ! I got a game going on my iPad3 (the same processing power as the lowly iPad2) at 60fps, pre-1.25 I was lucky to get 40-45fps with the same project.
Excellent work by the GameSalad team !
Oops sorry it was in the 1.25 release thread. Here it is. Even though he references spawning it relates overall to how the layer is scanned based on a frame.
"One thing to watch for in 1.25+ is how you spawn actors.
Before 1.25 the code that updates actors would count how many there were and then update that many by their index in the list. The problem with this is spawning a new actor makes that list bigger, so depending on which front/back layer/actor option you use you get different behavior.
For actors spawned behind the current actor (back of layer/actor) the new actor would not be updated until the next frame and it would stop the actor at the front of the layer from being updated that frame.
For actors spawned in front of the current actor the new actor would be updated, would be out of sync with physics, and it would stop the actor at the front of the layer from being updated that frame.
For actors spawned at the front of the layer the new actor would not be updated that frame, but since they are at the end of the list they wouldn't stop other actors from being updated.
If you spawn more than one actor a frame it just makes things more inconsistent.
In 1.25+ all actors that already existed are updated and any new actors are not updated until the next frame to be consistent and keep them in sync with physics.
We tested this in many projects and didn't see any issues, but any spawned actors counting on that first frame update happening immediately might need to be tweaked to make sure their initial state is what you want."
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
Would there be a possibility of the option to change an actors layer position? Not just to the back or front, but a specific number of position. Eg. Change self.layer to self.layer - 8. Might make isometrical games possible (or easier, more realistic).
Best,
GSLearn.com | Templates | Free Demos | Udemy Course
That's been a feature request for some time now. I'd welcome it with open arms!
My GameSalad Academy Courses! ◦ Check out my quality templates! ◦ Add me on Skype: braydon_sfx
GS is not doing too well with the OSX update 10.11.5
Hi @whycali,
The same is happening to me. @Lost_Oasis_Games, any news about the update of GS to recover from its current useless state with OS X 10.11.5?
Thanks for posting. Gosh...that made my head hurt!
I'm not entirely sure how this may be slowing my app down. My app is a drawing app and spawning literally thousands of actors into the scene to create a scribbled line, I think there may be an issue with the way these actors are being sorted and this is causing a massive slowdown after about 10 seconds or so. To be honest at this stage I'm struggling to see a solution ;/
@strag said:
I was experiencing slowdowns because of large amounts of spawning with the most recents builds too.
I ended up doing a major code overhaul and reduced spawns significantly/optimized them.
The things I noticed that helped the most were just reducing the spawns per frame. Consistent measured spawns is much better then trying to call a bunch of spawns at the same time.
Nested spawns (spawned actor that spawns another actor) were also giving a pretty nasty hit to FPS.
It sounds like it might be even harder for you since it's a drawing type app but look into ways to reduce the per frame stress on the cpu from spawning if at all possible.
Maybe look into just having actors on screen before hand too, like a drawing grid made up of tiny actors that respond and change based on input.
Follow us: Twitter - Website
@AlchimiaStudios
Thanks for the advice.
Unfortunately I can't reduce the number of spawns per frame as it produces gaps in the drawn line. I think I will start again to see if the code can be optimized but after having a quick look it does not appear hugely inefficient to me. I've disabled all sound and unessential behaviors/timers yet it is still grinding to a halt. I'm concerned that with this new build the shear amount and frequency of spawning I need may not be achievable.
It's not that it's a slow down. It's that if you read above if spawning is not done properly an actor's code can get skipped a scan. Gamesalad in the past didn't produce a tight reliable scan. Which allowed us to be lose about how we were layering, aka, ordering our code in relation to the layer order. This led to other issue which are now fixed due to a proper scan. Now one must pay attention to our code as a whole. Especially code that other actors rely on from other actors on the scene. When you spawn an actor on the layer it changes how the other actors are scanned and could cause actors above it in the layer to skip the scan. I know it is more complex but you have to see your code as a whole now.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
@Lost_Oasis_Games
Thanks for the help. I'm currently trying lots of different layer order configurations and trying to very much simplify my code. Nothings working yet but I've already found lots of areas where I was being lazy like constraining the volume of a sound effect to a variable to control the timing of its volume fading in and out. Once I fix all these issues hopefully it will speed up a bit...fingers crossed!
Just ran a test, stripped my app down completely, a single moving actor spawning single dumb actors every 0 seconds. Nothing else in the scene.
Once the total number of actors reaches about 700 it is down to 30fps, by just over 1000 it is grinding to a halt. This is when viewing on an iPad.
This is the same whether its a timer or a loop. Layer order is not the issue as I've tried every conceivable variation of layer order. Seems it's unusable now above 700 actors. This was not the case with the last GS version.
Anyone having similar issues?
@allc1865 You are right.. GS is unstable on 10.11.5.. I am not able to edit even a single actor.. Please fix it!!
Current Projects I am working on: Stupid Duck, Zango's Shark Adventure, AoD: Age of Dragons, Rocket Jump: The Pixel Invaders
Facebook: https://facebook.com/reflectivebytegamestudios
Web: reflectivebyte.com
Are the changes in 1.25.54 for both Mac and Windows creator or only Mac creator? What's the latest for the Windows version? Or is the server responsible for performance changes as long as you post with a 1.25 build.
@ForumNinja Seriously? GameSalad has been rendered unusable by an OS X upgrade for more than a week now and at the same time the CEO / CTO / 25% of the programming capacity in the entire company just left and nothing but crickets from GS. Don't you think an explanation to your customers base on this forum is in order by now? How long will you just keep silent? Anyone left over there?
This is a post by SmallBytes in the 'why-is-gamesalad-so-slow' thread:
. . . . . . . . . . .
"Just got this from Gamesalad Support:
Hey there!
A fix has not been found yet, but we're actively working on it. This issue was brought about by the Mac OS X update 10.11.5.
To work around it in the meantime you can get a virtual machine that is running a previous version of Mac OS X (like 10.11.4) and work using that, or if you have access to a Windows machine, you can work using GameSalad's Windows version."
@Socks it does not answer the big question though. Why no official sticky post from someone, anyone at GS? The normal action in a situation like this is to talk to your customers in an official capacity when the news of big changes at the company have leaked out to the public. Just weird in my opinion. Wouldn't you say something if you had a community like GS has?