@hardkraft said:
OK, take my original project and remove the very top display. Now you’ll see that no displays inside the rule ever get triggered. Does that make sense?
It makes perfect sense.
The rule will only display the text if var1 = 1 and it changes from 0 to 1 back to 0 so fast you never see it, thats way when you have the top display working it only shows 0.
@BBEnk said:
The rule will only display the text if var1 = 1 and it changes from 0 to 1 back to 0 so fast you never see it, thats way when you have the top display working it only shows 0.
Then is this what’s happening:
var1 set to 1
rule var1=1 triggered
log displays 1
display inside the rule displays 1
var1 set to 0
display goes blank (why?)
Or do you mean that it changes so fast that the rule never gets triggered. But it does, the logs from inside the rule say so.
In my experience GameSalad executes in essentially random order. Typically it will run top to bottom, but it will not always. And when it doesn't, it won't necessary execute in exactly the same order twice in a row. It's very frustrating. Ultimately, if you have something that has to be executed last, put it in a 0 second timer, or makes its execution dependent on previous rules/behaviours completing first (i.e. when var1 =/= 0).
In essence, whenever possible GameSalad executes behaviours in parallel, not in serial. At least that's what I've experienced.
I would LOVE GameSalad to add a new kind of group that executes behaviours strictly in order when they're placed inside the group.
@Armelline said:
In my experience GameSalad executes in essentially random order.
Thanks, now I know I’m not going crazy I think GS builds some sort of recursive tree of execution which is not sequential order that you see on the screen. I think this messes up other things as well. I suspect that’s why touch/press gives unexpected results when want it to trigger just once per touch.
@hardkraft said:
Thanks, now I know I’m not going crazy I think GS builds some sort of recursive tree of execution which is not sequential order that you see on the screen. I think this messes up other things as well. I suspect that’s why touch/press gives unexpected results when want it to trigger just once per touch.
I vaguely recall a GS staff member posting in the past explaining that GS executes each behaviour as quickly as it can, and this means sometimes behaviours lower down the list get executed before ones higher. I can't find the link right now but I went through exactly the head scratching you are going through. If you come from a programming background, GameSalad's ways of doing things can be very... weird at times.
rule if var = 1
log debugging var1 = 1
display text var1 = 1
change var1 attribute to 0
log debugging var1 = 0
thats is correct and it all happens BUT it all happened in 1 frame so you never see it because on frame 2 var1 = 0.
and by frames I mean Frames per second aka 60 FPS your code all executed on frame 1 which is why a timer will show the displays because they happen on different frames.
@Armelline, so what you’re telling me, don’t overthink it, go with the flow. It’s tough for a programmer
Thanks, for the 0sec trigger tip. GS could a cool platform if not for the need of all the tips/workarounds like this. I started on a simple, I thought, project and it’s been a workaround after workaround.
@Armelline said:
I vaguely recall a GS staff member posting in the past explaining that GS executes each behaviour as quickly as it can, and this means sometimes behaviours lower down the list get executed before ones higher. I can't find the link right now but I went through exactly the head scratching you are going through. If you come from a programming background, GameSalad's ways of doing things can be very... weird at times.
I have games dependent on Gamesalad running in the correct order and it's never been a problem for me.
@BBEnk said:
I have games dependent on Gamesalad running in the correct order and it's never been a problem for me.
Normally it will. But not always. It's probably the case that correct order doesn't actually matter in your game. 99.9% of the time it won't, even if you think it will.
A good example of when it does matter is in @RThurman's layers demo, and he has to use a 0 second timer in that to ensure the necessary operations are completed before the dependent ones are executed.
@hardkraft said:
Thanks, for the 0sec trigger tip. GS could a cool platform if not for the need of all the tips/workarounds like this. I started on a simple, I thought, project and it’s been a workaround after workaround.
Yeah GameSalad frustrates programmers a lot Sometimes it's WAY faster to get something done in GameSalad, sometimes it's slower. But mostly faster :P
FYI we do not guarantee order of execution of actions or behaviors except when in a timer is set to run to completion. You can set up dependance with while predicates.
@BlackCloakGS said:
FYI we do not guarantee order of execution of actions or behaviors except when in a timer is set to run to completion. You can set up dependance with while predicates.
Any chance of getting a group we can put things in that WILL guarantee order of execution? Then we have the best of both words. Fastest execution by default, but the ability to specify order easily when we need it.
@BBEnk said:
thats is correct and it all happens BUT it all happened in 1 frame so you never see it because on frame 2 var1 = 0.
Thank you.
What I think you’re saying is that the rule triggers and does everything inside but on the next frame it undoes all that. So if I were to spawn an actor it would get spawned but then destroyed by itself on the next frame. Do I understand you right?
If that’s what’s going on then it’s very confusing. Especially that the concept of frames never gets mentioned.
Armelline
Normally it will. But not always. It's probably the case that correct order doesn't actually matter in your game. 99.9% of the time it won't, even if you think it will.
Oh, it matters and works perfect even if @BlackCloakGS can't guarantee it.
OK, I did another test maybe it will help someone. I put a timer around the attr change to 0. The 0sec timer did not change anything. 1sec timer would output the correct value of 1 to the screen and then, behold, it would erase it after 1 sec.
Then I added a spawn in the same rule. The screen would blank out just as before but the actor would not get unspawned. The actor would still get spawned even with no timers, so the changing var1 is no problem for that, but it seems that the text is some special case.
So maybe in this case it’s not the order of execution that’s the issue but the unexpected behavior of the text box.
@BBEnk said:
No, it just runs the rules and thats it, nothing is undone.
It looks like it does get undone, see my post above, but it happens only to text boxes. It seems like the text boxes have some sort of a timer inside of their own. Still don’t quite understand it, I guess I’ll just have to accept it.
it's because your display text is in a rule that says you var1 must be 1 before I can display and when it change to 0 it stops working, put your display text outside the rule and it will show 0 , 1, 0..
@BBEnk, yes, but I added spawn inside the rule too so spawning an actor should work only as long as the rule is valid too. I see spawning text (putting it in a text box) analogous to spawning an actor. Once it’s displayed it should stay displayed unless I erase it or replace it with something else. But clearly the rules are different for text.
@hardkraft said:
BBEnk, yes, but I added spawn inside the rule too so spawning an actor should work only as long as the rule is valid too. I see spawning text (putting it in a text box) analogous to spawning an actor. Once it’s displayed it should stay displayed unless I erase it or replace it with something else. But clearly the rules are different for text.
Yes, display text is only active as long as the rule it's in is active. It's actually much more flexible this way, but is a little counter-intuitive at first.
@hardkraft said:
yes, but I added spawn inside the rule too so spawning an actor should work only as long as the rule is valid too.
Right the spawn BEHAVIOR will only work when rule is valid and it will spawn a actor at that time.
But the actor it spawns is not part of the rule so it stays on screen.
I see spawning text (putting it in a text box) analogous to spawning an actor. Once it’s displayed it should stay displayed unless I erase it or replace it with something else. But clearly the rules are different for text.
your not spawning text your only displaying it which is why it goes away when rule changes to 0 its in the rule, it not a actor.
@BBEnk, I would expect text box to behave like any other repository of text for example a string attribute. When I put some text in a string inside a rule that text will still be there even when the rule no longer applies. Obviously text boxes are a different animal and it’s not explained anywhere how different.
Comments
It makes perfect sense.
The rule will only display the text if var1 = 1 and it changes from 0 to 1 back to 0 so fast you never see it, thats way when you have the top display working it only shows 0.
Then is this what’s happening:
Or do you mean that it changes so fast that the rule never gets triggered. But it does, the logs from inside the rule say so.
In my experience GameSalad executes in essentially random order. Typically it will run top to bottom, but it will not always. And when it doesn't, it won't necessary execute in exactly the same order twice in a row. It's very frustrating. Ultimately, if you have something that has to be executed last, put it in a 0 second timer, or makes its execution dependent on previous rules/behaviours completing first (i.e. when var1 =/= 0).
In essence, whenever possible GameSalad executes behaviours in parallel, not in serial. At least that's what I've experienced.
I would LOVE GameSalad to add a new kind of group that executes behaviours strictly in order when they're placed inside the group.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
It does trigger but all in the same frame so you never see it happen.
Thanks, now I know I’m not going crazy
I think GS builds some sort of recursive tree of execution which is not sequential order that you see on the screen. I think this messes up other things as well. I suspect that’s why touch/press gives unexpected results when want it to trigger just once per touch.
@BBEnk: maybe it would be clearer to me if you listed the sequence of statements that get executed line by line the way I did. Thanks.
I vaguely recall a GS staff member posting in the past explaining that GS executes each behaviour as quickly as it can, and this means sometimes behaviours lower down the list get executed before ones higher. I can't find the link right now but I went through exactly the head scratching you are going through. If you come from a programming background, GameSalad's ways of doing things can be very... weird at times.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
OK one last time.
var1 = 0
display text var1 = 0
change var1 attribute to 1
rule if var = 1
log debugging var1 = 1
display text var1 = 1
change var1 attribute to 0
log debugging var1 = 0
thats is correct and it all happens BUT it all happened in 1 frame so you never see it because on frame 2 var1 = 0.
and by frames I mean Frames per second aka 60 FPS your code all executed on frame 1 which is why a timer will show the displays because they happen on different frames.
@Armelline, so what you’re telling me, don’t overthink it, go with the flow. It’s tough for a programmer
Thanks, for the 0sec trigger tip. GS could a cool platform if not for the need of all the tips/workarounds like this. I started on a simple, I thought, project and it’s been a workaround after workaround.
I have games dependent on Gamesalad running in the correct order and it's never been a problem for me.
Normally it will. But not always. It's probably the case that correct order doesn't actually matter in your game. 99.9% of the time it won't, even if you think it will.
A good example of when it does matter is in @RThurman's layers demo, and he has to use a 0 second timer in that to ensure the necessary operations are completed before the dependent ones are executed.
Yeah GameSalad frustrates programmers a lot
Sometimes it's WAY faster to get something done in GameSalad, sometimes it's slower. But mostly faster :P
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
FYI we do not guarantee order of execution of actions or behaviors except when in a timer is set to run to completion. You can set up dependance with while predicates.
Any chance of getting a group we can put things in that WILL guarantee order of execution? Then we have the best of both words. Fastest execution by default, but the ability to specify order easily when we need it.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Thank you.
What I think you’re saying is that the rule triggers and does everything inside but on the next frame it undoes all that. So if I were to spawn an actor it would get spawned but then destroyed by itself on the next frame. Do I understand you right?
If that’s what’s going on then it’s very confusing. Especially that the concept of frames never gets mentioned.
Oh, it matters and works perfect even if @BlackCloakGS can't guarantee it.
No, it just runs the rules and thats it, nothing is undone.
No. it would stay.
@Armelline that would be a great feature request to add submit to our public bug database
OK, I did another test maybe it will help someone. I put a timer around the attr change to 0. The 0sec timer did not change anything. 1sec timer would output the correct value of 1 to the screen and then, behold, it would erase it after 1 sec.
Then I added a spawn in the same rule. The screen would blank out just as before but the actor would not get unspawned. The actor would still get spawned even with no timers, so the changing var1 is no problem for that, but it seems that the text is some special case.
So maybe in this case it’s not the order of execution that’s the issue but the unexpected behavior of the text box.
It looks like it does get undone, see my post above, but it happens only to text boxes. It seems like the text boxes have some sort of a timer inside of their own. Still don’t quite understand it, I guess I’ll just have to accept it.
@hardkraft
it's because your display text is in a rule that says you var1 must be 1 before I can display and when it change to 0 it stops working, put your display text outside the rule and it will show 0 , 1, 0..
Added!
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
@BBEnk, yes, but I added spawn inside the rule too so spawning an actor should work only as long as the rule is valid too. I see spawning text (putting it in a text box) analogous to spawning an actor. Once it’s displayed it should stay displayed unless I erase it or replace it with something else. But clearly the rules are different for text.
Yes, display text is only active as long as the rule it's in is active. It's actually much more flexible this way, but is a little counter-intuitive at first.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Right the spawn BEHAVIOR will only work when rule is valid and it will spawn a actor at that time.
But the actor it spawns is not part of the rule so it stays on screen.
your not spawning text your only displaying it which is why it goes away when rule changes to 0 its in the rule, it not a actor.
@BBEnk, I would expect text box to behave like any other repository of text for example a string attribute. When I put some text in a string inside a rule that text will still be there even when the rule no longer applies. Obviously text boxes are a different animal and it’s not explained anywhere how different.