Problem with change table cell value

sawkastee

My change table cell value rule only works 80% of the time. I'm running GS rc 11.0.8

Deck of Cards exercise app, each card suit (spade, club, diamond, heart) is a different exercise. When a button is pressed I display a random card from the deck. Card value is number of reps and suit is exercise. I'm trying to write the card exercise to a table based on the card displayed, (for a history/log scene). My rules:

Scene Loads
I randomize 1 column in table containing all 52 card's with @tatiang‌ demo here:
http://forums.gamesalad.com/discussion/53553/demo-randomize-table-rows
The column I randomize is the card's unique code e.g. c4 is 4 of clubs, d14 is ace of diamond, etc.

Button Actor
When touch pressed
Change Attr - game.CardRow to game.CardRow +1
Change Attr - game.CurrentCardCode to tableCellValue( game.TBL_Cards , game.CardRow ,5)
Spawn the card actor

Rule when all valid
Attr - game.CurrentCardCode contains "d"
Change table cell table - Cards, row game.CardRow, col#, value game.DiamondExercise

Rule when all valid
Attr - game.CurrentCardCode contains "s"
Change table cell table - Cards, row game.CardRow, col#, value game.SpadeExercise

Rule when all valid
Attr - game.CurrentCardCode contains "h"
Change table cell table - Cards, row game.CardRow, col#, value game.HeartExercise

Rule when all valid
Attr - game.CurrentCardCode contains "c"
Change table cell table - Cards, row game.CardRow, col#, value game.ClubExercise

I have another button that takes user to the History/Log scene.
When touch is pressed Save table TBL_Cards
Timer after .2 sec change scenes to History/Log scene.

I expect there to be a game.Exercise in every row of the table but sometimes it displays sometimes it's blank. Any ideas on why this isn't working?

Hopscotch

@sawkastee, when you are saying "sometimes it displays sometimes it's blank" that the table is not updated?

I am investigating a problem also where certain "change table values" very seldom and randomly get dropped, even if the behaviour is wrapped in a "after 0 seconds timer".

Behaviours before and after get executed but the table does not get updated.

Also using 11.0.8 (now 9)

Maybe @CodeWizard / @BlackCloakGS can shed some light as to how the table behaviours run, inline (that is to say with the normal flow of the code) or spawned off like timers, etc.?

Because I notice the problem most often when multiple actors change the table (different rows mind you) in one code cycle.

sawkastee

@Hopscotch said:
sawkastee, when you are saying "sometimes it displays sometimes it's blank" that the table is not updated?

That's correct.

To me seems like the "change table cell value" behavior has a bug in it??? IDK, I've tried changing the behavior to use an attribute or text expression and I get the same results, I cannot find a pattern. I've even tried placing massive wait times in my rules to ensure they have time to execute but still no luck. Since posting this thread I've also started using 11.0.9 and I have the same results.

I'm not that good with GS so I haven't reported a bug as it could be user error.

Hopscotch

@sawkastee, have you used a display text or the "log debugging statement" to make sure that the attributes have the right value before updating the table?

sawkastee

@Hopscotch said:
sawkastee, have you used a display text or the "log debugging statement" to make sure that the attributes have the right value before updating the table?

No I've never used the debug statement before. I'm not sure what to do with it?

Hopscotch

In the top menu under "View" you will find the Debugger.

You can output any description, Attribute or Expression to this Debug Window to follow your code as it runs by including "log debugging statements" in your actors.

sawkastee

@Hopscotch said:
In the top menu under "View" you will find the Debugger.

You can output any description, Attribute or Expression to this Debug Window to follow your code as it runs by including "log debugging statements" in your actors.

I'm at my day job, I'll try tonight.

Hopscotch

@sawkastee, I did a stress test on the change table behaviour and it seems to behave as expected, the problem I have noticed appears to be something else, as described below.

@CodeWizard, @BlackCloakGS, please give us a peek under the hood of GS.

Do behaviours wrapped in a timer behaviour run in a separate thread? Is it possible that between a "get table value" and a subsequent "change table value", a different actor with similar behaviours can intercut the sequence if both fire at the same time?

e.g.

2 actors with following behaviours

get table value
add +1 to value
change table value

table value starting as 0 could lead to:

actor 1 gets value
         actor 2 gets value
actor 1 adds +1 and does a change table
         actor 2 add +1 and does a change table

The expected result would be a value of 2, but in this case it would be just 1

ForumNinja

@Hopscotch, It looks to me like the actors could both be grabbing the value at the same time and then when they change the table value they're just both changing it to 1.

That being said, I've tried making a project (RC 11.0.9) to create the issue you're having and was unable to. I tried putting the 2 Actors in timers to cause them to act at the same time and separate times and every time I get the result of the table value being 2.

I've included my little test project (it's at the point after I added the timers). Feel free to check it out and let me know if I was trying to do it incorrectly!

The_Gamesalad_Guru

It's never a good idea to have separate blocks of code trying to write to the same attribute at the same time. You need code in there that orders when each element writes to that attribute.

Hopscotch

Thanks @AlexSalad, I did a similar stress test without being able to break GS

Well aware of it @The_Gamesalad_Guru, it is a hypothetical situation, trying to get a answer from the GS Team as to how GS behaves under these situations.

From tests it seems that the linear execution can be relied upon to handle these concurrent processes safely. To the contrary, some other behaviours, notably timers, predict potential problems. A little like the particle/wave paradox of light.

So, it would be nice if the GSTeam explain a little as to how timers behave, since once spawned they seem to run parallel to the rest of the code.