The majority of people copy… that’s how the majority of “new”(not just re-hashes of the same old ****) structures and such are added.
Your insight has been warped by your work with a stock UE4 engine where you’re working with a much smaller project and it’s easier to child directly because your hierarchy is nowhere near as large and you know what exactly does what and how and why it does it, because shocker… you created it. To get something clear, in the example of a new structure, you only child an existing structure if your structure is/should be related in some way and you require any changes made to that structure to propagate to yours. There are specific base - or parent - classes for actors based on their type. Using a structure example again, if you copy an existing structure that basically does what you want well enough already but you want to change the meshes and modify its behaviour in the graph, then this new copied structure will have exactly the same parent as the original structure as it is still a child of ARK’s core classes… there is no recreation of functions(seriously, where the hell did you come up with this?). With ARK, when people say to not child and rather copy, then they’re referring to the process of finding the basics of what you want that already exists in the game and copy all relevant files to your mod folder and replace what you what want within those files, be it the meshes, the graph, etc. to achieve your desired outcome. This has worked perfectly fine since the beginning of modding for ARK.
"Nothing is “stackable” and everything needs to “load me first”…
If you got anywhere in the DevKit you would know that replacing core elements of ARK are the only things that are required to be loaded first by priority. The most common of these is replacing the UI and/or HUD, replacing the Player pawns, or replacing the GameMode/GameState for one with custom logic - the latter being not entirely the case so long as another mod does not override the GameMode first(a habit we’ve been trying to get people to break unless they actually need to) then a custom gamemode can be loaded as low as last in the load order. Making copies of existing blueprints does not make mods unstackable… certain types of mods and certain approaches to mods is what makes them unstackable. A/Genesis is an example here because their mod is stackable, but it loses some functionality if not first because they make use of a custom Mode(and perhaps State too).
As dumbfounded as I am these days at the threads and posts I see almost everyday in these forums, I’m just going to lay this out as simple as I can…
If you take a class and make a child of it, you - in essence - get a copy of the parent with the benefit of any change to the parent being reflected in the child(s) automatically. If this class has a child already and you make a copy of it… guess what, it still retains the exact same parent so any changes to said parent(where they’ve not been modified/overridden in the child) are then propagated to the now **two **child classes. The only difference between either approach is one already has variables and/or function(s/ality) set up that may be fit for purpose or close enough to it, both will retain the exact same parent and will be valid in all circumstances unless an exact class match is required. I have no idea where this confusion has erupted from, but it needs to end. There are literally over a thousand stackable mods on the workshop… I personally have 27 stackable mods that work perfectly fine in each environment(only three, or something, are public). I don’t just talk **** for the hell of it, if I’m talking about something I make **** well sure I’m informed about the subject matter.
But this is a moot point, I can see that, by your thrice-redundant emphasis, as you’re right absolutely and I’m wrong absolutely and you’re stuck in that belief, so there is no point in continuing after this. I bid you, adieu.
-WM
