Inter-actor "communication" ?
Ignis
Member Posts: 72
Thank you all for the valuable response to my first post a few days ago. The time since then has brought me further along with learning GS. Now for my next question! (and remember, I'm still a rookie so maybe this issue is easy, maybe not).
So, can actors "communicate" certain information between them upon a Rule execution, such as a collision? For example, when Actor1 collides with Actor2, can Actor1 "grab" a piece of information from Actor2 such as its color, rotation angle, or a custom attribute?
Let's imagine that you have a series of raindrops falling from the top of the screen. On the ground, there are 2 "paint buckets": red and green. These buckets are modifications of ONE actor called "Bucket" but assigned different colors in the individual actor instances (theoretical example, maybe not the best way). The immediate question would be "why not use 2 unique actors like Red_Bucket and Green_Bucket"? I'll address that below... but let me continue with the scenario.
When the raindrops hit a bucket, the idea is to change the color of that *specific* drop to the color of the bucket it hits. In this imaginary example, the raindrop is like an eye-dropper that picks up the color of the bucket, then that color is applied to the individual raindrop. All I can determine is this: when the drop hits the bucket, I can change almost any attributes for the raindrop, but I can't grab an attribute variable from the bucket to assign to the raindrop...
So why not 2 buckets using 2 different actors? I could do that, setting each bucket with a tag "Bucket" and using `"If Raindrop collides with actor of tag Bucket"`... but then the raindrop wouldn't know which color of bucket it collided with, only that it collided with the actor tag 'Bucket'. As far as I can tell, to accomplish that, I'd need to create 2 separate rules, such as `"If Raindrop collides with actor of type Red_Bucket"` and `"If Raindrop collides with actor of type Green_Bucket"`. Not a bad solution, but extend that outward... what if there were 10 buckets? What if there were multiple varieties of raindrops, and each one was affected differently by the paint? Maybe one type absorbs the color... another type is "immune" to absorption, etc. The number of rules and variables could easily spiral out of control, am I correct?
In the "Rule" attribute, as far as I can tell, you can relate any actor to another expression, including any custom Game attribute. I briefly considered Constrain Attribute of certain values to Game attributes, i.e. `"self.Bucket.color.Red > Game.Bucket1.Red"` and `"self.Bucket.color.Green > Game.Bucket2.Green"`. Then, the raindrops could "grab" the Game attribute and use it (to change its own color). But again, this could get unruly if there were 10 buckets, each with 10 "holding variables". Did the raindrop hit Bucket1? Bucket6? And so forth...
How wonderful would it be to have something like:
`"IF Raindrop collides with actor of type Bucket THEN change self.Color.Red to THIS.bucket.Color.Red"` (in other words, it grabs the red value from the bucket it just collided with and applies that red value to the raindrop).
Anyway, perhaps there is already a method to accomplish this and I'm just not aware of it. Perhaps there's a work-around that doesn't entail a huge memory hit or an excessive number of custom game variables, if the scenario theoretically became more involved.
Hopefully this isn't too confusing! I'm sure there are some vastly more experienced GS users here who can address this...
Brent
So, can actors "communicate" certain information between them upon a Rule execution, such as a collision? For example, when Actor1 collides with Actor2, can Actor1 "grab" a piece of information from Actor2 such as its color, rotation angle, or a custom attribute?
Let's imagine that you have a series of raindrops falling from the top of the screen. On the ground, there are 2 "paint buckets": red and green. These buckets are modifications of ONE actor called "Bucket" but assigned different colors in the individual actor instances (theoretical example, maybe not the best way). The immediate question would be "why not use 2 unique actors like Red_Bucket and Green_Bucket"? I'll address that below... but let me continue with the scenario.
When the raindrops hit a bucket, the idea is to change the color of that *specific* drop to the color of the bucket it hits. In this imaginary example, the raindrop is like an eye-dropper that picks up the color of the bucket, then that color is applied to the individual raindrop. All I can determine is this: when the drop hits the bucket, I can change almost any attributes for the raindrop, but I can't grab an attribute variable from the bucket to assign to the raindrop...So why not 2 buckets using 2 different actors? I could do that, setting each bucket with a tag "Bucket" and using `"If Raindrop collides with actor of tag Bucket"`... but then the raindrop wouldn't know which color of bucket it collided with, only that it collided with the actor tag 'Bucket'. As far as I can tell, to accomplish that, I'd need to create 2 separate rules, such as `"If Raindrop collides with actor of type Red_Bucket"` and `"If Raindrop collides with actor of type Green_Bucket"`. Not a bad solution, but extend that outward... what if there were 10 buckets? What if there were multiple varieties of raindrops, and each one was affected differently by the paint? Maybe one type absorbs the color... another type is "immune" to absorption, etc. The number of rules and variables could easily spiral out of control, am I correct?
In the "Rule" attribute, as far as I can tell, you can relate any actor to another expression, including any custom Game attribute. I briefly considered Constrain Attribute of certain values to Game attributes, i.e. `"self.Bucket.color.Red > Game.Bucket1.Red"` and `"self.Bucket.color.Green > Game.Bucket2.Green"`. Then, the raindrops could "grab" the Game attribute and use it (to change its own color). But again, this could get unruly if there were 10 buckets, each with 10 "holding variables". Did the raindrop hit Bucket1? Bucket6? And so forth...
How wonderful would it be to have something like:
`"IF Raindrop collides with actor of type Bucket THEN change self.Color.Red to THIS.bucket.Color.Red"` (in other words, it grabs the red value from the bucket it just collided with and applies that red value to the raindrop).
Anyway, perhaps there is already a method to accomplish this and I'm just not aware of it. Perhaps there's a work-around that doesn't entail a huge memory hit or an excessive number of custom game variables, if the scenario theoretically became more involved.
Hopefully this isn't too confusing! I'm sure there are some vastly more experienced GS users here who can address this...
Brent
Comments
Actors can communicate with each other directly at the actor *instance* (not actor prototype) level but that leads to all sorts of scene setup, scene copy, and scene change issues. Also, in this instance, it still doesn't get you what you want since all the actor-to-actor communication is setup manually (i.e. by hand placing and wiring up) within the aforementioned actor *instance(s)*. There is no new instance pointer/handle discovery.
Actors can also communicate by sharing game level attribute(s) but this method gets trouble prone if more than two actors can share the "communication" game level attribute(s). If that is the case, you need to use lock, or better yet, semaphore programming methods to keep the usage in control/sync. Even then, sequencing in GS is an art. :-)
Yeah, I wish GS was a bit more sophisticated too!