[Solved] Mixed Versioning between Source/Binary engine/plugin? Project vs Engine plugin?


#1

Possibly silly question, but in order to use the github version of the plugin do I need to be using the github version of the engine? I prefer to use the launcher downloaded versions of UE when I can (unless I need to compile a dedicated server) as my turnaround is faster (less waiting between code changes, I’m impatient).

If possible (maybe necessary given how I want to mix versions?) I’d also like to maybe make :sk: a project plugin. I had some success/failure with that in the past but what I’d tried in the past didn’t seem to work this time around.

I have several projects using various engine versions (source/binary 4.11/4.16 respectively) depending on project needs.

I’m thinking I need the source version of UE as one of the instructions is to clean the UHT but I just wanted to confirm.

As always if any extra info is required feel free to ask.

Cheers!

Edit:
Just found this while poking about.

That answers that.


#2

You actually can use the GitHub release of Sk as a project plugin with the Epic Games Launcher version of the engine. You would then distribute it to your team members just like project source code. They’ll get latest plugin along with latest project source and UE4 detects changes and builds them. There’s a few caveats though, e.g. you’d have to manually build the SkookumScriptGenerator UHT plugin module and check the binary into your local source control, and you’d have to make sure the Marketplace SkookumScript plugin is not installed at the same time.


#3

Awesome! I’m not sure how to go about that at the moment but I’ll poke around and see if I can figure it out.


#4

To build the SkookumScriptgenerator plugin DLL, once you have the plugin moved to your project folder, the commandline should be:

<path_to_ue4_folder_in_launcher_install>\Engine\Build\BatchFiles\Build.bat UnrealHeaderTool Win64 Development -NoMutex -2015 -PLUGIN "<path_to_sk_plugin_folder>\SkookumScript.uplugin" -module SkookumScriptGenerator

You should need that step only if you are using the project with the launcher engine. If you build from GitHub, that DLL should be built automagically along with the project.


#5

You’re faster than the UE source download/compile :smiley:

I’ll give that a shot and report back.


#6

Worked like a charm.

Thanks so much!


#7

When working on full-source, I’m used to cleaning UHT and compiling to force :sk: to generate all of the bindings for my C++ code. How would I manually hook that in this scenario since in the binary engine, there’s no UHT to clean?


#8

In this scenario there would ideally be a build engineer who would pull latest Sk from our P4, build the generator DLL, then check latest Sk plus the DLL into the team’s local P4.

With UE 4.15 and below, “touching” a header file that contains UCLASSes/USTRUCTs might be necessary to trigger a re-run of UHT. UE4.16 would probably do this automatically.

We have not tested this setup extensively, but if there’s interest we could post a detailed guide.


#9

I was just testing this out, it’s an attractive solution to be on latest github for faster updates while simultaneously avoiding the entire team having to build the project. Following your guide to manually build SkookumScriptGenerator worked fine and checking in the dll no problem. But in my case none of the C++ code is usable. I get this error on startup:

###SkookumScript code/binary not in synch with C++ Engine : 138 atomic routines have been declared via script files without being associated with C++ functions.

I can see that the Generated-C++ !Overlay.sk contains all the boilerplate for my C++ functions. But if I call any of them I get the Tried to call non-registered C++ method error. I’ve tried modifying a few source files and even cleaning the project to force a rebuild but results are the same. If I were working off of UE4 source, I’d just clean UHT and build and all would be well.

Side-question, does the other half of the C++ binding live in the Content/Skookumscript compiled binaries?


#10

I’d have to test this a bit more on our end. An additional step might be necessary to get this to work properly.

We are in the process of putting out a new release of the plugin at the moment which keeps us busy. Once that’s out, I’ll have a look at this and post a detailed guide how to set it up.


#11

I guess we need to stop asking questions and let you finish your work. :grinning:


#12

Please always feel free to ask questions. If we are busy we’ll answer as soon as we can.

Questions are great!


#13

You fellows are exceptionally nice for programmers, it is a breath of fresh air. I am too used to programmers lamenting endlessly about how much they hate the language they are working in. That must be the Skookum teams secret to their impenetrable positivity, they actually enjoy what they do because they are using a great language.

Ok, I am done derailing now…


#14

So I just set up our FireBot demo project with the project plugin, and the only extra step that was needed was to manually build the SkookumScriptGenerator DLL as mentioned above. Except that it worked fine.

So I am wondering if the project you were testing this setup with is properly set up according to this guide? In particular, there needs to be the include statement #include <SkUEProjectGeneratedBindings.generated.inl> in the main game module’s cpp file - this performs the binding of C++ implementations to script methods.


#15

Hmm, you’re right, I completely forgot to update this project’s Build.cs :dizzy_face: You’d think I’d have this down by now, I just setup new projects so infrequently that it completely skipped my mind. I’ll revisit integration in this project this weekend and suspect it’ll just work.