Hey folks, just a quick update regarding 4.20. We continue to work with Epic to resolve a breaking change in the build system. Apologies for the delay, hoping to have good news soon
Hi. I just recently discovered SkookumScript, but unfortunately I am using UE 4.20
Any updates on when/if we will get 4.20 SkookumScript plugin? I would really like to try it out!
Hey Kyle, the short version is that we are still working on getting 4.20 running.
For those that want the
too many details version. The smoking gun seems to be a refactor to the build process in 4.20. Previous engine versions iterated through a list of foreign plugins and added them to the list of things to build. This step was removed in 4.20 but not replaced with any obvious alternative.
and other script plugins are built on top of a plugin that Epic provides called
ScriptPlugin. The goal of the plugin is to allow 3rd parties to provide scripting support in without needing to make any modifications to the engine itself.
ScriptPlugin itself does not work .
ScriptPlugin is actually 3 separate plugins and specifically
ScriptGeneratorPlugin seems to be the component that’s suffering. Its role in life is to leverage
UHT to auto-generate C++ code that binds the scripting language to all of the classes, functions and properties in . So when the build process forgets to add things to the build list, those bindings don’t get generated and things don’t work as planned .
We had originally hoped that Epic might take this issue under their wing but understandably the folks at Epic are busy, and to be fair,
ScriptPlugin is not the most glamorous/used plugin out there. We are working on resolving the issue internally and submitting a PR to Epic.
I hope this post gives some insight into why it is taking so long to get 4.20 going .
You guys are now having to take this on Internally, so that does explain the delay.
I guess I am lacking bits of info…
Could you elaborate a little more as to what constitutes a “Foreign” plugin and how does this relate to Marketplace script plugins?
Is there some sense as to the motivation for refactoring the code without the alternative to add foreign plugins into a build?
Let’s hope Epic acknowledges the PR… I am unsure what would happen if they did not.
A foreign plugin is any plugin not shipped with the engine. The problem is a little more complicated than originally described. This has to do with foreign plugins that have modules of type
Program with loading phase of type
PostConfigInit that require being ran by
The epic codebase changes rapidly with many underlying motivations by many contributors. There’s not enough context from the commit notes to glean an overall motivation for the changes other than continued improvement. I’m sure we’ll get this sorted out.
Thanks. That is definitely reassuring.
Thanks for the very informative reply, I really appreciate it!
I am going to install UE 4.19 so long to get up to speed with SkookumScript while waiting for the 4.20 plugin.
Thanks again and good luck!
Maybe I’m missing something… But if not: any news on the 4.20 version? Any release estimates?
I just found out Epic broke the custom online subsystem in 4.20 as well. That one’s an easy one line fix in the engine, it’s too bad the script base plugin isn’t as simple
Looking forward to updates, I miss
Well the good news is that the
ScriptPlugin stuff is working again in the master branch. We made the decision to jump straight into 4.21 for now as things work there. Support for 4.20 may depend on the specific UHT changes required being backported into the 4.20 branch by Epic.
I would break out the upgrade as follows:
General bug fixes
The UHT and IDE tasks are mostly syntax/compiler oriented. Since things initially don’t compile, the task here is to replace any deprecated types and methods, trying to take note of significant changes in the engine.
Once things compile, we move on to the Runtime task, which is where we are now. This involves finding the internal engine changes that prevent normal operation during runtime. This could be data types that have changed, different execution paths etc. One that was most recently found was a change to
UPROPERTY meta-data that affected null and float values.
We are still chipping away .
That’s awesome. Great to hear!
We made the decision to jump straight into 4.21 for now as things work there
Do you know when Epic is planning to release 4.21? I’m working on 4.20 here and soon, maybe even this month I’ll start scripting, and of course I’d like to use skookum from the beginning.
Ah, by the way. The game I’m making:
Fantastic! Really itching to use in my new project
And thanks for the amazing support especially in this phase where you guys are at a difficult point in the process.
Wow, please post in the Project section and keep us up to date on this! I’ll be interested to see how things progress as you start to roll into this. I have an ancient project where I was playing with procedural horse animation, the 3D model I was using looks like pixel art compared to these renders .
Thanks! Great to hear you liked the horses. Do you have a link to the procedural animation tests? You made me curious.
Thanks for the suggestion. I’ll post it in the Project section as soon as I start scripting something here with skookum.
I hope 4.21 come on time to use it without delay.
@error454 Now that 4.21 is out, are there any roadblockers or it’s just a matter of time until the plugin comes out?
Well the good news it that with 4.21 released, the ground won’t be shifting anymore. On the front, there is still 1 major runtime crash to be tracked down and then hopefully after that it should all be very trivial work.
I was about to write asking about 4.21, as today I saw the news and just installed it. I’m going to start to prototype the demo level for my game today, and was wishing to have Skookum available for this. By the way… I was planning here the way to implement the basic AI for the foes/NPCs, thinking about navmeshes, behavior trees, state machines… and I recalled the Fire Bots demo, that awesome thing of testing commands while the game is running… My questions (I’m going to create a topic for this later, probably):
What do you think about using Skookum or Skookum + behavior trees for this versus using only Behavior trees + Blueprints? Do you think is there any kind of road block or difficulty that would make it more reasonable to not use Skookum for this? Does Skookum interfaces enough with/accesses the systems for AI and navigation? Your thoughts on this, please.
I’m very inclined to use Skookum for this specially because of the fast testing cycle and coroutines - be able to only check certain things at bigger time intervals, to make the game logic lighter.
Behavior Trees, AI, UE4