Creating a Crazy Buff

From ARK Modding Wiki
Jump to: navigation, search

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.

Buff Overview

What is a buff? As a player, you might associate the word “buff” with a temporary boost or improvement to the character you’re playing. A regeneration buff makes you recover health; a strength buff makes you hit harder or carry more. This definition is true in ARK, to the extent it goes—however, there are many things that you can do with buffs as a modder, that a normal player would not associate with being a buff.

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

For this tutorial I’m assuming that you already have, at the very least, a level file and PrimalGameData_BP set up for your mod. If you don’t, then you should take a step back and visit another tutorial. If you do, then the first thing that we need to do is create a buff blueprint. There are a couple ways you could do this, such as typing “buff_base” into the search bar and creating a child of it into your mod folder. Another way would be to right click inside your mod folder, creating the blueprint, and selecting that parent from the list (see image 2). There are other buff parent classes you could use, depending on what you want to do, but the base gives us a nice, basic place to start.

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.

If you want your buff to have a visible icon, look for “Buff Description” (image 3). Here you can set the icon and set whether a message appears at the top of the screen when the buff is applied. If you want a custom icon, make sure it is a square .png or .tga. I usually size my custom icons at 256x256, but it should work as long as it’s a square image. "Buff Type" at the bottom allows you to select the background color of the icon. 0 for white, 1 for green, 2 for red—these values are defined in the PGD, and any other setting can and will cause crashing. On the other hand, you may not want a buff icon to appear at all. In that case, there are two tick boxes to hit: “Hide Buff from HUD” and “Hide Timer from HUD.” Note that hiding the buff from HUD also disables any HUDMessage you set. This is why I enable this setting through the graph on my buffs—so that the message will show but the icon will not.

“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.

AOE Stuff.png
The AOE (area of effect) settings are an easy way to spread a buff. You could, for example, make everyone around your buff owner drunk (image 4). There are 25 settings relating to AOE effects, so I’m not going to cover them all. Simply type “AOE” into the search bar of your buff file to take a look at them yourself.
If you just want to make a simple buff that regenerates health, or any other stat of your choice, all you need is to tick the “Add Character Values” box, and then input the type and speed of regeneration you want in the “Values to Add Per Second” array. Do note that not all the listed values work—MeleeDamageMultiplier, TemperatureFortitude (also known as insulation), and SpeedMultiplier, are all set elsewhere in the buff defaults. Temperature and CraftingSpeedMultiplier don’t work at all, to my knowledge. There’s also the “Character Status Value Modifiers” array, which has a similar functionality but allows you more specific control. If, for example, you wanted a buff to give exactly 500 health over the course of 20 seconds, or 1000 torpor over a minute (see image 5), this option would be the easy place to make that happen. Also, as I said, these are for regeneration type effects—these increase the current value of your stat, they do not increase the cap of the stat. This means if you set weight to increase, it will make the player encumbered instead of allowing them to carry more. If you want to increase the maximum value of a stat, look for the “Max Stat Scalers” array. The “Apply Stat Modifier to [Players/Dinos]” tick boxes are relevant to the max stat scalers array—if the right one isn’t ticked, nothing will happen.

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

Basic Components.png
The components tab is where you add most of the visual and sound effects for your buff. A particle system component and a sound are already set up by inheritance, so if you want to attach either of those things to your buff, all you have to do is select the asset to use (image 7). These are both set to follow the buff owner around (think of an alpha’s red glow or how the Halloween music would play around skeletal dinos or the DodoRex). If you want to use a custom sound, it must be in .wav format. One thing to keep in mind about the sound, however, is that you need to set the attenuation (image 8). Attenuation controls from what distance the sound can be heard. If this isn’t set, then the sound could potentially be heard from anywhere on the map. There are quite a few preset options, and I suggest playing with them until you find the one that works for your purposes.
This is also the place where you can add static or skeletal meshes to your buff, like my little ghost boy. To do so, simply click the “Add Component” button—the options for skeletal and static meshes are both near the top. Once you have your mesh, scroll down in the details section to the “Mesh” heading, and select the asset you want to use (image 9). You can also change the material the mesh uses from this section. For mine, I chose a water material (image 10). Note that if you choose an existing material, you may have to copy it to your mod folder and alter it for use with your mesh—in my case, it was just a tick box to enable it for use with skeletal meshes.
Choosing a Material.png

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 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).
Ignore the error on the loop. Forgot to clear it before taking the picture.

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.

Defaults of the initial "Casper" buff
Defaults of the "DodoSpin" buff
Defaults of the "Inverted Movement" buff
Defaults of the "Taller" buff
Defaults of the "Smaller" buff
Defaults of the "Raining" buff
Defaults of the "Umbrella" buff
Components of the Casper buff
Components of the DodoSpin Buff
Components of the Umbrella Buff