playMaker

Author Topic: Prefab States  (Read 344 times)

Broken Stylus

  • Sr. Member
  • ****
  • Posts: 282
    • View Profile
Prefab States
« on: September 23, 2019, 09:39:07 AM »
As the title says.
Bye.


 :P
There are typical states I store in a "toolbox" FSM, currently a template but it could be just another generic FSM.
Thus far, I pick the state I want, then copy paste paste paste^333 etc. in all FSMs that need it.
But if I want to change the content of this Mother State and apply it to all copies, I have to go through aaaallll of them one by one.
So I'd love to be able to store Prefab States and be able to create instances of them, and also apply local changes according to the same principle used by Unity for its own prefab system.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 14684
  • Official Playmaker Support
    • View Profile
Re: Prefab States
« Reply #1 on: November 13, 2019, 01:10:26 AM »
Hi,

 is that not what Prefab Variant is about? have you tried that?

Bye,

 Jean

Broken Stylus

  • Sr. Member
  • ****
  • Posts: 282
    • View Profile
Re: Prefab States
« Reply #2 on: November 14, 2019, 04:52:42 AM »
is that not what Prefab Variant is about? have you tried that?

It's Unity swapping names more than anything else:
Explanation

Quote
Quote
Looking at the video it seems as if prefab variants are just nested prefabs that use the overrides to create variants, however since things are clearly presented as separate I'm wondering if I'm missing something there...

It's practically the same. Say you have a Prefab called 'A':
If Prefab 'A' contains another Prefab as a child GameObject, we call that a nested Prefab.
If Prefab 'A' has another Prefab as its root GameObject, then Prefab 'A' is a Variant and we called the other Prefab its base Prefab.
So it's really all about whether it's a child GameObject or the root GameObject.
In both cases you can have overrides on the other Prefab. And in both cases, if you make changes to the inner Prefab, you will see those reflected in the outer Prefab ('A') too (except if they're overridden).

Almost like
- root/base (parent prefab)
- child/variant (nested prefab)
But without a clear hierarchy (aside from a difference in icon look in prefabs, ehh).

What I'm thinking of is a State Template, found for example in something like favorites, which you can instantiate in a FSM from a personal list/database, and override locally too.

I have several states I know I often use but for now, they're stored in a FSM, which is stored in templates but it could be on any random Game Object tbh but since I have the Templates tab docked, it's slightly faster to access. It's a sort of toolbox but damn, it would be so faster if I could just right click in the FSM and select it from a drop down menu or a pop window within the Graph view.

Right now I go back and forth between the FSMs I work on and the "toolbox", and copy/paste, most of the time without even needing to change the content aside from one variable, at most.
« Last Edit: November 14, 2019, 08:28:16 AM by Broken Stylus »

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 14684
  • Official Playmaker Support
    • View Profile
Re: Prefab States
« Reply #3 on: November 24, 2019, 11:20:46 PM »
Hi,

 again, your explanation is the definition of a prefab variant, at least in my understanding. which is not the same as nested prefab, and not the same as overrides.

BUT, inside an FSM, it's true that you can't have differences between prefabs without an override or variant at the fsm level.

 for this, I would rather use templates, and have variants of prefabs using different templates.

 I also usually resort to child gameobjects which contains specific logic and create a contract between the parent and these childs so that the parent doesn't care what the child is doing, it simply communicates via a generic set of events and variables. say, you have a weapon with various effects, make effects a child of the weapon and have the parent control the life cycle of the weapon, probably waiting for effect to finish, so the parent expects from its internal unknown fsm, a callback when things are done, then it can handle the weapon life cycle.


Bye,

 Jean