Inputs and properties

[dire dome]

First question to start things off - are "functions" a thing in unity, or have I been calling them the wrong name all along and they are just all classes?

[grave karma]

Functions are what you call a method that doesn't belong to a class, so really C# only has one kind of function: a lambda (or inline) function.

A method is conversely a function that is a member of a class. You can't write code outside classes in C#.

A lambda function is sort of it's own topic.

MyClass.SomeMethod() is a pattern for a method. You can't have SomeFunction() outside of a class, which is not universal to all languages.

Action storedFunctionInAVariable = () => { return "Hello world"; }; would be a lambda. That code would execute inside a class, but it doesn't actually use the class. This might be a relatively advanced topic.

[dire dome]

So generally what I refer to as functions is incorrect.

That makes sense, I'll just call them classes to make sure I don't get confused

[grave karma]

Yeah. They are different from methods and C# can only have methods in signature space. By signatures, I mean the whole Name.Name hierarchy.

In other words, method = a function that belongs to a class.

So good on you if you understand the difference because it isn't inconsequential, even in C#.

[dire dome]

Alright, so back to InputMaster. I'm still a tad bit confused about how get helps with it - is it something with it being a static?

To my knowledge statics are only used once, and everything else is re-accessing the same static, correct?

[grave karma]

Would you want to talk about this in a voice call? I might be able to go over things a bit more comprehensively.

Brb - stepping away briefly.

[dire dome]

I can't voice call at the moment, it's getting pretty late and I am a bit to tired to get my words together well and I find it easier through text.

[remote oracle]

Actually function and method are often used interchangeably in C# context. You can even find some examples in the C# docs by Microsoft.

[grave karma]

This could very well be, but that's convention or people just not being too bothered. It's a C# thing that all named functions are methods.

But yes everyone knows what someone is talking about.

Anyway, brb again.

[remote oracle]

It's true that the more common name in C# context is "method". I also prefer using that. Function sounds like a more general term applied in other disciplines, but basically coming from math.

[remote oracle]

Static members belong to the class and not it's instances.

[grave karma]

This is exactly the reason for it. Methods are actionable and used as verbs within the context of their class whereas functions define a transformation from inputs that returns a single result. Critically, a function must live in the global scope, which is why it doesn't exist in C#: there is no global scope, only classes and an entry point.

[dire dome]

I think I'm getting this. So because there is only one static, it's not a "one-and-done" like other classes when they are. Instead they are continually there and stuff is run using staticThing.someProperty?

[grave karma]

When you instantiate an object from a class, they don't get the static variable. The static variable lives on the class itself and isn't part of the "copying" process.

[remote oracle]

I've never ever heard such a definition of a function. Specifically the part about it living in the global scope. I do agree that function refers more often to them transforming some input and returning the results, while methods generally don't have that constraint.

[dire dome]

I see. I assume "instantiating" something is the esoteric term for running a function (eg. doThisThing(); )?

I hope I used esoteric right, I recently learned the word and haven't had the chance to use it much

[grave karma]

Behaviourly, functions and methods kind of do the same thing, but their uses are very different. The global scope bit would be true of any named function.

I'd like to offer that lambdas can exist in a narrowed scope but still not meet the criteria for being a method.

Consider that in a language like C++, this actual matters. It isn't all that important in C#.

[remote oracle]

Where did you actually get that global scope thing?

Ah, ok, if you're talking in C++ context, indeed, there is a difference.

[grave karma]

Yeah I first started with PHP back in like 2004, but as much as we can joke about that language, the principal applies there too.

[dire dome]

I'll probably make you feel old with this, but I was born in 2004 and now I am legally an adult

[remote oracle]

However, in C# there is no "global scope" at all. There are top level statements that were added recently, but they're not the same.
In C# you would hear method and function terms used interchangeably 99% of time.

[grave karma]

Yes, this. In C# it only matters if you're talking about assembly really, because functions without signatures can exist due to lambdas.

But yes, 99% will not care.

Anyway, I hope I managed to explain the reason why these two words exist simultaneously for @dire dome . 😄

[dire dome]

I think I'll just stick to calling them classes and methods for now

[grave karma]

And lambda functions! (when the day comes)... 😄

[dire dome]

mmmm lamb

[remote oracle]

Instantiating refers to creating a new instance of a class in C# context and an instance of a prefab in Unity context. You've probably seen the Instantiate method. That is used in unity to create a new instance of an object/prefab.

[dire dome]

I see, so the term is reused for both Unity creating objects as well as "running" a class

[grave karma]

MyObject obj = new MyObject(); is the simplest form of instantiation you'll find in Unity. That means to create an object from a class. The class defines the object, but obj is where the "instantiated object" lives.

[remote oracle]

No. You're not "running" anything. And usually in C# you'd say "create a new instance".

[grave karma]

The class is a cookie-cutter and the objects are cookies made from it.

By this logic you can think of non-static fields as attributes of the cookies, and static variables are attributes of the actual cookie cutter.

[dire dome]

Gotcha, so when you use SomeClass someName = new SomeClass() that's instantiation. I misunderstood and thought that just using SomeClass(parameter) was instantiation.

[grave karma]

So you know, that's called invocation.

😄

[dire dome]

Ah, good to know

[grave karma]

You invoke a method, but you instantiate an object.

[dire dome]

So in the original class,

  private static InputActions _inputActions;
  public static InputActions InputActions
        {
            get
            {
                if (_inputActions == null)
                {
                    _inputActions = new InputActions();
                }
                return _inputActions;
            }
        }
}```
, _inputActions is used as a list of the saved input actions (which are keys/buttons). Is this correct?

[grave karma]

InputActions is GameControls in my application.

You called your generated class something different from what I do.

[dire dome]

Oh right

    {
        private static GameControls _gameControls;
        public static GameControls GameControls
        {
            get
            {
                if (_gameControls == null)
                {
                    _gameControls = new GameControls();
                }
                return _gameControls;
            }
        }
    }```

[grave karma]

Sure, might as well be that.

[dire dome]

And so when I run GameControlsMaster.GameControls it will check to see if there are any assigned game controls, and if there aren't then it will set all of them to the default controls?

Or I suppose it would set them all to whatever the saved GameControls are

[grave karma]

GameControls myControls = GameControlsMaster.GameControls; returns the same instance of GameControls, no matter where from or when it is used. This is because new GameControls(); gets called only once ever.

[dire dome]

I see

so then when I modify any instance of GameControls it will be used from any other version of GameControls

[grave karma]

That's right. Note that it is still not connected to the asset after instantiation but that will always be the case. When starting rebind operations, you need to do something like this:

InputAction myBindingAction = myControls.asset.FindAction("myactionname");
myBindingAction.DoTheRebindStuff();

[dire dome]

That makes sense

[grave karma]

GameControls myControls2 = GameControlsMaster.GameControls;
GameControls myControls3 = GameControlsMaster.GameControls;```
...are all pointing to the exact same instance and not 3 separate instances cookie-cut from the original GameControls class.

The first time it is assigned, new is used. After that, the same stored object is served again and again.

Brb again.

[dire dome]

So I assume that it is impossible or bad practice to just directly modified the Input Action Asset that sits in the unity project, which is why I need to make a new version inside of the code that everything accesses.

[grave karma]

                {
                    _gameControls = new GameControls();
                }
                return _gameControls;``` Look closely here if you're wondering what is going on.  Remember that `get` defines what happens when `GameControlsMaster.GameControls` is requested.

[dire dome]

This seems to all be making sense now

[grave karma]

It's not bad practice, just somewhat impractical due to how a computer can have many input devices, different players can play split-screen on the same device, key assignments can be with/without modifier keys, compatibility with VR devices or screenreaders, etc.

You can't easily isolate changing keyboard keys in that environment, for example, without considering what it means to be an input. Unity provides tools to make this happen in a meaningful way, but it means playing by their system.

What if the player has 2 keyboards?

[dire dome]

That makes sense, and also explains why all of the older threads when the new input system was released talked about it as though it was useless and poorly designed

[grave karma]

Yeah, it's actually really effective at what it does when you understand the breadth of what it all manages.

[dire dome]

So I think the next step is to find out how I would go about making the controls save between exiting and reentering the game? I assume the static is lost after closing, correct?

[grave karma]

I think in the editor it will save just fine but once you publish, the changes won't save due to how ScriptableObjects work.

But yeah... give me a moment on that one.

[dire dome]

A longer-term goal would be having multiple saved "profiles" of controls that many local games have, such as Crawl and Rivals of Aether (along with many other platform fighters).

However, I don't think I need to learn all of that tonight, if I try to learn to much without some rest I won't leave my brain time to process it all and retain the information.

That's one of the biggest problems I have run into with super long tutorials and the likes in the past

[grave karma]

        {
            for (int i = 0; i < action.bindings.Count; i++)
            {
                PlayerPrefs.SetString(BuildActionStorageKey(action, i), action.bindings[i].overridePath);
            }
        }```
Here is how I take a *single* InputAction and save its bindings.  `PlayerPrefs` is a simple interface provided by Unity to store to registry.

There's a bit to digest in there as actions can have multiple bindings. Also, composite actions such as WASD movement as a 2D Axis will have multiple binding entries internally. This is a consequence of inputs being as complex as I mentioned earlier.

[dire dome]

Yup, I have looked into PlayerPrefs quite a bit, I had a whole 8+ class menu system written out before realizing I wanted to switch to the new UI system before it was too late

Luckily it wasn't written out in code yet, but I spent around two hours of my morning writing out the design in pseudo-code on notecards. I found it a lot easier to visualize the interactions when everything was in front of me on paper

Anyways, I think I have a good understanding of how to use the input system here

I also learned a lot about C# which is going to be useful for a lot of future scripts

Thank you so much for your time and patience Omi. I am going to get some sleep now.