why are red "get/set/trigger" scene behaviors not communicating with actors?

JBW86

  • Posts: 15
Hi all,

I am have a recurrent problem with using red behaviour blocks to communicate with actors. The tl;dr is an "actor behavior <x> not found on <actor>" error when referring to that actor from a scene behaviour (regardless of whether that is a "trigger <event> in <specific behavior/all behaviors> for <actor>" or a "get/set <attribute> in <behavior> for <actor>". Red blocks are the bane of my existence!

I've just started a new game and come up against this again. I know I somehow circumvented it on the last game I made (a jam entry) but I forgot how. I've revisited that one but I'm unable to identify what the difference is and where I'm going wrong.

Context: the game is a cross-between a customizable drum loop and an RTS. (Don't ask me how the second part works yet).

Here is the first behaviour (scene behaviour) which regulates the timing of the whole thing.

Every "tick" of the beat it should trigger "pulse" in every actor of type "district"

Here is the second behaviour (actor). As you can see there is a print statement in there for the purpose of debugging; this is not working at all. The rest of the script is irrelevant atm.


I know the scene behavior as it least trying because the error log is a "behaviour does not exist on actor"  and this returns * the number of that actor in the scene. Basically the scene behaviour finds the relevant actors but cannot  seem to find the referenced behaviours attached to them (even though the editor could!?)

I got it working at one point and I don't know how. This is why it's so frustrating and I have similar issues getting behaviours to communicate with each other on every project I start. Is it because the "district" actors have been drawn in with the scene editor instead of me creating them at runtime with a script? Is it a bug? I've tried wiping everything and starting again, running in every different format etc.

« Last Edit: March 10, 2015, 03:36:34 am by JBW86 »

sdieters

  • Posts: 2068
HeyJBW86 and welcome to the forum!
First couple of things i can think of are pretty simple, but in my 2 years of using stencyl it frustrated me many times.
1. The actor behavior with the pulse event is either not attached to your actor or is disabled. Keep in mind that if you want to create actors at runtime, you have to have all the behaviors added in the actor's behaviour tab.
2. The pulse event is diasabled in the list of events.

another thing could be (i never use the ... for all behaviors for... block. So its a guess) the way you call for the event. if the above things are not the issue, try calling the event from one behavior, just to check the function.

let me know!
My new profile is TheIndieStation.
When you see a recent post with this name, i'm probably using my phone. So dont mind any typo's =p

captaincomic

  • *
  • Posts: 6109
Are you triggering "tick" in "when created"? If so, try with a small delay in a "do after 0.01 seconds" instead. At the time of "when created" it is not guaranteed that other behaviors are initialized already.

sdieters

  • Posts: 2068
Im not sure its the issue Captain, since the tick event is recalling himswlf every .7 seconds, so it should work the second tick. or i must miss something.
My new profile is TheIndieStation.
When you see a recent post with this name, i'm probably using my phone. So dont mind any typo's =p

captaincomic

  • *
  • Posts: 6109
Ya, that's true. I'm not sure either, just guessing..

JBW86

  • Posts: 15
Im not sure its the issue Captain, since the tick event is recalling himswlf every .7 seconds, so it should work the second tick. or i must miss something.

Thankyou both.
The "tick" behaviour is working as I get the debug readout that counts 1-16 and back to 1. (this is the scene behaviour which basically loops a variable from 1-16 to keep track of the position of the drum-beat the player will later be programming as part of the gameplay).

I have double-checked all the following:
- actor behaviour with "pulse" event trigger attached to appropriate actors
- actor behaviour is correctly attached; not disabled etc.
- I've also tried "in all behaviours" and triggering the "pulse" event in a specific behaviour in each of those actors. Both return an error message that indicates the actor has been located but the behaviour is missing (it's definitely not)
- deleted the whole thing and rebuilt in several ways, same problem always occurs communicating between behaviors with red blocks (specifically when calling actor behaviour from a scene behaviour). Seems like an engine bug but I'll double-check everything again tonight.

Thanks for taking a look. Still baffled.



JBW86

  • Posts: 15
Thanks for the welcome btw. Been Stencyling for 2 years or so but the forum was being odd for my old account so I started a new one.

yoplalala

  • *
  • Posts: 1511
If you try to get an attribute from the specific behaviour, does it work ?

JBW86

  • Posts: 15
If you try to get an attribute from the specific behaviour, does it work ?

Nope. Similar problem.
The "districts" each have a "sequence number" which is saved in their actor behaviour and set-up in the editor (so I can make different "shape" beat machines for levels). The original set-up was* to find each actor of type, work out whether <get attribute "sequence number" from actor behaviour [etc.]> was equal to the BeatNumber game attribute, and then only trigger the event in that single actor. Same returning of "behaviour doesn't exist" was occurring then.

I'll go over it with a fine-tooth comb tonight but I've spent about 3 hours with the same problem. Hopefully it will just be a d'oh! moment. If it's a case of me using the blocks wrong or failing to apply some esoteric workaround then something unintuitive is going on w/ the software.


*instead of the <trigger event pulse in every actor of type> (see pic)
 
The workaround is to do all of this within the actor behaviors themselves, but I really really want to get to the bottom of what I'm doing wrong here, because it's a recurrent problem across projects.

yoplalala

  • *
  • Posts: 1511
That is weird I've been using attributes from behaviours and I've been triggering events in other behaviours without problems.
What version of Stencyl do you have ?

JBW86

  • Posts: 15
That is weird I've been using attributes from behaviours and I've been triggering events in other behaviours without problems.
What version of Stencyl do you have ?

3.2 now. Doesn't seem to be a version-specific problem and like I say, it's something I've come across before so it seems like there's a quirk of how the software works which I'm working against in a bad (yet logical, in my eyes) way.

in your project, is that working cross both scene and actor behaviours? I have a hunch it might be the scene miscommunicating with the actors.

Although I've also just seen on a thread from 2013 that it might be an issue with "on init" triggers; and I should use "after 0.01" instead to ensure the behaviours can find eachother properly. I'll report back when I'm near my home computer.

JBW86

  • Posts: 15
Still stuck, going from image A to B always returns the "behavior does not exist - DistrictScripts" message every time the scene behavior tries to access it.


If I strip out the attributes from the actor behavior as shown below so it I have nothing but a direct "trigger in behavior" with no dependencies, it still doesn't work...

... I no longer get the error message to say the behavior doesn't exist, but I don't get the print message in the log either.


This is infuriating because exactly the same process works in older projects.
It feels distinctly like a bug.

rob1221

  • *
  • Posts: 9424
Where is the initial call to "tick"?

JBW86

  • Posts: 15
Where is the initial call to "tick"?

In the bottom-most screenshot, the 1st event in the BeatController scene behaviour.
I've tried it as both an "init" with a couple of seconds delay to let everything else init, and in that screenshot I've tried it as an "after x secs..."


rob1221

  • *
  • Posts: 9424
Can you attach a sample project showing the problem?  It's much easier to solve that way.