Download

make ACharacter inherit from custom Actor

Okay. I’ll make it short. I want core functionality on everything (Actors, Pawns, Characters… all need to share the same base values and functions). It’s no use if the Actor gets a scene component for good measure on the way - brakes stuff. There are a lot of half decent workarrounds, but I want a solution. Is it possible through some programmer wizzardry to gently inject code into the AActor Class, so the Character Class get’s the memo? Or Make a custom Character Class that includes functionallity from that Custom Actor?

I’m about to override AActor to get it done… that works perfectly fine but will brake on updates, is messy in the file system and not a good practice i could imagine.

I’m writing in a forum so i’m desperate, cuz I’m searching and trying for hours and the only “solutios” are for missunderstood questions and none at all.

I’m Chris by the way, this is my first threat… thank you for your time ^^

Hi Chris,

Do I understand correctly that you want to inject some shared functionality that has to be accessible in multiple classes? In this case, first I suggest considering creation of a Component. You can then add your Component to different actors in order to make them to share component’s functionality. In another case, for example if you want some functionality to be accessible in ALL classes (including built-in classes from the Engine module) then you need to put your new code directly into AActor class or APawn class depending on where you want this functionality to be injected. You need to download code from GitHub to modify the engine directly.

I have build 15.1 and wanted confirmation first, that there is not an easy trick (like adding “, ACustomActor” to the class declaration) before I go on and hack the engine ^^… thx for your Help.

One piece of advice, a strong one: never change the engine’s code, or at least, avoid it as much as you can. The sheer amount of changes the engine goes through is enough to make it so your project can’t be easlily updateable to the newer versions. Do try to bypass/add custom changes without influencing the base code at all costs, sometimes it leads to some nasty-looking solutions… But with some patience, you can make it work properly and make it pretty :wink:

Yeah, I know… that’s why I asked. I try to combine everything from my prototype BP components into a single big C++ one, right now. The thing is components need to be hooked up propperly. (assign events in base class, capture events like point damage). I just wanted a clean and fast solution so I don’t spend 20 min to set up a new actor (and potentially forget stuff). I’m adding the coreComponent to the BaseActor right now… see where that leads.

Oh… capturing base class events… is there a way to do that, that does not involve recreating the event in the coreComponent? like a reverse assign or something I’m missing or I’m not aware of? ^^ …

I think the ActorComponent has no “pointDamage” function… so NO… off to influence the mediclorians to… create… life … good … GOOOOD

It’s a good point but I would argue about “avoiding it at all cost”. There are things to consider:

  1. Updating the engine is not always a priority. It’s cool to have all the latest shiny features, but does your project absolutely need them? It’s not uncommon for some projects to just stick to one version of the engine.

  2. You should preserve the overall structure of the code to keep the engine code mergeable. Unless you start moving/renaming functions, properties or files you should be good. Adding a couple of properties, functions or calls won’t really hurt.

  3. Workarounds can be way more ugly and/or buggy than direct modifications of the code. If you need some additional data or properties to be associated with ALL your Textures or Static Meshes and you want your artists/level designers to be able to customize it and you already have a ton of maps where you use those resources it can be a reasonable solution to just add these new properties directly to the engine.

So my advice would be: “be reasonable, don’t modify the engine just because you can and don’t do it if you don’t feel experienced enough” instead of “avoid it at all cost” :slight_smile: There’s nothing really wrong about adding some tweaks to the engine when necessary.

@Hellrunner - I’d love to help you mate, but I haven’t been involved in UE4 projects lately, and I never delved into components much. Tbh I’d go with the easy way: directly call the event on the component when its triggered in the base class.

@Rober Khalikov - You are absolutely right, its just one of those “golden rules” where its actually a guideline, of course, it depends on what you’re trying to achieve. But trying to reply directly, as what you say makes perfect sense:
1- Absolutely. Thing is, its not always about shiny features, its about bug fixes, incremented or added features which will save you a lot of work. Not less important, are designer features which may help boost the visual capabilities of your project, saving designers time and actually helping them out.

2- My experience showed me - unfortunately - that it is often not the case, sometimes even changing a few lines is enough to mess up the whole merging, but it might be my fault, I probably messed up along the way :slight_smile:

3- Absolutely. But between possibly preventing engine updates and creating something a tad ugly… I’d go with ugly with some frostin on it :smiley:

I appreciate your thoughts, always good to learn :slight_smile:

Cheers!

Components and interfaces exist for this exact reason, you’d be better off using them than modifying source.

@Hellrunner
If you tell us what exactly you are trying to achieve we might be able to help you. :slight_smile:

It’s fine. My solution for now is a big, all including component that detects in what type of actor it’s placed. I cut out a lot of stuff from the base classes and left them almost bare bones exept for the component implementations. I went through the clensing phase today, where I rip out the old bases and reparented everything needed. Then the crashes (cuz I’m not actually knowing what I’m doing ^^) that where easily tracable via a print macro (thx rama, peace be upon him) and now everything runns like AKitten (was about to correct that typo but was to funneh)
and I can actually continue prototyping :smiley: thx guys… Stack overflow could learn a LOT from this community ^^ :heart:

PS: Oh… and for the dynamic collision shapes I’m using interchangable StaticMeshes… just letting you know, cuz that question pops up alot as far as I’ve seen.