+4

UNIT TOOLS: Events (Experimental Graph Communication)

JasonJonesLASM 4 years ago updated 4 years ago 6

UNIT TOOLS: EVENTS

Latest Version: v0.2


SUPER CLASS (OOP/Encapsulation/Inheritance)

This was crazy, because I didn't touch next to any API, just for one unit to get the current graph of that residing unit. This is all event driven, but does and will continue to act like it's not, but it has the edge that it is events, it is in bolt, so a class can be placed anywhere, and access like anything else.

  • SUPER CLASS UNITS


    • Super Class
    • Get Class Variable
    • Set Class Variable
    • Super Class Method
    • Invoke Class Method



GRAPH TAGS

Setting and Getting variables from any graph work the same in both Super Classes and Graph Tags. The only difference is its stripped down nature. It is intended to be a super quick super light weight solution to setting and getting variables in any graph anywhere. Yes including from outside to insides state machines, 20 million children below or parents above. Doesn't matter.

  • GRAPH TAG UNITS


    • Graph Tag
    • Set Tag Variable
    • Get Tag Variable

*Below are some examples. These a little earlier shots than the current version, but it works the same way. I will update that soon. But the "Super Class" here is the now Variable Tags. It was split.


SETTING AND GETTING NEST GRAPHS



SETTING AND GETTING PARENT GRAPHS



Latest Version

DOWNLOAD v0.2

You will need to regenerate your units. There is two packages that are needed and already included. Flow Control assembly (You can uncheck these if you have a newer version then when this was last update), and a Helpers assembly. As with all my previous assets, no need to add into assemblies or types. 

Previous Versions

DOWNLOAD v 0.1


ROADMAP

Will add the following most likely, as long as it doesn't blow up my computer making these.

  • Nested Super Classes
  • Super Class Return Method
  • Data Binding
  • On Value Changed Event
  • Lose those pesky Control Inputs on the getters. Needs a workaround though.


Bolt Version:
Unity Version:
Platform(s):
Scripting Backend:
.NET Version (API Compatibility Level):
+1

Fixed the links, sorry about that, thought it was working and went to sleep. All good now.

Are you still developing this macro. Mostly interested in that return method.

Not specifically. Wasnt hearing much feedback,  didn't really have a solid direction of what I was doing and what would benefit people more across the board. But I could put together a generic one sometime soon. For a return method of some sort. Any suggestions with this stuff would help.

I love experimenting with this kind of stuff though. 

Not sure. I was creating things in bolt and wanted to create something that was reusable. I thought about trading events back and forth between flow machines. That however seemed as if it'd become harder to follow as I created more.

With this I was thinking it'd be slightly more organized. I could create an empty gameobject called "BoltClasses." Then underneath that have gameobjects that were like individual "namespaces." Then calling those "namespaces" to utilize their "classes."

Not sure if that's the best way of doing it.

There are Super Units. I'm not sure if I should just organize macros into folders. Then use them as a super unit. 

What advantages does this serve over organizing macros into folders to be called into Super Units?

the main thing was it turns your graph variables in its graph into retrievable values by name, but that's why I changed and made tags seperated. Did the same and its core, but super small. Honestly it was experimental, and the more I played with it, the more I couldn't see the benefits of it. Only way inheritance would help, is to have real stuff behind it. Actually being able to do interfaces, abstract classes, and the like, and effecting unity just like normal scripts.

I think graph tags do the job personally as far as returning those kind of variables. Maybe interested in retrieving anything attached to it as another tag type perhaps? Dunno.

The first way you did it, was how I originally did it. You are right though, it got very hard to read. I'd like to do something cleaner.

I manage my personal macros just like namespaces.

UI.Effect.Default

Stuff like that. Also wrap events in macros that are harder to read. Then just use that instead. Filters sent through are great too.