Does this mean that games cant be moddable?

Hi SememeS,

The FBX importer being so deeply tied into the Editor modules right now is more of an artifact of history than a conscious design decision (at the time we weren’t thinking about editor extensibility nearly as much, etc…). We don’t have any short-term plans to refactor it right now, due to higher priorities for the tools team (UMG, Sequencer, etc…), but we would certainly consider taking a pull request that refactors FBX importing to reside in a separate Runtime module (and in general any work that heads towards making mesh importing pluggable, whether it be Developer or Runtime code).

If anyone is interested in working on , I can put them in touch with people who can guide the effort / review it.

Cheers,

Hello, thank you for the response.

Not really, for me anyways… But If I end up having no choice, we’ll see. It all depends more on the legal limitations of the users too(would they be limited by having to own a ue4 license to use ? If so it’s even less appealing)… So TBD :stuck_out_tongue_winking_eye:

[EDIT] Also I wouldn’t even know where to begin implementing such a large change like that… I barely have the knowledge for it. And it would take me so much time just to even begin…

At first I was hoping more to extend on the current fbx importer, which would have been hard for me but still much simpler than the tall order you just asked…

I’m sorry I just wasn’t expecting an answer of: Why don’t one of you do it for us

[EDIT2] Sorry… I apologize. I’m tired and I took your response the wrong way.

See currently for modding, the solutions are pretty limited and unappealing(for me anyways). In most cases they require the user to have ue4 or creating such separated tools from ue4 that it’s a big headache.

Sorry, I know it’s probably not the answer you were looking for, but I just wanted to make it clear that we’re potentially open to refactoring it so that FBX importing lives in Runtime code. Then it could then be used without triggering the EULA clause that would require a subscription. Part of being more transparent includes saying when we’re not planning on working on something in the short-term, in addition to when we are (limited resources and things like UMG will benefit many/most teams using UE4).

Cheers,

Well said. Thank you for taking the time to explain & answer us, and I apologize again.

I do appreciate the transparency a lot

is definitely the kind of thing we’d like to see! Migrating content import and asset packaging away from the editor-only side of the project would actually solve a lot of our problems. It’s not a catch-all for everyone though - our game is largely procedural, so we only really need content import and some scripting ability to incorporate basic modding. I can easily see other games needing much more though.

So ignoring all the griping about reality in the thread here I’d really like some information on how to actually support mods ASSUMING that modders are registered licensees of UE4. I posted my question here on answerhub but I haven’t heard back yet.

https://answers.unrealengine./questions/73707/technical-how-to-support-modding-with-ue4-tools-ar.html

As far as I can figure out UE4 has no way of letting you mod the game. All I can figure out how to do is basically give modders the entire .uasset content repository and let them package entirely custom versions of the entire game, meaning they could change anything and everything, including hooks into DB backends, loading screens, menu’s etc. I have no real control over what can and cannot be changed. It potentially exposes sensitive systems in blueprint etc.

Ideally somehow they’d be able to produce new content based on some basic blueprint types and other smattering of assets we provided for them without having to give them the entire project. The sheer size alone of the full project could be gigabytes. Because of the dependancy system in UE4 I don’t see a way to even trim down the existing asset tree to just the basics.

Also UE4 currently has no way of packaging a mod. I want to end up with something like Doom WAD’s: mod authors can distribute UE4 pak files that the game can optionally load to add new content, or override existing content. I don’t think that is currently possible? Does anyone have experience with ? If we do have to distribute the entire asset directory it’s not very easy for mod authors to separate out their new or modified content and only package that (assuming there was a packaging process for mods).

Anyone know how to do ?

Assuming licences, you could move everything you want to protect over to c++, or you could just encrypt/protect the important .uasset files, and from there you’d simply re-load any models/actors/etc. that are put into a separate mod folder to replace default ingame content. And you will want to load anything new also. And then you can restrict what would overwrite “original game” files. All can be done right at the end of your project, possibly.

If you want to restrict everything, maybe you can get by on implement lua scripting and including an open source 2d/3d level editor and read model IDs from resulting text files.

As for packaging a mod- why can’t zip/rar files work? And there is free code for uncompressing and reading archives. Packaging a mod is one of the more specific things they’re tried to avoid in ue4, I think. It would have to fit your needs specifically.

The real frustrating, as I see it, would be the changing features and options in major future versions over the next year or so. Having said that, though, it looks like a lot of thought has been put into the overall structure of ue4 so maybe it can’t change so much. But if an engine change/update messed up my maps and project code through tedious things like changing hundreds of function names, that’s really unattractive as a small or indie developer, or at least for me, even though it’s well-intended. These are the make or break issues for me.

The packaging conundrum is actually one of the core problems. By packaging I don’t mean zipping or compressing. I mean the UE4 packaging process: You have to cook the content or it won’t load in a shipping build of the game, all the generic loading code is stripped out in a shipping build: static meshes and textures are compiled and built for their target platforms, and so are other types of assets. Zipping up .uasset files used by UE4 tools won’t work.

For sensitive things it’s true that we could keep certain things in C++ and forcibly load our version of certain assets instead of ones possibly included in a mod.

Something that just occurred to me about pairing down the size of necessary content is using the migrate to export certain blueprints and assets to a clean “mod” project that could be used as a starting point for mods. Theoretically the migrated blueprint classes could be loaded from our copy still.

Agreed: versioning of things is a potentially difficult situation as well.

In UE4 Editor: File->Cook Content For [PLATFORM]

That probably does exactly what I want.

alarming

might be the child wondering why the emperor has no clothes, but whatever happened to UnrealScript?

A cursory glance at http://www.gamasutra./view/news/213647/Epics_Tim_Sweeney_lays_out_the_case_for_Unreal_Engine_4.php suggests yeah, UE4 got murdered because, uh, “development”. Since the whole point of being at least partially open-source is that you can do things like add features, what technical reasons are there that has not been re-done, even if it makes it impossible to use some magical innovative synergy schematic, if one wants to have mods? I’m glad at least one person is working on Javascript or something, but why was a scripting language an in the first place? I feel like when says “huge dividends” in that article he literally means it, they got to fire all the script developers, charge a subscription fee for basic needs, and then mooch off everything made. It makes good business sense, but holy **** are developers getting screwed in utility. A car shouldn’t come with a subscription for the tools I need to make a steering wheel. There’s an expectation of functions which are clearly being missed by what’s been communicated in thread.

Does a level editor and whatnot really have to be hand-built because a general-purpose scripting engine has been removed? It seems every release there are critical steps backwards, UT99 started off with annoying model formats that even these days aren’t widespread, then UT2k4 had some bad AI (though it was **** good otherwise), UE2.5 welcomed graphics over world sizes and started closing assets, then UT3 had graphics out the wazoo, the gameplay deteriorated, and now we can’t even get scripting.

There’s a feeling like AAA devs need to be locked in a garage with nothing but pizza and soda for a few months to remind them of how it feels to not be on the top. Although closed, Unreal Engine 1 worked (with logic bugs, not engine bugs, being an for developers), performed incredibly well (cross-platform, on nearly all hardware, any FOV, easy config settings), and had lots of actually fun games and mods. Feels like we have to lose everything that made the engine good if UE4 is to be used. I mean, hell, I didn’t know until I tried Anaglyph 3D that an notice or credit in UT99 or Unreal was a texture on a plane, that the first Unreal Engines worked in 3d better than many games were working more than a decade later. It may have been my gpu drivers supporting earlier DirectX during a beta, or it could’ve been an enhanced renderer (which, including games themselves, are still actively being worked on, much to the chagrin of newer engines).

I even got bamboozled into thinking there were going to be many UE3 games for Linux. Boy was that disappointing, and but Linux support is improving. Sweeney should just cut’n’run with Ryan C. Gordon for greener pastures. Also take Dmitry Rekman and Polge, they seem pretty smart.

Please delete post. It doesn’t add anything meaningful to the discussion.

It sums up a lot of the frustrations, I can edit out my opinions, but mod support at point should be considered a bug.

Regarding how to ship a moddable UE4 game:

It’s possible to package a UE4 game for PC/Mac with all .uasset files as-is, rather than combining them together into a .pak, so the Unreal Editor works as expected. It’s also possible to create a mod .pak that overrides certain files contained in a shipping game’s .pak, but that process hasn’t been polished to make modding work nicely; for example the editor’s content browser doesn’t know how to deal with content in a game distributed with .pak files.

We have some work to do to polish so it works nicely with respect to mod development, packaging, and redistribution. In the meantime, the hacky approach of modifying a game in-place works.

We’ll be putting a lot of thought into modding, and hopefully start some implementation efforts towards the end of the year.

Regarding moving from UnrealScript to C++ as of Unreal Engine 4:

Here’s a long discussion on the topic with a bunch of we Epic folks weighing in: https://forums.unrealengine./showthread.php?2574-Why-C-for-Unreal-4. Mastering advanced C++ features is certainly hard, but for ordinary gameplay code as you’d write in UE3 or UE4, the equivalent C++ reads very similarly to UnrealScript, and shouldn’t be too tough to learn.

@, any word on being able to get gift codes for a month’s subscription, so that those could be included in a “modder’s edition” of a game?

Thanks ! That sounds pretty much right on so there really aren’t any major obstacles there. Is it possible for mod authors to package just their content (and not the original assets in the game)?

I agree with (always very impressed on having you on the forums… thanks)
coming from Unity I shall say that most people do not understand that Ue4 C++ can be considered a simplified form of C++, not much difficult than using C++.

There are some improvements on editor /code integrations that are being worked on, but will not affect much your productivity, especially if you use a tool like Visual AssistX

On the modding part I posted an idea On the Epic Feedback Forum which could possibly be a starting point for Unreal Engine modding decisions.

Please comment what you think about it…

thanks
Fred

is very, very good news. Thank you

Has there been work on a limited API? I didn’t read through the entire link on UnrealScript, but it sounds like it tried to much to be a programming language, and the only interface between inside/outside code. Even if it was added in, a standard extra-object importing library and handling system could go a long way.

I imagine most developers would like there to be an ultra-optimized core, but still have a middle more flexible layer where content could be dynamic. Red Alert 2 and Yuri’s Revenge for example had some of the most beautiful modding available, where there was a strong hierarchy, like for a weapon, bottom-up, you’d have warhead+projectile->weapon->unit, and was all accessible through text in the beginning, with huge reference sections. Later an “IDE” called TibEd simplified while still permitting manual editing. The game did bug out when you tried to select thousands of units, but the engine performance and net performance were beyond incredible, comparing the flexibility and ease at which one could modify the game. Even without hardware acceleration it ran incredibly (I think I was on a 1.6ghz P4 with 2GB of ram for the longest time). The packaging system was also additional and standardized, and since even the start-up sequences and campaigns were exposable, it is what I would call the best closed-source moddable game. It did not permit changing the AI routines directly, but there was weighting factors on a per-difficulty basis, and pathfinding was top-notch.

On a side-note, it feels like there’s weird performance gap, where something like Team Fortress 2 looks to have the same quantity of variables exposed as some previous games like Red Alert 2 but there was a severe regression comparing like 100 buildable units. 100 buildables all with modifiable statistics and patterns, while a more modern game has maybe 30 at a non-default value. Can a developer shed any light on what may contribute to ? I’m not disrespecting modern engines, I’m looking for personal experiences on “better” or “worse” decisions when programming and exposing flexibility.

Some considerations?
-modifications are set before the game commences (the rules were set, although unit statistics like speed and damage had multipliers, and weapons could change per-unit)
-there were strict limits on what could be imported, there was a weird voxel format for 3d, icons were low-resolution bitmaps as opposed to vectors
-the AI was mildly effective, but not intelligent or strategy-changing
-some games have full 3d floating point, while older ones tended to used 2d ground + limited height variables
-nearly everything did not scale, so rendering was pretty fixed-pipeline

Edit: Here is the example file for Yuri’s Revenge. I include it because it is, whether a modder or developer, the organization, accessibility, and documentation for modifying the game are extensive. is only the core file, it does not include the art or sound mod files, which are available freely, nor did I include any references to tools used to modify asset containers.

Epic be happy to consider that sort of arrangement if a high quality game were in development that planned a polished mod integration effort and cost significantly more than $19. I think the timeframe for having sufficient mod functionality for doing successfully would be 2015. For a moddable game effort on an earlier timeline, I recommend using the existing mechanisms in place, such as checking your customized Unreal Editor into a public UE4 fork on Github so that it’s accessible to UE4 subscribers.

Technically, there are engine mechanisms to support (with one .pak overriding the contents of another, and support for creating these .pak’s for game patches), but it’s not polished for usability or easy deployment/management yet.

Yes, the subset of C++ functions in UE4 defined as BlueprintCallable comprise the UE4 “scripting” API. These functions are exposed to the Blueprint visual scripting system now, and would be exposed to scripting languages in the various efforts to integrate scripting into UE4. Here is an early example that contains a clear description of the approach: https://forums.unrealengine./showthread.php?1753-Simple-JavaScript-Scripting-interpreter-embedded-in-BluePrint.

Thanks , that sounds pretty good! Thanks :smiley: