Can't get interface from auto generated Input Action Asset class to work

I'm getting the null reference error to my interface IWorldActions.

Assets\Scripts\Player\PlayerControl.cs(6,45): error CS0246: The type or namespace name 'IWorldActions' could not be found (are you missing a using directive or an assembly reference?)

This interface was generated automagically from the Input Action Asset class script. I don't understand why I'm getting this error... its like the interface doesn't exist, but its there. I'm typing it next to my other player classes declaration, ie:

public class PlayerControl : Monobehaviour, IWorldActions

Here is the interface code at the bottom of the auto generated class:

Code (CSharp):

1.     public interface IWorldActions
2.     {
3.         void OnMove(InputAction.CallbackContext context);
4.         void OnJump(InputAction.CallbackContext context);
5.         void OnActivate(InputAction.CallbackContext context);
6.         void OnTarget(InputAction.CallbackContext context);
7.     }

Here is my code in PlayerControl.cs:

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4. using UnityEngine.InputSystem;
5.  
6. public class PlayerControl : MonoBehaviour, IWorldActions
7. {
8.  
9.  
10. ...
11.  
12.  

All I wanna do is take full advantage of the interface in the auto generated class like this guy explains (at 10:08)

 

Here is an example from the official documentation at https://docs.unity3d.com/Packages/com.unity.inputsystem@1.0/manual/ActionAssets.html

Code (CSharp):

1. using UnityEngine;
2. using UnityEngine.InputSystem;
3.  
4. // IGameplayActions is an interface generated from the "gameplay" action map
5. // we added (note that if you called the action map differently, the name of
6. // the interface will be different). This was triggered by the "Generate Interfaces"
7. // checkbox.
8. public class MyPlayerScript : MonoBehaviour, IGameplayActions
9. {
10.  
11. ...
12.  

This is all I want to do, but again I'm getting

Assets\Scripts\Player\PlayerControl.cs(6,45): error CS0246: The type or namespace name 'IWorldActions' could not be found (are you missing a using directive or an assembly reference?)

 

If I put

public class PlayerControl : Monobehaviour, PlayerInput.IWorldActions

it works. PlayerInput is the auto-generated class that has the interface, sure, but NONE of the examples I see use this dot syntax for referencing interfaces. Why does it work for them and not me? Even in the microsoft C# reference docs, I didn't see them having to use dot notation (albeit they weren't examples that had cross-file references). Anyone know what would cause this?

This kind of crap drives me bonkers. Spent over an hour on this and only because I lucked out and decided to try a fleeting thought before I hit the pillow. Now I want to know why it works... whats different, why did I have to do that, etc. Buying a beer for the first person that splains this to me

 

Yeahhhhhh the documentation isn't that great, or at least it's missing some small details that will drive you insane trying to figure it out

 

For me I had to access it with PlayerControls.I___Actions
I just put `using static PlayerControls` at the top tho.

I saw somewhere something about compilation order, but don't have the time to bother trying to understand it.

 

The video linked seems to be no more... do you have the title or a separate source by any chance?
Was looking for information on how to specifically use this interface, looking at the API I'm assuming by calling the

SetCallbacks(this)

(or any other class that implements it) on a instance of the inputs map (in your case I guess it would be a GameplayActions input maps). Is that correct?

I started by using BroadcastMessages downwards, it's for UI button pressing via GamePad, I can be a bit reckless on that front for now, no performance critical situation and just do scripts almost like Unity (Start, OnEnable, etc... the same for OnPrimaryMove, OnAccept, OnBack, etc)... but then figured if I have to write methods anyways might as well just let them implement the interface, tie the events via that and call it a day.