Creating Plugin-Based Game Code - Sept 6th - Live From Epic HQ

[BrUnO XaVIeR]

Why override values when you can pick the UObject used by these engine and game INI values, change them as usual then call SaveConfig() ...
All it takes is digging into the engine source and find the name of these UObject classess then call GetMutableDefault() on them from your plugin, change the object's variables then save it. Just like the Settings panel does in Editor.

[kamrann]

Because that will write values out to project config files. I don't want to trample on the project level files of people that use my plugin, I just want to override engine defaults and let the project override my values.

Besides, the whole point of using config files is that you can modify values without hard coding it into source.

[ZioYuri78]

Probably i miss it during livestream but how to re-use a plugin in another project? I only have to compile it and copy/paste the dll?

[Blue man]

Probably i miss it during livestream but how to re-use a plugin in another project? I only have to compile it and copy/paste the dll?

Just copy and paste the plugin.

[ZioYuri78]

Just copy and paste the plugin.

And if i don't want to share the plugin source code?

[Blue man]

And if i don't want to share the plugin source code?

I never tried it but I think you can just build it and delete the Source folder because the Plugin has all the binaries when you build it.

[kamrann]

Probably i miss it during livestream but how to re-use a plugin in another project? I only have to compile it and copy/paste the dll?

Run the automation tool as follows to build your plugin for distribution (RunUAT is a batch file in Engine/Build/BatchFiles):

RunUAT BuildPlugin -Plugin="<full path to your .uplugin>" -TargetPlatforms=Win64+Android+Whatever -Package="<full path to where you want the output>" -Rocket

Then you can delete the source folder from the output and distribute the rest. But, as far as I'm aware there is a longstanding issue that prevents binary-only plugins from working as a project level plugin in packaged builds. So if you want to distribute it to people and your plugin gets linked in to a packaged build (ie. it's not an editor-only plugin) then you'll need to tell people to install it to the Engine/Plugins directory, as opposed to their project Plugins directory.

[Richard Hinckley]

For those who watched the stream, there were two issues that came up where we sort of glossed over them to keep things moving rather than diving in and debugging like we would if we weren't broadcasting. Both of those will be addressed in the uploaded version of the project, but I thought I would mention them here:

1. The compilation failure with "SM_State.h" not being found. This was a simple matter of needing the "StateMachine" module added to the "AdditionalDependencies" array in PluginDevelopment.uproject. The relevant chunk of the file should now look like this:

 "AdditionalDependencies": [
   "StateMachine",
   "Engine"
 ]

2. The function that "looked wrong" on the stream did have some buggy code, but it was nothing that affected the use case we demonstrated. A simplified (and corrected) version of that function looks like this:

USM_State* USM_Branch::TryBranch(const UObject* RefObject, 
	const TArray<USM_InputAtom*>& DataSource, int32 DataIndex, int32 &OutDataIndex)
{
	OutDataIndex = DataIndex + 1;
	if (DataSource.IsValidIndex(DataIndex) && AcceptableInputs.Contains(DataSource[DataIndex]))
	{
		return bReverseInputTest ? nullptr : DestinationState;
	}
	return bReverseInputTest ? DestinationState : nullptr;
}

The previous check for an empty set of "AcceptableInputs" was not needed or correct. The OutDataIndex variable is now always advanced, regardless of whether the AcceptableInputs test passes. This is made necessary because of the presence of bReverseInputTest, meaning that failing the input test can still cause the branch to be taken, and thus input needs to be consumed in all cases.

[NLEBEDENCO]

Hey great presentation guys.

I just wanted to add that contrary to what was said in the video, Finite Automata do not necessarily have a guaranteed acceptance state for any arbitrary input sequence. Repeating states with cycles of different sizes may be perfectly valid (i.e. one may want a FA for its side effects only). The "Finite" term there refers to the number of states in the machine. What guarantees you termination is the general definition for Deterministic FAs which requires a non-empty set of acceptance states.

And without touching the proof by contradiction the most simple intuition behind the halting problem is not that you may trick the analyzer into returning the wrong result but that any analyzer would have to be able to evaluate all possible states and transitions of a program to determine if it would ever come to an end which is basically the same as to say the analyzer would have to run the original program itself. Since the hypothesis is that the original program may never end we get stuck back where we started...

[Richard Hinckley]

Hey great presentation guys.

Thanks, glad you enjoyed it!

I just wanted to add that contrary to what was said in the video, Finite Automata do not necessarily have a guaranteed acceptance state for any arbitrary input sequence.

That's definitely true, and I hope I didn't say that. Having a guaranteed acceptance state for any arbitrary input would mean that we can only build "yes" machines, using strict DFA construction rules.

What guarantees you termination is the general definition for Deterministic FAs which requires a non-empty set of acceptance states.

Here, I differ a little bit here in my understanding of DFAs. There are two departures I have from this:
1. FAs, as I understand them, require the set of acceptance states to be a subset of all states. But the empty set is a subset of every set, so this is OK as far as computer science theory goes. However, doing that means we made a "no" machine, which is as useless as a "yes" machine, so we probably shouldn't do that in an engineering/game development context.
2. I would say that what guarantees termination are the following rules: every transition in a DFA consumes one character from the (finite-length) input string, no state or transition can add characters back into the input string, the machine terminates immediately upon running out of input. This also lets me know that, given an input string of N length, the machine will definitely terminate within N steps.

I may have been wrong (or unclear) about some of what I said about NFAs, though. NFAs are equivalent to DFAs in terms of what they can do (any NFA can be converted to a DFA; any DFA technically is already an NFA) and therefore the same tasks can be performed by either. The reason we steered away from NFAs is that, although NFAs can often be written with fewer total nodes/transitions than equivalent DFAs, writing code to evaluate them can be more complex. I hope that's what came across during the stream.

And without touching the proof by contradiction the most simple intuition behind the halting problem is not that you may trick the analyzer into returning the wrong result but that any analyzer would have to be able to evaluate all possible states and transitions of a program to determine if it would ever come to an end which is basically the same as to say the analyzer would have to run the original program itself. Since the hypothesis is that the original program may never end we get stuck back where we started...

I think you make a good point here, so thanks for making it! That's true, I did gloss over that in the stream. I think you're right that the most naive approach would be to construct a "watcher" that simply observes the machine being tested, and this "watcher" would fail to detect halts for just the reason you said. The second step would be to construct an "analyzer", which is subject to being "tricked" as I said. I just skipped right to the "analyzer" and for a first-time introduction to state machines (some viewers may have been new to the concept), walking through the "watcher" scenario first would have been better. It's interesting to see the different approaches people take to these kinds of questions, and I like how clearly you laid out that part of the problem. Thanks for contributing your explanation!

Anyway, it's been a while since I just discussed raw CS theory stuff outside of "how will this make a game project better", so thank you again for bringing it up. I hope the community benefits from this kind of discussion and maybe some people explore and apply different areas of computer science to their game development work.

[kamrann]

[MENTION=2247]Richard Hinckley[/MENTION]: Would you be able to address the questions I posted above, or pass them onto someone? It's nigh on impossible to get answers on technical questions from Epic staff (with a couple of exceptions) if they're not part of a bug report, so a related stream is about the only chance I have.

It seems Q1. has been shown to be the case, but I'd be interested in why it's this way. I think a lot of people would be surprised to discover their project is packaging, for example, Paper2D related code, if they never did anything to explicitly enable it.

[Richard Hinckley]

[MENTION=2247]Richard Hinckley[/MENTION]: Would you be able to address the questions I posted above, or pass them onto someone?

Hi, kamrann. I'm not an expert in that area, and I'm not actually sure who is, but I'll ask around for you.

[kamrann]

Thanks Richard, that would be appreciated.

[NickDarnell]

I'm going to repeat my questions from the stream as they got misinterpreted. Hopefully someone can help out.

1. Do engine plugins need to be explicitly disabled to not be linked?
If someone uses one of my plugins in their project, most likely they will make use of it via types exposed to blueprint and not add any dependencies in their .build.cs files. Nonetheless, my plugin, assuming it's enabled, will be packaged and linked into their game. So, since many engine plugins are enabled by default, does this mean that they are all getting linked to a project executable even if they are not being used? Most projects won't use most plugins, so if this is the case it would be a pretty big unnecessary overhead.

2. Are config files in plugins coming any time soon?
Paper2D does not have any config files, contrary to what was stated. I'm referring to the ability to provide config values that will be processed as part of the config hierarchy in projects in which the plugin is used. So for example, we could add custom collision channels or configure things like the online subsystem in the plugin, and not have to give instructions to users to modify project config files themselves to make the plugin work as intended.

3. Why are .lib files generated by the RunUAT BuildPlugin command so much bigger than those in Launcher engine plugins?
When I package a plugin with the automation tool, I'm getting non-editor build .lib files in the region of 30MB+, whereas those that come with the engine are rarely above a couple of MB. Why is this, and is there some flag I can use to generate smaller .libs?

Thanks.

1. Yes. Though you can black list / disable the enabled by default plugins to not have them linked. Some plugins don't get linked in shipping builds, e.g. Developer Plugins.
2. Maybe, it's on the list of important things to solve with plugins; as is making it possible for plugins to have a Shader directory.
3. Because of the large engine header files. On the build machines we share PCHs to avoid the obj being stuffed into each lib, is my understanding. If you were building the whole engine from source & the plugins you should also see a similar size.

[kamrann]

1. Yes. Though you can black list / disable the enabled by default plugins to not have them linked. Some plugins don't get linked in shipping builds, e.g. Developer Plugins.
2. Maybe, it's on the list of important things to solve with plugins; as is making it possible for plugins to have a Shader directory.
3. Because of the large engine header files. On the build machines we share PCHs to avoid the obj being stuffed into each lib, is my understanding. If you were building the whole engine from source & the plugins you should also see a similar size.

Thanks for the answers Nick.

With number 3, I don't really understand why the libs would need to be so big when built independently - presumably this stuff ends up getting dropped when linking anyway, rather than duplicated in the exe. But I won't pretend to have any idea what I'm talking about. Cheers.