FMG, in regards to my previous post...

Ignis

firemaplegames said:
One of the things you mentioned are already in place:

Every actor has access to every other actor in the Scene - as well as all the attributes of every actor. You can listen to other actors as well as control other actors. I can touch one actor and have it change ANY attribute of any other actor - without using any attributes.

Hi Joe,

This might have been lost in the shuffle of my last post; hopefully you can help me out here. I really need to figure out this functionality, not only for the usage described below, but various other implementations throughout my game. I posted this topic as a separate thread a couple weeks ago, and the overall response was "Actors cannot share information between each other in run-time", but you state that it actually can be done! Solving this would go a long way to keeping me on the GameSalad engine.

Here's my synopsis from yesterday:

-----

I have an actor called "air_blower". This actor is intended to blow other actors in the direction it's facing, like a powerful jet of air. I want this actor to be rotated to basically any angle... 0, 45, 90, 270, 322, etc. So, let's say that an actor "marble" collides with "air_blower", how do I write code to say:

`IF "marble" collides with actor "air_blower", then READ the specific rotation of that air blower (whatever rotation it's set to) and accelerate the marble in that direction.`

So, if "marble" collides with an "air_blower" rotated to 95 degrees, "marble" gets blown (accelerated) at 95 degrees. An air blower rotated to 225 degrees would blow the marble at 225 degrees. Additional vent-specific traits would very useful to me, i.e. maybe one vent is high powered, and jets the marble at an acceleration of 2000. Another vent might be weak, affecting the marble at just 500 acceleration.

Obviously I don't want to "solve" this issue with multiple performance-killing contrains, hidden actors, temporary storage of game variables set on timers, etc. I simply want to share variables between actors upon collision or another rule.

Regards,
Ignis

danayel

You can do this with objects that are already placed within the game.

Newly spawned objects can't do it unfortunately.

Once you place an object in the game screen, open it's properties (NOT the prototype), click on the function button and you will see that there is a new group of attributes -> scene

In the group you will have access to all the actors, and their attributes currently placed in the scene.

If your marble game has all the marbles on the screen at the start, then it should be fine. If it needs to spawn some, then you could be in trouble.

firemaplegames

Hey,

Yes, like danayel says, only Actor Instances in the Scene have access to other Actor Instances.

Now, to use this functionality you need to live 'on the edge' a bit, and break the Prototype-Instance bond.

GameSalad, and most of the Object-oriented programming environments are designed to take advantage of this bond. i.e., you edit the prototype, and all the instances of that Actor get updated. This is nice because it keeps all of your code in one place.

I usually have one Actor in each Scene that acts as a 'Scene Controller'. This actor resets all the level data, and controls the camera, etc.

Utilizing or controlling the camera is a great example of why to break the bond.

To break the bond, you click the padlock in an Actor Instance. That's why the padlock is there: to preserve the bond. You can always change anything on the left-hand of an instance. Either its image, or any of its attributes and still preserve the bond. But start adding new behaviors, and now that instance is 'rogue'.

Anyway, an instance can see all of the other instances in the Scene, including all of their attributes. The path to each Actor is: Current Scene => layers => [layer] => Actor

You can access them in the expression editor.

Now I always need to access the camera, so I NEED to 'break' an actor. I make an actor specifically for this. The prototype never has any code, and it is just a simple box. It sits just outside of view in each Scene.

If I need to access any other Actor's attributes, I generally put the code in that Actor, since its already broken, and I can keep all the code in one place.

Now here comes the fine print:

You MUST be careful if you do this. If you willy-nilly move an Actor you were targeting to a new layer - well, now your Rule is broken. You just have to be careful. You now have code all over the place, not just in the Actor Library and you need to remember where stuff is.

My new game almost exclusively uses 'broken' actors. I have a 'generic' actor in the library that I use for most of the Actors in the game. All of the instances have different code on them. I haven't seen an issue with doing this. My game runs nice and fast.

Good luck!

Ignis

Thanks FMG and danayel!

I will investigate this much further. I already utilized a "broken" camera actor, perhaps without realizing what I was doing, because my camera scrolls around within the bounds of a larger scene like any RTS game where you might have a large world map, and the player can scroll around the map. Since I intend each level in my game to be of a different overall size, I was forced to "break" the camera actor so I could read that scene's unique size, and tell the camera where to stop upon hitting the edges. As you stated in your own examples, my camera actor has zero rules in the prototype, but several rules in the actor instance.

I might still encounter some problems with this entire theory because, at this moment, I still spawn my "marble" actors using the Spawn Actor feature. I might be able to place all of my actors off-scene and move them into place when necessary, which would probably be better from a performance standpoint regardless.

Anyway, I'll keep chugging away for a bit to see where this leads... I'm more encouraged that these things are possible in GameSalad, when you are willing to break that foreboding GIANT LOCK symbol and tinker with the inner mechanics.