@Socks said:
Although I am still of the mind (as yet untested) that in theory multiple conditions in a single expression are going to be less efficient than nested rules (for the same reasons that nested rules are more efficient than multiple condition rule)
They're essentially the exact same thing, logic wise, and the GS staff actually confirmed they'll be (imperceptibly) faster, as they're doing the exact same thing with a little less overhead.
Also @Armelline - you missed arcsin, arccos and arctan off your list, which are all pretty useful (except maybe for arctan), they could be tagged on the end of an explanation of cos and sin and tan as they are just the inverse functions of cos and sin and tan (value returns angle, rather than angle returns value).
With so much to go over, and the need to give special attention to sin/cos etc. in much greater detail another time, I decided not to include them. I also had to scrap the text functions in the end. You'll find my coverage of sin/cos etc. very inadequate - I couldn't give them too much time and was really not very well on Thursday. I still intend a much more thorough video on them later, actually getting into the maths. (A video you're actually far more qualified to make, hint hint.)
One other question, weren't we advised a while back (last year even?) that precision was not an efficient function, as it had to convert values to text and then back to numbers (making it comparatively slow) - and that roundTo should now be used in its place ?
I look at precision specifically for that reason. If you're just wanting to do number stuff, roundTo is the way to go. But if you want to, say, take the result of a calculation and pull the 5th digit out of it, prec can be very handy specifically because it returns text not a number. It has it own special, useful place! My custom font template could actually have used prec and saved some processing, which I forgot about at the time. I'll be updating it to take advantage of that later on.
@Armelline said:
They're essentially the exact same thing, logic wise, and the GS staff actually confirmed they'll be (imperceptibly) faster, as they're doing the exact same thing with a little less overhead.
I'm going to do something weird here, without having tested it, I'm going to say the opposite ! (even with GS staff having said what they said ), I am going to say that I suspect the whole expression is evaluated even if the first condition within the expression fails, of course I could be wrong (and it needs to be tested), but that's my hunch, a multiple conditional expression will - with all other things being equal - be slower than nested rules that serve the same function when the first condition fails (in the same way that a multi conditional rule is slower than the nested equivalent when the first condition fails) . . . . speculative, needs testing, but I suspect that is what would happen.
@Armelline said:
With so much to go over, and the need to give special attention to sin/cos etc. in much greater detail another time, I decided not to include them. I also had to scrap the text functions in the end. You'll find my coverage of sin/cos etc. very inadequate - I couldn't give them too much time and was really not very well on Thursday.
Yeah, I thought with you having a cold it might be touch and go whether you managed to make the talk at all, but well done for getting through it, I would have stayed in bed !! The reason I thought you could have thrown them on the end of sin/cos was that once you know what sin/cos does you kinda' automatically know what arcsin/arccos do.
@Armelline said:
I still intend a much more thorough video on them later, actually getting into the maths. (A video you're actually far more qualified to make, hint hint.)
Lol ! Busy right now, unfortunately, very boring job making window models, job's nearly finished, maybe after then !?
@Armelline said:
I look at precision specifically for that reason. If you're just wanting to do number stuff, roundTo is the way to go. But if you want to, say, take the result of a calculation and pull the 5th digit out of it, prec can be very handy specifically because it returns text not a number. It has it own special, useful place!
Ah ! I see, yes that makes sense.
@Armelline said:
My custom font template could actually have used prec and saved some processing, which I forgot about at the time. I'll be updating it to take advantage of that later on.
On the subject of custom fonts, I found the standard method (lots of constrains) to be very inefficient, so threw together my own version . . . . which goes back to something I've always thought, that rather than having Game of the Month competition, there should be a Method of the Month competition, where a challenge is set to produce the most efficient/beautiful/fast/flexible (etc) X, so one month it might be 'How to set up a triangular collision shape', the next month might be 'Produce the custom font system with the least processor overhead', or 'The most realistic GS generated 3D planet' or 'The fastest way to spawn a grid of actors' or 'The nicest radar system for top down projects' (etc etc).
With rules ! No imported images, or no images over 512 x512, or no image sequences, or no tables, or
Basically challenges focused on individual game elements rather than complete games, this would be good in the respect that the smaller scale of individual game elements means more people could get involved, genuinely useful projects would be generated which all forum users would be allowed to help themselves to, to use in their own projects, and having 10 or 12 people argue in a thread as to the best method to generate an analog clock or functioning crane or slingshot effect would - hopefully - generate new ways to approach common game elements, it would also create a repository of 'the best way to X' discussions. For example, a very common question we've all seen is 'why does my every random seconds timer not work', so a typical challenge might be 'Produce the most efficient and flexible random timer' . . . . .
What tends to happen in threads where these questions come up is that one person answers the question from start to end, or if the thread starts with a few people pitching in it usually ends up producing an answer (and even demo) from just one person, with a competition it would be good to see 8 or 10 people battling it out with ideas for rapid table scans or circular gravity or the most realistic top dow vehicle controls - and let the best one rise to the top - at the end of the competition all project files are made available.
Of course @RThurman would need to be banned from entering.
@Socks said:
I'm going to do something weird here, without having tested it, I'm going to say the opposite ! (even with GS staff having said what they said ), I am going to say that I suspect the whole expression is evaluated even if the first condition within the expression fails
It's not. Both my testing and the Lua manual say otherwise :P The Lua manual actually specifically and explicitly says that Lua does not evaluate any more than necessary.
I think you're misunderstanding quite what is happening in both cases. The conditions are just the rules written out. You can have:
If a is true
then
if b is true
then
if c is true
then
if d is true
etc.
And you can have:
if a is true
and
if b is true
and
if c is true
and
if d is true
These are not the same thing. The conditional logic method can duplicate both, differently. It's not doing the second compared to the first. It's doing the second or the first depending on how you write it.
@Armelline said:
They're essentially the exact same thing, logic wise, and the GS staff actually confirmed they'll be (imperceptibly) faster, as they're doing the exact same thing with a little less overhead.
They referred to the following, which would give the same result:
Change Attribute self.A to "(self.B==1) and (true) or (false)"
and
Rule: If self.B=1 then
self.A=true
otherwise
self.B=false
end Rule
The above do the same, but the Rule takes slightly more resources as it has a Listener attached.
This listener is necessary however, unless the condition is only checked once in the actor.
Using a Constrain Attribute would usually also be no good as it would do the result every code cycle, as opposed to a Rule which only does it when triggered. Although there are cases where it is handy, like the examples with Display Text in your video.
Also, @Socks, lets not confuse this with a previous discussion about multi-conditional rules vs nested rules. This is where we established that if a rule has multiple conditions, that they all get evaluated (or at least impact performance), even if the first condition already is satisfied. As you suspect, the same holds true for compound rules like above.
@Armelline said:
It's not. Both my testing and the Lua manual say otherwise :P The Lua manual actually specifically and explicitly says that Lua does not evaluate any more than necessary.
I was basing the idea on that multi-conditional rules all get evaluated even if the first one fails, I just imagined that the whole expression would be evaluated, but I'm happy to be wrong !
@Hopscotch said:
Also, @Socks, lets not confuse this with a previous discussion about multi-conditional rules vs nested rules.
I've not confused the two discussions at all !! I've made a guess that if multi-conditional rules continue to be evaluated after the first condition fails (something you gave me a really good explanation of) then it might well be the case that a multi-conditional expression is also fully evaluated in the same way as the logic structure would be the same (my guess), that's all I was thinking, but like I say I'm happy to be mistaken.
@Hopscotch said:
As you suspect, the same holds true for compound rules like above.
? I'm confused now ! Lol Are 'compound rules' the same as 'multi-conditional expressions' (that is, an expression with a series of conditions/rules) - sorry, I don't actually know the correct terminology.
For clarity, my suspicion was that an expression (where you have a series of conditions in a single expression) would fall foul of the same issue that multi-conditional rules have - where the whole series of conditions are evaluated regardless of whether the first condition fails or not.
@Socks said:
there should be a Method of the Month competition
Oh cool....
where a challenge is set to produce the most efficient/beautiful/fast/flexible (etc) X
hmmm... yes....
With rules ! No imported images, or no images over 512 x512, or no image sequences, or no tables
yes!
Basically challenges focused on individual game elements rather than complete games
Yes!
with a competition it would be good to see 8 or 10 people battling it out with ideas for rapid table scans or circular gravity or the most realistic top dow vehicle controls
@Armelline said:
The Lua manual actually specifically and explicitly says that Lua does not evaluate any more than necessary.
'More than necessary' doesn't really answer anything !
In the case of multi-conditional rules (set to 'All') it is necessary that Lua evaluates all the conditions, so my suspicion can be reworded from 'I suspect that multi-conditional expressions are all evaluated, even if the first failed condition negates any further evaluation' to 'I suspect that it's necessary that multi-conditional expressions are all evaluated, even if the first failed condition negates any further evaluation'.
@Armelline said:
Both and and or use short-cut evaluation, that is, they evaluate their second operand only when necessary.
Ok, I don't know Lua at all, so cannot make any comment on that page and will take your word on it, but I take it there are exceptions to this, for example multi-conditional rules (set to All) do evaluate the second condition - even when the first has failed ?
@Hopscotch said:
However, LUA does not support this really as some other languages do. So the above are "Quasi Ternary Operations" if you want to be pedantic.
Yeah, I knew that, they are obviously quasi ternary operations, everyone knows that.
So, these quasi ternary operations, are they subject to the same limitation that multi-conditional rules are, where the whole quasi ternary operation ( ) is evaluated regardless of a failed first condition ?
Quasi ternary operations . . . just thought I would say it again.
@Socks said:
So, these quasi ternary operations, are they subject to the same limitation that multi-conditional rules are, where the whole quasi ternary operation ( ) is evaluated regardless of a failed first condition ?
Yes, the reason is that a decision tree needs to be defined for the whole operation before the real evaluation happens. This is what causes the overhead, not the individual "is x=y" bits.
@Hopscotch said:
Yes, the reason is that a decision tree needs to be defined for the whole operation before the real evaluation happens. This is what causes the overhead, not the individual "is x=y" bits.
Just as I suspected, your basic quasi ternary operation decision tree, lol
So I guess then that in some situations they might be less efficient than the same set of conditions set up as nested rules (where I am going to guess a decision tree is still defined, but only needs accommodate the first condition) ?
Lol I can think of loads of questions that come up from time to time, that would be good to hammer out in a competition like this, how to detect line of sight (I liked your fire-out-a-bunch-of-particles solution), how to pass information between two colliding actors, how to simulate water, how to defocus/blur an image in real time . . . and recent examples like how to roll an oval along the ground . . and so on. . . . be good to see 6 solutions from different approaches.
In this demo project A = B, but not C or D. C = D, but not A or B. Each pair are going to be converted into the same code when the project is compiled. What would make B more efficient than A, or D more efficient than C?
I was happily following this thread until about halfway down the second page... then it just got so technical that it became a blur of words...
Then @Armalline dropped in a demo to help bring it all back into understandable territory....
Agree with earlier comment though that @Socks should do a GameSalad meet up to show what funky stuff can be done with sine and cosine and stuff... if only to see what crazy stuff he would come up with...
@Armelline said:
What would make B more efficient than A, or D more efficient than C?
Cheers for the demo ! Very useful.
The question is surrounding multi-conditional expressions (or I have always called them 'quasi ternary operation decision trees' ) vs nested rules, so A vs B is the relevant comparison here.
We know that the nested rules version stops evaluating the nested conditions once (and if) the first condition fails (whereas the multi-conditional rule evaluates all conditions regardless of the initial condition failing), the question is whether the multi-conditional expression equivilent would do the same given that as Hopscotch says: "a decision tree needs to be defined for the whole operation before the real evaluation happens"_
(Hopscotch explained this to me in detail a while back, but I can't find the PM now!)
Also, I don't know my way around multi-conditional expressions enough to really understand your '(( self.A ==1)and(( self.B ==2)and(( self.C ==3)and("Yes!")or("No3"))or("No2"))or("No1"))' expression, so perhaps it is circumventing the need to evaluate the whole operation for all I know ?
@Hopscotch said:
Yes, the reason is that a decision tree needs to be defined for the whole operation before the real evaluation happens. This is what causes the overhead, not the individual "is x=y" bits.
This would make sense as that tree is one logic structure and need to be viewed as a whole. Do other languages handle that differently?
Also can we confirm that multiple conditions are in matching order to the rule in the background? As we know GS doesn't adhere to a strict order of events.
@Socks said:
The question is surrounding multi-conditional expressions (or I have always called them 'quasi ternary operation decision trees' ) vs nested rules, so A vs B is the relevant comparison here.
A and B are both nested rules. C and D are both multi-conditional rules. So you're trying to compare two of the same things while giving them different names. In the case of comparing two things, then yes one will be faster. A will be faster than C or D, which is the comparison you seem to be trying to make.
@Chunkypixels said:
I was happily following this thread until about halfway down the second page... then it just got so technical that it became a blur of words...
All you need to know is that someone, somewhere, is growing pseudo nested quasi ternary operational decision trees.
@Chunkypixels said:
Agree with earlier comment though that Socks should do a GameSalad meet up to show what funky stuff can be done with sine and cosine and stuff... if only to see what crazy stuff he would come up with...
Thanks for the vote of confidence ! I was actually playing around with mapping actors/images to a spherical surface, maybe a 'build your own planet' type tutorial as the basis for explaining some of that stuff - the actual maths involved is fairly straightforward, just a single constrain behaviour is needed for an actor to follow a spherical surface, if you want you can throw in a few others, one to track horizontal distortion ('squash'), one to track lighting, rotation and so on, but they are all essentially the same maths . . . might be a good basis for a talk ?
@Armelline said:
A and B are both nested rules. C and D are both multi-conditional rules. So you're trying to compare two of the same things while giving them different names.
I've only differentiated them in that one is expression based and the other is rule based, in that respect they do have different names.
@Armelline said:
In the case of comparing two things, then yes one will be faster. A will be faster than C or D, which is the comparison you seem to be trying to make.
'seem to be trying to make'
Lol
I'll leave this one to you and Hopscotch, who seem to have a much better handle on all this stuff, looking forward to seeing your talk !!
@Socks said:
I've only differentiated them in that one is expression based and the other is rule based, in that respect they do have different names.
The issue is there are two types of rules there: nested, and multi-conditional. You keep trying to call A multi-conditional and B nested, but A just a written representation of B. C is multi-conditional, though, as is D.
I think that's where all this confusion is coming from.
@Lost_Oasis_Games said:
This would make sense as that tree is one logic structure and need to be viewed as a whole. Do other languages handle that differently?
Most Compilers have the ability to optimise the conditional statements when producing native code.
But GS code runs interpretively, like LUA, Python, etc. Here the conditional statements need to be built as a logic tree before they get evaluated. An analogy is the "case" or "select" statement in other languages, while convenient and readable, should be avoided if optimisation is an issue.
to be clear, @Armelline's implementation of ternary operations is fantastic in many situations and bring real optimisation. E.g.:
"Display text" - since this behavior evaluates its contents every code cycle, putting ternary operations directly into this behavior cuts out the need for separate rules and placeholder attributes which cause overhead.
"Every 0s Timers" - if you already have 0s timers in your code, then using ternary operations inside "Change attribute" behaviors instead of rules has two big benefits. 1- avoids the overhead of rules. 2- makes the code more linear and avoids possible "code order" problems.
"Change attribute" behaviors which only execute once when an actor is created.
Do not use them in "Constrain attribute" behaviors, this kills performance.
--
The debate around Nested Rules vs Multi conditional Rules also does not have a clear cut answer as it relates to GS. The decision relies on the situation. E.g.:
If you are testing for 10 totally random occurrences, it may be better to use multi conditional rules. Why? Because it creates a complex decision tree, but only one listener in GS. A nested structure on the other hand would mostly create multiple listeners (per new rule in the nested structure) as the logic reaches deeper into it.
It you know that certain conditions have a higher probability of occurring than others, then definitely use nested structures.
@Armelline said:
You keep trying to call A multi-conditional and B nested, but A just a written representation of B.
Yes, B is nested and A is a written representation of B, I understand that, there is no confusion there, my thoughts were around whether A would needed to be evaluated as a whole being a single expression. I expect your talk will help clarify this stuff or me as it's still (obviously) a little unclear for me.
@Socks said:
Yes, B is nested and A is a written representation of B, I understand that, there is no confusion there, my thoughts were around whether A would needed to be evaluated as a whole being a single expression. I expect your talk will help clarify this stuff or me as it's still (obviously) a little unclear for me.
I don't really go into that in my talk, as we were running over 1 hour by the time I got to conditional logic so I only touched on it very briefly. The GS team (and this seems supported by what @Hopscotch is saying) said that A will be imperceptibly faster than B, though, because of the avoidance of the unnecessary listeners. C will not be faster than, D, though, in any even vaguely meaningful way (at least that was my understanding).
A is just the same thing as B but written in one line. You could take B, write it in Lua, and you'd end up with A. Both are single expressions, B is just visually broken down.
I don't think I cover anything in my talk that experienced users like you will not already know, so I'd not expect any revelations from it
@Armelline said:
A is just the same thing as B but written in one line. You could take B, write it in Lua, and you'd end up with A. Both are single expressions, B is just visually broken down.
That helps, cheers for the clarification ! Now all I need to do is learn how to write this stuff in an expression.
Comments
They're essentially the exact same thing, logic wise, and the GS staff actually confirmed they'll be (imperceptibly) faster, as they're doing the exact same thing with a little less overhead.
With so much to go over, and the need to give special attention to sin/cos etc. in much greater detail another time, I decided not to include them. I also had to scrap the text functions in the end. You'll find my coverage of sin/cos etc. very inadequate - I couldn't give them too much time and was really not very well on Thursday. I still intend a much more thorough video on them later, actually getting into the maths. (A video you're actually far more qualified to make, hint hint.)
I look at precision specifically for that reason. If you're just wanting to do number stuff, roundTo is the way to go. But if you want to, say, take the result of a calculation and pull the 5th digit out of it, prec can be very handy specifically because it returns text not a number. It has it own special, useful place! My custom font template could actually have used prec and saved some processing, which I forgot about at the time. I'll be updating it to take advantage of that later on.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I'm going to do something weird here, without having tested it, I'm going to say the opposite ! (even with GS staff having said what they said
), I am going to say that I suspect the whole expression is evaluated even if the first condition within the expression fails, of course I could be wrong (and it needs to be tested), but that's my hunch, a multiple conditional expression will - with all other things being equal - be slower than nested rules that serve the same function when the first condition fails (in the same way that a multi conditional rule is slower than the nested equivalent when the first condition fails) . . . . speculative, needs testing, but I suspect that is what would happen.
Yeah, I thought with you having a cold it might be touch and go whether you managed to make the talk at all, but well done for getting through it, I would have stayed in bed !!
The reason I thought you could have thrown them on the end of sin/cos was that once you know what sin/cos does you kinda' automatically know what arcsin/arccos do.
Lol !
Busy right now, unfortunately, very boring job making window models, job's nearly finished, maybe after then !?
Ah ! I see, yes that makes sense.
On the subject of custom fonts, I found the standard method (lots of constrains) to be very inefficient, so threw together my own version . . . . which goes back to something I've always thought, that rather than having Game of the Month competition, there should be a Method of the Month competition, where a challenge is set to produce the most efficient/beautiful/fast/flexible (etc) X, so one month it might be 'How to set up a triangular collision shape', the next month might be 'Produce the custom font system with the least processor overhead', or 'The most realistic GS generated 3D planet' or 'The fastest way to spawn a grid of actors' or 'The nicest radar system for top down projects' (etc etc).
With rules ! No imported images, or no images over 512 x512, or no image sequences, or no tables, or
Basically challenges focused on individual game elements rather than complete games, this would be good in the respect that the smaller scale of individual game elements means more people could get involved, genuinely useful projects would be generated which all forum users would be allowed to help themselves to, to use in their own projects, and having 10 or 12 people argue in a thread as to the best method to generate an analog clock or functioning crane or slingshot effect would - hopefully - generate new ways to approach common game elements, it would also create a repository of 'the best way to X' discussions. For example, a very common question we've all seen is 'why does my every random seconds timer not work', so a typical challenge might be 'Produce the most efficient and flexible random timer' . . . . .
What tends to happen in threads where these questions come up is that one person answers the question from start to end, or if the thread starts with a few people pitching in it usually ends up producing an answer (and even demo) from just one person, with a competition it would be good to see 8 or 10 people battling it out with ideas for rapid table scans or circular gravity or the most realistic top dow vehicle controls - and let the best one rise to the top - at the end of the competition all project files are made available.
Of course @RThurman would need to be banned from entering.
It's not. Both my testing and the Lua manual say otherwise :P The Lua manual actually specifically and explicitly says that Lua does not evaluate any more than necessary.
I think you're misunderstanding quite what is happening in both cases. The conditions are just the rules written out. You can have:
If a is true
then
if b is true
then
if c is true
then
if d is true
etc.
And you can have:
if a is true
and
if b is true
and
if c is true
and
if d is true
These are not the same thing. The conditional logic method can duplicate both, differently. It's not doing the second compared to the first. It's doing the second or the first depending on how you write it.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
They referred to the following, which would give the same result:
Change Attribute self.A to "(self.B==1) and (true) or (false)"and
The above do the same, but the Rule takes slightly more resources as it has a Listener attached.
This listener is necessary however, unless the condition is only checked once in the actor.
Using a Constrain Attribute would usually also be no good as it would do the result every code cycle, as opposed to a Rule which only does it when triggered. Although there are cases where it is handy, like the examples with Display Text in your video.
Also, @Socks, lets not confuse this with a previous discussion about multi-conditional rules vs nested rules. This is where we established that if a rule has multiple conditions, that they all get evaluated (or at least impact performance), even if the first condition already is satisfied. As you suspect, the same holds true for compound rules like above.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
I was basing the idea on that multi-conditional rules all get evaluated even if the first one fails, I just imagined that the whole expression would be evaluated, but I'm happy to be wrong !
I've not confused the two discussions at all !!
I've made a guess that if multi-conditional rules continue to be evaluated after the first condition fails (something you gave me a really good explanation of) then it might well be the case that a multi-conditional expression is also fully evaluated in the same way as the logic structure would be the same (my guess), that's all I was thinking, but like I say I'm happy to be mistaken.
? I'm confused now ! Lol
Are 'compound rules' the same as 'multi-conditional expressions' (that is, an expression with a series of conditions/rules) - sorry, I don't actually know the correct terminology.
For clarity, my suspicion was that an expression (where you have a series of conditions in a single expression) would fall foul of the same issue that multi-conditional rules have - where the whole series of conditions are evaluated regardless of whether the first condition fails or not.
Oh cool....
hmmm... yes....
yes!
Yes!
YES!
Oh...RATS!
'More than necessary' doesn't really answer anything !
In the case of multi-conditional rules (set to 'All') it is necessary that Lua evaluates all the conditions, so my suspicion can be reworded from 'I suspect that multi-conditional expressions are all evaluated, even if the first failed condition negates any further evaluation' to 'I suspect that it's necessary that multi-conditional expressions are all evaluated, even if the first failed condition negates any further evaluation'.
@Socks
http://www.lua.org/pil/3.3.html
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Ok, I don't know Lua at all, so cannot make any comment on that page and will take your word on it, but I take it there are exceptions to this, for example multi-conditional rules (set to All) do evaluate the second condition - even when the first has failed ?
The correct term is "ternary operations"
However, LUA does not support this really as some other languages do. So the above are "Quasi Ternary Operations" if you want to be pedantic.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Yeah, I knew that, they are obviously quasi ternary operations, everyone knows that.
So, these quasi ternary operations, are they subject to the same limitation that multi-conditional rules are, where the whole quasi ternary operation (
) is evaluated regardless of a failed first condition ?
Quasi ternary operations . . . just thought I would say it again.
@Armelline
They are quasi ternary operations, don't you know.
Yes, the reason is that a decision tree needs to be defined for the whole operation before the real evaluation happens. This is what causes the overhead, not the individual "is x=y" bits.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Just as I suspected, your basic quasi ternary operation decision tree, lol
So I guess then that in some situations they might be less efficient than the same set of conditions set up as nested rules (where I am going to guess a decision tree is still defined, but only needs accommodate the first condition) ?
Lol
I can think of loads of questions that come up from time to time, that would be good to hammer out in a competition like this, how to detect line of sight (I liked your fire-out-a-bunch-of-particles solution), how to pass information between two colliding actors, how to simulate water, how to defocus/blur an image in real time . . . and recent examples like how to roll an oval along the ground . . and so on. . . . be good to see 6 solutions from different approaches.
Yup
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Are we all on the same page here?
In this demo project A = B, but not C or D. C = D, but not A or B. Each pair are going to be converted into the same code when the project is compiled. What would make B more efficient than A, or D more efficient than C?
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I was happily following this thread until about halfway down the second page... then it just got so technical that it became a blur of words...
Then @Armalline dropped in a demo to help bring it all back into understandable territory....
Agree with earlier comment though that @Socks should do a GameSalad meet up to show what funky stuff can be done with sine and cosine and stuff... if only to see what crazy stuff he would come up with...
Cheers for the demo ! Very useful.
The question is surrounding multi-conditional expressions (or I have always called them 'quasi ternary operation decision trees'
) vs nested rules, so A vs B is the relevant comparison here.
We know that the nested rules version stops evaluating the nested conditions once (and if) the first condition fails (whereas the multi-conditional rule evaluates all conditions regardless of the initial condition failing), the question is whether the multi-conditional expression equivilent would do the same given that as Hopscotch says: "a decision tree needs to be defined for the whole operation before the real evaluation happens"_
(Hopscotch explained this to me in detail a while back, but I can't find the PM now!)
Also, I don't know my way around multi-conditional expressions enough to really understand your '(( self.A ==1)and(( self.B ==2)and(( self.C ==3)and("Yes!")or("No3"))or("No2"))or("No1"))' expression, so perhaps it is circumventing the need to evaluate the whole operation for all I know ?
This would make sense as that tree is one logic structure and need to be viewed as a whole. Do other languages handle that differently?
Also can we confirm that multiple conditions are in matching order to the rule in the background? As we know GS doesn't adhere to a strict order of events.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
A and B are both nested rules. C and D are both multi-conditional rules. So you're trying to compare two of the same things while giving them different names. In the case of comparing two things, then yes one will be faster. A will be faster than C or D, which is the comparison you seem to be trying to make.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
All you need to know is that someone, somewhere, is growing pseudo nested quasi ternary operational decision trees.
Thanks for the vote of confidence !
I was actually playing around with mapping actors/images to a spherical surface, maybe a 'build your own planet' type tutorial as the basis for explaining some of that stuff - the actual maths involved is fairly straightforward, just a single constrain behaviour is needed for an actor to follow a spherical surface, if you want you can throw in a few others, one to track horizontal distortion ('squash'), one to track lighting, rotation and so on, but they are all essentially the same maths . . . might be a good basis for a talk ?
Quick video example:
Link - https://www.mediafire.com/?l21lbjdbtfnjgfn
I've only differentiated them in that one is expression based and the other is rule based, in that respect they do have different names.
'seem to be trying to make'
Lol
I'll leave this one to you and Hopscotch, who seem to have a much better handle on all this stuff, looking forward to seeing your talk !!
The issue is there are two types of rules there: nested, and multi-conditional. You keep trying to call A multi-conditional and B nested, but A just a written representation of B. C is multi-conditional, though, as is D.
I think that's where all this confusion is coming from.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Most Compilers have the ability to optimise the conditional statements when producing native code.
But GS code runs interpretively, like LUA, Python, etc. Here the conditional statements need to be built as a logic tree before they get evaluated. An analogy is the "case" or "select" statement in other languages, while convenient and readable, should be avoided if optimisation is an issue.
@Armelline, @Socks,
to be clear, @Armelline's implementation of ternary operations is fantastic in many situations and bring real optimisation. E.g.:
"Display text" - since this behavior evaluates its contents every code cycle, putting ternary operations directly into this behavior cuts out the need for separate rules and placeholder attributes which cause overhead.
"Every 0s Timers" - if you already have 0s timers in your code, then using ternary operations inside "Change attribute" behaviors instead of rules has two big benefits. 1- avoids the overhead of rules. 2- makes the code more linear and avoids possible "code order" problems.
"Change attribute" behaviors which only execute once when an actor is created.
Do not use them in "Constrain attribute" behaviors, this kills performance.
--
The debate around Nested Rules vs Multi conditional Rules also does not have a clear cut answer as it relates to GS. The decision relies on the situation. E.g.:
If you are testing for 10 totally random occurrences, it may be better to use multi conditional rules. Why? Because it creates a complex decision tree, but only one listener in GS. A nested structure on the other hand would mostly create multiple listeners (per new rule in the nested structure) as the logic reaches deeper into it.
It you know that certain conditions have a higher probability of occurring than others, then definitely use nested structures.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Yes, B is nested and A is a written representation of B, I understand that, there is no confusion there, my thoughts were around whether A would needed to be evaluated as a whole being a single expression. I expect your talk will help clarify this stuff or me as it's still (obviously) a little unclear for me.
Thanks for the info.
I don't really go into that in my talk, as we were running over 1 hour by the time I got to conditional logic so I only touched on it very briefly. The GS team (and this seems supported by what @Hopscotch is saying) said that A will be imperceptibly faster than B, though, because of the avoidance of the unnecessary listeners. C will not be faster than, D, though, in any even vaguely meaningful way (at least that was my understanding).
A is just the same thing as B but written in one line. You could take B, write it in Lua, and you'd end up with A. Both are single expressions, B is just visually broken down.
I don't think I cover anything in my talk that experienced users like you will not already know, so I'd not expect any revelations from it
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
That helps, cheers for the clarification ! Now all I need to do is learn how to write this stuff in an expression.