How to spawn a buddy?

  • Imagine an object wants to spawn a buddy it can instruct and it can know about, more than once.

    In other words, it can set properties on its buddy, and it can get properties from its buddy, and it can know when its buddy has collided with something else.

    Is any of this possible?


  • @Deeeds using broadcasts similar to how I was saying before. Just need to do a little simple setup.

  • @iTap-Development "Simple", says you.

    As I said before, I'm coming from languages and environments where there are more ways to establish lines of communication than can ever be needed -> to this one where there are no references, of any sort, and it's unknown how costly broadcasting and receiving actually is, and wherein that's been tacked on to make up for whatever it was like before that.

  • @Deeeds yep! I said simple.
    You said, “it's unknown how costly broadcasting and receiving actually is”, why not just build a project to test it then? When I don’t know what a feature is capable of, I test it.
    Have you even figured out how to add behaviors yet?

  • @iTap-Development Have you even figured out how to think conceptually?

  • @iTap-Development Or how to add links, or how to discuss sensibly, or how to explain yourself, or how to not act like a smug little runt?

  • @Deeeds 🤣🤣🤣
    If you mean like open, if I can use a location and weather api to make a weather app. Let’s just say....what the heck?

  • @Deeeds What sort of properties? Objects can always Get and Set properties of each other, and for detecting its collision, just have the buddy selected as the first collision target. I’m guessing you know how to select targets with behaviours that target objects?

  • @Aidan-Oxley I think you're missing the part that's problematic, for me.

    I'm spawning the buddy.

    Therefore I don't have a reference to him. So I can't get anything from him, or set anything on him, nor can he know who I am.

  • @Deeeds Ohhh I see. Ok there is a way to do this, but it’s pretty ridiculous and shouldn’t have to happen. This is where dynamic object targeting would be awesome. The only way to do this at the moment is to either broadcast messages n stuff or put the buddy in a tag and have the spawned object collide with that tag and underneath the collision behaviour have all the stuff you want to do to the object. Either way it’s not gonna be easy I think.

  • @Deeeds I used collisions in my 3D project, where points would collide with triangle faces once, and then run a timer on a get position behaviour that ran under the collided behaviour. It was pretty annoying and messy to get this to work, also I didn’t have dynamic broadcasts when I made that. But I think for your case it might be better to use broadcasts messages. Here’s how I’d do it:

    I don’t know how many buddies you’re gonna have, but for simplicity I’m gonna say just 1.
    Instead of the buddies spawner changing the properties, the buddy will change its own properties. Each property will be given its own broadcast/receive key.
    When the main object wants to change a buddy’s property, it simply broadcasts a certain message and includes in it the data of the new property you want (e.g, I want to change its mass to 5, broadcast key is say MASS, value is 5). The buddy then receives the message with key MASS, and changes it’s own mass to the value given, 5.

    This can work too if there are more than 1 buddy. How easy it is to make depends on how many buddies there are.

  • @Aidan-Oxley Here's my "fix", that's not working.

    Each buddy has a Channel_ID that he listens on. These are the numbers, 1 through 9.

    Each "mate" of a buddy stores a variable with the Channel_ID of his buddy.

    When "mate" wants to send a message to his buddy, he's using that variable... which holds his number for his buddy.

    But, for some reason, this isn't working.

    Is there a rule against broadcasting with an Event key that's the contents of a variable and as simple as the number 1, 2, 3, etc..

  • @Aidan-Oxley for buddy one just have it be ‘mass1” for buddy two “mass2” etc. just increase a number by 1 each time you spawn a new buddy and combine it to the “mass” key. then You can have unlimited buddies. Then @Deeeds won’t be so lonely!

  • This post is deleted!

  • @iTap-Development Each buddy has a receive message, and looks to his variable (which should be unique) to see what "channel" he should be listening on.

    This variable is set when he's spawned.

    That part works

    Him listening on the variable channel doesn't work.

  • @Deeeds are you willing to give a project to look at?

  • @iTap-Development No, I'm deep into something, and simply need to know... can a receiver use a variable as the Event Key?

    That is the part that's not working.

  • @Deeeds as far as I know, yes. That’s why I suggested a project.

  • @iTap-Development Are you SURE it works? Have you ever done this?

    Spawn and object. Let's call him Mate

    Spawn an object to be Mate's Buddy

    Mate sends a channelID to Buddy

    Buddy sets that variable in his local storage.

    Buddy's got a Receiver with an Event Key that's set to that locally stored variable.

    Everything works except Buddy's receiver.

  • @iTap-Development @Aidan-Oxley I found the problem.

    Buddy's Receiver is set by creating a copy of what's in the variable for itself, it's not a reference to the variable's contents (nor is looking contents via a pointer etc). So once it gets a value from the variable, it's got its own copy and isn't actually looking at the variable's contents to know what it's listening to.

    In the initial Spawning, he's getting a null as the receiving channel because the variable hasn't yet been initialised.

    And that never changes, even when the variable's value changes.

    A very slight delay before activating the receiver forces it to set itself with that variable after the variable has been initialised with the value of the previously received ChannelID from his Mate.

    This goes back to my other point, somewhere else, that I think broadcasting might be quite efficient, and that @hamed is setting up fast lookup tables for messaging and been a clever fella about how he's done messaging, even if nobody has bothered to describe how/why it works the way it does.

Log in to reply