Creating a Crazy Buff
This is a series of buffs that sends the player on a magic carpet ride and deep into the rabbit hole. Or, less metaphorically, it launches them into the air, plays trippy music, and makes weird things happen. Steam workshop entry if you'd like to try the buff yourself. https://steamcommunity.com/sharedfiles/filedetails/?id=1358329936
The buff system is one of the most versatile tools we have as modders. Some of the best mods are accomplished primarily or even exclusively with buffs. You can change nearly anything you want about a dino or player’s character using buffs—stats, appearance, size, sound, abilities. They can be temporary or permanent changes. The sky’s the limit when it comes to buffs.
So again, what is a buff? In modding terms, a buff is an actor that gets attached to another actor. Now, I understand that this might be confusing, considering we think of actors as things that have a “physical presence,” such as structures*, dinos, etc., whereas most buffs are invisible or just shown with a particle effect. Personally, I like to think of buffs as a little ghost that rides on your shoulder; it’s still there even though you can’t see it or feel it in the usual ways.
The goal of this tutorial is not to tell you how to create the same crazy buff that I made, though you should be able to do that by the end. Rather, by the end of reading this guide, you should have a clearer idea of how buffs work and what crazy things you can do with them. So, let’s get on to making our first “Casper” (image 1).
- Note: Buffs cannot be attached to structures. I’m not entirely sure where this limitation comes from, but it is an undisputable fact. If you want to modify a structure in some way, there are ways to do it, but a buff is not one of those ways.
How Buffs are Applied
There are several ways to apply a buff. The easiest way is to make a consumable—“Buff to Give Owner Character” is built right into the defaults. You can also add a buff via a piece of equipment (i.e. scuba gear), through a costume (i.e. gliders), through overlap events (i.e. liopleurodon magic buff) (you could also run overlap events like this from a structure), or through the primal game data’s “Additional Default Buffs” array. This array allows you to choose a specific class to apply your buff to, for example if you wanted a buff to apply to all dodos on the map. Note that this only applies the buff to fresh spawns—if adding a buff via the additional defaults to an existing world, you’ll need to instruct players to do a dino wipe or apply the buff through some other means such as a singleton.
You can also apply buffs from other buffs as a kind of “Buffception.” The “Buff to Give on Deactivation” automatically gives a new buff as the old one ends (i.e. being hungover after getting drunk). You can also spread buffs through simple proximity with the AOE options, which I’ll discuss a bit more below. You can also apply a new buff through graphing in the current buff. I use all three of these methods, as well as a consumable to start it all off, in the following tutorial. Since the consumable isn’t the focus of this tutorial, all I did was copy an eatable (one of the berries) and add my buff to the “Buff to Give Owner Character” setting.
The File and its Defaults
Like most other blueprints, a buff has a lot of default options at our disposal. This section of the tutorial is going to be a generalized introduction to those defaults rather than being specific to the buff I’m making. There is a lot you can do with just the tick boxes and basic arrays of a buff, but the buff I created was accomplished primarily through graphing, which I will discuss later. I highly recommend simply scanning through these options for a few minutes, perhaps multiple times, to get an idea of what you can do with them. I find this practice to be quite helpful any time you’re working with a new type of blueprint—you can save yourself a lot of time and energy if you know what boxes you need to tick, and knowing they exist is the first step towards that.
One of the most important default settings is the “Instigator Attachment Socket.” Remember how I said that buffs are actors that get attached to other actors? This setting tells the buff where to attach itself. For the invisible type of buff, this just needs to be a valid socket—“BuffSocketCenterDynamic” (centered in the body) or “SantaHatSocket” (centered on the head) are often used since they are common sockets to both player and dino skeletons. If you’re attaching something visible, say another mesh of some kind, then a different socket may be more suitable. You can always open up the relevant skeleton (i.e. the skeletal mesh file of whatever you plan to attach the buff to, whether that be a specific dino or a player) and see what sockets are available. Since I want a little “ghost” on my shoulder for this buff, I’m going to use “MountedDinoSocket2.”
“Deactivate After Time” vs “Deactivation Lifespan” are two settings that people get confused about. Deactivate After Time is the length of your buff in seconds—this is the one you generally want to change. Setting this to 0 will make your buff duration unlimited. Deactivation Lifespan is a little less obvious. It is the amount of time between when any deactivation logic runs and when the buff actually ends. For example, in one of the buffs I made today, I have Casper wave goodbye as the buff ends, using the BPDeactivated function. That animation lasts about 2 seconds. I set the Deactivation Lifespan to 2.1 to ensure Casper can do his wave before the buff truly ends and he disappears for good. If I set it any shorter, he would disappear mid-animation.
“Buff Post Process Effect” is how visual overlays are applied. If you want your buff to change what/how your character sees (i.e. the gas mask, or how dilo spit turns your screen green) this is where you set that.
If you want to make a buff that lasts forever, including through character death or server restarts, it’s actually relatively simple to do. The primary thing that most beginners don’t know is that the buff will detach from its owner on a server restart. In order to counteract that, a bit of graphing is needed—but don’t worry, even that part isn’t complicated. These defaults and the graph is all you need to make your buff stay put (image 6).
The last thing I’ll mention about the defaults, and this will be true of any blueprint you work with, is that certain graph functions need to be enabled with a tick box in the defaults before it will run your custom logic. If you make a graph and can’t figure out why it’s not working, always check the defaults for a “BP(name of function).”
There are a lot more options and settings in the default tab, and again, I highly encourage you to look through them thoroughly.
The Components Tab
There are other things you could add, such as box or sphere components (which can be useful for creating custom logic), text renders, extra particles, or extra sounds. There’s a lot of other possibilities, but most of them aren’t useful for buffs.
The Graph Tab
Ah, the graphing tab. This is where the magic happens. A lot of new modders are intimidated by this section and try to avoid it at all costs. Looking at some of Wildcard’s more complicated graph work can certainly be confusing and daunting. I certainly felt that way when I first started. Now, though, playing with the visual scripting is the most fun part of working in the dev kit for me. So, you may be asking, how did my attitude on it change so drastically? Well, I watched the tutorials and read some of the documentation, as everyone always said to do, and that certainly helped—but the real trick for me was to just create a throw-away structure that served no purpose other than for me to play in the graph. Then I just tried to emulate things I knew could be done from seeing other mods do it (things like making the structure change its mesh, its color, play a sound, etc.) Low pressure with no specific goal—that is how I learned to graph. Once I started to understand more about the graph, then I went back to looking at Wildcard’s graphs and started picking them apart to figure out what did what. All I can say is the effort to understand graphing is worth it, as a good graph will make your mod a thousand times more interesting. Casper believes in you! (gyazo gif)
Okay, enough about that. The basics of graphing is not the topic of this particular tutorial. The topic of this tutorial is how to make a crazy prank buff, which is why this tutorial may have seemed a bit bland up until this point—as I said, the graph is where all the magic really happens. Turns out, Casper is a pretty mischievous ghost who likes to scare people and make them see strange things! My buff is actually going to be a series of different buffs for the sake of clarity and organization. I’ve uploaded the bigger or more complicated graphs to blueprintue.com for easier sharing. I’ve commented on these graphs heavily, so let’s take a look at the first buff (blueprintue link). Other than the embedded comments, the only additional note I have on that is the “Slow Instigator Falling” needs to be enabled while the player is in the air. Otherwise, the buff will end before it begins. Now, in the defaults of that first buff, I have “Buff to Give on Deactivation” set to my second buff, and so the second buff is automatically applied when the player touches ground. Here is the second buff’s primary graph (blueprintue link). In this buff I use timelines to make little dodos spin around the player’s head. Timelines are useful for many things, such as creating simple, custom animations, making an object’s color change, making a light pulse—basically anything you want to make happen smoothly and in a set pattern. My timeline uses a vector track, is 8 seconds long, has 4 key frames, and is set to loop. Here’s a picture (image 11):
Now this buff is set to add my third buff as soon as all three dodos have started circling the player’s head. Here’s the graph for the Inverted Movement buff (blueprintue link). This buff also uses the “Buff Tick Client” function to cause the player’s screen to move around on its own—I basically stole this from the aberration poison mushrooms and tweaked it to my preferences. Here’s a picture of that graph (image 12):
Buffs four and five, which are applied to the player via the “Alice” event in buff three, are very similar in structure, even though they are opposites. One makes you bigger, the other makes you tiny. Since they are so similar, I uploaded them into the same graph—just understand that they are meant to be separate, with the bottom one hooked to its own “event begin play”: (blueprintue link). The Deactivated functions for these two buffs are essentially identical to their “begin play” logic, except the values are reversed (i.e. using multiplication with the same value instead of division, and vice versa) in order to set the player back to normal size (blueprintue link).
The next buff, which is also applied by the “Alice” event of buff three, makes it rain cats and dogs—as in it spawns sabers and direwolves above and around the player. Here’s the graph for that one (blueprintue link). These are meant to be temporary creatures, so on deactivation of the buff they’re cleared from the world (image 13). This buff also uses the “Prevent Actor Targeting” function, since I don’t want the spawned dinos to attack the player (image 14).
Now, I don’t want the cats and dogs to attack other players or tamed dinos that have the misfortune to be too close, either. To accomplish that, I use a few of the AOE settings to apply a seventh buff to all players and dinos near the buffed player (image 15). Of course, with these settings, my umbrella buff was being applied to the cats and dogs themselves, which obviously isn’t necessary. To counteract that, I use the “BPExclude AOEActor” function with the following logic (image 16). From the Umbrella buff, I add a sphere component with overlap events turned on. That sphere checks for untamed sabers and direwolves, and, on finding one, adds it to a custom array variable (image 16)—after that it’s the same as the other buff, using the “Prevent Actor Targeting” to protect the buffed player or dino.
Going back to the Inverted Movement buff, which has been running the entire time in order to make the player fluctuate sizes, let’s take a look at its Deactivated graph (image 17):
And, finally, the Deactivated graph of the DodoSpin buff, which has also been running for the duration (image 18).
At the bottom are pictures of each buff's modified settings in the defaults tab, as well as a look at the components for the three buffs that I added components to.
So, there you have it. I tried to cover as many concepts as I could in this tutorial. Hopefully it has given you some ideas on how buffs can be used to create weird and great experiences for the player. Good luck and have fun.