Any updates on this?
Bumpā¦ Been waiting literal years for this lol
Any updates?
Yeah itās been literally two years now. Is this going to be another bold promise that never actually happens ?
Would this be related as to why my game wonāt find any assets that are added after packaging? I made a function that reads uassets in a folder, and it gets the files that are in the game when I made the editor. But after packaging, uploading to steam and downloading, then adding 2 extra assets to the location (Without ticking Use Pak File), the game wonāt read those 2 extra assets.
https://answers.unrealengine.com/questions/561352/how-to-read-uassets-outside-of-packaged-game.html
Hey [MENTION=8] [/MENTION] are there any updates on this in light of the recent activity with Conan? It seems like Conan gives access to the entire game contents and an essentially unmodified editor. Personally, my major concern here is how to do this safely, without the end user being able to easily migrate my assets to their own project, or introduce c++ code that accesses the file system, or dish out steam achievements, etc. Currently, afaik we would have to release the source for any editor changes we make, which would immediately invalidate any security measures we could take on our own, not to mention the fact they could simply open the (apparently unpackaged?) .uassets in the standard editor
I canāt really check the custom editors from the launcher, my pc will explode.
I hope we have some news at GDC, regarding modding.
But then again, it is still complicated with licensing of certain assets.
But anyway i would love to have mods support for my games, even if they are not in the same caliber/budget of Conan Exiles, Ark etc.
But for smaller teams or one man projects, better support/documentation, from Epic, regarding custom editors and modding would be extremely helpful.
In regards to this Bioware did this with a few of their games (mainly NWN1 & 2 <= Obsidian modified for NWN2) and there were not many issues with art assets being pilfered. The game hobbyists simply wanted to make content and paint their adventures in the toolset provided. You could say similar things of Skyrim and Fallout 4. Indeed there are the lowlifes that steal art for their own uses but there is nothing that really can be done about thatā¦they will always be present and making something so locked down only inhibits the modding process in the first place.
Modding has been on the palette for my designs in both Unity 4 and 5 (extremely difficult to implement and very fragile) and now in UE4 (wiki shows how it can work => https://wiki.unrealengine.com/Modding:_Adding_mod-support_to_your_Unreal_Engine_4_project) but it is definitely not the smooth process Bioware had with HAK and 2DA files. Yes combining 2DA files was a pain and NWN2 did some things to make HAK files much easier but in general the system is really amazing.
The UE4 dream would be to have 1 folder dedicated to moddingā¦built inā¦call this Mods. Then under this modders can make 1 folder per mod. Everything associated with that mod goes into that folder. Mods would be specific to the developer so getting each mod to work in that particular game would need to be done in that game project and not in a general UE4 made project.
Now as to exporting the mod so that it will work in the actual game play (or available from Nexusmods or Steam for Free) could be a PAK or DAT file that is nothing but binary data inside that is useless unless imported into the UE4 game project it was made in. In fact if UE4 was enabled for Modding (which it kind of is already) could create a Content PAK that could be loaded into the UE4 editor so that modders can play away with the game project and create mods but are unable to export the uassets from the engine. Perfectly acceptable and keeps all but the most stalwart lowlife out of the original files.
NWN1, NWN2, and Skyrim among others are still going today because of excellent modding support. I have played a lot of hours in ARK but not many in the un-modded versionā¦there are excellent mods for it but ARK is far too rough to mod in. Having a universal UE4 export mechanism that game devs can follow that is simple enough for these devs to create their specific workflows from would make UE4 projects with modding intent a real haven for the modding communities.
With the recent Robo Recall modding videos I think is time to bump this thread.
Yey! +1 itās really difficult to reverse engineer Robo recall
Hey, I put together some example code for modding in Unreal without engine customization: Functioning UE4 Modding Example Code - No Engine Customization Required - Modding - Epic Developer Community Forums Iād love some feedback if anyone has a to take a look.
I also found this guide http://rokel.me/programming/2017/02/05/ue4-asset-loading-01.html somewhere on the forum.
Edit: Loading Assets at Runtime - Community Content, Tools and Tutorials - Unreal Engine Forums
I, too, have been hoping to let users create levels for my current project once it ships. It seems like if we could distribute an editor build that didnāt allow exporting of assets (to protect our own assets, and the marketplace creators whose assets weāre using) weād be most of the way there. I guess also a way to restrict which editor elements modders could access would be good too - e.g. if Iām only allowing creation of levels thereād be no reason to give users access to blueprints (other than level blueprints). Different games would want to restrict differently, I guess.
Looks like the community stepped up to the plate on this.
Howdy folks, apologies for the longest of all waits on updates hereā¦ Weāve been working with partners and on our own games (Robo Recall, specifically) in order to take the right approach to building out a reusable framework for making UE4 games moddable, and I wanted to wait until we had more to share to follow up. I think we made some great progress for Robo Recall, and a lot of that code should be heading your way in future releases (thinking 4.17 right now). I know thatās still a little ways out, however, I felt it important to point to a couple areas of Robo Recall in which you can have a look at to get an idea of what we did in the meantime:
There are three core aspects to building a moddable game and editor - Editor changes, Engine changes, Gameplay changes. Iāll point out how we approached each and where you can look to get reference.
**Editor Changes
**In the Robo Recall Mod Kit, the things we did were add new buttons for creating and packaging mods, new menus that helped make subclasses of our moddable base classes, and built a set of subclasses (mod templates) that are referenced by those menus. You can find all about how we built the buttons and what packaging scripts we used, where the mod templates and everything live by checking in Engine\Plugins\OdinEditor. Mods are essentially content plugins that are packaged into .paks and mounted at runtime. Weāll be able to cover this more extensively in a livestream in the future 
If youāre using our approach here as reference, it is imperative that you force cook the Mod Templates folder when you package your game, as they probably wonāt be referenced by anything and will get culled from the list (something we ran into).
**Engine Changes
**Taking a page from the Unreal Tournament book, we leaned on the AssetRegistry as a pretty big crutch when working with asset look ups for mods. Since weāre using .pak files for mods and each .pak has itās own AssetRegistry, we needed to automate the process of appending these manifests so they can be accessed easily without having to check each individual package (UT did this as well but manually, you can check their code here, look for AssetRegistry [GitHub login required]). This is something that will be coming in a later build of Unreal Engine, but the manual UT process works today.
**Gameplay Changes
**For the gameplay side of Robo Recall and making the game ready to consume new info, we moved some of the code that UT has in UTGameEngine into our GameInstance class to ensure it happens after the mods are mounted and the AssetRegistry files are combined. Basically, we look for all new mods found by their package path, check to see if theyāve got content that we care about (subclasses of our base classes, maps), and register them up when theyāre proven to be valid. OdinGameInstance.cpp and BP_OdinGameInstance.uasset have all the base code for the mod registry and handle most of the work here.
Robo Recall mods work by registering two classes together and returning the other when one is requested. When a player selects a mod, OdinGameInstance does the following:
-
Checks each moddable type in that mod (players, enemies, etc)
-
Checks any valid assets that are in that type (Catgun, RocketLauncher, etc.)
-
Casts the assets to base class, checks value of Class Overrides (Which is set in the actor when making a mod) and registers that class with the class found in the list (assuming itās found).
Once the pair has been registered, you can call GetOverrideForClass from Blueprints (or code) as we do in the Holsters (or maybe HolsterComponent?) and OdinCharacter (how we spawn enemy guns). If there are no overrides registered for the class, it just returns the same class so the game functions as usual. Maps are referenced by string and opened by name.
A few other things weāre still trying to sort out:
-
How to handle content that you canāt redistribute in your own editor (like Marketplace content). We had to do some work-arounds for this for Robo Recall and our partners like Wildcard and Funcom have done similar, but we donāt yet have a formalized process for making this smooth and easy. What we ended up doing was cooking the assets and then replacing the editor ones with the cooked versions (often to fun, new crashes :D). A build server that can strip files or automate some of these things helps greatly here.
-
Engine content referenced by mods. We spent a lot of time tracking down what was going on with specific materials on some mods only to find that there were Material Functions being used that were referenced by the mods but not by the vanilla game due to them being in the Engine directory instead of Game directory. IIRC, we ended up just forcing those to cook as well.
-
Other things Iām sure Iām forgettingā¦ but Iāll add here as I ārecallā them
I hope that gives some of you some insight into our approach and a little bit as to what to expect next. Apologies again on the mega-delay in getting back with you all, Iāll be checking back in more regularly and preparing to cover this in more detail in live form soon!
Thanks ! Awesome to hear.
So how about allowing us to redistribute the editor with the game on Steam ? Because thatās the one thing we really need.
Thank you thatās great, Iām especially excited about this:
Weāve discussed the explorations of other distribution options but have no plans at this time. Will update if that changes!
Thanks for the reply !
I must say, that itās good to hear about the new upcoming modding support.
For my game Musical Range, I got Super, Super lucky. My mods only needs 4 files. A empty file extension for manifest, a text file for meta data, a jpg image for album covers, and a midi track to play the music track in the game. (Look at my game trailer if you wonder what my game is about).
Thanks to @ I managed to get a blueprint function that reads a raw jpg image in a folder. Thanks to Fpaths and FileManager I can read a txt file. Thanks to FileManager I can get a list of the names of files to read the manifest list of mod songs available. And it turns out the MIDI Plugin had a function already to read midi directly from file, without having to create a new uasset.
This means, in my game, I made a folder called CustomSongs.
Inside of 0Manifest
Inside of RickAndMorty-mainTheme and inside of the txt file.
And you can see from Meta.txt I simply have a youtubeID string, that I use to load in game a youtube video that plays the music to the midi track.
It works, and is super user friendly! The players dont need to download ue4, dont need to packag,e create plugins, nothing! So direct.
What is amazing, is that I can use this same set up to upload items to the workshop. Which I literally just managed.
Now, I only have to check what files the user sis subscribed to, and have the game look at those directories!
What I am saying, is, if you want your modders to be able to replace or add files, look into adding support to read directly from a file folder. It makes the modders life much easier. This may not work with maps, but for example. Weapon skins or model reskins can work very easy. Models to replace weapons, or props, like hats, can also work. And also can be useful for custom sound effects, or adding song support. It takes some work to add this support to the game, but making the end user life easier is worthed IMO.
I bet many of us started moding, just by downloading skins to weapons, and later on started doing more and more modding. So the support to very basic mod is very valuable IMO.