owen_dennis this bug has just been ignored. Ive tried to follow up on it with GS staff but they just don't respond. You can track the bug here but they don't update or respond to n otes on it so why bother!
I certainly would wait for it to be fixed. It was logged as a bug in Aug of last year and still hasn't been fixed (or if it has, it was never announced or updated and I dont update tables this way anymore. Like the rest of the bugs in GS, we just find a work around and apply that).
To help you get past this, you have to change all your table references into global attributes. You simply can't update tables like this or your game will crash. To clarify, you can't update a TableCellValue (TCV) with a TCV+1 or any other value. You can update a TCV with a fixed value but not as a TCV+1. You can update a global attribute with an integer+1 and no memory leaks occur. Solving the issue but you will need to change the way your game works and use attributes and not tables.
Depending on your game this will be a short or an extensive task. For my game it was a days work as I had a lot of table references to it. But that 1 days work saved me waiting on a fix for something that isn't even monitored and now a year has passed since they acknowledged it and promised a fix in 0.12 and then 0.13.
Wow, I would think this would be a priority fix! I've only just come across this myself!
Could we all rally together to get this fixed! Let's make some noise guys
owen_dennisJust a guy, you know.Member, PROPosts: 236
edited July 2015
Well this is all good to know. I'm going to go through my game and try to find every instance where I've done TCV+whatever and change it and see what happens. Hopefully this will fix my crashing problem and the memory leak between scene changes will be fixed soon as well.
@mc99093 said:
gingagaming Would this cause a leak ... TCV+(random 30,200). Also does the leak occur when you do a TCV-1 as well?
Yes this will indeed cause the leak. Both examples. Its when you have to refer back to a TCV and then do something with that value (like add or subtract it)
@supafly129 said:
Does this mean that changing table values (Boolean or integer) causes memory increases? Or is it ONLY when tables are self referenced?
The bug we encountered was specifically related to self-referencing. That's not to say there aren't other issues, though.
Can someone post actual Instruments results for this self-referencing table problem?
I have tried to recreate it every way possible,
LARGE tables,
referencing itself or other tables 1000s of times,
on text and numeric values,
within left side rule expressions,
checked against using a mediator attribute ... no leak.
Please post results or proof if you have some, otherwise we are wasting @BlackCloakGS 's precious time on the wrong stuff.
If you are experiencing crashes related to tables, it is much more likely that it is a code problem. For example, a row being referenced that does not exist.
@Hopscotch said:
Please post results or proof if you have some, otherwise we are wasting BlackCloakGS 's precious time on the wrong stuff.
It's entirely possible it's already been fixed, as was noted at the start of the discussion about it. This was a while ago this problem was encountered. We confirmed at the time that it was the self-referencing causing the problem, and that removing it fixed the problem. (Using both instruments and process of elimination.) If you're unable to reproduce it now, then the problem was probably fixed.
owen_dennisJust a guy, you know.Member, PROPosts: 236
edited July 2015
@Hopscotch said:
Can someone post actual Instruments results for this self-referencing table problem?
I have tried to recreate it every way possible,
LARGE tables,
referencing itself or other tables 1000s of times,
on text and numeric values,
within left side rule expressions,
checked against using a mediator attribute ... no leak.
Please post results or proof if you have some, otherwise we are wasting BlackCloakGS 's precious time on the wrong stuff.
If you are experiencing crashes related to tables, it is much more likely that it is a code problem. For example, a row being referenced that does not exist.
I don't think that would explain why the game crashes after it's open for awhile. If it was some new actor or rule within an actor that references a bad cell, you'd be able to test that actor or rule. I've seen all of my actors on screen they've all fired all their rules and the game hasn't crashed. The only correlation I've been finding is that it appears to happen after my game has been playing for about 5-6 minutes and I've watched the RAM usage slowly go up and up. Doesn't seem to matter what I'm doing at the time or where in the game I am.
My game has a whole lot of images, so I was thinking that's where it was hurting. I changed all my images to be non-retina and it still crashed, it just took longer. That's why I was starting to assume it had something to do with memory dumping.
@Hopscotch said:
Specifically related to memory issues. I only rely on Ad Hoc builds when testing my games. An Ad Hoc is exactly what the client will see and play.
All this stuff has been happening in my ad hoc build and my viewer.
I left my ipad at my gf's house, so I'll have to wait until I get it back to show what happens. Might not be until the end of the week, so I can't post a video or anything right now. :-/
When I get it I'll start a new thread on it, unless this one is still going strong about the issue.
These are just the patterns I've been seeing. I could also be totally wrong about everything, cause what do I know really?
If you are experiencing crashes related to tables, it is much more likely that it is a code problem. For example, a row being referenced that does not exist.
This I suspect is the issue. In my recent multiplayer testing i ran across this a lot as the tables rely on the player ID and such to reference the proper table as well as table row/column info. Addressing a zero row/column causes crazy weird issue.
@Hopscotch said:
Can someone post actual Instruments results for this self-referencing table problem?
Like @Armelline has stated above, this was an old bug we worked on and according to the bug report filed for it, it has never been fixed. But as the bug system is poorly monitored, it may have been fixed and never updated. Who knows.
Since this bug was filed a year ago, I personally have never referenced a table like this since so I don't know if its present or not.
Please post results or proof if you have some, otherwise we are wasting BlackCloakGS 's precious time on the wrong stuff.
I seriously doubt we are wasting @BlackCloakGS time here, like I mentioned before, the bug has gone unmonitored and not updated for some time. I don't think he is looking at it at all. If he is then I'm sure he will update us all and add his comments to the bug report.
Hopefully its just an oversight and it was fixed but without me digging out my old project and carrying out some tests I cannot confirm or deny that it was.
If you are experiencing crashes related to tables, it is much more likely that it is a code problem. For example, a row being referenced that does not exist.
I agree, this is a major thing in GS, referencing a row or column that doesn't exist causes outright crashes. Unfortunetly, this wasn't the issue with the bug at the time when myself and @Armeline worked on this particular project. It was a GS bug that was causing it. One which according to the bug report (that was merged several times) was never fixed, hence both mine and Armelines comments enquiring if it was ever fixed or not.
@gingagaming, yep, would be nice to have confirmation either-way. Yes, I am positive that @BlackCloakGS is on top of thing. I also know that GS myths tend to hang around. If the forum keeps pointing at old issues without re-evaluating them, it will still cause @BlackCloakGS or QA to have to revisit them and this takes time.
@owen-dennis, I just often see that especially in large, table spawned games (which more likely than not have complex rules and random conditions for building the levels), there are often some rare events where some attribute is not set right, causing the illegal referencing of a row or column.
As a test, I just played @Hymloe's complex game for a full 30 minutes, dozens of levels, total memory rollover of over 7 Gigs. Although there was a slight memory increase over time, it had no spikes, no crashes. Live allocated memory cycled between 90Mb and 130Mb. After spending hours on this today, testing projects and building specific test cases, to me, it looks like the current GS version is in a fairly good place.
There definitely are still issues, although I think that the major ones are now probably due to memory fragmentation in projects using large images. This is something that may happens in any dev tool. The new rendering engine, with big continuous image blocks, will probably eliminate this.
Contrary to popular belief we're not ignoring this issue, we talk about it often, and I was even all set to look at it today but something else I was working on took longer than I thought it would.
It's a complex issue or it would have been fixed already, and I'm happy to spend some time on it to try and figure it out, but if I don't have a good way to test it then it's going to take longer.
@The_Gamesalad_Guru said:
This I suspect is the issue. In my recent multiplayer testing i ran across this a lot as the tables rely on the player ID and such to reference the proper table as well as table row/column info. Addressing a zero row/column causes crazy weird issue.
Similar to what @owen_dennis mentioned, my game crashes after playing the game for a while, and it seems to always occur during a scene change so I'm pretty sure it's memory related (especially since my game has some large images).
Unfortunately I was unable to get instruments to work to test memory spikes, but I did test creating a rule to destroy every actor before the scene changes, which seemed to help prevent early crashes, but it could also be a coincidence.
@GeorgeGS said:
Contrary to popular belief we're not ignoring this issue, we talk about it often, and I was even all set to look at it today but something else I was working on took longer than I thought it would.
It's a complex issue or it would have been fixed already, and I'm happy to spend some time on it to try and figure it out, but if I don't have a good way to test it then it's going to take longer.
@GeorgeGS would you like specific proj files that are reporting the crashes discussed to test this out?
@supafly129 I am looking for specific cases of the reported memory leak issue. The smaller and simpler the better. If it's hard for me to use to duplicate and narrow down the issue then it probably isn't super helpful.
I'm not looking for "I think my game crashes because of memory" without any research behind it.
owen_dennisJust a guy, you know.Member, PROPosts: 236
@supafly129 said:
Unfortunately I was unable to get instruments to work to test memory spikes, but I did test creating a rule to destroy every actor before the scene changes, which seemed to help prevent early crashes, but it could also be a coincidence.
I also did the destroy actor thing, but again, it only seemed to extend the inevitable.
@GeorgeGS said:
So true... I might have to find something else to work on.
Lets not think too highly of your work, there is still much to do.
Fortuna Infortuna Forti Una
owen_dennisJust a guy, you know.Member, PROPosts: 236
Wow, that's a pretty telling graph. Maybe there IS some weird thing happening in my game where it's looking for a table cell that doesn't exist somehow. I don't know how though, I've been looking at those tables and what gets updated and how for a long time now. I can't see where it could be going wrong. That or it's the image stuff that'll be fixed in 14.0.
It just doesn't seem like it's a weird rule thing, only because I've seen all my rules fire at various points in the game. Maybe I can post a crash log for some input? I don't know if that will help, I don't know how to read a crash log so I personally can't get anything from it.
Comments
Wow, I would think this would be a priority fix! I've only just come across this myself!
Could we all rally together to get this fixed! Let's make some noise guys
Potentially yes in both cases. It's the self-reference that seemed to be causing the problem.
The easiest way to test is to load your game into the viewer and watch the memory usage.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Well this is all good to know. I'm going to go through my game and try to find every instance where I've done TCV+whatever and change it and see what happens. Hopefully this will fix my crashing problem and the memory leak between scene changes will be fixed soon as well.
Vote for Nearest Neighbor Scaling option in gamesalad! Let's make our games look truly stunning!
Yes this will indeed cause the leak. Both examples. Its when you have to refer back to a TCV and then do something with that value (like add or subtract it)
Does this mean that changing table values (Boolean or integer) causes memory increases? Or is it ONLY when tables are self referenced?
POLAR ROLLOUT (New Line-Drawing Physics Puzzler!) - FREE Download
The bug we encountered was specifically related to self-referencing. That's not to say there aren't other issues, though.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Can someone post actual Instruments results for this self-referencing table problem?
I have tried to recreate it every way possible,
LARGE tables,
referencing itself or other tables 1000s of times,
on text and numeric values,
within left side rule expressions,
checked against using a mediator attribute ... no leak.
Please post results or proof if you have some, otherwise we are wasting @BlackCloakGS 's precious time on the wrong stuff.
If you are experiencing crashes related to tables, it is much more likely that it is a code problem. For example, a row being referenced that does not exist.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
It's entirely possible it's already been fixed, as was noted at the start of the discussion about it. This was a while ago this problem was encountered. We confirmed at the time that it was the self-referencing causing the problem, and that removing it fixed the problem. (Using both instruments and process of elimination.) If you're unable to reproduce it now, then the problem was probably fixed.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
That is great.
I would also like to add that the Viewer behaves differently and gives different results to an actual Ad Hoc build.
Specifically related to memory issues. I only rely on Ad Hoc builds when testing my games. An Ad Hoc is exactly what the client will see and play.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
I don't think that would explain why the game crashes after it's open for awhile. If it was some new actor or rule within an actor that references a bad cell, you'd be able to test that actor or rule. I've seen all of my actors on screen they've all fired all their rules and the game hasn't crashed. The only correlation I've been finding is that it appears to happen after my game has been playing for about 5-6 minutes and I've watched the RAM usage slowly go up and up. Doesn't seem to matter what I'm doing at the time or where in the game I am.
My game has a whole lot of images, so I was thinking that's where it was hurting. I changed all my images to be non-retina and it still crashed, it just took longer. That's why I was starting to assume it had something to do with memory dumping.
Maybe this is just a byproduct of the scene switching? That the memory wasn't dumped after the scene switch, so it makes further scenes have a bunch of stuff in the RAM that it doesn't need anymore? In the thread that I had made about it earlier I was told the problem I'm referring to was fixed in 14.0.
All this stuff has been happening in my ad hoc build and my viewer.
I left my ipad at my gf's house, so I'll have to wait until I get it back to show what happens. Might not be until the end of the week, so I can't post a video or anything right now. :-/
When I get it I'll start a new thread on it, unless this one is still going strong about the issue.
These are just the patterns I've been seeing. I could also be totally wrong about everything, cause what do I know really?
Vote for Nearest Neighbor Scaling option in gamesalad! Let's make our games look truly stunning!
This I suspect is the issue. In my recent multiplayer testing i ran across this a lot as the tables rely on the player ID and such to reference the proper table as well as table row/column info. Addressing a zero row/column causes crazy weird issue.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
Like @Armelline has stated above, this was an old bug we worked on and according to the bug report filed for it, it has never been fixed. But as the bug system is poorly monitored, it may have been fixed and never updated. Who knows.
Since this bug was filed a year ago, I personally have never referenced a table like this since so I don't know if its present or not.
I seriously doubt we are wasting @BlackCloakGS time here, like I mentioned before, the bug has gone unmonitored and not updated for some time. I don't think he is looking at it at all. If he is then I'm sure he will update us all and add his comments to the bug report.
Hopefully its just an oversight and it was fixed but without me digging out my old project and carrying out some tests I cannot confirm or deny that it was.
I agree, this is a major thing in GS, referencing a row or column that doesn't exist causes outright crashes. Unfortunetly, this wasn't the issue with the bug at the time when myself and @Armeline worked on this particular project. It was a GS bug that was causing it. One which according to the bug report (that was merged several times) was never fixed, hence both mine and Armelines comments enquiring if it was ever fixed or not.
@gingagaming, yep, would be nice to have confirmation either-way. Yes, I am positive that @BlackCloakGS is on top of thing. I also know that GS myths tend to hang around. If the forum keeps pointing at old issues without re-evaluating them, it will still cause @BlackCloakGS or QA to have to revisit them and this takes time.
@owen-dennis, I just often see that especially in large, table spawned games (which more likely than not have complex rules and random conditions for building the levels), there are often some rare events where some attribute is not set right, causing the illegal referencing of a row or column.
As a test, I just played @Hymloe's complex game for a full 30 minutes, dozens of levels, total memory rollover of over 7 Gigs. Although there was a slight memory increase over time, it had no spikes, no crashes. Live allocated memory cycled between 90Mb and 130Mb. After spending hours on this today, testing projects and building specific test cases, to me, it looks like the current GS version is in a fairly good place.
There definitely are still issues, although I think that the major ones are now probably due to memory fragmentation in projects using large images. This is something that may happens in any dev tool. The new rendering engine, with big continuous image blocks, will probably eliminate this.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Contrary to popular belief we're not ignoring this issue, we talk about it often, and I was even all set to look at it today but something else I was working on took longer than I thought it would.
It sounds like you guys are saying it might not be an issue anymore? Is this project still a problem? http://forums.gamesalad.com/discussion/comment/521671/#Comment_521671
It's a complex issue or it would have been fixed already, and I'm happy to spend some time on it to try and figure it out, but if I don't have a good way to test it then it's going to take longer.
Similar to what @owen_dennis mentioned, my game crashes after playing the game for a while, and it seems to always occur during a scene change so I'm pretty sure it's memory related (especially since my game has some large images).
Unfortunately I was unable to get instruments to work to test memory spikes, but I did test creating a rule to destroy every actor before the scene changes, which seemed to help prevent early crashes, but it could also be a coincidence.
POLAR ROLLOUT (New Line-Drawing Physics Puzzler!) - FREE Download
What issues were you having with instruments? I have a video on it if you need a reference.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
@GeorgeGS would you like specific proj files that are reporting the crashes discussed to test this out?
POLAR ROLLOUT (New Line-Drawing Physics Puzzler!) - FREE Download
@supafly129 I am looking for specific cases of the reported memory leak issue. The smaller and simpler the better. If it's hard for me to use to duplicate and narrow down the issue then it probably isn't super helpful.
I'm not looking for "I think my game crashes because of memory" without any research behind it.
I also did the destroy actor thing, but again, it only seemed to extend the inevitable.
Vote for Nearest Neighbor Scaling option in gamesalad! Let's make our games look truly stunning!
Nope, it is no longer a problem. It is even better than it was in v0.12.x, all actions in that project now behave as expected!
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
@GeorgeGS, here the tested behaviors.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
I believe that is one of the most beautiful graphs that I have ever seen!
Nope, it's ugly, it means we are running out of excuses for not producing kick-a$$ games.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Thanks for info @gingagaming @Armelline
So true!
So true... I might have to find something else to work on.
Lets not think too highly of your work, there is still much to do.
Fortuna Infortuna Forti Una
Wow, that's a pretty telling graph. Maybe there IS some weird thing happening in my game where it's looking for a table cell that doesn't exist somehow. I don't know how though, I've been looking at those tables and what gets updated and how for a long time now. I can't see where it could be going wrong. That or it's the image stuff that'll be fixed in 14.0.
It just doesn't seem like it's a weird rule thing, only because I've seen all my rules fire at various points in the game. Maybe I can post a crash log for some input? I don't know if that will help, I don't know how to read a crash log so I personally can't get anything from it.
Vote for Nearest Neighbor Scaling option in gamesalad! Let's make our games look truly stunning!
add to the list.... viewer no longer needs updating with every release.
and ill start updating.
Game Salad should take care of whatever problem may or may not be caused for me.
(I'm somewhat joking. Ideally they could either tell me what the limitation / issue is, or fix it.)