I have a C++ class derived from UObject that modifies a character and I need that to call a destructor to cancel that modification. This class has to be a base for BP classes implementing various type of modifications on the character.
No destructor exists in BPs for UObject derived classes, so I tried to call a blueprint implementable event from a destructor or from a “virtual BeginDestroy() override” but the editor crashes when the event is called because it is “unreachable”
What can I do?
afaik it’s not a good idea to override UE Memory managment system.
What about a function to UndoModifications() ?
Do not use the actual class destructor. Unreal provides alternatives both available in BP and C++
Event Destroyed → Called once the actor receives the command to be added to garbage collection.
Event End Play → Called once the actor is ready to be added to garbage collection. You can also switch on the reason to ensure it fires in only certain circumstances.
Thanks
Alex
I think he’s talking about UObject
Exactly, I’m used to those events, but I can’t see any of them in UObjects, they seem to be declared in AActor which is child of UObject.
UObjects are not designed to use the native constructor / destructor functions outside of C++.
I do not think you will be able to create a Blueprint version of the destructor.
Can you explain a bit more about what you’re trying to achieve. You say “modify the character”. Prehaps there is a better approach you can take.
Thanks
Alex
I did that, but problem is that I don’t know how to call a function like that when the UObject is going to be destroyed.
I partially solved the problem calling an “UndoModifications()” function when a specific Actor causes the object to be destroyed, but it’s not optimal because if, for any reason, the object will leave play in other circumstances I can’t be sure the “UndoModifications()” function will be called.
These objects will have to implement things like “run”, “dash”, “jump”, “fly”, “run faster”, “jump higher” etc. in order to have a fully modular and configurable “hero” that reflects the gaming style of the player.
I don’t want to implement these things in the character to keep it leaner and using these actor I can “launch” any of these functionality via the same “LaunchAbility()” function with a general approach.
I could do it using actor components, but it seems expensive to have many of them doing such “silly” things.
ActorComponent is derived from UObject not AActor and then seems to be the right answer to your problem.
I would then try to stick with a single generic Component including those skills and custom logic inside to allow him use of functions included, with no special need to destroy that component (like character movement is not constantly deleted / constructed)
Can you explain why you think that such a component woud be too “heavy” or what ?
Because i’m not a teacher and i may be wrong here.
It’s just because if I add 5 components just to handle these things I think it’s gonna be expensive, but if, as you suggest, I make a single component with all the logic it would surely fit the purpose, though probably even less expensive would be to put everything directly inside of the character.
Generally speaking UObjects implements less features, so they’re surely going to be lighter, but they’re annoying me in many ways because probably Epic meant the Actor components to be used for this kind of needs and UObjects are “underpowered” and don’t fit nicely the job.
Ideally I’d like to have something that adds to the character only the needed functionality (like functions and so on) and doesn’t add new objects, but I think it can’t be done.
There are a few ways to go about this.
If you want for example multiple heroes:
1 can super jump
1 can run really fast
1 has special powers etc
Then this is where OOP is your friend. You create a base character class with all the functionality shared between the different hero types with virtual functions. Then create a child of the base character for each of the hero types. Then in each child you will override the base functionality and implement your bespoke powerups.
If you want a single hero which can gain different abilities, then use actor components. Components are an extension of a class to help separate groups of functionality. For example, if we had a VR character. The class will contain different components. 1) To manage the HMD, 2/3) To manage each motion controller (hand), 4) To handle location mechanics such as teleportation.
Providing you setup your components correctly, i.e. they don’t tick if they’re not required and you’re sensible with your casting, there are issues with using multiple components to separate your logic.
You could even use a child actor class entirely to handle specific calculations which can then be passed back to the character, again providing its setup correctly and the casting is sensible.
Having a blank empty object to handle character game mechanics is not desirable as the components and actor classes manage a lot of the internal setup and memory management for you.
Hope this helps
Alex
I tried to use UObject because I wished to use the simplest base class available, but it’s clear, now, that they aren’t well suited for complex tasks because they have very little functionality. Yesterday I spent a whole day fixing crashes related to the use of these UObject classes, so I reparented them to AActorComponent and all the problems vanished.
The “virtual character” approach would be too complex in this application because there are too many possible combinations, so now I implemented every “ability” with a different actor component, then, if performance will be poor I’ll look for a different solution
Thanks anyway!
Nice solution Alex to implement functions via virtualization.
@dvdtcc1 though you used the UActorComponent solution and marked the wrong one as “Solving my problem”. Glad you fixed it anyway
Actually I didn’t know which to mark as correct, I tought that this chain of messages would have given more informations to someone that will read this in future