MegaGrantRecipient

I am super excited to announce that Magic Nodes Plugin‘ is officially a Epic Mega Grants recipient for this year of 2020!
Thanks to Epic Games’ terrific generosity I have the path clear to move forward and make this tool grow to the point where it can be.
I also want to thank you, everyone out there who is a believer and has been using Magic Nodes, always providing me with awesome feedback.
Feel free to always get in contact with me through email or PM me if you use Magic Nodes and want to share your experience!

Thank you again, Tim Sweeney & all of Epic Games staff!!
Much appreciated!

Epic Mega Grants: Magic Nodes

Sometimes as developers we don’t Blueprints or C++ code to fail silently. Sometimes we need things to break to warn us that something unexpected went wrong. However at same time we don’t want our Editor crashing all the time either, we just need it to point us to the correct direction and then break execution, pop warnings, etc.

Exceptions are great for that. However, Blueprints do not implement nor provide any way to implement exceptions out of the box. So I built a library of self-explanatory custom nodes for that: To implement exception logic on top of Blueprints.


 

This plugin implements a friendly high-level exception handling library for Blueprints.

You can facilitate automation tests and help designers to have an easier quality of life when debugging game features, making use of Try / Catch / Break statements on Blueprint Uber Graphs.

There’s over 70 C++ classes to incorporate 20+ new nodes into the engine for that purpose:

  • Throw and log exceptions from graphs without crashing the Unreal Editor.
  • Catch Casting Failures before expending cycle resources on ‘Cast To’ nodes.
  • Catch Null Pointers, Invalid Object References, with logs for programmers.
  • Catch Invalid Property Values (Arguments) from gameplay graphs.
  • Prevent ‘Divide-by-Zero’ errors.

These nodes are very self-explanatory and can be found under the newly introduced “Exceptions” category of your Blueprints’ Master Graphs:

BPEx_1

BPEx_2

BPEx_3

BPEx_4


 

This library is due to release on Unreal’s Marketplace soon.
One of those things that “should be part of the engine by default”, but for whatever reason Epic Games isn’t interested in adding to the engine due to internal philosophies.


 

This is now published to Unreal’s Marketplace:
unrealengine.com/marketplace/blueprint-exceptions-library

Blueprint Exceptions (Programming)

 

What

Recently I had to create a system to make materials remember several input parameters that are changed at runtime.
For infrastructure reasons, the project needed this to be implemented without involving any “Save Game” systems, to capture all parameters from existing dynamic material instances on scenes and restore them exactly like they were left when the application quit.
It had to serialize Scalar parameters, Vector parameter, and Texture2D reference parameters without care about saving or loading back any level or info about the actors using those material instances.

So I put together a plugin that captures and restores all dynamic materials of a scene that can later be restored, for persistent game worlds and interactive ArchViz projects.
The idea was to make it feel like a “save game” system, but without using any actual save game system with dependencies to the “Game World”.
There’s a “Capture Snapshots” and a “Restore from Snapshots” node that can be used to save and restore all runtime material states from a scene.

The materials must be “Dynamic Material Instances” to work. No workflow changes or changes to existing materials are required, the target meshes just have to properly use a Dynamic Material Instance to make it work.
Scalar Parameters, Vector Parameters, Texture Param2Ds are supported by the system. I decided to make it public and publish on Marketplace, Epic Games should have it available online in their store soon.


 

How To Use

This is extremely simple to use even for non programmers.

  • Step #1, your materials assigned to the meshes must be dynamic material instances, it’s an internal shader requirement of Unreal Engine due to how materials work.
    From within your Blueprint’s Constructor Script you can do something like this to create and apply a dynamic material instance to your mesh:
  • Step #2, the base material, the one you edit in Material Editor, it should contain dynamic parameters you’re willing to be changed at runtime and that the plugin will later record and restore recorded values from.
    A very simple base material as example. “Color” vector, “Diffuse” texture, “NormalMap” texture, “Metallic” param, and “Roughness” param, are all parameters from the material below that can be changed at runtime and restored back to their changed values by the plugin even after the application was closed and then later executed again:
  • Step #3, to capture or restore material data. You just need to execute a variation of these nodes to do so.
    Capture Material Snapshots” will record every dynamic material instances and their parameters in scene.
    Restore Materials from Snapshots” will revert them instantly back to the state they were captured:

 

Note

Keep in mind that this system doesn’t make distinction of “levels” or “maps”, this is by design. A material named “MyCoolestMatInstance01” in multiple levels will be treated as one same material to be captured and restored.


 

This is now published to Unreal’s Marketplace:
https://www.unrealengine.com/marketplace/en-US/slug/persistent-dynamic-materials

Persistent Dynamic Materials (Programming)

Unreal “Magic Nodes” (Programming)

 

What:

I’ve put together a system which I call “Magic Nodes” where we can write some C++ functions in-place on any Blueprint Graph and that node will “morph” to match the input and output parameters of the function we wrote within the node itself. Reasons behind why I built this is, in part, because there’s numerous tasks where dragging wires on Blueprint Editor slows down productivity and this tool could be useful to address that, sometimes it’s simply faster to type a few lines of code instead of dealing with wire spaghetti!

With this I also hope, with time, Blueprint developers have a first contact with C++ code and slowly become comfortable moving to Visual Studio workflow later on, if wanted.

 

mgc_1

 

We can type some code, compile (hot-reload), and the node will “morph” its pins to accommodate and execute the function we wrote inside of it.
This can be very handy for developers missing something in-between Blueprints and pure C++ code… Also it’s very useful to actually “read” right there what exactly that one node is doing.

 

mgc_2

 

While coding our functions in this node, we can have some basic auto-complete functionality as well. However keep in mind that I have no previous experience with any of this, turns out making an auto-complete feature is a beast of a complex task and I’ve implemented only the very basics!
For example, in this screenshot the node detected I am trying to invoke a function from a ACharacter class, so while I was typing an auto-complete panel will popup, showing me functions and properties members of ACharacter class:

 

mgc_3

 


 

Workflow:

Here a quick intro of how these nodes are setup and how to make them work correctly for you…
Because this is “real C++” (encapsulated into a safer environment), but still C++, these nodes require your Unreal Project to be a C++ project in order to execute.
Magic Nodes rely on Unreal’s Hot-reload feature to be useful. The basic workflow:

mgc_nodeusage

  1. Just like regular C++, you have a Header field (H) and a CPP field (CPP) where you can declare and define you node’s functions, respectively. Alternatively there’s also a Type field (T) where you can declare any additional types such as enums, structs or classes that your node will use at runtime to execute the code you create.
  2. Before compiling your changes, you have to save your node, that will update the “root source”, the source which stores your code and shares it with all the instances of your node. You can place on Blueprints multiple instances of your node, the source code to execute will be the same for all of the instances executed.
    “Ctrl+S” works as a shortcut for this save button.
  3. Once you’re happy with your code, you need to compile the node, this first button from the Node toolbar. This will run a pre-compilation system that will examine your code… If everything seems correct the this pre-compiler will do all the work necessary to generate (or update) a native C++ class which is what is going to be executed at runtime once your game is packaged. That means that this node is just a “shell” holding the entry point of where and when your C++ code will execute within your Blueprint Graph. The node itself is purely visual and in reality doesn’t do anything besides display to you what it is going to execute.
    If the pre-compiler is happy with what it sees in your code you should hear a “success” beep sound confirming that it indeed generated the native node correctly.
  4. If the pre-compiler is happy with your code, next step is to tell Unreal Engine to incorporate the node runtime into the Blueprint’s Graph execution flow. We do that by hitting the Hot-reload button from the main editor’s toolbar.
    This step is where the actual C++ compiler kicks in and catch any deeper defective code you might be trying to compile; If you can’t get past this stage, it’s a good idea to ask C++ veterans on Unreal’s forums, usually they can point out what exactly is wrong with your code.
  5. Once Hot-reload compilation is complete, this is where the “magic” part comes in… Click the refresh button and the node, now properly compiled to binary library, shall update its input and output pins to reflect the entry function in your code (“FSelf::Execute” function). Once pins are generated and/or updated, you can proceed to link your target variables to it and/or set default values of your pins.

 


 

Example:

Let’s create a node which takes a reference to our Character Blueprint, subscribes a native (node’s internal) function to Character’s “Jump” event and then tells the Character actor instance in game world to jump… This example characterizes as a “Persistent Node”, it keeps running like an Async Function such as Delay Nodes.
Of course, you could simply call the the “Jump” node instead and be done with it, but the point here is to exemplify how you can do that same action from Native C++ with magic nodes instead of calling one new Blueprint Virtual Machine‘s function for every single node you need to call (VM function calls in the end have heavy performance implications, they are orders of magnitude slower than native code and many developers end up converting good portions of their code to C++ because of that). The fact that we can add hundreds of functions to a Magic Node’s source and a call to that node is going to be just ONE call from the Virtual Machine, that’s a performance boost to be considered while at same time we don’t have to deal much with complex plugin modules setup (lot’s of boilerplate code) just to run our functions is also a workflow improvement, there’s much less support code to write on Magic Nodes…

So, make sure that you have Magic Node plugin installed and properly activated:

mgc_guide_0

 

First we will need to create our “source”. We can do this from File -> Project -> “New Magic Node Class…“; That will create a new Magic Node pack in your content browser:

mgc_guide_1

 

Once the source is created and named, let’s forget about it for now. Let’s go to our Character Blueprint and add a new Magic Node to its Graph:

mgc_guide_2mgc_guide_3

 

We now have a “shell” to execute our node. By default it is empty, if you try to compile the Character Blueprint you’ll see Unreal’s Blueprint Compiler to complain about it:

mgc_guide_4

 

So, that source pack we have created before, we need to tell our shell to use that source we have created, for that we use the asset picker right below that error message on the node, it will bind this shell node to our source so we can start coding our functions in it:

mgc_guide_5

 

Now we have our source and the node shall become editable. If we try to compile our Character Blueprint once again, you might notice that it now recognizes our Magic Node as valid, however it will now complain it can’t allocate the entry point “Execute” function even though we can see it is there in our source. The reason why it is that way is because the runtime C++ only cares about compiled binaries, it doesn’t care or interact with any components of the Blueprint’s Virtual Machine:

mgc_guide_6

 

We don’t have to care about that right now, let’s proceed and create our node’s code.
To make it work, we’re going to directly use two member classes of Unreal’s Game Framework, Character class and Input Component class. To use them, we have to include the path to their respective header files; if you’re not sure where those headers are located you can type their types in your script ( ACharacter, UInputComponent ) then Ctrl+LMB them: The Magic Node will launch your browser and search Unreal’s API website for your looking for those classes pages. If the page exists, you should be redirected to these pages, at the bottom of the pages you can find the paths to their headers, here:

GameFramework/ACharacter/
Components/UInputComponent/

Click the “+” sign of # Includes row to include their paths:

mgc_guide_7

 

Done that, we now need to type some code to achieve our goal.
Let’s add this functionality to our H section and CPP section of the node
(don’t worry about the “Character” pin already visible here, that is only there because I have already compiled this node).
Code to the left goes within the Header (H), right one goes within the CPP section:

mgc_guide_8


FIX:

Epic Games team added the same “Subscribe()” function to Unreal Engine on 4.24 and above. To avoid problems then we have to use now “Enroll()” macro inside of Execute function, instead of the “Subscribe()” you see above.


 

Done that, let’s now save and pre-compile our node, from the node’s toolbar:

mgc_guide_9

Then tell Unreal to compile the binary version of our node.
Clicking the Hot-reload button:

mgc_guide_10

 

Once Hot-reload compilation is complete, let’s head back to our node’s toolbar and click the “Refresh” button:

mgc_guide_11

 

Done that, we shall now see that your Magic Node now displays an input pin called “Character”. Let’s attach to it a variable of our Character’s self Blueprint:

mgc_guide_12

 

If you did everything correctly, now compile the Character Blueprint (Blueprint toolbar, not Hot-Reload) and then your Character Blueprint should now be happy and understand what have just made; When playing in editor, if you press the space key the character will jump (make sure you have input settings setup on project settings panel):

mgc_guide_13

 

And that’s it, a quick example of how to run native C++ code on Blueprint Graphs without leaving the Blueprint Editor to work on external applications such as Visual Studio!
If you leave the game running for a while though, the code will stop working…
That will happen because Unreal will run a Garbage Collection operation and our Magic Node running will be destroyed. It’s simple to avoid that, because our node is latent (Persistent Node), we don’t want it to be garbage collected, so we just have to change the declaration and definition body of our “Execute” to output a self-reference, like this:

mgc_out

Then we save the script, pre-compile again, Hot-reload again and now after Refresh our node has an output pin. We promote the output to a variable (here named “Controller Script“) and make the Character Blueprint hold a reference to it, so while our Character Blueprint exists the Magic Node will never be garbage collected:

mgc_guide_14

When we are done with it and want the node to be destroyed, all we have to do is set the variable “Controller Script” to null pointer. The next time Garbage Collector runs it will collect the remains of our node and destroy it as expected!

 

But what if we don’t need a persistent node?
In this case it’s way simpler. We can write the whole functionality within the entry point “Execute” function. Doing so will NOT generate any garbage and the Magic Node will be a “Fire & Forget” type of node, it will be destroyed right after execution flow (white wires) leaves the Magic Node, just like any regular Blueprint nodes!
Like this example node shown previously:

mgc_2

So, I’m running out of time for now, this should illustrate how the general workflow is meant to be when you create Magic Nodes. If you have doubts and questions, feel free to ask in the Unreal Engine’s public forums (link below).


 

Note:
When you want your C++ classes to reference and use Magic Node classes from the Source/MagicNodes/  directoy, besides including a node’s respective class header, make sure you add the “MagicNodeRuntime” module dependency to your project as well:

magicnoderuntimemodule

 

-We don’t make mistakes, just happy little accidents!”  — Bob Ross
Happy coding!

 


 

You can find more about this tool and contribute feedback on Unreal Engine’s forums here: https://forums.unrealengine.com

This is a simple Editor Plugin for Unreal Engine.

It helps to batch transfer Blueprint Properties (variables) between any number of Blueprints selected on Asset Browser.

 

 

It’s very simple to use:

  • Pick a ‘Source’ Blueprint.
  • Pick Target(s) from Asset Browser.
  • Pick which variables to copy.
  • Click ‘Apply’ and save.

Property Picker supports keyboard modifiers:

  • Alt + Click: Pick variable under cursor right away.
  • Ctrl + Click: Unselect selected variable.
  • Shift + Click: Multi-selection.

Property Transfer Tool for Unreal (Programming)

I was in need for a low-poly (real low) human male basemesh modeled with decent line loops for sculpting and prototyping some concepts inside Unreal Engine… Strangely, even though Unreal Engine’s community is a big one, I couldn’t find any resembling an actual human nor one below 50.000 polygons.

I mean, it’s nice to have all muscular volumes detailed everywhere, but for a naked skin character where clothing and accessories are later added upon, that many polygons is just too much for non cinematic character models.

Because of that, I took some time this last weekend to model and UV map a decent male basemesh accurately scaled and fitting EpicGames’ Mannequin Skeleton… And now I’m sharing with you, do whatever you want with it, sculpt your characters, rig, animate, etc*

* If you make models with this to sell on Marketplace, I see no problem at all with that, but I don’t know if Unreal Marketplace policies will allow you to do that.

Anyway, this mesh is:

  • 5.000 vertices.
  • 10.000 triangles.
  • Has Eyes + Mouth cavities.
  • UV Mapped, ready for sculpting.
  • Fits Unreal Mannequin’s Skeleton for Rigging.

Can be downloaded here:
https://www.dropbox.com/s/ic3zzub5t6dfr0o/SM_Male.fbx?dl=0

May be useful to someone out there, cheers!

 

UE4 Male Basemesh (Modeling)

This is a major update for the “Auto-Save Game” system I’ve been maintaining up on Unreal Marketplace for last couple years.

Focused on performance and data reach, I’ve totally scrapped original code and wrote this version from scratch, implementing a fully custom serialization engine that made possible for me to achieve the goal of moving away from the built-in ‘FArchive‘ system and it’s ‘ << ‘ operator constraints. The reasons why I moved away from the internal FArchive operator are many, so I won’t go too much into details about this… Instead, let me throw at screen the new ‘features‘ for you:

  • Savior 2 is tens of times faster than Savior 1.x releases.
  • Multi-Threaded Save & Load capabilities, no freezes or hiccups.
  • Save all data from outside your Game’s main thread, even Actor References.
  • Save any class. Any UObject is now supported, not just Actors or Components.
  • Versioning. Your Game will be capable of loading from old ‘*.SAV’ files after patches.
  • Encryption. All data goes through a lightweight, fast, multi-platform compatible encryption pass.
  • Optimized: Savior 2 is designed to predict and avoid crashes at all costs, no matter how complex Levels are.
  • Optimized: NO Components needed to be attached anywhere thus no memory eaten for the sake of storing data.
  • Optimized: NO destructive workflow. Existing Actors aren’t destroyed/replaced, keeping references alive and safe.
  • Optimized: NO containers created when saving game data thus no big chunks of memory garbage generated.
  • Optimized: Savior 2 Slots are UObjects, not Actor nor Component, avoiding large resource allocations.
  • Automatic Level Transitions on Load from Slot.
  • Threaded Save & Load the whole Game World or individual Actors.
  • Threaded Save & Load Game Mode in real-time, independent of Level.
  • Threaded Save & Load Streamed Levels without pausing the Gameplay.
  • Threaded Save & Load all Properties marked ‘Save Game’, no C++ required.
  • Threaded Save & Load any Dynamically-Created Classes of Actors and Components spawned in Runtime.
  • Threaded Save & Load Actor’s Scale, Location and Rotation, Linear and Angular Velocity automatically.
  • Threaded Save & Load Actor’s Visibility state, Collectibles’ or Particle Systems’ state automatically.
  • Optional Built-in HUD Class with auto generated Load-Screens with Blur, Splash-Screens or Videos.
  • Optional Built-in Progress Bar System with auto generated UI Elements for your Loadscreens.
  • Optional Built-in Slot Widgets with auto generated UI Slot Elements for your HUD Menus.
  • Optional Built-in support for Slot UI Thumbnails and UI/UX Decorators.

 

Continue reading “Savior v2”

Savior v2

This is my implementation of SQLite API for Unreal Engine 4.
This is one of most complex and useful Unreal Engine extensions I’ve built so far.
This system empowers developers to save and load any data to and from SQLite Databases in Unreal Engine 4 without forcing them to write a single line of SQL Code
(or Blueprint Spaghetti).
If you’re developing a Game that heavily relies on persistent data that must be reliably saved and loaded all the time, such as RPG Games, your best bet is implementation of a Database such as SQLite to record Player’s progress, instead of relying on binary or text files to save your Game…

But learning SQL programming may become a daunting and lengthy process for you to achieve that goal. With this system in place, you can create reliable Databases for your Games, and never care less about SQL syntax.

Making use of a powerful custom serializer engine that I’ve built after a lot of research, based on Unreal Engine’s Code Reflection System, this system is capable of helping you to do amazing and unique data persistence in runtime that otherwise would be impossible.
For example: Unreal Engine’s “SaveGame” system can’t easily save Actor References and restore them to your Properties in real time, but with this system you can:

  • Execute Multi-Threaded SQLite Functions!
  • Create & Edit Database Assets in Unreal Editor!
  • Auto Generate SQL Code through Property Reflection!
  • Setup Property Versioning to support old Game Versions!
  • Save & Load Object References (Pointers) and easily restore them!
  • Save & Load data without conflicts across multiple streamed Levels!
  • Save & Load Actors or Component References and even Arrays of References!
  • Save & Load any kind of Struct as well as basic types like Ints, Strings, Vectors, etc!
  • Save & Load from Background Thread, while players sill interac with Game World!
  • (Optional) Progress Bar System can accurately report loading status without freezing the Game!
  • (Optional) HUD System can automatically generate and show Loadscreens when saving or loading the Game.

9V1HbGi

Continue reading “USQLite (Programming)”

USQLite (Programming)

 

 

WHAT

SPB Sound Occlusion is a plugin for Unreal Engine 4 that implements a complex sound occlusion function in C++ which generates real-time collisions from line traces to physical bodies then calculates volume and pitch variations to the audio source relative to the listener’s position.
The function takes into consideration the physical material attached to the render material used by the shapes the audio source’s traces hit as well as how much direct sound the listener receives to finally calculate the volume output an audio source should play.
Each audio source traces its own path to the listener and multiple collision channels can be traced at the same time.
Any kind of physical body is supported: Static meshes, dynamic meshes, characters, physics volumes and etc, all can be traced against an audio source depending on collision channel settings.
Many occlusion presets for physical materials are included to streamline workflow when creating occlusion effects; For wood, metal, plastic, concrete, so on and so forth.

 

HOW TO USE

Physical Material Setup:

 

First we need a physical material to be attached to render material of a mesh we wish audio occlusion to consider.
To do this, on the asset browser select or create a new physical material used by the mesh:

 

Now on Project Settings panel, look for “Sound Occlusion” and the SPB plugin settings will show up in the panel. There are several Material Presets;
Click on the “Physical Materials” list on the top of the panel to register the Material you’ve created earlier:


 

Because “concrete” is a preset, the plugin will automatically assign ‘concrete’ values to your physical materials, if you name them with that word, when you pick it from the drop-down list.
If you wish to just use your own custom values for this particular occlusion material, just keep the “override” checkbox active and you will be able to edit all values:

 

Then on your render material, base or instance of a material, open it up with Unreal’s Material Editor and set its “Phys Material” to the physical material you have assigned as “concrete” in Project Settings panel.
After that any meshes using such material will react to the occlusion system accordingly with the values of that material we’ve set previously:

 

Listener Component Setup:

 

Now, we need to setup a Listener Component, usually attached to the main Character so this is the focus of this example.
Open the Character Blueprint and from the “+Add Component” button add a “SPB Listener” Component attached to the Capsule Component.
Done that you can click the newly created “SPB Listener” Component to check it’s properties.
On the SPB section of properties there’s a checkbox “Is Player Listener”, in this case we want it set to true because then the plugin will automatically override the origin point of audio spatialization to match the location of our SPB Listener in the game world:

 

After we’re happy with local position of our SPB Listener Component, relative to the Character’s Capsule Component, the Listener needs two complementary elements; add twice an “LLR Component” to the Character Blueprint… Then an important step that can’t be missed: click the LLR Components and drag them to be children of the SPB Listener Component.
By dragging the LLR Components into the SPB Listener, they are registered as children and from there in C++ land the Listener does some voodoo to keep track of them when we actually run the game. So, again, this is important! Attach LLR Components to SPB Listener, two of them, no more no less!
If you did this right, your Character Blueprint would now look like this:

I should highlight that in big red text, but I really want you to read the whole guide instead of dragging your attention to bold areas of the text while you miss the rest 🙂

 

Speaker Component Setup:

 

So the only step missing now is actually creating our SPB Cue or adding an SPB Speaker Component to some Actor that we want to emit sounds and be occluded by the line tracing system.
You will notice that this look alike the default Audio Component, but in this case with an SPB section on its properties:

 

After we created the SPB Speaker Component and attached to our mesh, just like the process with the Listener, we need two sub-components attached to the Speaker; But this time we need “CLR Component”.
We add twice a CLR Component then drag it as a child of the SPB Speaker Component, if you did it right then when you check the properties panel of a Speaker in the Level you should see that the “None” values for “CL Component” and “CR Component” are now updated to reflect the fact that the plugin, in C++ land, have registered the newly created CLR Components and now they have their properties exposed to the SPB Speaker Component:

 

Now, by default the Speaker will trace for occlusion on the “World Static” and “World Dynamic” collision channels.
You can edit this list at will, remove or add channels to fit your project accordingly; for maximized performance is good to trace only one channel, the more channels your SPB Speaker traces the more performance impact is caused.
Still, I believe there’s no need to stress too much about it, the heavy code is all executed entirely in C++ so it’s very very fast even while running line traces for hundreds of Speakers on the same Level:

 

So, done the steps above, the occlusion is ready and you can play-test it! If you click the “Debug” checkbox will can see some of the calculations while ‘Playing in Editor’.
The other settings are very intuitive to use and have detailed tooltips on what they do. Later on I will explain what are “SPB Gates” and what they do, enjoy! Cheers!

 

 

 

(UPDATE) Common Mistakes:

 

This plugin has been live for a while now and many developers use it daily.
From time to time new developers seem to get confused by a few common mistakes I want to outline here in hopes for these occurrences to disappear. There are usually these few common complaints I receive from new users:

#1: “I have followed all steps, but there’s no rays following my character!”
A: What happens is you actually forgot to mark your Listener as ‘Player’. This mistake is so common that I have decided to push an update and make this setting be marked by default when a new Listener Component is created…
islistener

#2: “For some reason it still doesn’t work!”
A: You don’t have a Game Mode set in your level. SPB Listener accesses variables from your Character that are members of Player Controller class, spawned by your Game Mode class. When you do not properly setup a Game Mode for your Map/Level, SPB cannot find the Spatialization component stored in the Player Controller class…
spb_nogamemode

#3: “Still nothing… I can’t see anything happening *angry face*”
A: If your Speaker is using attenuation settings you have to make sure the falloff area is large enough for the player with a Listener attached to move in. When attenuation is activated on the Speaker, it will only trace occlusion until the limits of the falloff area, once the Listener leaves its area the Speaker stops tracing occlusion against that Listener.
spb_attenuation

#4: “But I disabled attenuation or increased falloff distance and still doesn’t work!”
A: In this case one or more of the following things are wrong in your setup:

  • Your components are not activated.
    spb_autoactivate
  • Your Speaker has no sound to play.
    spb_nosound
  • Your Speaker has volume set to zero.
    spb_novolume
  • Your list of channels to trace is empty.
    spb_channels
  • Your Speaker isn’t debugging or is marked with ‘No Trace’.
    spb_debug

 

 

Make sure you have those mistakes above fixed and everything will work correctly.
spb_fixresult

 

 

 

** This plugin is now release on Unreal Marketplace **

UE4 SPB Sound Occlusion (Programming)