![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
relee2:53pm - I'm done lunch and lunch activities and I'm back at the library. Unfortunately, while I was away some more people came and the good table is all filled up, so I'm stuck either sitting at one of the regular, non-electrified tables, or one of the exotic chairs near the window that do have power. I'm hoping to be at this a while so I took a seat with power, but it's very uncomfortable and I worry about my pocket stuff falling out.
If I had known the Library was so busy I might have gone to the McDonalds again. Well, there's always next time.
For now I'm going to try and get the Dialogue working with the new Interactable system.
3:05pm - Something's nagging at me. It's a problem with the whole UnityEvent delegate thing. In order to do the baton pass my MobileInteract component needs to turn off the PlayerInput component on the Object it's a part of. But I was all set to activate any sort of event with my MobileInteract/Interaction intersection. So, there might be other types of interaction that don't require the PlayerInput to be shut down, and which wouldn't know to start it up again. Hmm... Things you interact with in JRPGs... Mostly they're things that come with a dialogue. Are they all? They all could be. So maybe this is okay?
I'm not sure. Doors are an example where you want to just push the button and enter, without having to have a dialogue pop up and ask if you want to go in. There might be buttons you want to push that don't have a dialogue, too. Chests/treasures have a whole different sort of dialogue.
So yeah, it's not okay.
What shall I do as an alternative?
3:23pm - Bleh, someone just put on some fragrance. I've never had to deal with that at the McDonalds. :/
There's a lot of stuff here that bugs me that I don't have to deal with at the McDonalds. I'm definately reconsidering the idea of working here more often.
Anyways, I'm trying to figure out what to do with my interactables...
I think what I need to do is have the MobileInteract know what sort of interaction it's interacting with, rather than just firing off a remote function on some other object.
Maybe instead of passing a function, the Interactable component should pass an object? But if I have different components for different interaction types, how would it know what sort to recieve?
If I used polymorphism here, I don't think it would work, because the MobileInteract needs to know the type it's interacting with. Treating it as a base class won't work. I could put a function on the base class though that returns the type of the interaction so it knows what it's working with. That might work...
Alright let me run through the logic again to make sure I've got it clear in my head.
First the MobileInteract activates and gets a reference to the Interactable. Then it activates the Interactable's interact function.
...
Oh hang on. I could have the interact function return an enum that says what kind of interactible it's activating. But then, how would the Interactible know that? o.o;;
There's a third hand in this pot and that's the Interaction that the Interactable is triggering. So yeah, the Interactable component won't even know what type of Interaction it is. It'll fall to the MobileInteract component to figure out what it's been passed.
So let's try that logic again.
First the MobileInteract activates and gets a reference to the Interactable. Then it takes the public Interaction component from Interactable's reference. Then it uses the Interaction component's GetInteractionType() method to figure out what type of interaction it's dealing with, and it responds accordingly, potentially turning off the PlayerInput component. Then it runs the Interact() method on the Interaction, causing it to do its thing.
It almost seems like I could combine Interactable and Interaction, except that then there wouldn't be an easy way to find it. So all Interactable does is provide an easy to lookup redirection to the actual Interaction.
I'm going to code that up and see how it works.
5:12pm - I need to use the washroom and I don't feel safe leaving my laptop out in the library. I'm going to pack up and head to the McDonalds and work there until I'm tired of working.
If I had known the Library was so busy I might have gone to the McDonalds again. Well, there's always next time.
For now I'm going to try and get the Dialogue working with the new Interactable system.
3:05pm - Something's nagging at me. It's a problem with the whole UnityEvent delegate thing. In order to do the baton pass my MobileInteract component needs to turn off the PlayerInput component on the Object it's a part of. But I was all set to activate any sort of event with my MobileInteract/Interaction intersection. So, there might be other types of interaction that don't require the PlayerInput to be shut down, and which wouldn't know to start it up again. Hmm... Things you interact with in JRPGs... Mostly they're things that come with a dialogue. Are they all? They all could be. So maybe this is okay?
I'm not sure. Doors are an example where you want to just push the button and enter, without having to have a dialogue pop up and ask if you want to go in. There might be buttons you want to push that don't have a dialogue, too. Chests/treasures have a whole different sort of dialogue.
So yeah, it's not okay.
What shall I do as an alternative?
3:23pm - Bleh, someone just put on some fragrance. I've never had to deal with that at the McDonalds. :/
There's a lot of stuff here that bugs me that I don't have to deal with at the McDonalds. I'm definately reconsidering the idea of working here more often.
Anyways, I'm trying to figure out what to do with my interactables...
I think what I need to do is have the MobileInteract know what sort of interaction it's interacting with, rather than just firing off a remote function on some other object.
Maybe instead of passing a function, the Interactable component should pass an object? But if I have different components for different interaction types, how would it know what sort to recieve?
If I used polymorphism here, I don't think it would work, because the MobileInteract needs to know the type it's interacting with. Treating it as a base class won't work. I could put a function on the base class though that returns the type of the interaction so it knows what it's working with. That might work...
Alright let me run through the logic again to make sure I've got it clear in my head.
First the MobileInteract activates and gets a reference to the Interactable. Then it activates the Interactable's interact function.
...
Oh hang on. I could have the interact function return an enum that says what kind of interactible it's activating. But then, how would the Interactible know that? o.o;;
There's a third hand in this pot and that's the Interaction that the Interactable is triggering. So yeah, the Interactable component won't even know what type of Interaction it is. It'll fall to the MobileInteract component to figure out what it's been passed.
So let's try that logic again.
First the MobileInteract activates and gets a reference to the Interactable. Then it takes the public Interaction component from Interactable's reference. Then it uses the Interaction component's GetInteractionType() method to figure out what type of interaction it's dealing with, and it responds accordingly, potentially turning off the PlayerInput component. Then it runs the Interact() method on the Interaction, causing it to do its thing.
It almost seems like I could combine Interactable and Interaction, except that then there wouldn't be an easy way to find it. So all Interactable does is provide an easy to lookup redirection to the actual Interaction.
I'm going to code that up and see how it works.
5:12pm - I need to use the washroom and I don't feel safe leaving my laptop out in the library. I'm going to pack up and head to the McDonalds and work there until I'm tired of working.
