SkookumScript for Nintendo Switch

Hi,

I’m trying to get a test project up and running on our Switch dev kit. The marketplace page says that it will work on all platforms. I’m building the engine and plugin from source and get an error when building with the Switch configuration:

59>  [342/617] SkRotationAngles.cpp
59>  In file included from F:\Code\UnrealEngine-For-Switch\Engine\Plugins\Runtime\SkookumScript\Source\SkookumScriptRuntime\Private\Bindings\VectorMath\SkRotationAngles.cpp:13:
59>  In file included from ..\Plugins\Runtime\SkookumScript\Source\SkookumScriptRuntime\Public\Bindings\VectorMath\SkRotationAngles.hpp:15:
59>  In file included from ..\Plugins\Runtime\SkookumScript\Source\SkookumScriptRuntime\Public\Bindings\VectorMath/../SkUEClassBinding.hpp:15:
59>  In file included from ..\Plugins\Runtime\SkookumScript\Source\SkookumScriptRuntime\Public\SkookumScriptBehaviorComponent.h:18:
59>  In file included from ..\Plugins\Runtime\SkookumScript\Source\AgogCore\Public\AgogCore/AIdPtr.hpp:96:
59>F:\Code\UnrealEngine-For-Switch\Engine\Plugins\Runtime\SkookumScript\Source\AgogCore\Public\AgogCore\AgogCore.hpp(74,6): error : No known platform type is defined (A_PLAT_PC32, A_PLAT_PC64, A_PLAT_PS3, A_PLAT_PS4, A_PLAT_X360, A_PLAT_X_ONE, A_PLAT_WIIU, A_PLAT_iOS, A_PLAT_tvOS, A_PLAT_OSX or A_PLAT_LINUX64)!
59>      #error No known platform type is defined (A_PLAT_PC32, A_PLAT_PC64, A_PLAT_PS3, A_PLAT_PS4, A_PLAT_X360, A_PLAT_X_ONE, A_PLAT_WIIU, A_PLAT_iOS, A_PLAT_tvOS, A_PLAT_OSX or A_PLAT_LINUX64)!

HAven’t been able to find any info regarding consoles, except for this quote from few years ago here on the forum:

With a Standard or Pro License you can run :sk: on any platform that has a pre-built binary. You’ll notice that consoles aren’t on that list, if you want to build for consoles you need to have a conversation with the :sk: folks for a Project License.

Do I need to contact or do something more to have SK work on consoles, ,specifically the Switch? We’ve already have all the necessary setup for non-SK projects and successfully run those on the Switch hardware, but SK won’t compile when installed into the Engine/Plugins with the Switch as the target. It works fine when Win64 is selected…

edit - using UE 4,24 and latest source from the SkookumScript github as per the instructions

Many thanks

Hello and welcome!
There currently is not support for the Switch in :sk:, but this is because I don’t have a dev kit. The Switch uses the Tegra X1, which is just another ARM cpu and :sk: runs on ARM already.

I think it would be fairly simple to add support for the Switch, but it is a difficult task to write the code blind. Do you have a C++ engineer on your team? I could point them to a few places in code to get started and they could likely stumble to the solution 1 compile error at a time.

Feel free to PM if anything is sensitive.

Thanks @error454 - I’ll gladly take a stab at making it compile. I was already looking around in the AgogCore file but haven’t made any changes yet - some pointers would be much appreciated! Feel free to PM or reply here with the places to get started and I’ll work my way through :slight_smile:

Thanks!

Ok, here is how I’d get started on this.

  1. You need to add the switch to the list of WhitelistPlatforms in the SkookumScript.uplugin. This is required for all modules except for the editor modules, follow the pattern there it should be easy to see.
  2. SkookumScript.Build.cs needs an entry for the Switch, after the PS4 entry. Platform name should be SWITCH.
  3. AgogCore.Build.cs needs an entry for the Switch, after the PS4 entry. Platform name should be SWITCH. Public definition should be added for A_PLAT_SWITCH.
  4. AgogCore.hpp should add && !defined(A_PLAT_SWITCH) to the WiiU line
  5. AgogCore.hpp should add an #ifdef A_PLAT_SWITCH, this will contain all of the custom work to support the platform. See the definition for the Xbox One to see an example of including any custom platform includes. Since Switch is ARM64, you might start by copying the entry for A_PLAT_ANDROID and forcing the A_BITS64 define.

Let me know how it goes.

Thanks for this!

I was able to get it all to compile, was getting a socket error when deploying to the dev-kit with on the fly cooking but that may be the project setup - going to test some more but feels like making progress, I’ll report back if hit any walls or get it running!

Thanks again!

Great! If you could send over a pull request or let me know the contents of the #ifdef once it is all working I’d love to get this into the repo.

Who threw the socket error? Was it the local :sk: runtime or the :sk: IDE? Are you using the ide-ip.txt to have the :sk: runtime on the switch connect back to the IDE? Maybe the switch requires some kind of manifest permissions to allow socket communications.

I certainly will once it’s all up and running. Good news is that I now have the scripts (or at least, a rotating cube) running on the Switch!

The socket error I mentioned was from the Switch connecting to the Cook Server but after a couple of engine rebuilds that got sorted.

What I’m having trouble with now is having the Switch connect back to the :sk: IDE - I’ve set up the ide-ip.txt and when I deploy to the Switch I get messages in the IDE that it has disconnected from my PC runtime and connected to the new runtime which all looks good. However, when I make a change and hit F7, it doesn’t appear to update and I don’t get any “updating runtime” messages in the console.

I’ve put the console output up on pastebin here: Skookum IDE console output

Are there any other logs or places I can look that may help find out what’s not working? I’m pretty confident the problem isn’t with the Switch setup, as the Cook Server connects and I’ve confirmed that it has network access while running - if network access isn’t available it displays a warning message during runtime which I had to enable to remove.

Thanks again, can’t wait to get stuck into :sk:

Taking a look at the console output, I can see a few things.

  1. The IDE is binding itself to the *.99 address on your PC
  2. A remote runtime with address *.129 connected and appears to be just fine

A few things to try in the SkookumIDE workbench (REPL) window, try typing in GameLib.platform_name and then make sure the cursor is active on the line and press F4 to execute. This should be an easy test to see if you are connected to the correct runtime. It will print the return value of the method in the IDE window (it should be something other than “Windows”).

You can also try this command on the REPL to see debug text printed to the device:

SystemLib.print_screen("Hello world", duration: 50)

Or this command which will turn on stat unit performance information on the device (should be very visibly obvious):

SystemLib.execute_console_command(, "stat unit")`

In the logs I see that you modified and reloaded the file _rotate_cube. So I’m guessing that you are connected to the remote runtime, but were trying to modify a running coroutine. Here are the rules on what you can modify during runtime.

  1. Once a coroutine is running, you cannot modify the code it is executing
    a. Branching a new version of a modified coroutine will work as expected
  2. You can always modify the code inside of a method and any callers will immediately run the new code

So for example, if you had the following coroutine:
_rotate_cube

()
[
  loop
  [
    !rot : actor_rotation
    rot.@yaw += GameLib.world_delta_seconds * 5
    actor_rotation_set(rot)
    _wait
  ]
]

And let’s say you wanted to change the rotation rate from 5 to 7. Well, if this coroutine was just running forever, then too bad, you can’t make any changes to this running coroutine. You have 2 options. You could organize your code to stop and restart the running coroutine, in which case you would see your modification. However, the easier route is to use a method instead.

If you re-factor the coroutine to call a method:
_rotate_cube

()
[
  loop
  [
    rotate_my_cube
    _wait
  ]
]

rotate_my_cube

()
[
  !rot : actor_rotation
  rot.@yaw += GameLib.world_delta_seconds * 5
  actor_rotation_set(rot)
]

Now you can modify the rotate_my_cube method and the running coroutine will call the updated method.

I’m hoping this is your issue. One non-:sk: thing that may help you out here. When you launch to a platform from the :ue4: editor, you can open up the dev tools Session Frontend and it will list your connected sessions under My Sessions. When running on the switch, if you select this, you will see the entire contents of the UE_LOG scrolling by. This can help get triage information from the device. You can also execute console commands from this window (you can also do that via :sk: as shown above).

Ah d’oh, it probably is because I was modifying the running coroutine. Thanks for this info, I’ll work on it some more and let you know how it goes, you’ve been incredibly helpful getting this to work!

1 Like

You were absolutely right, that’s all it was! Rookie mistake :slight_smile:

I’ve submitted a pull request to the repo with the changes, they’re pretty minimal. The #ifdef in AgogCore was copied word for word from the Android def.

Thanks again for the help! I’m looking forward to using :sk: and any future iterations that may come. We previously used a monogame + lua custom engine which was a delight to work with - coroutines, fast iteration, etc. I’m very excited to have the same and much more but now with the power of UE behind it!

Awesome, thanks for that!

Iteration time is so important in :ue4:. I’d love to see how you end up using :sk:. As you progress be sure to mention any problematic things you come across. Fresh eyes are always the best at finding issues.