#also mind if we continue this tomorrow
1 messages · Page 1 of 1 (latest)
Ok.
Thank you so much, truly
hello, are you currently avaliable @tawny wasp ?
@tawny wasp I made a delegate array for my skill list https://gdl.space/oxoyivayaq.cs
Why..?
didn't you say to make an array for my skills?
Yes, but weren't your skills scriptable objects?
ah well....I decided that SO's aren't really helpful here
it felt like I was just over complicating everything
that wont be a problem will it?
Well, it doesn't solve any of your problems does it?
Where are you gonna store skill data?
And what exactly do you plan to do with these delegates?
The delegates?
Do you understand what a delegate is?
function containers?
Okay, let's say so. And how do expect them to hold any data?
the methods I made will hold the data
Methods don't hold data. At best they hold temp data required for the method processing or hardcoded constants.
how do they not hold data? like my attack_one method
That's the method yes. How do you expect to get a skill sprite out of it for example?
ah, it only holds at the moment data
and since its not in update nothing can be called over and over, only once when pulled
yeah this wasn't a good approach huh?
should I have done SO's?
First of all, approach to what? What problem are you trying to solve with it?
skill storage
It doesn't hold a skil. It holds a method. At best it's the behavior of the skin. What about other type of data, like the sprite?
oh I see, methods usually only do one thing, it doesn't have enough data to also hold image data or hypothetically animation
Yes.
crap, what can I do?
Well, you've been suggested to use SOs.
The other method is to define a plain class that contains the skill data and initialize it on the character prefab. In either way, you'll need to use interfaces of inheritance to define the actual behavior of the skill.
how would the SO's work?
SOs are basically classes that you can serialize as assets.
Same as MonoBehaviour on gameObjects, but without gameObjects. They can live just as files in your assets folder. That's why they're useful for defining static data and referencing it from wherever you want.
So uh…I’ve actually decided on some design changes
I still will do SO’s for skills, but things are much more simpler
Okay
Im throwing away the idea of a skill menu or item menu that generates buttons, too complicated
The buttons mainly just puts SO’s into queue
So what's the difference with what you planned before? The buttons are preexisting objects now?
Bingo
Ok, so what's the actual question?
Well it’s more about the SO’s since the Queue is just a gameobjecy array, I’m not sure on how to do the SO’s now
No I meant the SO’s themselves
What about them..?
Please ask whole questions. I'm kinda tired of playing the guessing game...
Well I’m not sure what to fill into the SO’s, my idea for the queue is to use empty game objects to represent the array and they would change if there was an SO was assigned, so from what I believe would I assign an SO to a gameobject in this case, and have it filled with just image data and on execute, or an SO not attached to anything and still have all that?
Why do you need an empty go if your goal is to get access to the SOs in the end? Just have a queue of your SOs. And I don't understand the second part of your question. You add whatever data you need to the SO.
The Empty GO are meant to represent slots for the skills, to show what skills are selected and the order they will go in, the timeline will show an image of the assigned skill as well