Things seem to be looking quite good with these release candidates. I'm going through my project with 11.0.6 and doing some thorough testing, to help find issues that I personally need addressed, so as to result in a solid Stable Build of Game Salad that I can use to finish and release my game with.
I think this approach of having a series of Release Candidates leading up to the release of a new Stable workhorse build is great. Ironing out all the bugs, so we have a really solid version of Game Salad to work with for months to come is really good.
But if the load times issue is not fixed for this version, then it ultimately undermines all the progress made in 0.11, because I wouldn't want to actually release any games using 0.11 if the load times are going to be that long.
And relying on Nightly Builds is not something I feel comfortable with, as with whatever fixes and new features that are in each build, there also seems to be a few show-stopper bugs in each version.
I really hope 0.11 can turn out to be a reliable workhorse, with all the bugs ironed out, and good load times. As I'm not sure when the next stable build will be available after that, and I wouldn't want to hold my breath for it.
To release a 0.11 with flaws that prevent shipping will ultimately make me feel like I can't really finish off my game this year, making the past year also a waste of time.
Keen to hear any news that says this won't be the case.
I've run some tests for my problem with the parallax scrolling layers after going to my Pause Scene OPTIONS MENU.
I find that once I return from my OPTIONS SCREEN, the parallax layers are no longer updating their self.Position.X values.
I've added a Display Text behaviour to my layers, and when I first load the game, they show the self.Position.X attributes updating every frame as the layers whiz along to the left.
After I go to the OPTIONS MENU (which has a Pause Scene behaviour) and then return to the Main Menu, the parallax layers are no longer updating. They keep moving to the left, but the layers show their self.Position.X attributes as unchanging.
Hence, they move off the screen to the left, but never reset to their start positions. They just keep going and never come back.
All that happens when you click it is that it changes the MenuState attribute to "2", that causing the camera to shift to another part of the scene and show the shop.
It works fine, as it always has. But once you've gone to the OPTIONS MENU and back again, clicking on it does not change the MenuState attribute to 2. It is just stuck on 1.
So there seems to be a problem with attributes in general once going to the OPTIONS MENU, which may be related to using the Pause Scene behaviour, judging from what others are saying above.
Also, I find that some scene changes do not show a LOADING WHEEL, and hence it looks as if it's crashed. It just shows a frozen screen until the scene is loaded.
The "crash-like" sensation of this is exacerbated by the rather extended loading times being experienced with 11.0.6.
I also get a weird problem where, when I go into a character actor, for example, I get a popup appearing saying "Is this an image sequence?" over and over again. Whether I click YES or NO (many times) to get rid of the boxes, they come back again over and over, the next time I open up the same actor.
This seems to be the case for every image that appears in an Animation behaviour.
And it seems to recur over and over again, every time the actor is opened.
To be honest there have been issues with pause going back a year now. I couldn't use pause for one of my games because it was screwing up multitouch. I reported it back then and nothing was done. Maybe now that the problem is bigger now they will finally address it. I agree with the general consensus, fix all the issues, including memory problem before you release 11. We waited this long let's get this release virtually bug free. Having the RC and the nightly helps people get by until these issues are fixed. Don't be in a rush, keep working it until you get it rights! Maybe for the first time we can have a very stable creator version. This would be a huge first and a milestone for gamesalad.
I've reported a series of bugs with my project included with steps to reproduce. All the best having a look at the issues. And I look forward to the next release candidate! Cheers.
@The_Gamesalad_Guru said:
To be honest there have been issues with pause going back a year now. I couldn't use pause for one of my games because it was screwing up multitouch. I reported it back then and nothing was done. Maybe now that the problem is bigger now they will finally address it. I agree with the general consensus, fix all the issues, including memory problem before you release 11. We waited this long let's get this release virtually bug free. Having the RC and the nightly helps people get by until these issues are fixed. Don't be in a rush, keep working it until you get it rights! Maybe for the first time we can have a very stable creator version. This would be a huge first and a milestone for gamesalad.
Yes. Please, please, please don't pull the trigger early on the next stable and leave us wanting. Fix the Pause bug, fix the load times and odd loading wheel issue here and there. Of course it isn't going to be 100% bug free, but it is very close to being very stable and usable.
@Hymloe said:
On the whole, this is looking like a good build, and I'm really appreciating Game Salad's processes with these new builds. Nice work guys!
I disagree. I can't load any scene on iOS in this project. So for me, it's a game breaking build.
Send in a report to Game Salad and include your project. It's the best way for them to diagnose the cause of the problem, and fix potential issues. It'll help all of us out if they can effectively address bugs.
(I've Posted this on the latest annoucement, thought it was more appropriate! now can't delete this comment, D'oh!!)
Hey guys,
Has anyone noticed the GS logos (Iterations of app icon sizes) being added to the build of apps published from a nightly/candidate build?
when you install your adhoc app on your phone, the GS logo displays WHILST the app is downloading because of a 'image.xassets' folder full of GS app icons being added to the build, then once the app is downloaded, it reverts to YOUR app icon.
This is a pressing issue for me, i don't want customers to see the GS logo... am i being stupid and it'll be removed on the stable build or will users not see this once it's downloaded from the appstore?
@BlackCloakGS said:
Socks can you give me your support ticket for "The link between prototypes and instances is still broken, makes laying out large complex actor heavy projects a real pain." if you don't have one please submit one.
Yes, I know we need to get load times down. I will see if we can find a path or a small fix to do to try to bring them down.
If you are not aware of this I ask "Where have you been?" I am shocked to the core that this glaring bug reported by just about everyone on here and discussed at length in the forums draws a blank from you @BlackCloakGS ??? Honestly are you joking? Honestly?
I reported the bug, made a video, reported it again, posted the video in the forums - and you seem to have no idea about the most glaring bug in GameSalad?
I have experienced the bug many months ago. I can't remember if I wrote in an official report. If someone could write up an official bug for it in the bugbase, that would be great.
From memory, the issue can be worked around by unlocking the instance from the prototype, then closing and re-opening Game Salad, and the link between the instance and prototype is appropriately disconnected.
Ideally, it should just break the connection properly without having to quit and re-open.
But suffice to say, Game Salad need to know specifically what the issue is, and steps to reproduce it. They can't just guess what the problem is. I know it's a bit of a hassle to write it up. But if we can get all the bugs into the database, Game Salad can get onto fixing them.
From memory, you make an actor, drag say, three instances of it out into the scene, then unlock the instances from the prototype.
Then, when trying to adjust the individual attributes of the actors, it behaves as though they have not been unlocked - as if you're editing the prototype itself. The unlocked instances don't act as if they've been unlocked.
But if you quit Game Salad and open the project again, the unlocked instances are correctly broken off and behave as you would expect - where you can edit each one individually, and give them unique attribute values, etc.
The expected/desired result would be that as soon as you unlock the actors, they should be editable individually.
Reported it, been working around it ever since. I can deal with that known thing for now. Quit and restart fixes it. Unlock and revert fixes it. Do that a lot to get things working well. There's some bad memory leak in GameSalad too that cripples it. Best to quit and restart quite regularly.
@Hymloe said:
From memory, you make an actor, drag say, three instances of it out into the scene, then unlock the instances from the prototype.
Then, when trying to adjust the individual attributes of the actors, it behaves as though they have not been unlocked - as if you're editing the prototype itself. The unlocked instances don't act as if they've been unlocked.
But if you quit Game Salad and open the project again, the unlocked instances are correctly broken off and behave as you would expect - where you can edit each one individually, and give them unique attribute values, etc.
The expected/desired result would be that as soon as you unlock the actors, they should be editable individually.
Is that correct matarua ?
I'm just going from memory!
I demonstrated my first experience of this months ago, November 2013 (reported the bug), it's worse than just your preview code of a certain instance not obeying the prototype.
You see with this that copied actors that are prototypes are not really prototypes either?
The issue of non-updating instances is so widespread I am sure I don't need to demo that too, am I right?
A prototype is not a prototype and an instance is not an instance nor is it an instance of a prototype. That's the bug. It seems to be with the preview view of code in some situations, and with the actual code in others.
@Hymloe said:
From memory, the issue can be worked around by unlocking the instance from the prototype, then closing and re-opening Game Salad, and the link between the instance and prototype is appropriately disconnected.
I think you are confusing things here, the issue is that the instances lose their connection with the prototype when they are not unlocked, for instance drag 20 copies of an actor onto the scene, then change the colour of the prototype from its default white to red . . . . now look at the instances in the scene they are all still white.
Quitting and restarting doesn't always fix the problem, nor does the unlocking / reverting trick.
@Hymloe said:
But suffice to say, Game Salad need to know specifically what the issue is, and steps to reproduce it. They can't just guess what the problem is. I know it's a bit of a hassle to write it up. But if we can get all the bugs into the database, Game Salad can get onto fixing them.
Again I think the point being made here is getting missed, people have been sending in bug reports, often detailed bug reports with videos and example projects and so on, and still the bugs turn up month after month and - worryingly - GameSalad still seem entirely unaware of some issues that have been reported and discussed extensively.
@Hymloe said:
Send in a report to Game Salad and include your project. It's the best way for them to diagnose the cause of the problem, and fix potential issues.
I honestly don't think that's the case, I'd say the best way is to try and raise the issue on the forums, get enough people to join in with discussing the issue and you can often attract GameSalad's attention - once interested they can be pretty quick when it comes to fixing bugs, but historically the bug reporting system has been very hit and miss, to be honest I've not used it for years, but from the reports I've seen it doesn't seem much different to how it's always been.
My experience of the GameSalad bug reporting system has been this:
If you can provide steps to accurately and consistently reproduce the bug, they acknowledge it generically ("Thank you for reporting this issue" etc.) and at some point in the future it may or may not be fixed.
If the bug is something that happens in circumstances you cannot reproduce (such as the the bug that's still in this latest RC where it's hit or miss if images added to a project will show up in the image browser), and if you can't provide steps to consistently reproduce it, then the assumption is you are wrong.
There's definitely a lot of sand in the GameSalad offices that makes frequent cranial contact.
Comments
Things seem to be looking quite good with these release candidates. I'm going through my project with 11.0.6 and doing some thorough testing, to help find issues that I personally need addressed, so as to result in a solid Stable Build of Game Salad that I can use to finish and release my game with.
I think this approach of having a series of Release Candidates leading up to the release of a new Stable workhorse build is great. Ironing out all the bugs, so we have a really solid version of Game Salad to work with for months to come is really good.
But if the load times issue is not fixed for this version, then it ultimately undermines all the progress made in 0.11, because I wouldn't want to actually release any games using 0.11 if the load times are going to be that long.
And relying on Nightly Builds is not something I feel comfortable with, as with whatever fixes and new features that are in each build, there also seems to be a few show-stopper bugs in each version.
I really hope 0.11 can turn out to be a reliable workhorse, with all the bugs ironed out, and good load times. As I'm not sure when the next stable build will be available after that, and I wouldn't want to hold my breath for it.
To release a 0.11 with flaws that prevent shipping will ultimately make me feel like I can't really finish off my game this year, making the past year also a waste of time.
Keen to hear any news that says this won't be the case.
My game is crashing on iPod Touch 4. But that's kind of normal. Stupid iPod Touch 4. Why did Apple short-change the poor little guy's memory?
On the whole, this is looking like a good build, and I'm really appreciating Game Salad's processes with these new builds. Nice work guys!
I'm not sure if this has always been like it but I've found an inconsistency when changing boolean table values.
0 or "false" works for changing a table boolean value to FALSE
Only "true" works for changing the boolean value to TRUE. The value 1 doesn't work.
I've submitted a bug report. Has it always been like it? If not, maybe check your projects if you've used the value 1...
I've run some tests for my problem with the parallax scrolling layers after going to my Pause Scene OPTIONS MENU.
I find that once I return from my OPTIONS SCREEN, the parallax layers are no longer updating their self.Position.X values.
I've added a Display Text behaviour to my layers, and when I first load the game, they show the self.Position.X attributes updating every frame as the layers whiz along to the left.
After I go to the OPTIONS MENU (which has a Pause Scene behaviour) and then return to the Main Menu, the parallax layers are no longer updating. They keep moving to the left, but the layers show their self.Position.X attributes as unchanging.
Hence, they move off the screen to the left, but never reset to their start positions. They just keep going and never come back.
Likewise, there's a SHOP button on the Main Menu.
All that happens when you click it is that it changes the MenuState attribute to "2", that causing the camera to shift to another part of the scene and show the shop.
It works fine, as it always has. But once you've gone to the OPTIONS MENU and back again, clicking on it does not change the MenuState attribute to 2. It is just stuck on 1.
So there seems to be a problem with attributes in general once going to the OPTIONS MENU, which may be related to using the Pause Scene behaviour, judging from what others are saying above.
Also, I find that some scene changes do not show a LOADING WHEEL, and hence it looks as if it's crashed. It just shows a frozen screen until the scene is loaded.
The "crash-like" sensation of this is exacerbated by the rather extended loading times being experienced with 11.0.6.
I also get a weird problem where, when I go into a character actor, for example, I get a popup appearing saying "Is this an image sequence?" over and over again. Whether I click YES or NO (many times) to get rid of the boxes, they come back again over and over, the next time I open up the same actor.
This seems to be the case for every image that appears in an Animation behaviour.
And it seems to recur over and over again, every time the actor is opened.
To be honest there have been issues with pause going back a year now. I couldn't use pause for one of my games because it was screwing up multitouch. I reported it back then and nothing was done. Maybe now that the problem is bigger now they will finally address it. I agree with the general consensus, fix all the issues, including memory problem before you release 11. We waited this long let's get this release virtually bug free. Having the RC and the nightly helps people get by until these issues are fixed. Don't be in a rush, keep working it until you get it rights! Maybe for the first time we can have a very stable creator version. This would be a huge first and a milestone for gamesalad.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
I've reported a series of bugs with my project included with steps to reproduce. All the best having a look at the issues. And I look forward to the next release candidate! Cheers.
I'm kinda glad I'm not the only one having issues with the Pause functionality!
QS
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io
Well, that's jumping to conclusions - you might still be going crazy
Awesome! I was going crazy thinking I might not be going crazy!
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io
Yes. Please, please, please don't pull the trigger early on the next stable and leave us wanting. Fix the Pause bug, fix the load times and odd loading wheel issue here and there. Of course it isn't going to be 100% bug free, but it is very close to being very stable and usable.
I disagree. I can't load any scene on iOS in this project. So for me, it's a game breaking build.
Shadows Peak is an atmospheric psychological horror that explores the dark side of a player.
@quantumsheep Best put in a "crazy" report!
I reported before that my images were screwed up see image below, and they are in preview but on the actual device there all fine.
11.6 looks like 11.5 in preview but on device they look correct like 11.3 publishing with 11.6, and I did use tinying on these images.
except the alpha looks like 11.5 which is correct "angel and airship".
So what I'm saying is images on device using 11.6 are correct.
and Load time between scenes is 6-8 seconds more the 11.03, may not seem like a lot but on my flappy clone thats forever.
Send in a report to Game Salad and include your project. It's the best way for them to diagnose the cause of the problem, and fix potential issues. It'll help all of us out if they can effectively address bugs.
The extended load times are a deal breaker for me. Lets make this stable build count!
(I've Posted this on the latest annoucement, thought it was more appropriate! now can't delete this comment, D'oh!!)
Hey guys,
Has anyone noticed the GS logos (Iterations of app icon sizes) being added to the build of apps published from a nightly/candidate build?
when you install your adhoc app on your phone, the GS logo displays WHILST the app is downloading because of a 'image.xassets' folder full of GS app icons being added to the build, then once the app is downloaded, it reverts to YOUR app icon.
This is a pressing issue for me, i don't want customers to see the GS logo... am i being stupid and it'll be removed on the stable build or will users not see this once it's downloaded from the appstore?
Many thanks!
Josh
If you are not aware of this I ask "Where have you been?" I am shocked to the core that this glaring bug reported by just about everyone on here and discussed at length in the forums draws a blank from you @BlackCloakGS ??? Honestly are you joking? Honestly?
I reported the bug, made a video, reported it again, posted the video in the forums - and you seem to have no idea about the most glaring bug in GameSalad?
This is sad.
I have experienced the bug many months ago. I can't remember if I wrote in an official report. If someone could write up an official bug for it in the bugbase, that would be great.
From memory, the issue can be worked around by unlocking the instance from the prototype, then closing and re-opening Game Salad, and the link between the instance and prototype is appropriately disconnected.
Ideally, it should just break the connection properly without having to quit and re-open.
But suffice to say, Game Salad need to know specifically what the issue is, and steps to reproduce it. They can't just guess what the problem is. I know it's a bit of a hassle to write it up. But if we can get all the bugs into the database, Game Salad can get onto fixing them.
Rock on.
From memory, you make an actor, drag say, three instances of it out into the scene, then unlock the instances from the prototype.
Then, when trying to adjust the individual attributes of the actors, it behaves as though they have not been unlocked - as if you're editing the prototype itself. The unlocked instances don't act as if they've been unlocked.
But if you quit Game Salad and open the project again, the unlocked instances are correctly broken off and behave as you would expect - where you can edit each one individually, and give them unique attribute values, etc.
The expected/desired result would be that as soon as you unlock the actors, they should be editable individually.
Is that correct @matarua ?
I'm just going from memory!
Reported it, been working around it ever since. I can deal with that known thing for now. Quit and restart fixes it. Unlock and revert fixes it. Do that a lot to get things working well. There's some bad memory leak in GameSalad too that cripples it. Best to quit and restart quite regularly.
I demonstrated my first experience of this months ago, November 2013 (reported the bug), it's worse than just your preview code of a certain instance not obeying the prototype.
You see with this that copied actors that are prototypes are not really prototypes either?
The issue of non-updating instances is so widespread I am sure I don't need to demo that too, am I right?
A prototype is not a prototype and an instance is not an instance nor is it an instance of a prototype. That's the bug. It seems to be with the preview view of code in some situations, and with the actual code in others.
Black screens appear for many seconds on Android devices following the close of Revmob ads.
This will continue to happen?
I think you are confusing things here, the issue is that the instances lose their connection with the prototype when they are not unlocked, for instance drag 20 copies of an actor onto the scene, then change the colour of the prototype from its default white to red . . . . now look at the instances in the scene they are all still white.
Quitting and restarting doesn't always fix the problem, nor does the unlocking / reverting trick.
Again I think the point being made here is getting missed, people have been sending in bug reports, often detailed bug reports with videos and example projects and so on, and still the bugs turn up month after month and - worryingly - GameSalad still seem entirely unaware of some issues that have been reported and discussed extensively.
I honestly don't think that's the case, I'd say the best way is to try and raise the issue on the forums, get enough people to join in with discussing the issue and you can often attract GameSalad's attention - once interested they can be pretty quick when it comes to fixing bugs, but historically the bug reporting system has been very hit and miss, to be honest I've not used it for years, but from the reports I've seen it doesn't seem much different to how it's always been.
My experience of the GameSalad bug reporting system has been this:
If you can provide steps to accurately and consistently reproduce the bug, they acknowledge it generically ("Thank you for reporting this issue" etc.) and at some point in the future it may or may not be fixed.
If the bug is something that happens in circumstances you cannot reproduce (such as the the bug that's still in this latest RC where it's hit or miss if images added to a project will show up in the image browser), and if you can't provide steps to consistently reproduce it, then the assumption is you are wrong.
There's definitely a lot of sand in the GameSalad offices that makes frequent cranial contact.
Love you all anyway
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support