+4

Get Machine Instance

JasonJonesLASM 3 years ago updated 3 years ago 8

Decided since I have some extra time for a few days I'd go back and redo some old stuff. This is one of them. Saw a couple people over time asking how to see if a machine exists on an object. This should solve that. 


* Note: This will only work with Macros. For Embed, you need to handle how to resolve a type in your own way.




DOWNLOAD the NEW Version 1.0.0

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

Very nice contribution

UPDATE:  I forgot to cycle between all components for machines. Once you added another machine, It wouldn't work. Fixed and updated! Same Filename and URL. Download Here


Sorry, I am very baby new to bolt. Why not just use the get / set graph, object or scene variables or am I missing something here?

When you get graph variables it expects the variable in the current graph. There is no port other than a string lookup. Object variables  can take a game object, graph doesn't. So I made this to cycle between all macros on an object, to first, find the correct macro type you want. Then get the graph and it's variable from that instance. Would kind of be a pain to do this many nodes every time you wanted to get a graph variable from a different object.

Hi and thank you, I understand a little more, but why use then graph variables in the first place when you could use object vars get/ set or even prefab the scene variables with common vars like input and then these variables are always in your scene.  I never want to have to say get key arrow up, I just want to look for a variable in update if it is being pressed or not. For that I use Scene variables

So what can a graph variable do for me that the others cannot?

+1

I can't speak on all use cases, but I've been strictly a C# programmer in Unity for like 6 years. Maybe it's old habits, but I thought it might be useful for people who wanted to use graphs as classes. That way you could know if a particular thing is of that type of macro. If so, you know it'll have so and so variables and functions to work with and won't be exclusively tucked onto one object. Less mistakes, more modular practices. Sure you could do object variables. No less beneficial, probably better for certain reasons. But messy, and prone too mistakes with larger games and crazy amount of variables. For me anyways.

If anyone does decide to use it, you'd want to use the cache node on the instance of the macro before accessing it's variables. Then you won't need to search every frame.

As I'm learning this tool, I'm finding better ways to do things I never thought to do by just coding. I haven't even used this myself since I created it. But it works for it's purpose.


+1

Then what needs to be done, which would be cool is for example: Build a flow macro with its own graph variables. Then save it as a macro. When needed drag it onto another graph as a nested and still hold its variables. Like writing a onetime input manager that you can drag anywhere where you need it. That would be encapsulation, just ask get graph, is arrow up down? Boll true or false no matter where you are from whatever graph, think about that!

I have not even had this tool a week yet, I am a very bad coder but good in Playmaker. This tool is teaching me so much about c#.