Is there any progress on Actor Components?

Yes, to me, this should already be available. I do not like single inheritance systems, components are a way around the limitations of these systems. I think that a lot of people are going to expect to be able to fully utilize components when they learn about skookum.

1 Like

I’d like to clarify what exactly you guys would like to accomplish with ActorComponents. I assume something like this:

  1. Ability to derive a SkookumScript class from ActorComponent with constructor/destructor and important methods of ActorComponent overridable in SkookumScript.
  2. Ability to create such a component on the fly in SkookumScript and attach to an actor.
  3. Ability to detach and destroy such a component in SkookumScript.

Is this what you are looking for? If this is a much desired feature we will move this to the front burner!

Can we also be able to add data to said component?

Yes! We would like components in their full glory!! This is a much needed feature.

Also, (just to clarify) components should be able to hold data (members) as well.

Ok officially moved to front burner :fire:.

I currently make use of actor components as well. I get around the data issue by adding the data in the actor component blueprint.

Having constructors / destructors, overrides, and ability to attach and destroy would be great as well.

UE4 object hierarchy is disjointed so I always struggle doing things elegantly with base classes and end up using components.

This is not a solution to the problem. I will quote shadino here where he is talking about adding data through blueprints in a component…

I do not know about you but I do not like it when something partially works when I am programming.

I read that thread before but can’t follow it. what partially works and what doesn’t? I so far have luckily not run into issues so just curious.

Ok I created a new post explaining raw data members. Hope this resolves some of the mystery surrounding them. :slight_smile: As usual please ask if something is unclear!

1 Like

Do not worry about it then =). This thread will, hopefully, ensure that you will continue to be able to use actor components, with skookum, in an error free manner.

2 posts were merged into an existing topic: Raw data members - how do they work?

Yes exactly. The basic workflow I’m looking for would be like so:

  1. Programmer defines a new actor component in C++ using UCLASS / UPROPERTY macros to define how they can be edited / replicated etc. This class exists mostly as a data structure at this point. Note that in a perfect world I would really prefer to be able to define this new subclass directly in Skookum including the members with UE flags etc but I understand the difficulty in doing this.

  2. Compile and switch to Skookum editor to start attaching behaviour to the new component. This includes constructor / destructor and overriding the other important UE methods such as BeginPlay.

  3. Game designer loads up UE4 editor, creates a new blueprint actor and attaches my newly created component along with whatever other UE components and edits all values exposed in step 1.

I expect a lot of others would enjoy the same workflow except that the initial creation of the component would happen in Blueprint instead of C++. In our case we are specifically trying to avoid having our primary game data structures defined in non-mergable binary files hence the interest in a pure C++ and Skookum workflow up until authoring step at least.

Thank you for the responses so far including the detailed post about raw data members, it was very helpful and made a lot of sense.


Amen to that!

What’s a shame in :ue4: is that BP Graph files are binary when you can actually select a whole graph routine in the editor and paste it into notepad and see its textual representation. Doesn’t make it any easier to merge or diff; that’s for sure, but it’s a wasted opportunity to create a visual diff’ing tool at least!

Hey btw here is the latest work in progress from our mad science lab!

We now got three new components (plus old one that still exists but is deprecated) which are:

  1. SkookumScriptClassDataComponent: Attach it to an actor to allow :sk: constructors/destructors to be called upon construction/destruction, store data members, specify custom actor class (that’s kinda like the component we already got). Will allow only one of these per actor. Attached in BP editor - no attach/detach control from script. Support for default constructor only. Component not exposed to :sk: as class.
  2. SkookumScriptMindComponent: For attaching a mind to an actor. Gets constructed along with actor, and destroyed along with actor. Attach as many as you want. Attached in BP editor - no attach/detach control from script. Support for default constructor only. Component not exposed to :sk: as class.
  3. SkookumScriptBehaviorComponent: Component exposed as class to :sk: to derive your custom component classes from. Can be attached in BP editor and/or attached/detached from script at any time via attach/detach methods. Attach as many as you want. Keep component around and attach/detach several times if you like. Allows custom constructors/destructors. Allows custom C++ subclasses so you can combine C++ and SkookumScript methods in your custom component. You could also keep a Mind in such a component, making the SkookumScriptMindComponent technically unnecessary. SkookumScriptMindComponent is easier to use though if all you want to do is just attach a Mind for the lifespan of an actor.

We will subject these three new fellas to a few more days of testing and fine tuning before we release a new code drop to you guys. Ideas/comments appreciated!


Looks awesome! I cannot wait to complain about them soon… jkin =P Seriously though, thanks!

The system you’ve outlined is better than what was in my imagination. I think this is going to be very clear and easy to use, really looking forward to giving it a test drive!


Two questions, if I subclass SkookumScriptBehaviorComponent in C++ and define UPROPERTY and UFUNCTION will I be able to modify / call those properties / functions from the corresponding skookum script such that unreal will replicate their changes / call replicated methods to the server or client etc?

And will any additional subclasses of those components (say in blueprint or even C++ again) inherit the behaviour provided by skookum in the parent class?

MyCustomComponent (C++ with Skookum)
MyCustomComponentSubclass (Blueprint)

If so, then double thumbs up from us, exactly what we wanted :thumbsup: :thumbsup:


Yes this should be all possible! To clarify though:

  1. SkookumScript does not (currently) natively support replication, but allows direct access to replicated UE4/Blueprint functions/variables that you can use for this purpose. We are planning even deeper integration with replication in the future.
  2. Yes you can derive a C++ component from USkookumScriptBehaviorComponent and expose its properties and methods to SkookumScript via UFUNCTION/UPROPERTY. You can then further derive your own SkookumScript and/or Blueprint classes from it.
  3. You can expose SkookumScript methods and events to Blueprint graphs, even in components, so you can combine C++, :sk: and Blueprint Event Graphs in your component if you dare :slight_smile: .

This is all brand new functionality though - we hope to have a test project soon to show everything off!


This is great news, I look forward to testing it all out. Thank you so much for the hard work!

1 Like

So the new components are now released and available on GitHub and the Marketplace! Here is an introduction on how they work. Enjoy! :slight_smile:

1 Like