You might have been wondering what we mad scientists have been up to recently. Well we did a major overhaul of the plugin so that you can now keep it installed in the engine plugin folder at all times and use it with all your C++ projects as well! That also means it’s now a lot more convenient to use with the Epic Games Launcher version of UE4. Then we created a new C++ demo project that demonstrates the new plugin architecture. And last but not least we fixed a number of glitches making your workflow even smoother!
This update is available right now from our GitHub repository for GitHub/C++ users and (back by popular demand!) also as a good old precompiled zip file for you Epic Games Launcher users so you don’t have to wait until it appears on the Marketplace (which will happen soon as well).
So what’s new?
- The plugin now supports C++ projects without having to be moved into your project. It can remain in the engine plugins folder.
- No need to modify the plugin or modify UHT’s
DefaultEngine.inito accommodate your project.
- Instead, there is a new file named
SkookumScript.ini. You find it in two places:
- in the SkookumScript plugin’s
Configfolder allowing you to specify how the plugin generates bindings for the plugin itself (if used without a -enabled C++ project, i.e. on a Blueprint-only project)
- in your project’s
Configfolder where you specify how the plugin generates bindings for your game module.
SkookumScript.ini, you specify
+ScriptSupportedModulesto tell SkookumScript for which module to generate bindings,
+AdditionalIncludesto specify additional include files to include to make the binding code work (this is sometimes necessary as UE4 header files very often do not include all necessary sub-includes and will simply not compile unless used in a “magic order” which is hard to get perfect), and
+SkipClassesto specify the name of classes or structs that you do not want to export to SkookumScript.
SkookumScriptGenerator, the module that reads the
UFUNCTIONetc. macros, now generates a set of bindings each for (1) the engine (
SkookumScriptRuntimemodule) as well as (2) your game module. The engine bindings exist so that the plugin can still function without any -enabled C++ game module (i.e. on Blueprint-only projects). When a SkookumScript-enabled game module is present, its bindings override the engine bindings (in the
- There is a new overlay
Project-Generated-C++for script code generated from the
UFUNCTIONetc. macros in your game modules, and the old overlay named
Project-Generatedhas been renamed to
Project-Generated-BP(existing overlays named just
Project-Generatedwill still work though, but renaming to
- You need to add some custom code to your game module to enable SkookumScript:
- In your game module main cpp file add:
#include <SkUEGeneratedBindings.generated.inl>``` and then inside `StartupModule()` function, add ```FModuleManager::Get().GetModuleChecked<ISkookumScriptRuntime>("SkookumScriptRuntime").set_game_generated_bindings(SkUEGeneratedBindings::get());``` If there's no `StartupModule()` function, you need to create one by deriving a custom class from `FDefaultGameModuleImpl` and use that in the call to `IMPLEMENT_PRIMARY_GAME_MODULE` (for reference, see the file `FireBot.cpp` in our new C++ project demo `FireBot`) - In your game module's `Build.cs` script file, add the following code to the constructor: ```PrivateDependencyModuleNames.AddRange(GetSkookumScriptModuleNames(Path.Combine(ModuleDirectory, "../..")));``` (see the `FireBot` sample project's `Build.cs` file for the implementation of `GetSkookumScriptModuleNames()`). You also need to add the function `GetSkookumScriptModuleNames()` itself to the `Build.cs` file until we figure out how to just call the version of it that already exists in `SkookumScriptRuntime.Build.cs`. - This should be all that's needed for you to start using `UCLASS()`, `UFUNCTION()` etc. macros and see the respective SkookumScript classes appear in the IDE! - In any C++ file that uses generated SkookumScript bindings, specify `#include <SkUEGeneratedBindings.generated.hpp>` 7. Numerous bug fixes - see detailed change log below **IMPORTANT:** Changes in `SkookumScript.ini` or the `SkookumScriptGenerator` plugin source files are not automatically detected by the build system. If you make changes to these, you have force a re-run/re-build of UHT by `Clean`ing UHT. That's a bit annoying right now but on the positive side you do not frequently change those particular files. :-) ## FireBot, our new C++ demo project! <img src="/uploads/default/original/1X/adc45e2f1521f3d6e898f53353a83494dc93057d.jpg" width="690"> In order to illustrate how you use the new plugin with a C++ project, we created a new demo project that shows off how this works. It's called `FireBot` where you play an inflammatory mannequin that lights things on fire. Download it from the [usual location](http://forum.skookumscript.com/t/downloads-latest-plugin-and-demos/419)! ## Complete list of changes from 3.0.2822 to 3.0.2983 So here's the nitty gritty detail of all changes from the last version (3.0.2822) to this version: ###Skookum UE4 Plugin - fixed bug where Blueprints could not be derived from SkookumScriptBehaviorComponents - fixed bug that would incorrectly delete `Project-Generated` class folders - fixed crash bug on shutdown when component was attached to actor whose Blueprint needed saving while quitting UE4Editor while game is running - fixed crash issue upon reload of compiled binaries due to improper UObject deletion call - fixed incorrect test of components with overlap events - fixed bug where :sk: class hierarchy would get confused when reparenting a Blueprint - fixed bug where accessing null components caused an exception fault - !Class.sk-meta file for SkookumScriptBehaviorComponent - commented out shutdown dprint causing some deallocation issues (quick workaround for old IDE) - fixed static memory deallocation occurring too late on shutdown - added required header files to public header of SkookumScriptBehaviorComponent so it can be included from a foreign module - fixed ref counting sequence issue with SkookumScriptBehaviorComponent that lead to crash - fixed bug where the wrong target object (object owning the Blueprint instead of the target link) was passed to Sk Blueprint nodes - MAJOR refactor of SkookumScriptGenerator and generated binding system to facilitate C++ projects without moving the plugin into the project folder - SkookumScriptGenerator now generates two sets of bindings - one for the engine that links into the SkookumScriptRuntime module and one for the game that links into the game module - it also generates script files now in different overlays depending if the class is an engine or game class (`Engine-Generated` vs `Project-Generated-C++`) - SkookumScript.ini now read from project `Config` folder if present there - SkookumScript.ini now allows specification of `AdditionalIncludes` to provide a systematic way of addressing sub-include issues that some UE4 files exhibit when included out of order by generated binding code - bindings now encapsulated in singleton class SkUEGeneratedBindings, so game module can pass pointer to that object to the SkookumScriptRuntimeModule which it will bind the binaries against - removed obsolete `Classes` folder from SkookumScriptRuntime module and moved a number of files between `Private` and `Public` folders to deliberately expose binding functionality (e.g. SkVector3, SkUEName) to other modules, and hide other functionality (e.g. SkookumScriptListener) - moved includes and declarations required by generated bindings into the generated code - reworked SkookumScriptGenerator to generate classes in guaranteed order (all because of those stooopid header files that have sub-includes missing all the time) - add SKOOKUMSCRIPTRUNTIME_API macro to various binding classes in SkookumScriptRuntime modules so that they can be used from other modules - yet another big refactor of SkookumScriptGenerator, gettign rid of a lot of black magic and now deriving include order from dependency graph - SkookumScriptGenerator now applies an include priority based on theorder modules are specified in SkookumScript.ini, so that include order can be influenced by re-ordering the ScriptSupportedModules - fix for crash when a Blueprint finished compiling but has no GeneratedClass (apparently that can happen) - SkookumScriptGenerator now uses separate target structures for genrating engine and project binding code and scripts - project scripts & code are generated based on SkookumScript.ini in the _project_ Config folder - engine scripts & code are generated based on SkookumScript.ini in the _plugin_ Config folder - factored out SkookumScriptRuntime.GetSkookumScriptModuleNames to extract module names from SkookumScript.ini file - split loading and binding of compiled binaries into two function calls so that compiled binaries can be loaded first, and bindings initialized at a later point to allow a game module to specify an alternate SkUEGeneratedBindings object - fixed project-generated overlay paths - added SkookumScript.ini to FilterPlugin.ini file - SkookumScriptGenerator automgically generates Sk project file (in Intermediate folder just like BP script generator) if none present - when project SkookumScript.ini file not found, now defaults to engine SkookumScript.ini file - fixed bug where project bindings would overwrite engine bindings if no script supported game module was specified - refactored generated binding mechanism so that registration of UE classes, registration of Sk classes and registration of routine bindings are now separate steps, so that UE and Sk class initialization can be invoked for both generated engine and project bindings whereas routine binding is only run on one or the other - fixed clang compile errors - fixed bug where compiled binaries weren't properly initialized after a hot reload - renamed SkUEGeneratedBindingsInterface to SkUEBindingsInterface - renamed generated_bindings_p to game_generated_bindings_p - fixed crash when SkUERuntime::set_game_generated_bindings was called with nullptr - fixed glitch in SkookumScriptBehaviorComponent.attach when actor being attached to is not yet initialized - fixed component initialization order issues - removed commas from generated Sk method parameter lists - removed get_ from new component getters - fixed component getters so they work with pure Sk classes as well - added register_component() and unregister_component() - fixed bug where read-only sk files could not be regenerated - made ISkookumScriptRuntime::is_skookum_component_class() more specific and changed to ISkookumScriptRuntime::is_skookum_class_data_component_class() - updated some error messages and comments - added asserts to Sk components to ensure the Sk instance has been created by BeginPlay - set version to 3.0.2983 ###Skookum IDE - Command_show no longer requires class and member symbol ids tobe valid if present - if they aren't valid they are assumed to be null - this fixes occasional assert upon reception of Command_show by the IDE - fixed auto-complete from preventing mult-level undo - set backgound color for "Create member/class" text box (previously was often white text on white background) - fixed potential access violation bug in SkParser::parse_class_instance - prevent secondary server remote IP address from being localhost ###AgogCore - added parameter require_existance to ASymbol::create_from_binary to allow silent failure if so desired