I’ve made i mod that runs ok on the testbed. It loads on the client and it’s id is visible on escape, but it appears to do nothing. the none-dedicated server doesn’t appear to keep logs.
When i place it in a dedicated server and start it, it crashes with this error.
I want to say that this is a startup error caused either by something in your PrimalGameData, or GameMode… I had this error recently myself when I was messing with those two (the supply crate spawning volume). What have you edited in those files?
You mean the supply grate wpawning files?
Nothing? I haven’t touched those files.
No no, I mean in general. You should run the mod stripped down, with nothing besides the name/description. Then slowly add pieces of your mod to see where it crashes. I was just saying that when you get the “Supply Crates Spawning” crash, I think it’s related to one of those two files. In your dev kit when your level has your modded base primal referenced, instead of hitting play, hit the down arrow attached to the play button. At the bottom is a “Run dedicated server” option. Much better than uploading/testing
The mode one i would have thought. it seems to crash only on the server and not on the client. the problem is the cooking system rebuilds everything and if it does give any watnings at all about your mod, you are hard pressed to find them.
Sadly adding bit by bit is a long process due to that time it takes to cook the mod. The developers should do somethig about that.
Use the dedicated server option in the dev kit. Make sure your level is set to use your test game mode as well as primal game data.
Wont happen …
Something is wrong in the crate drops. I have seen this before in these forums. The other person didnt even touch the supply drops, yet, he was getting the exact error.
I dont know the resolution, because, he never came back to say “this was the error, this was the fix”
“SupplyCrateSpawningVolume” on several different cpp lines (cpp=c++ for those that dont know)
I would even venture to open the build of it and see whats happening. I forgot if yall have that ability tho. I think they removed the source line from Ark. Hmmmm … either way, something in your BP’s maybe wrong. Since thats what the cpp would correlate to. Maybe you made a change to something that effected another child some place. I dont know if all “supplycrates” are connected, or, whats a parent/child of them. Without knowing what you were modding, i dont even know where to start.
I scrapped the primary testgame_bp and sourced a child from another folder. I’m thinking that chaliding or copying the one from the testmod folder might be problematic. so far this one hasn’t crashed on me. So I’m rebuilding it slowly.
Here’s hoping, but the game developers need to leave their ego’s at home and fix the bugs with the game and the dev kit.
It’s best to child your blueprints from Game/PrimalEarth. Just click on that folder and search for PrimalGameData and TestGameMode. Same goes for any other structures, inventories, items, etc, take it directly from the parent class.
Yeah. i did that and reated children rather than copy. so far it seems to be behaving.
A LOT of blueprints will behave this way. When the came checks your mod for a file, it checks for children, not copies. Some things you can copy and it doesn’t matter, but children are often safe bets.
It certainly appears that way. Sadly the tutorial i was origionally working from used copies rather than children.
Copying the files from GenericMod works perfectly fine, just do not child them as this makes your parents invalid when the game tries to access them, thus causing the crash.
Everything inside of …\Content\Mods\ does not exist to the game, so unless you’re childing things from within your own mod, said mod being the one you’re working on - if you want to child from a mod in another folder then you *will ***need **to make the mod containing this parent a required item on the workshop page for the mod containing the child, stick to copying them for base-starting a mod.
And yes, , the “crate” crash is largely caused by the GameMode having an invalid parent, there is also the second GameMode crash that is caused by specifying an invalid GameMode in the PGD.
-WM
I beg to differ. mate but copying from the generic mods see,ed to casue the crash. Parenting from the ones on the game worked fine. By right altering child classes should not effect the parents.
The mod works find now on both test bench and standalone server.
Altering the childs doesn’t affect the parents, where has this ever been observed or stated?
Also, I’ve been working in the DevKit for over a year now, and from the beginning I - and many, many others - have copied the three “core” files(before we started insisting people stop specifying a GameMode, unless you actually need to, anyway) without incident.
Only logical and reasonable conclusion is perhaps you thought you hit copy instead of child but it actually childed instead, or it could have been an extreme edge-case where the DevKit had an aneurysm at the moment you wanted to copy the files over and either corrupted them(something few have claimed to have experienced but I’m still yet to observe or experience) or chose to make them childs instead.
-WM
copy? who copies?
Learn2bestpractice
Always child … always.
Always child the BPs when you can … why recreate when the functions are already there? Using child/parent is like “step 1” on learning Unreal. If you are copy/pasting and then editing those, your running some really bad code and design. Its just not the right way to do it. Bad practice is bad practice.
Always child and run from that. This allows you to run the functions from the parent and allows the child to inherit from the parent. This is why nothing is “stackable” and everything needs to “load me first”. Just parent/child and you will be fine …
I originally copied, that didn’t work. I childed it does. Object orientation logic shows using copy rather than childing would produce dirty mods which would often becom irrlevent when parent classes change. My mod is now working using inherited classes. It didn’t when i used copies, which i tried numerous times, Your “only logical conclusion” was miscounted, but thank you for the input.
Shall i hold your coat? 
Lol just giving yall a hard time …
But yea, always like I said haha.
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
