Coroutines & ScriptableObjects | Official Unity Discord | Page 1

untold ravine Dec 16, 2021, 2:05 AM

#

Sure. Currently, WeaponAbilities are stored within another ScriptableObject - Weapon - which is stored in a MonoBehavior - WeaponManager. Are there any good ways to pass the coroutine up to the WeaponManager class? It would be doubly convenient (if possible).

#

Some code screenshots:

#

sturdy tapir Dec 16, 2021, 2:10 AM

#

technically you could pass the reference whenever you use an ability through the function calls

untold ravine Dec 16, 2021, 2:10 AM

#

true

#

so in the OnEnable method of the WeaponManager I'd do something like

void OnEnable() {
  foreach(Weapon w in weapons) { w.weaponSystem = this; }
}

and in the OnEnable method of each Weapon

void OnEnable() {
  foreach(WeaponAbility a in abilities) {
  a.weaponSystem = this.weaponSystem;
}

so that each WeaponAbility could call methods from the WeaponManager class, I presume?

sturdy tapir Dec 16, 2021, 2:17 AM

#

yeah, seems like it would work

#

not sure if it applies but, because scriptableobject instances are basically the .asset files themselves, you don't want too much state information inside of them (for example the position vector) if you are going to be re-using these scriptableobjects in multiple places

#

an example of where saving state information like that wouldnt work would be, say, if you want enemies to be able to use these scriptableobjects as well

#

or, say, you want to be able to have multiple of the same weapon in your inventory

untold ravine Dec 16, 2021, 2:20 AM

#

yeah, this is sort of what I was asking

#

my biggest concern with this is whether or not I was storing too much within the ScriptableObject

#

I like the ability to have information saved outside of runtime, but to me it seems like there's probably a better way to store all this important data

sturdy tapir Dec 16, 2021, 2:22 AM

#

the way you want to think about it is just => store runtime data in non-scriptable objects (for example position, velocity, etc) and store constant data / functions inside the scriptableobject

untold ravine Dec 16, 2021, 2:22 AM

#

I see

#

and so if I wanted to store something like the following

#

#

in a ScriptableObject, that would be more or less okay? Still getting the hang of ScriptableObjects

sturdy tapir Dec 16, 2021, 2:25 AM

#

well.. sort of, let me try and explain the problem a bit better

#

basically, if you have multiple enemies, and they all have a reference to the AssaultRifle scriptableobject for example

#

every single enemy will receive the callbacks

#

since it's all the same scriptableobject instance

untold ravine Dec 16, 2021, 2:27 AM

#

so the impression I'm getting is this is probably a bad idea if I want to procedurally generate content?

sturdy tapir Dec 16, 2021, 2:29 AM

#

well it's a bad idea if more than one thing is going to access the scriptableobject instance at a time

#

basically it should just be a template for data

#

like some BaseStats scriptableobject is a good time to use scriptableobjects

untold ravine Dec 16, 2021, 2:30 AM

#

I see

sturdy tapir Dec 16, 2021, 2:30 AM

#

but nothing dynamic at all

untold ravine Dec 16, 2021, 2:30 AM

#

so nothing created in runtime (not modified, just created)?

#

the end goal is (really, was) to have a procedural weapon generator that automatically creates individual ScriptableObject instances for different weapons

sturdy tapir Dec 16, 2021, 2:33 AM

#

I will try to illustrate the main issue again

#

let's say you make one scriptableobject instance, and it's a weapon

#

if you have two enemies in your scene

#

and you drag the same scriptableobject into some public field in both of the enemy's scripts

#

any changes that one enemy makes to the scriptableobject will be reflected in both enemy's references

untold ravine Dec 16, 2021, 2:34 AM

#

so if it's just a container full of methods that doesn't get modified at runtime, it's fine then?

sturdy tapir Dec 16, 2021, 2:34 AM

#

yes, exactly

#

not modified at runtime

untold ravine Dec 16, 2021, 2:35 AM

#

just accessed

sturdy tapir Dec 16, 2021, 2:35 AM

#

yes

#

that is the intended use

untold ravine Dec 16, 2021, 2:35 AM

#

okay, cool

sturdy tapir Dec 16, 2021, 2:35 AM

#

but like I said before, this rule only applies if you are going to have multiple things accessing the same scriptableobject

#

if you have some TerrainGeneration scriptableobject, and it actually does get modified at runtime

#

that's probably fine since only one thing is ever accessing the scriptableobject, or rather it makes perfect sense that there is only one instance

#

conflicts will arise if multiple things are fighting over control of the variables, though

#

which is what I described in the "enemy" example

untold ravine Dec 16, 2021, 2:37 AM

#

I see

sturdy tapir Dec 16, 2021, 2:38 AM

#

so really it's up for you to decide, as I don't know the plan you have for these scriptableobjects exactly

#

but if you understand the limitations, you will probably be fine

untold ravine Dec 16, 2021, 2:39 AM

#

I think I have a grasp of what I need to do now, though

#Coroutines & ScriptableObjects