Spawned Objects with Receive Message, only original works?
-
@iTap-Development "should"... and you know this how?
-
@Deeeds that discernment you referred to.
-
-
@Deeeds just made a test project(surprise!) and it is as I said.
-
@iTap-Development See my updates. I'm not seeing the same as you.
-
@Deeeds are you broadcasting right after spawning? Because if my spawn triggered the broadcast, It didn’t work.
-
@Deeeds they can receive the message. I'm guessing part of the problem might be that you're broadcasting and spawning in the same tick.
When an object is spawned its behaviours don't activate until the next tick, so you can wait about 0.017s and it should work.
If you're not destroying the original then the original should receive the message... Typo? It's case sensitive.
-
@iTap-Development No. I'm spawning at the start of the game, then, much later, sending broadcasts.
-
@Jack8680 No, not spawning and sending.
The objects are created at the beginning of the game/scene.
The messages are sent much later.
The original is ALSO not receiving the messages.
-
@Deeeds that doesn't make sense. Can you reproduce it in a different project? I just made a test project and all my objects including the original receive the message:
-
@Jack8680 I've just "solved" the problem.
Out of curiousness, I created a new message receiver, and gave it the same event key, and hooked it up. It worked. The other one still does not, they contain the same key.
The receiver that isn't working was a duplication of a different receiver, and has had its Event Key changed a couple of times, that I can remember. It seems to not work for its original key, nor for the new key, or any key that's given to it.
It's still sitting in my project, up above the newly made and working message receiver, doing nothing.
If you want to try to recreate this, it's got something to do with duplicating a receiver and then changing its event key more than once.
-
@Deeeds could there be a space after the non-working receive message's key?
-
@Jack8680 No. I thought this, too. And have changed the key in each situation very carefully before posting the initial question. And tried many many other keys, both digits and alphanumeric, thinking that might be a problem, too.
I also found something else interesting, during that - using 000 as a key is auto-reduced to 0, but shows as 000 in the behaviour's visual representation of itself. And the receivers also auto-reduce this, when set to 000, retaining the visual representation of being 000, but are actually 0. But it all works, even if they are reduced and treated as ints as keys whilst strings as representations of their former selves.
-
I've further isolated how this happens:
I have a factory, it makes objects with IDs based on their initial x position and a Box Container "constant" name. These two things are combined with the text combination behaviour, and then the receive message is set to this result, or to another box container that stores this result. If I switch the receiver from the box container with the result to the combine text behaviour's result and then to custom arbitrary values in a duplicate, the receiver doesn't work for anything. Ever. Might as well just delete it and make a new one.
-
There is a teeny tiny glitch with this. I understand you. You just need the event key to have some data in it and whenever an object receives a broadcast, it would work. If it doesn't work, just add a conditional IF behavior.
-
@RobinsonX Huh? I'm sorry. I'm not following you, at all.
How does an IF solve any of this?
-
I think I may know the issue. When you change the event key, you need to use behaviour On on the receive message for it to "Get" the new key. Unless you're typing the key manually in the field, then it sounds like a bug.
-
@Hamed The Receiver Behaviour that had this problem, once it stopped working, no longer cared how I set the key. It simply stopped working. I had, quite literally, two keys with the same Event Key, and could turn one off and the other on, and see that only the new one worked, that the old one had bitten the bullet. Could never be reused, in any way. This is the first time I've seen this particular type of bug, where a behaviour node has seemingly lost contact with the hyperPad world. It took an enormous amount of time and testing to isolate it to this being the problem. It was about the last thing I thought could happen...
