https://wiki.arkmodding.net/api.php?action=feedcontributions&user=RedDwarf&feedformat=atomARK Modding Wiki - User contributions [en]2024-03-29T11:53:59ZUser contributionsMediaWiki 1.33.0https://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=46631Tutorial: Solar Panel2020-12-20T00:16:58Z<p>RedDwarf: </p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, as long as it's located outside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Due to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel. Create a new blueprint called "PrimalItemStructure_SolarPanel" that's parented to "Primal Item Structure Generic", and change the following defaults:<br />
<br />
<br />
[[File:2PqEKQE(1).png|center]]<br />
<br />
<br />
These settings just change the name of the item, the icon, crafting requirements, the structure to build, and which folder the engram will show up in.<br />
<br />
Feel free to adjust these values as desired!<br />
<br />
<br />
=== Rechargeable Battery ===<br />
<br />
Next, let's create the PrimalItem for the battery that players will be able to craft in the solar panel. Again, not very complicated -- just a simple item that has a good name/description/icon, and weight/crafting-requirements that make sense based on the context of the item.<br />
<br />
<br />
[[File:OxlOOm6(1).png|center]]<br />
<br />
<br />
I made the battery cost a little high, since they completely replace gasoline, and you only have to build them once.<br />
<br />
<br />
== Setting up the Solar Panel logic ==<br />
<br />
Buckle up, kids! We're about to go diving into all of the logic that makes the solar panel actually function. Don't worry, it's not too bad. =)<br />
<br />
Open up your "SolarPanel_BP" blueprint, and click on "Graph" on the top-right. Then click the "Event Graph" tab.<br />
<br />
Let's start here. <br />
<br />
<br />
[[File:SWitz9b(1).png|center]]<br />
<br />
<br />
Like most "Event Begin Play" events, we start with a small delay to give the code time to initialize everything. In many cases (but not all) this is considered a general best-practice in order to avoid problematic glitches down the road.<br />
<br />
We also check to see if the structure is currently a "Preview Structure" (this refers to the green placement structure) -- and we only want to continue if it's the real thing, and not a preview.<br />
<br />
Most of this logic will be run server-side, hence the "Switch Has Authority".<br />
<br />
One of the first things we do is call a custom function called "Check Panel Status". This function will check all of the details needed to determine if the solar panel should be on or not, and then sets the container active/inactive based the results, and this "Check Panel Status" function will be called multiple times, in multiple places.<br />
<br />
<br />
[[File:IHVR9Fr(1).png|center]]<br />
<br />
<br />
As you can see, most of this logic is contained in the "Get Solar Panel Status" function. We'll look into that in more detail later, but for now, let's stick with the "Event Being Play" logic.<br />
<br />
<br />
[[File:KOXL2N2(1).png|center]]<br />
<br />
<br />
The next thing we'll do is call the "Day Cycle Manger". This handles the in-game time system, and contains useful information about whether or not it's currently daylight outside, etc.<br />
<br />
One of the most important features of the Day Cycle Manger, is the ability to "bind delegates" to certain events. In this case, we're able to bind custom events to the "On Start Daytime" and "On Start Nighttime" events. This means that whenever Day Cycle Manager determines that it's daytime or nighttime has happened, it will trigger our custom events.<br />
<br />
We also have a check to see if it's currently nighttime. Why? Because if it's nighttime, we need to check to see if the batteries are still charged enough to keep the solar panel online, and if not, to disable the solar panel. To do that, we setup a looped timer which will call the "Check Panel Status" function every 10 seconds, which nicely equates to 5 minutes in-game.<br />
<br />
<br />
[[File:Qu7uA6G(1).png|center]]<br />
<br />
<br />
This shows our custom events that trigger when day or night happen.<br />
<br />
* When day starts: We clear the timer (since the batteries only run at night), and we run a "Check Panel Status" to trigger the switch to using solar power (instead of batteries), if sunlight is available.<br />
<br />
* When day ends: We count the number of batteries currently in the panels inventory, and we multicast that value to everyone, then set the looping timer and run another "Check Panel Status"<br />
<br />
<br />
[[File:D4BOYlN(1).png|center]]<br />
<br />
<br />
This "MULTICAST - Set Number of Batteries" function is important, and will be used in a few different places, as we'll see soon.<br />
<br />
Next, we need the ability to draw text at the bottom of the Solar Panel whenever a player looks at it, so that they can tell what the current status of the panel is. For example:<br />
<br />
<br />
[[File:FhfXMwd(1).png|center]]<br />
<br />
<br />
This shows that the panel has solar power, but there aren't any batteries available for charging.<br />
<br />
To achieve this HUD message, go to our "SolarPanel_BP" blueprint, and right-click the "Blueprint Draw HUD" function and click "Implement Function". Then we can add the following logic:<br />
<br />
<br />
[[File:Z00cwfJ(1).png|center]]<br />
<br />
<br />
As you can see, this function calls the main "Get Solar Panel Status" function again, which returns the desired HUD text color, as well as the HUD message.<br />
<br />
Then, all we have to do is offset the "Y" location by 100, which will push the text downwards. "BP Draw Text Centered" will keep the text nicely centered in the screen, regardless of character length.<br />
<br />
Okay, now for the big one!<br />
<br />
Let's look at the main "Get Solar Panel Status" function, which calculates whether or not the panel is able to be powered, how much battery life is remaining, and what HUD text/colors should be returned.<br />
<br />
<br />
[[File:GCHFFiQ(1).png|center]]<br />
<br />
<br />
Right off the bat, let's setup two local variables called "Is Daytime" and "Is Indoors". Both of those will be used later. We get the "Is Daytime" value directly from the Day Cycle Manger, and we can get the "Is Indoors" value from the "Is Indoors at Loc" built-in function.<br />
<br />
Note: I added a +100 offset in the Z direction (100 units up off the ground) so that the game didn't register the structure as being inside the foundation that it's placed on.<br />
<br />
Now for the fun part: We need to calculate the amount of battery power remaining.<br />
<br />
<br />
[[File:IAbuSZu(1).png|center]]<br />
<br />
<br />
In this piece, we take the usable number of batters (which was set earlier in the MULTICAST event), and we multiply by the number of seconds in an hour, and how many hours we want each battery to run for.<br />
<br />
Note: These are '''in-game''' hours, not real-life hours.<br />
<br />
We then add this value to the "Day Time End" (the time when night began) from the Day Cycle Manager, and subtract the current time. This gives us our countdown based on how many batteries we have in the solar panel's inventory. We take the "Max" value to guarantee that the timer will stop at zero, instead of going into negative numbers. This value is then assigned to the "Battery Time Remaining" local float variable on our main execution path.<br />
<br />
<br />
[[File:LAWBiZf(1).png|center]]<br />
<br />
<br />
Now for the fun part. We need to decide what message the HUD will display, based on the information we know (Is Indoors, Is Daytime, Number of Batteries, and Battery Time Remaining). What this ends up creating is a simple decision tree. I usually draw out the tree on graph paper before I start coding, which really helps me simplify the process in my head.<br />
<br />
<br />
[[File:KO9ihi5(1).png|center]]<br />
<br />
<br />
The tree starts on the right-hand side. If the solar panel is located indoors, then the panel overrides all previous message and issues a warning.<br />
<br />
If the structure in not indoors, then we check to see if it's currently daytime. If it is, then we check to see if we have any batters and display the appropriate message. If it's not daytime, then we check to see if we have any battery power remaining, and display the appropriate message (including a countdown timer to display the amount of battery power remaining).<br />
<br />
The last step of this function is to calculate whether or not the solar panel should have power, and what color the resulting HUD text should be.<br />
<br />
<br />
[[File:MiQCthj(1).png|center]]<br />
<br />
<br />
As you can see, the solar panel has to have either solar power or available battery power in order for "Power Available" to be true, otherwise it's false. If the power is on, we color the text orange, otherwise it's gray.<br />
<br />
<br />
Believe it or not, that's the end of the SolarPanel_BP graph! You did it!<br />
<br />
== Setting up the Solar Panel inventory component == <br />
<br />
Last, but not least, we'll need to make an inventory component for our solar panel. This will be where batteries are crafted and stored. Create a new blueprint called "PrimalInventoryBP_SolarPanel" and add it to your "SolarPanel_BP" blueprint, in the component's tab.<br />
<br />
Next, add the following items to your new inventory:<br />
<br />
<br />
[[File:Hwhezl8(1).png|center]]<br />
<br />
<br />
This is a pretty standard inventory.<br />
<br />
Note the following things:<br />
<br />
* BP Notify Item Added / Removed: We need to check these boxes, so that we can use these blueprint functions later.<br />
<br />
* Max Inventory Items: Make the panel's storage as big or small as you want. In this case, I chose 50, because that seems like enough room to comfortably store a dozen or so batteries, plus any crafting components the player might need to add.<br />
<br />
* Remote Add Item Only Allow Item Classes: This allows us to limit the solar panel's inventory to only batteries, and the items that make the batteries. I consider this a good best practice for these types of structures, so players don't just throw random items in these types of inventories. Nobody's poop or spoiled meat should be in the solar panel. =)<br />
<br />
* All Default Inventory is Engrams: That's an important one. It means that all blueprints in the inventory are considered to be engram blueprints, meaning that they can't be removed from the station. Note: The "Battery" primal item is labeled as an "Always Learned Engram", which allows it to show up here, and be treated like an engram, even though the player did not unlock it in their engram list.<br />
<br />
Now, let's get back to those "BP Notify Item Added / Removed" functions we mentioned earlier.<br />
<br />
For the "Added" function, we want to detect when a battery has been deposited, and increment the solar panel's number of available batteries -- but only if it's daytime. Batteries added at night are not considered charged yet.<br />
<br />
<br />
[[File:DrZIm4V(1).png|center]]<br />
<br />
<br />
Similarly, with the "Removed" function, we need to verify that the current number is less than the existing number before we change the "number of charged batteries" count on the solar panel.<br />
<br />
<br />
[[File:9bdtWM5(1).png|center]]<br />
<br />
<br />
For example, if the solar panel started the evening with 5 batteries, then adding 10 more and removing 1 would trigger the "Remove" function to execute, and the structure would think that it had 14 batteries -- even though we still only consider 5 of them charged. In other words, when day flips to night, we cannot gain any "new" charged batteries until the next day, since batteries only recharge in sunlight.<br />
<br />
== Conclusion ==<br />
<br />
Finally, you'll need to create an engram entry for the panel, and update your PrimalGameData file with the "Additional Structure to Place" and the "Additional Engram Entry" and then you're done!<br />
<br />
You've made a fully functional solar panel with battery backup!<br />
<br />
Feel free to edit/change this project as much as you want for your own use.<br />
<br />
Enjoy!<br />
<br />
<br />
-- RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Open_Source_Dino_Evolution&diff=1811Open Source Dino Evolution2018-07-10T15:40:17Z<p>RedDwarf: Not a robot!</p>
<hr />
<div>[[Category:Open Source]]<br />
[[Category:Source Files]]<br />
<br />
== Introduction == <br />
<br />
This download contains an open-source "base" dinosaur blueprint that newer modders can make child blueprints from. The "base" dino blueprint adds Dino Evolution functionality, allowing players to setup various versions that can be unlocked.<br />
<br />
This mod was created and open-sourced by Pikkon38.<br />
<br />
<br />
== Download here! == <br />
<br />
https://drive.google.com/open?id=10P6z8EYxLvQ2qQPqOvc0PTL9Y0quFCwB<br />
<br />
<br />
<br />
== Author Notes ==<br />
<br />
How to use this file.<br />
<br />
Quick explanation:<br />
1. Reparent your dino or any sub-parent (if necessary) from Dino_Character_BP to Evolution_Dino_Character_BP.<br />
<br />
In-Depth explanation how to do the above:<br />
1. Close ADK<br />
2. Open a folder local folder in your mod, and paste Evolution_Dino_Character_BP.uasset into it.<br />
3. Open ADK<br />
4. Find the dino you want to evolve from and copy the BP to anothe folder<br />
5. Open the BP<br />
6. Look in the top right corner. If the Parent is Dino_Character_BP, skip to step 8.<br />
7. Assuming it is something other tha Dino_Character_BP, hit the magnifiying glass. Copy this parent to your folder. This parent should have its own parent, which should be Dino_Character_BP.<br />
8. Open whatever file that would normally have Dino_Character_BP as its parent, and go to file > reparent.<br />
9. When the list comes up, reparent it to Evolution_Dino_Character_BP.<br />
10. If you had to reparent something like Pack_Dino_Character_BP, open up your desired dino bp, and repeat step 8 and 9 to reparent your dino to whatever file you just reparented to Evolution_Dino_Character_BP.<br />
<br />
Ideally now, you should have a dino that has a parent of Evolution_Dino_character_BP. Or, if, for example, you are using a raptor, the Raptor BP should be parented to your copied Pack_Dino_Character_BP, which in turn has a parent of Evolution_Dino_Character_BP.<br />
<br />
Once this is done, everything necessary for item based evolution is now available to you in the blueprint section, with zero need for you to touch any graphing! Below are the explainantions for each property:<br />
<br />
Search "Evol"<br />
<br />
Ready to Evolve: Ignore. Used Internally. Leave unchecked.<br />
Evolve Particle Scale: The size of the particles that will spawn on evolution.<br />
Evolve Particle Location: The location on the dino body relative to the assigned bone.<br />
Dino to Evole: The dino you want to evolve to.<br />
Allow Evolution: Ignore. Used Internally. Leave unchecked.<br />
Number of items required to evolve: The amount of the required item before evolution is possible.<br />
Evolution Item Required: The item that should be in the dino inventory to allow evolution.<br />
Evolve Particle: The particle that should play during evolution.<br />
Evolve Particle Attach Point: The bone name the particle should attach to (I.E. Spine_01.). For the correct bone name, look in the dino skeleton, and pick any bone you want. Right click and copy bone name.<br />
Evolve Particle Rotation: The rotation of the Particle that plays on evolution<br />
Evolve Particle Delay: The time between when the particle starts and when the evolution dino spawns. Use this to time your particle and evolution.<br />
Evolve ini Section String: This is the section in your GUS that the game looks for. This should ideally be your mod name. (I.E. PrimalFear). When using it in GUS it will look for [ModName]. Brackets are added automatically<br />
Evolve ini Option Name: The option under the section name the game looks for. This is specifically for user control over the Number of Items Required To Evolve. You shouldnt need to touch this unless you want to change the name, but it will always look for number of items required.<br />
<br />
<br />
DEFAULT KEY FOR EVOLUTION:<br />
<br />
Control + X<br />
<br />
(This is unfortunately unchangeable unless you go into the graph)<br />
<br />
-- Pikkon38</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1620Tutorial: Solar Panel2018-05-01T15:10:35Z<p>RedDwarf: /* Setting up the Solar Panel inventory component */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, as long as it's located outside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Due to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel. Create a new blueprint called "PrimalItemStructure_SolarPanel" that's parented to "Primal Item Structure Generic", and change the following defaults:<br />
<br />
<br />
[[File:2PqEKQE(1).png|center]]<br />
<br />
<br />
These settings just change the name of the item, the icon, crafting requirements, the structure to build, and which folder the engram will show up in.<br />
<br />
Feel free to adjust these values as desired!<br />
<br />
<br />
=== Rechargeable Battery ===<br />
<br />
Next, let's create the PrimalItem for the battery that players will be able to craft in the solar panel. Again, not very complicated -- just a simple item that has a good name/description/icon, and weight/crafting-requirements that make sense based on the context of the item.<br />
<br />
<br />
[[File:OxlOOm6(1).png|center]]<br />
<br />
<br />
I made the battery cost a little high, since they completely replace gasoline, and you only have to build them once.<br />
<br />
<br />
== Setting up the Solar Panel logic ==<br />
<br />
Buckle up, kids! We're about to go diving into all of the logic that makes the solar panel actually function. Don't worry, it's not too bad. =)<br />
<br />
Open up your "SolarPanel_BP" blueprint, and click on "Graph" on the top-right. Then click the "Event Graph" tab.<br />
<br />
Let's start here. <br />
<br />
<br />
[[File:SWitz9b(1).png|center]]<br />
<br />
<br />
Like most "Event Begin Play" events, we start with a small delay to give the code time to initialize everything. In many cases (but not all) this is considered a general best-practice in order to avoid problematic glitches down the road.<br />
<br />
We also check to see if the structure is currently a "Preview Structure" (this refers to the green placement structure) -- and we only want to continue if it's the real thing, and not a preview.<br />
<br />
Most of this logic will be run server-side, hence the "Switch Has Authority".<br />
<br />
One of the first things we do is call a custom function called "Check Panel Status". This function will check all of the details needed to determine if the solar panel should be on or not, and then sets the container active/inactive based the results, and this "Check Panel Status" function will be called multiple times, in multiple places.<br />
<br />
<br />
[[File:IHVR9Fr(1).png|center]]<br />
<br />
<br />
As you can see, most of this logic is contained in the "Get Solar Panel Status" function. We'll look into that in more detail later, but for now, let's stick with the "Event Being Play" logic.<br />
<br />
<br />
[[File:KOXL2N2(1).png|center]]<br />
<br />
<br />
The next thing we'll do is call the "Day Cycle Manger". This handles the in-game time system, and contains useful information about whether or not it's currently daylight outside, etc.<br />
<br />
One of the most important features of the Day Cycle Manger, is the ability to "bind delegates" to certain events. In this case, we're able to bind custom events to the "On Start Daytime" and "On Start Nighttime" events. This means that whenever Day Cycle Manager determines that it's daytime or nighttime has happened, it will trigger our custom events.<br />
<br />
We also have a check to see if it's currently nighttime. Why? Because if it's nighttime, we need to check to see if the batteries are still charged enough to keep the solar panel online, and if not, to disable the solar panel. To do that, we setup a looped timer which will call the "Check Panel Status" function every 10 seconds, which nicely equates to 5 minutes in-game.<br />
<br />
<br />
[[File:Qu7uA6G(1).png|center]]<br />
<br />
<br />
This shows our custom events that trigger when day or night happen.<br />
<br />
* When day starts: We clear the timer (since the batteries only run at night), and we run a "Check Panel Status" to trigger the switch to using solar power (instead of batteries), if sunlight is available.<br />
<br />
* When day ends: We count the number of batteries currently in the panels inventory, and we multicast that value to everyone, then set the looping timer and run another "Check Panel Status"<br />
<br />
<br />
[[File:D4BOYlN(1).png|center]]<br />
<br />
<br />
This "MULTICAST - Set Number of Batteries" function is important, and will be used in a few different places, as we'll see soon.<br />
<br />
Next, we need the ability to draw text at the bottom of the Solar Panel whenever a player looks at it, so that they can tell what the current status of the panel is. For example:<br />
<br />
<br />
[[File:FhfXMwd(1).png|center]]<br />
<br />
<br />
This shows that the panel has solar power, but there aren't any batteries available for charging.<br />
<br />
To achieve this HUD message, go to our "SolarPanel_BP" blueprint, and right-click the "Blueprint Draw HUD" function and click "Implement Function". Then we can add the following logic:<br />
<br />
<br />
[[File:Z00cwfJ(1).png|center]]<br />
<br />
<br />
As you can see, this function calls the main "Get Solar Panel Status" function again, which returns the desired HUD text color, as well as the HUD message.<br />
<br />
Then, all we have to do is offset the "Y" location by 100, which will push the text downwards. "BP Draw Text Centered" will keep the text nicely centered in the screen, regardless of character length.<br />
<br />
Okay, now for the big one!<br />
<br />
Let's look at the main "Get Solar Panel Status" function, which calculates whether or not the panel is able to be powered, how much battery life is remaining, and what HUD text/colors should be returned.<br />
<br />
<br />
[[File:GCHFFiQ(1).png|center]]<br />
<br />
<br />
Right off the bat, let's setup two local variables called "Is Daytime" and "Is Indoors". Both of those will be used later. We get the "Is Daytime" value directly from the Day Cycle Manger, and we can get the "Is Indoors" value from the "Is Indoors at Loc" built-in function.<br />
<br />
Note: I added a +100 offset in the Z direction (100 units up off the ground) so that the game didn't register the structure as being inside the foundation that it's placed on.<br />
<br />
Now for the fun part: We need to calculate the amount of battery power remaining.<br />
<br />
<br />
[[File:IAbuSZu(1).png|center]]<br />
<br />
<br />
In this piece, we take the usable number of batters (which was set earlier in the MULTICAST event), and we multiply by the number of seconds in an hour, and how many hours we want each battery to run for.<br />
<br />
Note: These are '''in-game''' hours, not real-life hours.<br />
<br />
We then add this value to the "Day Time End" (the time when night began) from the Day Cycle Manager, and subtract the current time. This gives us our countdown based on how many batteries we have in the solar panel's inventory. We take the "Max" value to guarantee that the timer will stop at zero, instead of going into negative numbers. This value is then assigned to the "Battery Time Remaining" local float variable on our main execution path.<br />
<br />
<br />
[[File:LAWBiZf(1).png|center]]<br />
<br />
<br />
Now for the fun part. We need to decide what message the HUD will display, based on the information we know (Is Indoors, Is Daytime, Number of Batteries, and Battery Time Remaining). What this ends up creating is a simple decision tree. I usually draw out the tree on graph paper before I start coding, which really helps me simplify the process in my head.<br />
<br />
<br />
[[File:KO9ihi5(1).png|center]]<br />
<br />
<br />
The tree starts on the right-hand side. If the solar panel is located indoors, then the panel overrides all previous message and issues a warning.<br />
<br />
If the structure in not indoors, then we check to see if it's currently daytime. If it is, then we check to see if we have any batters and display the appropriate message. If it's not daytime, then we check to see if we have any battery power remaining, and display the appropriate message (including a countdown timer to display the amount of battery power remaining).<br />
<br />
The last step of this function is to calculate whether or not the solar panel should have power, and what color the resulting HUD text should be.<br />
<br />
<br />
[[File:MiQCthj(1).png|center]]<br />
<br />
<br />
As you can see, the solar panel has to have either solar power or available battery power in order for "Power Available" to be true, otherwise it's false. If the power is on, we color the text orange, otherwise it's gray.<br />
<br />
<br />
Believe it or not, that's the end of the SolarPanel_BP graph! You did it!<br />
<br />
== Setting up the Solar Panel inventory component == <br />
<br />
Last, but not least, we'll need to make an inventory component for our solar panel. This will be where batteries are crafted and stored. Create a new blueprint called "PrimalInventoryBP_SolarPanel" and add it to your "SolarPanel_BP" blueprint, in the component's tab.<br />
<br />
Next, add the following items to your new inventory:<br />
<br />
<br />
[[File:Hwhezl8(1).png|center]]<br />
<br />
<br />
This is a pretty standard inventory.<br />
<br />
Note the following things:<br />
<br />
* BP Notify Item Added / Removed: We need to check these boxes, so that we can use these blueprint functions later.<br />
<br />
* Max Inventory Items: Make the panel's storage as big or small as you want. In this case, I chose 50, because that seems like enough room to comfortably store a dozen or so batteries, plus any crafting components the player might need to add.<br />
<br />
* Remote Add Item Only Allow Item Classes: This allows us to limit the solar panel's inventory to only batteries, and the items that make the batteries. I consider this a good best practice for these types of structures, so players don't just throw random items in these types of inventories. Nobody's poop or spoiled meat should be in the solar panel. =)<br />
<br />
* All Default Inventory is Engrams: That's an important one. It means that all blueprints in the inventory are considered to be engram blueprints, meaning that they can't be removed from the station. Note: The "Battery" primal item is labeled as an "Always Learned Engram", which allows it to show up here, and be treated like an engram, even though the player did not unlock it in their engram list.<br />
<br />
Now, let's get back to those "BP Notify Item Added / Removed" functions we mentioned earlier.<br />
<br />
For the "Added" function, we want to detect when a battery has been deposited, and increment the solar panel's number of available batteries -- but only if it's daytime. Batteries added at night are not considered charged yet.<br />
<br />
<br />
[[File:DrZIm4V(1).png|center]]<br />
<br />
<br />
Similarly, with the "Removed" function, we need to verify that the current number is less than the existing number before we change the "number of charged batteries" count on the solar panel.<br />
<br />
<br />
[[File:9bdtWM5(1).png|center]]<br />
<br />
<br />
For example, if the solar panel started the evening with 5 batteries, then adding 10 more and removing 1 would trigger the "Remove" function to execute, and the structure would think that it had 14 batteries -- even though we still only consider 5 of them charged. In other words, when day flips to night, we cannot gain any "new" charged batteries until the next day, since batteries only recharge in sunlight.<br />
<br />
== Conclusion ==<br />
<br />
Finally, you'll need to create an engram entry for the panel, and update your PrimalGameData file with the "Additional Structure to Place" and the "Additional Engram Entry" and then you're done!<br />
<br />
You've made a fully functional solar panel with battery backup!<br />
<br />
Feel free to edit/change this project as much as you want for your own use.<br />
<br />
This project will be uploaded as a stand-alone mod, with a link to download the open-source code. Enjoy!<br />
<br />
<br />
-- RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1619Tutorial: Solar Panel2018-05-01T15:09:18Z<p>RedDwarf: /* Setting up the Solar Panel inventory component */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, as long as it's located outside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Due to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel. Create a new blueprint called "PrimalItemStructure_SolarPanel" that's parented to "Primal Item Structure Generic", and change the following defaults:<br />
<br />
<br />
[[File:2PqEKQE(1).png|center]]<br />
<br />
<br />
These settings just change the name of the item, the icon, crafting requirements, the structure to build, and which folder the engram will show up in.<br />
<br />
Feel free to adjust these values as desired!<br />
<br />
<br />
=== Rechargeable Battery ===<br />
<br />
Next, let's create the PrimalItem for the battery that players will be able to craft in the solar panel. Again, not very complicated -- just a simple item that has a good name/description/icon, and weight/crafting-requirements that make sense based on the context of the item.<br />
<br />
<br />
[[File:OxlOOm6(1).png|center]]<br />
<br />
<br />
I made the battery cost a little high, since they completely replace gasoline, and you only have to build them once.<br />
<br />
<br />
== Setting up the Solar Panel logic ==<br />
<br />
Buckle up, kids! We're about to go diving into all of the logic that makes the solar panel actually function. Don't worry, it's not too bad. =)<br />
<br />
Open up your "SolarPanel_BP" blueprint, and click on "Graph" on the top-right. Then click the "Event Graph" tab.<br />
<br />
Let's start here. <br />
<br />
<br />
[[File:SWitz9b(1).png|center]]<br />
<br />
<br />
Like most "Event Begin Play" events, we start with a small delay to give the code time to initialize everything. In many cases (but not all) this is considered a general best-practice in order to avoid problematic glitches down the road.<br />
<br />
We also check to see if the structure is currently a "Preview Structure" (this refers to the green placement structure) -- and we only want to continue if it's the real thing, and not a preview.<br />
<br />
Most of this logic will be run server-side, hence the "Switch Has Authority".<br />
<br />
One of the first things we do is call a custom function called "Check Panel Status". This function will check all of the details needed to determine if the solar panel should be on or not, and then sets the container active/inactive based the results, and this "Check Panel Status" function will be called multiple times, in multiple places.<br />
<br />
<br />
[[File:IHVR9Fr(1).png|center]]<br />
<br />
<br />
As you can see, most of this logic is contained in the "Get Solar Panel Status" function. We'll look into that in more detail later, but for now, let's stick with the "Event Being Play" logic.<br />
<br />
<br />
[[File:KOXL2N2(1).png|center]]<br />
<br />
<br />
The next thing we'll do is call the "Day Cycle Manger". This handles the in-game time system, and contains useful information about whether or not it's currently daylight outside, etc.<br />
<br />
One of the most important features of the Day Cycle Manger, is the ability to "bind delegates" to certain events. In this case, we're able to bind custom events to the "On Start Daytime" and "On Start Nighttime" events. This means that whenever Day Cycle Manager determines that it's daytime or nighttime has happened, it will trigger our custom events.<br />
<br />
We also have a check to see if it's currently nighttime. Why? Because if it's nighttime, we need to check to see if the batteries are still charged enough to keep the solar panel online, and if not, to disable the solar panel. To do that, we setup a looped timer which will call the "Check Panel Status" function every 10 seconds, which nicely equates to 5 minutes in-game.<br />
<br />
<br />
[[File:Qu7uA6G(1).png|center]]<br />
<br />
<br />
This shows our custom events that trigger when day or night happen.<br />
<br />
* When day starts: We clear the timer (since the batteries only run at night), and we run a "Check Panel Status" to trigger the switch to using solar power (instead of batteries), if sunlight is available.<br />
<br />
* When day ends: We count the number of batteries currently in the panels inventory, and we multicast that value to everyone, then set the looping timer and run another "Check Panel Status"<br />
<br />
<br />
[[File:D4BOYlN(1).png|center]]<br />
<br />
<br />
This "MULTICAST - Set Number of Batteries" function is important, and will be used in a few different places, as we'll see soon.<br />
<br />
Next, we need the ability to draw text at the bottom of the Solar Panel whenever a player looks at it, so that they can tell what the current status of the panel is. For example:<br />
<br />
<br />
[[File:FhfXMwd(1).png|center]]<br />
<br />
<br />
This shows that the panel has solar power, but there aren't any batteries available for charging.<br />
<br />
To achieve this HUD message, go to our "SolarPanel_BP" blueprint, and right-click the "Blueprint Draw HUD" function and click "Implement Function". Then we can add the following logic:<br />
<br />
<br />
[[File:Z00cwfJ(1).png|center]]<br />
<br />
<br />
As you can see, this function calls the main "Get Solar Panel Status" function again, which returns the desired HUD text color, as well as the HUD message.<br />
<br />
Then, all we have to do is offset the "Y" location by 100, which will push the text downwards. "BP Draw Text Centered" will keep the text nicely centered in the screen, regardless of character length.<br />
<br />
Okay, now for the big one!<br />
<br />
Let's look at the main "Get Solar Panel Status" function, which calculates whether or not the panel is able to be powered, how much battery life is remaining, and what HUD text/colors should be returned.<br />
<br />
<br />
[[File:GCHFFiQ(1).png|center]]<br />
<br />
<br />
Right off the bat, let's setup two local variables called "Is Daytime" and "Is Indoors". Both of those will be used later. We get the "Is Daytime" value directly from the Day Cycle Manger, and we can get the "Is Indoors" value from the "Is Indoors at Loc" built-in function.<br />
<br />
Note: I added a +100 offset in the Z direction (100 units up off the ground) so that the game didn't register the structure as being inside the foundation that it's placed on.<br />
<br />
Now for the fun part: We need to calculate the amount of battery power remaining.<br />
<br />
<br />
[[File:IAbuSZu(1).png|center]]<br />
<br />
<br />
In this piece, we take the usable number of batters (which was set earlier in the MULTICAST event), and we multiply by the number of seconds in an hour, and how many hours we want each battery to run for.<br />
<br />
Note: These are '''in-game''' hours, not real-life hours.<br />
<br />
We then add this value to the "Day Time End" (the time when night began) from the Day Cycle Manager, and subtract the current time. This gives us our countdown based on how many batteries we have in the solar panel's inventory. We take the "Max" value to guarantee that the timer will stop at zero, instead of going into negative numbers. This value is then assigned to the "Battery Time Remaining" local float variable on our main execution path.<br />
<br />
<br />
[[File:LAWBiZf(1).png|center]]<br />
<br />
<br />
Now for the fun part. We need to decide what message the HUD will display, based on the information we know (Is Indoors, Is Daytime, Number of Batteries, and Battery Time Remaining). What this ends up creating is a simple decision tree. I usually draw out the tree on graph paper before I start coding, which really helps me simplify the process in my head.<br />
<br />
<br />
[[File:KO9ihi5(1).png|center]]<br />
<br />
<br />
The tree starts on the right-hand side. If the solar panel is located indoors, then the panel overrides all previous message and issues a warning.<br />
<br />
If the structure in not indoors, then we check to see if it's currently daytime. If it is, then we check to see if we have any batters and display the appropriate message. If it's not daytime, then we check to see if we have any battery power remaining, and display the appropriate message (including a countdown timer to display the amount of battery power remaining).<br />
<br />
The last step of this function is to calculate whether or not the solar panel should have power, and what color the resulting HUD text should be.<br />
<br />
<br />
[[File:MiQCthj(1).png|center]]<br />
<br />
<br />
As you can see, the solar panel has to have either solar power or available battery power in order for "Power Available" to be true, otherwise it's false. If the power is on, we color the text orange, otherwise it's gray.<br />
<br />
<br />
Believe it or not, that's the end of the SolarPanel_BP graph! You did it!<br />
<br />
== Setting up the Solar Panel inventory component == <br />
<br />
Last, but not least, we'll need to make an inventory component for our solar panel. This will be where batteries are crafted and stored. Create a new blueprint called "PrimalInventoryBP_SolarPanel" and add it to your "SolarPanel_BP" blueprint, in the component's tab.<br />
<br />
Next, add the following items to your new inventory:<br />
<br />
<br />
[[File:Hwhezl8(1).png|center]]<br />
<br />
<br />
This is a pretty standard inventory.<br />
<br />
Note the following things:<br />
<br />
* BP Notify Item Added / Removed: We need to check these boxes, so that we can use these blueprint functions later.<br />
<br />
* Max Inventory Items: Make the panel as big as you want.<br />
<br />
* Remote Add Item Only Allow Item Classes: This allows us to limit the solar panel's inventory to only batteries, and the items that make the batteries. I consider this a good best practice for these types of structures, so players don't just throw random items in these types of inventories. Nobody's poop or spoiled meat should be in the solar panel. =)<br />
<br />
* All Default Inventory is Engrams: That's an important one. It means that all blueprints in the inventory are considered to be engram blueprints, meaning that they can't be removed from the station. Note: The "Battery" primal item is labeled as an "Always Learned Engram", which allows it to show up here, and be treated like an engram, even though the player did not unlock it in their engram list.<br />
<br />
Now, let's get back to those "BP Notify Item Added / Removed" functions we mentioned earlier.<br />
<br />
For the "Added" function, we want to detect when a battery has been deposited, and increment the solar panel's number of available batteries -- but only if it's daytime. Batteries added at night are not considered charged yet.<br />
<br />
<br />
[[File:DrZIm4V(1).png|center]]<br />
<br />
<br />
Similarly, with the "Removed" function, we need to verify that the current number is less than the existing number before we change the "number of charged batteries" count on the solar panel.<br />
<br />
<br />
[[File:9bdtWM5(1).png|center]]<br />
<br />
<br />
For example, if the solar panel started the evening with 5 batteries, then adding 10 more and removing 1 would trigger the "Remove" function to execute, and the structure would think that it had 14 batteries -- even though we still only consider 5 of them charged. In other words, when day flips to night, we cannot gain any "new" charged batteries until the next day, since batteries only recharge in sunlight.<br />
<br />
== Conclusion ==<br />
<br />
Finally, you'll need to create an engram entry for the panel, and update your PrimalGameData file with the "Additional Structure to Place" and the "Additional Engram Entry" and then you're done!<br />
<br />
You've made a fully functional solar panel with battery backup!<br />
<br />
Feel free to edit/change this project as much as you want for your own use.<br />
<br />
This project will be uploaded as a stand-alone mod, with a link to download the open-source code. Enjoy!<br />
<br />
<br />
-- RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1618Tutorial: Solar Panel2018-05-01T15:08:47Z<p>RedDwarf: /* Setting up the Solar Panel inventory component */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, as long as it's located outside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Due to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel. Create a new blueprint called "PrimalItemStructure_SolarPanel" that's parented to "Primal Item Structure Generic", and change the following defaults:<br />
<br />
<br />
[[File:2PqEKQE(1).png|center]]<br />
<br />
<br />
These settings just change the name of the item, the icon, crafting requirements, the structure to build, and which folder the engram will show up in.<br />
<br />
Feel free to adjust these values as desired!<br />
<br />
<br />
=== Rechargeable Battery ===<br />
<br />
Next, let's create the PrimalItem for the battery that players will be able to craft in the solar panel. Again, not very complicated -- just a simple item that has a good name/description/icon, and weight/crafting-requirements that make sense based on the context of the item.<br />
<br />
<br />
[[File:OxlOOm6(1).png|center]]<br />
<br />
<br />
I made the battery cost a little high, since they completely replace gasoline, and you only have to build them once.<br />
<br />
<br />
== Setting up the Solar Panel logic ==<br />
<br />
Buckle up, kids! We're about to go diving into all of the logic that makes the solar panel actually function. Don't worry, it's not too bad. =)<br />
<br />
Open up your "SolarPanel_BP" blueprint, and click on "Graph" on the top-right. Then click the "Event Graph" tab.<br />
<br />
Let's start here. <br />
<br />
<br />
[[File:SWitz9b(1).png|center]]<br />
<br />
<br />
Like most "Event Begin Play" events, we start with a small delay to give the code time to initialize everything. In many cases (but not all) this is considered a general best-practice in order to avoid problematic glitches down the road.<br />
<br />
We also check to see if the structure is currently a "Preview Structure" (this refers to the green placement structure) -- and we only want to continue if it's the real thing, and not a preview.<br />
<br />
Most of this logic will be run server-side, hence the "Switch Has Authority".<br />
<br />
One of the first things we do is call a custom function called "Check Panel Status". This function will check all of the details needed to determine if the solar panel should be on or not, and then sets the container active/inactive based the results, and this "Check Panel Status" function will be called multiple times, in multiple places.<br />
<br />
<br />
[[File:IHVR9Fr(1).png|center]]<br />
<br />
<br />
As you can see, most of this logic is contained in the "Get Solar Panel Status" function. We'll look into that in more detail later, but for now, let's stick with the "Event Being Play" logic.<br />
<br />
<br />
[[File:KOXL2N2(1).png|center]]<br />
<br />
<br />
The next thing we'll do is call the "Day Cycle Manger". This handles the in-game time system, and contains useful information about whether or not it's currently daylight outside, etc.<br />
<br />
One of the most important features of the Day Cycle Manger, is the ability to "bind delegates" to certain events. In this case, we're able to bind custom events to the "On Start Daytime" and "On Start Nighttime" events. This means that whenever Day Cycle Manager determines that it's daytime or nighttime has happened, it will trigger our custom events.<br />
<br />
We also have a check to see if it's currently nighttime. Why? Because if it's nighttime, we need to check to see if the batteries are still charged enough to keep the solar panel online, and if not, to disable the solar panel. To do that, we setup a looped timer which will call the "Check Panel Status" function every 10 seconds, which nicely equates to 5 minutes in-game.<br />
<br />
<br />
[[File:Qu7uA6G(1).png|center]]<br />
<br />
<br />
This shows our custom events that trigger when day or night happen.<br />
<br />
* When day starts: We clear the timer (since the batteries only run at night), and we run a "Check Panel Status" to trigger the switch to using solar power (instead of batteries), if sunlight is available.<br />
<br />
* When day ends: We count the number of batteries currently in the panels inventory, and we multicast that value to everyone, then set the looping timer and run another "Check Panel Status"<br />
<br />
<br />
[[File:D4BOYlN(1).png|center]]<br />
<br />
<br />
This "MULTICAST - Set Number of Batteries" function is important, and will be used in a few different places, as we'll see soon.<br />
<br />
Next, we need the ability to draw text at the bottom of the Solar Panel whenever a player looks at it, so that they can tell what the current status of the panel is. For example:<br />
<br />
<br />
[[File:FhfXMwd(1).png|center]]<br />
<br />
<br />
This shows that the panel has solar power, but there aren't any batteries available for charging.<br />
<br />
To achieve this HUD message, go to our "SolarPanel_BP" blueprint, and right-click the "Blueprint Draw HUD" function and click "Implement Function". Then we can add the following logic:<br />
<br />
<br />
[[File:Z00cwfJ(1).png|center]]<br />
<br />
<br />
As you can see, this function calls the main "Get Solar Panel Status" function again, which returns the desired HUD text color, as well as the HUD message.<br />
<br />
Then, all we have to do is offset the "Y" location by 100, which will push the text downwards. "BP Draw Text Centered" will keep the text nicely centered in the screen, regardless of character length.<br />
<br />
Okay, now for the big one!<br />
<br />
Let's look at the main "Get Solar Panel Status" function, which calculates whether or not the panel is able to be powered, how much battery life is remaining, and what HUD text/colors should be returned.<br />
<br />
<br />
[[File:GCHFFiQ(1).png|center]]<br />
<br />
<br />
Right off the bat, let's setup two local variables called "Is Daytime" and "Is Indoors". Both of those will be used later. We get the "Is Daytime" value directly from the Day Cycle Manger, and we can get the "Is Indoors" value from the "Is Indoors at Loc" built-in function.<br />
<br />
Note: I added a +100 offset in the Z direction (100 units up off the ground) so that the game didn't register the structure as being inside the foundation that it's placed on.<br />
<br />
Now for the fun part: We need to calculate the amount of battery power remaining.<br />
<br />
<br />
[[File:IAbuSZu(1).png|center]]<br />
<br />
<br />
In this piece, we take the usable number of batters (which was set earlier in the MULTICAST event), and we multiply by the number of seconds in an hour, and how many hours we want each battery to run for.<br />
<br />
Note: These are '''in-game''' hours, not real-life hours.<br />
<br />
We then add this value to the "Day Time End" (the time when night began) from the Day Cycle Manager, and subtract the current time. This gives us our countdown based on how many batteries we have in the solar panel's inventory. We take the "Max" value to guarantee that the timer will stop at zero, instead of going into negative numbers. This value is then assigned to the "Battery Time Remaining" local float variable on our main execution path.<br />
<br />
<br />
[[File:LAWBiZf(1).png|center]]<br />
<br />
<br />
Now for the fun part. We need to decide what message the HUD will display, based on the information we know (Is Indoors, Is Daytime, Number of Batteries, and Battery Time Remaining). What this ends up creating is a simple decision tree. I usually draw out the tree on graph paper before I start coding, which really helps me simplify the process in my head.<br />
<br />
<br />
[[File:KO9ihi5(1).png|center]]<br />
<br />
<br />
The tree starts on the right-hand side. If the solar panel is located indoors, then the panel overrides all previous message and issues a warning.<br />
<br />
If the structure in not indoors, then we check to see if it's currently daytime. If it is, then we check to see if we have any batters and display the appropriate message. If it's not daytime, then we check to see if we have any battery power remaining, and display the appropriate message (including a countdown timer to display the amount of battery power remaining).<br />
<br />
The last step of this function is to calculate whether or not the solar panel should have power, and what color the resulting HUD text should be.<br />
<br />
<br />
[[File:MiQCthj(1).png|center]]<br />
<br />
<br />
As you can see, the solar panel has to have either solar power or available battery power in order for "Power Available" to be true, otherwise it's false. If the power is on, we color the text orange, otherwise it's gray.<br />
<br />
<br />
Believe it or not, that's the end of the SolarPanel_BP graph! You did it!<br />
<br />
== Setting up the Solar Panel inventory component == <br />
<br />
Last, but not least, we'll need to make an inventory component for our solar panel. This will be where batteries are crafted and stored. Create a new blueprint called "PrimalInventoryBP_SolarPanel" and add it to your "SolarPanel_BP" blueprint, in the component's tab.<br />
<br />
Next, add the following items to your new inventory:<br />
<br />
<br />
[[File:Hwhezl8(1).png|center]]<br />
<br />
<br />
This is a pretty standard inventory.<br />
<br />
Note the following things:<br />
<br />
* BP Notify Item Added / Removed: We need to check these boxes, so that we can use thesefunction later.<br />
<br />
* Max Inventory Items: Make the panel as big as you want.<br />
<br />
* Remote Add Item Only Allow Item Classes: This allows us to limit the solar panel's inventory to only batteries, and the items that make the batteries. I consider this a good best practice for these types of structures, so players don't just throw random items in these types of inventories. Nobody's poop or spoiled meat should be in the solar panel. =)<br />
<br />
* All Default Inventory is Engrams: That's an important one. It means that all blueprints in the inventory are considered to be engram blueprints, meaning that they can't be removed from the station. Note: The "Battery" primal item is labeled as an "Always Learned Engram", which allows it to show up here, and be treated like an engram, even though the player did not unlock it in their engram list.<br />
<br />
Now, let's get back to those "BP Notify Item Added / Removed" functions we mentioned earlier.<br />
<br />
For the "Added" function, we want to detect when a battery has been deposited, and increment the solar panel's number of available batteries -- but only if it's daytime. Batteries added at night are not considered charged yet.<br />
<br />
<br />
[[File:DrZIm4V(1).png|center]]<br />
<br />
<br />
Similarly, with the "Removed" function, we need to verify that the current number is less than the existing number before we change the "number of charged batteries" count on the solar panel.<br />
<br />
<br />
[[File:9bdtWM5(1).png|center]]<br />
<br />
<br />
For example, if the solar panel started the evening with 5 batteries, then adding 10 more and removing 1 would trigger the "Remove" function to execute, and the structure would think that it had 14 batteries -- even though we still only consider 5 of them charged. In other words, when day flips to night, we cannot gain any "new" charged batteries until the next day, since batteries only recharge in sunlight.<br />
<br />
== Conclusion ==<br />
<br />
Finally, you'll need to create an engram entry for the panel, and update your PrimalGameData file with the "Additional Structure to Place" and the "Additional Engram Entry" and then you're done!<br />
<br />
You've made a fully functional solar panel with battery backup!<br />
<br />
Feel free to edit/change this project as much as you want for your own use.<br />
<br />
This project will be uploaded as a stand-alone mod, with a link to download the open-source code. Enjoy!<br />
<br />
<br />
-- RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1617Tutorial: Solar Panel2018-05-01T15:06:14Z<p>RedDwarf: /* Setting up the Solar Panel logic */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, as long as it's located outside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Due to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel. Create a new blueprint called "PrimalItemStructure_SolarPanel" that's parented to "Primal Item Structure Generic", and change the following defaults:<br />
<br />
<br />
[[File:2PqEKQE(1).png|center]]<br />
<br />
<br />
These settings just change the name of the item, the icon, crafting requirements, the structure to build, and which folder the engram will show up in.<br />
<br />
Feel free to adjust these values as desired!<br />
<br />
<br />
=== Rechargeable Battery ===<br />
<br />
Next, let's create the PrimalItem for the battery that players will be able to craft in the solar panel. Again, not very complicated -- just a simple item that has a good name/description/icon, and weight/crafting-requirements that make sense based on the context of the item.<br />
<br />
<br />
[[File:OxlOOm6(1).png|center]]<br />
<br />
<br />
I made the battery cost a little high, since they completely replace gasoline, and you only have to build them once.<br />
<br />
<br />
== Setting up the Solar Panel logic ==<br />
<br />
Buckle up, kids! We're about to go diving into all of the logic that makes the solar panel actually function. Don't worry, it's not too bad. =)<br />
<br />
Open up your "SolarPanel_BP" blueprint, and click on "Graph" on the top-right. Then click the "Event Graph" tab.<br />
<br />
Let's start here. <br />
<br />
<br />
[[File:SWitz9b(1).png|center]]<br />
<br />
<br />
Like most "Event Begin Play" events, we start with a small delay to give the code time to initialize everything. In many cases (but not all) this is considered a general best-practice in order to avoid problematic glitches down the road.<br />
<br />
We also check to see if the structure is currently a "Preview Structure" (this refers to the green placement structure) -- and we only want to continue if it's the real thing, and not a preview.<br />
<br />
Most of this logic will be run server-side, hence the "Switch Has Authority".<br />
<br />
One of the first things we do is call a custom function called "Check Panel Status". This function will check all of the details needed to determine if the solar panel should be on or not, and then sets the container active/inactive based the results, and this "Check Panel Status" function will be called multiple times, in multiple places.<br />
<br />
<br />
[[File:IHVR9Fr(1).png|center]]<br />
<br />
<br />
As you can see, most of this logic is contained in the "Get Solar Panel Status" function. We'll look into that in more detail later, but for now, let's stick with the "Event Being Play" logic.<br />
<br />
<br />
[[File:KOXL2N2(1).png|center]]<br />
<br />
<br />
The next thing we'll do is call the "Day Cycle Manger". This handles the in-game time system, and contains useful information about whether or not it's currently daylight outside, etc.<br />
<br />
One of the most important features of the Day Cycle Manger, is the ability to "bind delegates" to certain events. In this case, we're able to bind custom events to the "On Start Daytime" and "On Start Nighttime" events. This means that whenever Day Cycle Manager determines that it's daytime or nighttime has happened, it will trigger our custom events.<br />
<br />
We also have a check to see if it's currently nighttime. Why? Because if it's nighttime, we need to check to see if the batteries are still charged enough to keep the solar panel online, and if not, to disable the solar panel. To do that, we setup a looped timer which will call the "Check Panel Status" function every 10 seconds, which nicely equates to 5 minutes in-game.<br />
<br />
<br />
[[File:Qu7uA6G(1).png|center]]<br />
<br />
<br />
This shows our custom events that trigger when day or night happen.<br />
<br />
* When day starts: We clear the timer (since the batteries only run at night), and we run a "Check Panel Status" to trigger the switch to using solar power (instead of batteries), if sunlight is available.<br />
<br />
* When day ends: We count the number of batteries currently in the panels inventory, and we multicast that value to everyone, then set the looping timer and run another "Check Panel Status"<br />
<br />
<br />
[[File:D4BOYlN(1).png|center]]<br />
<br />
<br />
This "MULTICAST - Set Number of Batteries" function is important, and will be used in a few different places, as we'll see soon.<br />
<br />
Next, we need the ability to draw text at the bottom of the Solar Panel whenever a player looks at it, so that they can tell what the current status of the panel is. For example:<br />
<br />
<br />
[[File:FhfXMwd(1).png|center]]<br />
<br />
<br />
This shows that the panel has solar power, but there aren't any batteries available for charging.<br />
<br />
To achieve this HUD message, go to our "SolarPanel_BP" blueprint, and right-click the "Blueprint Draw HUD" function and click "Implement Function". Then we can add the following logic:<br />
<br />
<br />
[[File:Z00cwfJ(1).png|center]]<br />
<br />
<br />
As you can see, this function calls the main "Get Solar Panel Status" function again, which returns the desired HUD text color, as well as the HUD message.<br />
<br />
Then, all we have to do is offset the "Y" location by 100, which will push the text downwards. "BP Draw Text Centered" will keep the text nicely centered in the screen, regardless of character length.<br />
<br />
Okay, now for the big one!<br />
<br />
Let's look at the main "Get Solar Panel Status" function, which calculates whether or not the panel is able to be powered, how much battery life is remaining, and what HUD text/colors should be returned.<br />
<br />
<br />
[[File:GCHFFiQ(1).png|center]]<br />
<br />
<br />
Right off the bat, let's setup two local variables called "Is Daytime" and "Is Indoors". Both of those will be used later. We get the "Is Daytime" value directly from the Day Cycle Manger, and we can get the "Is Indoors" value from the "Is Indoors at Loc" built-in function.<br />
<br />
Note: I added a +100 offset in the Z direction (100 units up off the ground) so that the game didn't register the structure as being inside the foundation that it's placed on.<br />
<br />
Now for the fun part: We need to calculate the amount of battery power remaining.<br />
<br />
<br />
[[File:IAbuSZu(1).png|center]]<br />
<br />
<br />
In this piece, we take the usable number of batters (which was set earlier in the MULTICAST event), and we multiply by the number of seconds in an hour, and how many hours we want each battery to run for.<br />
<br />
Note: These are '''in-game''' hours, not real-life hours.<br />
<br />
We then add this value to the "Day Time End" (the time when night began) from the Day Cycle Manager, and subtract the current time. This gives us our countdown based on how many batteries we have in the solar panel's inventory. We take the "Max" value to guarantee that the timer will stop at zero, instead of going into negative numbers. This value is then assigned to the "Battery Time Remaining" local float variable on our main execution path.<br />
<br />
<br />
[[File:LAWBiZf(1).png|center]]<br />
<br />
<br />
Now for the fun part. We need to decide what message the HUD will display, based on the information we know (Is Indoors, Is Daytime, Number of Batteries, and Battery Time Remaining). What this ends up creating is a simple decision tree. I usually draw out the tree on graph paper before I start coding, which really helps me simplify the process in my head.<br />
<br />
<br />
[[File:KO9ihi5(1).png|center]]<br />
<br />
<br />
The tree starts on the right-hand side. If the solar panel is located indoors, then the panel overrides all previous message and issues a warning.<br />
<br />
If the structure in not indoors, then we check to see if it's currently daytime. If it is, then we check to see if we have any batters and display the appropriate message. If it's not daytime, then we check to see if we have any battery power remaining, and display the appropriate message (including a countdown timer to display the amount of battery power remaining).<br />
<br />
The last step of this function is to calculate whether or not the solar panel should have power, and what color the resulting HUD text should be.<br />
<br />
<br />
[[File:MiQCthj(1).png|center]]<br />
<br />
<br />
As you can see, the solar panel has to have either solar power or available battery power in order for "Power Available" to be true, otherwise it's false. If the power is on, we color the text orange, otherwise it's gray.<br />
<br />
<br />
Believe it or not, that's the end of the SolarPanel_BP graph! You did it!<br />
<br />
== Setting up the Solar Panel inventory component == <br />
<br />
Last, but not least, we'll need to make an inventory component for our solar panel. This will be where batteries are crafted and stored. Create a new blueprint called "PrimalInventoryBP_SolarPanel" and add it to your "SolarPanel_BP" blueprint, in the component's tab.<br />
<br />
Next, add the following items to your new inventory:<br />
<br />
<br />
[[File:Hwhezl8(1).png|center]]<br />
<br />
<br />
This is a pretty standard inventory. Not the following things:<br />
<br />
* BP Notify Item Added / Removed: We need to check these boxes, so that we can use thesefunction later.<br />
<br />
* Max Inventory Items: Make the panel as big as you want.<br />
<br />
* Remote Add Item Only Allow Item Classes: This allows us to limit the solar panel's inventory to only batteries, and the items that make the batteries. I consider this a good best practice for these types of structures, so players don't just throw random items in these types of inventories. Nobody's poop or spoiled meat should be in the solar panel. =)<br />
<br />
* All Default Inventory is Engrams: That's an important one. It means that all blueprints in the inventory are considered to be engram blueprints, meaning that they can't be removed from the station. Note: The "Battery" primal item is labeled as an "Always Learned Engram", which allows it to show up here, and be treated like an engram, even though the player did not unlock it in their engram list.<br />
<br />
Now, let's get back to those "BP Notify Item Added / Removed" functions we mentioned earlier.<br />
<br />
For the "Added" function, we want to detect when a battery has been deposited, and increment the solar panel's number of available batteries -- but only if it's daytime. Batteries added at night are not considered charged yet.<br />
<br />
<br />
[[File:DrZIm4V(1).png|center]]<br />
<br />
<br />
Similarly, with the "Removed" function, we need to verify that the current number is less than the existing number before we change the "number of charged batteries" count on the solar panel.<br />
<br />
<br />
[[File:9bdtWM5(1).png|center]]<br />
<br />
<br />
For example, if the solar panel started the evening with 5 batteries, then adding 10 more and removing 1 would trigger the "Remove" function to execute, and the structure would think that it had 14 batteries -- even though we still only consider 5 of them charged. In other words, when day flips to night, we cannot gain any "new" charged batteries until the next day, since batteries only recharge in sunlight.<br />
<br />
== Conclusion ==<br />
<br />
Finally, you'll need to create an engram entry for the panel, and update your PrimalGameData file with the "Additional Structure to Place" and the "Additional Engram Entry" and then you're done!<br />
<br />
You've made a fully functional solar panel with battery backup!<br />
<br />
Feel free to edit/change this project as much as you want for your own use.<br />
<br />
This project will be uploaded as a stand-alone mod, with a link to download the open-source code. Enjoy!<br />
<br />
<br />
-- RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1616Tutorial: Solar Panel2018-05-01T15:02:09Z<p>RedDwarf: /* Setting up the Solar Panel logic */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, as long as it's located outside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Due to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel. Create a new blueprint called "PrimalItemStructure_SolarPanel" that's parented to "Primal Item Structure Generic", and change the following defaults:<br />
<br />
<br />
[[File:2PqEKQE(1).png|center]]<br />
<br />
<br />
These settings just change the name of the item, the icon, crafting requirements, the structure to build, and which folder the engram will show up in.<br />
<br />
Feel free to adjust these values as desired!<br />
<br />
<br />
=== Rechargeable Battery ===<br />
<br />
Next, let's create the PrimalItem for the battery that players will be able to craft in the solar panel. Again, not very complicated -- just a simple item that has a good name/description/icon, and weight/crafting-requirements that make sense based on the context of the item.<br />
<br />
<br />
[[File:OxlOOm6(1).png|center]]<br />
<br />
<br />
I made the battery cost a little high, since they completely replace gasoline, and you only have to build them once.<br />
<br />
<br />
== Setting up the Solar Panel logic ==<br />
<br />
Buckle up, kids! We're about to go diving into all of the logic that makes the solar panel actually function. Don't worry, it's not too bad. =)<br />
<br />
Open up your "SolarPanel_BP" blueprint, and click on "Graph" on the top-right. Then click the "Event Graph" tab.<br />
<br />
Let's start here. <br />
<br />
<br />
[[File:SWitz9b(1).png|center]]<br />
<br />
<br />
Like most "Event Begin Play" events, we start with a small delay to give the code time to initialize everything. In many cases (but not all) this is considered a general best-practice in order to avoid problematic glitches down the road.<br />
<br />
We also check to see if the structure is currently a "Preview Structure" (this refers to the green placement structure) -- and we only want to continue if it's the real thing, and not a preview.<br />
<br />
Most of this logic will be run server-side, hence the "Switch Has Authority".<br />
<br />
One of the first things we do is call a custom function called "Check Panel Status". This function will check all of the details needed to determine if the solar panel should be on or not, and then sets the container active/inactive based the results, and this "Check Panel Status" function will be called multiple times, in multiple places.<br />
<br />
<br />
[[File:IHVR9Fr(1).png|center]]<br />
<br />
<br />
As you can see, most of this logic is contained in the "Get Solar Panel Status" function. We'll look into that in more detail later, but for now, let's stick with the "Event Being Play" logic.<br />
<br />
<br />
[[File:KOXL2N2(1).png|center]]<br />
<br />
<br />
The next thing we'll do is call the "Day Cycle Manger". This handles the in-game time system, and contains useful information about whether or not it's currently daylight outside, etc.<br />
<br />
One of the most important features of the Day Cycle Manger, is the ability to "bind delegates" to certain events. In this case, we're able to bind custom events to the "On Start Daytime" and "On Start Nighttime" events. This means that whenever Day Cycle Manager determines that it's daytime or nighttime has happened, it will trigger our custom events.<br />
<br />
We also have a check to see if it's currently nighttime. Why? Because if it's nighttime, we need to check to see if the batteries are still charged enough to keep the solar panel online, and if not, to disable the solar panel. To do that, we setup a looped timer which will call the "Check Panel Status" function every 10 seconds, which nicely equates to 5 minutes in-game.<br />
<br />
<br />
[[File:Qu7uA6G(1).png|center]]<br />
<br />
<br />
This shows our custom events that trigger when day or night happen.<br />
<br />
* When day starts: We clear the timer (since the batteries only run at night), and we run a "Check Panel Status" to trigger the switch to using solar power (instead of batteries), if sunlight is available.<br />
<br />
* When day ends: We count the number of batteries currently in the panels inventory, and we multicast that value to everyone, then set the looping timer and run another "Check Panel Status"<br />
<br />
<br />
[[File:D4BOYlN(1).png|center]]<br />
<br />
<br />
This "MULTICAST - Set Number of Batteries" function is important, and will be used in a few different places, as we'll see soon.<br />
<br />
Next, we need the ability to draw text at the bottom of the Solar Panel whenever a player looks at it, so that they can tell what the current status of the panel is. For example:<br />
<br />
<br />
[[File:FhfXMwd(1).png|center]]<br />
<br />
<br />
This shows that the panel has solar power, but there aren't any batteries available for charging.<br />
<br />
To achieve this HUD message, go to our "SolarPanel_BP" blueprint, and right-click the "Blueprint Draw HUD" function and click "Implement Function". Then we can add the following logic:<br />
<br />
<br />
[[File:Z00cwfJ(1).png|center]]<br />
<br />
<br />
As you can see, this function calls the main "Get Solar Panel Status" function again, which returns the desired HUD text color, as well as the HUD message.<br />
<br />
Then, all we have to do is offset the "Y" location by 100, which will push the text downwards. "BP Draw Text Centered" will keep the text nicely centered in the screen, regardless of character length.<br />
<br />
Okay, now for the big one!<br />
<br />
Let's look at the main "Get Solar Panel Status" function, which calculates whether or not the panel is able to be powered, how much battery life is remaining, and what HUD text/colors should be returned.<br />
<br />
<br />
[[File:GCHFFiQ(1).png|center]]<br />
<br />
<br />
Right off the bat, let's setup two local variables called "Is Daytime" and "Is Indoors". Both of those will be used later. We get the "Is Daytime" value directly from the Day Cycle Manger, and we can get the "Is Indoors" value from the "Is Indoors at Loc" built-in function.<br />
<br />
Note: I added a +100 offset in the Z direction (100 units up off the ground) so that the game didn't register the structure as being inside the foundation that it's placed on.<br />
<br />
Now for the fun part: We need to calculate the amount of battery power remaining.<br />
<br />
<br />
[[File:IAbuSZu(1).png|center]]<br />
<br />
<br />
In this piece, we take the usable number of batters (which was set earlier in the MULTICAST event), and we multiply by the number of seconds in an hour, and how many hours we want each battery to run for. Note: These are '''in-game''' hours, not real-life hours. We then add this value to the "Day Time End" (the time when night began) from the Day Cycle Manager, and subtract the current time. This gives us our countdown based on how many batteries we have in the solar panel's inventory. We take the "Max" value to guarantee that the timer will stop at zero, instead of going into negative numbers. This value is then assigned to the "Battery Time Remaining" local float variable on our main execution path.<br />
<br />
<br />
[[File:LAWBiZf(1).png|center]]<br />
<br />
<br />
Now for the fun part. We need to decide what message the HUD will display, based on the information we know (Is Indoors, Is Daytime, Number of Batteries, and Battery Time Remaining). What this ends up creating is a simple decision tree. I usually draw out the tree on graph paper before I start coding, which really helps me simplify the process in my head.<br />
<br />
<br />
[[File:KO9ihi5(1).png|center]]<br />
<br />
<br />
The tree starts on the right-hand side. If the solar panel is located indoors, then the panel overrides all previous message and issues a warning.<br />
<br />
If the structure in not indoors, then we check to see if it's currently daytime. If it is, then we check to see if we have any batters and display the appropriate message. If it's not daytime, then we check to see if we have any battery power remaining, and display the appropriate message (including a countdown timer to display the amount of battery power remaining).<br />
<br />
The last step of this function is to calculate whether or not the solar panel should have power, and what color the resulting HUD text should be.<br />
<br />
<br />
[[File:MiQCthj(1).png|center]]<br />
<br />
<br />
As you can see, the solar panel has to have either solar power or available battery power in order for "Power Available" to be true, otherwise it's false. If the power is on, we color the text orange, otherwise it's gray.<br />
<br />
<br />
Believe it or not, that's the end of the SolarPanel_BP graph! You did it!<br />
<br />
== Setting up the Solar Panel inventory component == <br />
<br />
Last, but not least, we'll need to make an inventory component for our solar panel. This will be where batteries are crafted and stored. Create a new blueprint called "PrimalInventoryBP_SolarPanel" and add it to your "SolarPanel_BP" blueprint, in the component's tab.<br />
<br />
Next, add the following items to your new inventory:<br />
<br />
<br />
[[File:Hwhezl8(1).png|center]]<br />
<br />
<br />
This is a pretty standard inventory. Not the following things:<br />
<br />
* BP Notify Item Added / Removed: We need to check these boxes, so that we can use thesefunction later.<br />
<br />
* Max Inventory Items: Make the panel as big as you want.<br />
<br />
* Remote Add Item Only Allow Item Classes: This allows us to limit the solar panel's inventory to only batteries, and the items that make the batteries. I consider this a good best practice for these types of structures, so players don't just throw random items in these types of inventories. Nobody's poop or spoiled meat should be in the solar panel. =)<br />
<br />
* All Default Inventory is Engrams: That's an important one. It means that all blueprints in the inventory are considered to be engram blueprints, meaning that they can't be removed from the station. Note: The "Battery" primal item is labeled as an "Always Learned Engram", which allows it to show up here, and be treated like an engram, even though the player did not unlock it in their engram list.<br />
<br />
Now, let's get back to those "BP Notify Item Added / Removed" functions we mentioned earlier.<br />
<br />
For the "Added" function, we want to detect when a battery has been deposited, and increment the solar panel's number of available batteries -- but only if it's daytime. Batteries added at night are not considered charged yet.<br />
<br />
<br />
[[File:DrZIm4V(1).png|center]]<br />
<br />
<br />
Similarly, with the "Removed" function, we need to verify that the current number is less than the existing number before we change the "number of charged batteries" count on the solar panel.<br />
<br />
<br />
[[File:9bdtWM5(1).png|center]]<br />
<br />
<br />
For example, if the solar panel started the evening with 5 batteries, then adding 10 more and removing 1 would trigger the "Remove" function to execute, and the structure would think that it had 14 batteries -- even though we still only consider 5 of them charged. In other words, when day flips to night, we cannot gain any "new" charged batteries until the next day, since batteries only recharge in sunlight.<br />
<br />
== Conclusion ==<br />
<br />
Finally, you'll need to create an engram entry for the panel, and update your PrimalGameData file with the "Additional Structure to Place" and the "Additional Engram Entry" and then you're done!<br />
<br />
You've made a fully functional solar panel with battery backup!<br />
<br />
Feel free to edit/change this project as much as you want for your own use.<br />
<br />
This project will be uploaded as a stand-alone mod, with a link to download the open-source code. Enjoy!<br />
<br />
<br />
-- RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1615Tutorial: Solar Panel2018-05-01T14:59:30Z<p>RedDwarf: /* Solar Panel: Components */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, as long as it's located outside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Due to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel. Create a new blueprint called "PrimalItemStructure_SolarPanel" that's parented to "Primal Item Structure Generic", and change the following defaults:<br />
<br />
<br />
[[File:2PqEKQE(1).png|center]]<br />
<br />
<br />
These settings just change the name of the item, the icon, crafting requirements, the structure to build, and which folder the engram will show up in.<br />
<br />
Feel free to adjust these values as desired!<br />
<br />
<br />
=== Rechargeable Battery ===<br />
<br />
Next, let's create the PrimalItem for the battery that players will be able to craft in the solar panel. Again, not very complicated -- just a simple item that has a good name/description/icon, and weight/crafting-requirements that make sense based on the context of the item.<br />
<br />
<br />
[[File:OxlOOm6(1).png|center]]<br />
<br />
<br />
I made the battery cost a little high, since they completely replace gasoline, and you only have to build them once.<br />
<br />
<br />
== Setting up the Solar Panel logic ==<br />
<br />
Buckle up, kids! We're about to go diving into all of the logic that makes the solar panel actually function. Don't worry, it's not too bad. =)<br />
<br />
Open up your "SolarPanel_BP" blueprint, and click on "Graph" on the top-right. Then click the "Event Graph" tab.<br />
<br />
Let's start here. <br />
<br />
<br />
[[File:SWitz9b(1).png|center]]<br />
<br />
<br />
Like most "Event Begin Play" events, we start with a small delay to give the code time to initialize everything. In many cases (but not all) this is considered a general best-practice in order to avoid problematic glitches down the road.<br />
<br />
We also check to see if the structure is currently a "Preview Structure" (this refers to the green placement structure) -- and we only want to continue if it's the real thing, and not a preview.<br />
<br />
Most of this logic will be run server-side, hence the "Switch Has Authority".<br />
<br />
One of the first things we do is call a custom function called "Check Panel Status". This function will check all of the details needed to determine if the solar panel should be on or not, and then set's the container active/inactive based the results, and this "Check Panel Status" function will be called multiple times, in multiple places.<br />
<br />
<br />
[[File:IHVR9Fr(1).png|center]]<br />
<br />
<br />
As you can see, most of this logic is contained in the "Get Solar Panel Status" function. We'll look into that in more detail later, but for now, let's stick with the "Event Being Play" logic.<br />
<br />
<br />
[[File:KOXL2N2(1).png|center]]<br />
<br />
<br />
The next thing we'll do is call the "Day Cycle Manger". This handles the in-game time system, and contains useful information about whether or not it's currently daylight outside, etc.<br />
<br />
One of the most important features of the Day Cycle Manger, is the ability to "bind delegates" to certain events. In this case, we're able to bind custom events to the "On Start Daytime" and "On Start Nighttime" events. This means that whenever Day Cycle Manager determines that it's daytime or nighttime has happened, it will trigger our custom events.<br />
<br />
We also have a check to see if it's currently nighttime. Why? Because if it's nighttime, we need to check to see if the batteries are still charged enough to keep the solar panel online, and if not, to disable the solar panel. To do that, we setup a looped timer which will call the "Check Panel Status" function every 10 seconds, which nicely equates to 5 minutes in-game.<br />
<br />
<br />
[[File:Qu7uA6G(1).png|center]]<br />
<br />
<br />
This shows our custom events that trigger when day or night happen.<br />
<br />
* When day starts: We clear the timer (since the batteries only run at night), and we run a "Check Panel Status" to trigger the switch to using solar power (instead of batteries), if sunlight is available.<br />
<br />
* When day ends: We count the number of batteries currently in the panels inventory, and we multicast that value to everyone, then set the looping timer and run another "Check Panel Status"<br />
<br />
<br />
[[File:D4BOYlN(1).png|center]]<br />
<br />
<br />
This "MULTICAST - Set Number of Batteries" function is important, and will be used in a few different places, as we'll see soon.<br />
<br />
Next, we need the ability to draw text at the bottom of the Solar Panel whenever a player looks at it, so that they can tell what the current status of the panel is. For example:<br />
<br />
<br />
[[File:FhfXMwd(1).png|center]]<br />
<br />
<br />
This shows that the panel has solar power, but there aren't any batteries available for charging.<br />
<br />
To achieve this HUD message, go to our "SolarPanel_BP" blueprint, and right-click the "Blueprint Draw HUD" function and click "Implement Function". Then we can add the following logic:<br />
<br />
<br />
[[File:Z00cwfJ(1).png|center]]<br />
<br />
<br />
As you can see, this function calls the main "Get Solar Panel Status" function again, which returns the desired HUD text color, as well as the HUD message.<br />
<br />
Then, all we have to do is offset the "Y" location by 100, which will push the text downwards. "BP Draw Text Centered" will keep the text nicely centered in the screen, regardless of character length.<br />
<br />
Okay, now for the big one!<br />
<br />
Let's look at the main "Get Solar Panel Status" function, which calculates whether or not the panel is able to be powered, how much battery life is remaining, and what HUD text/colors should be returned.<br />
<br />
<br />
[[File:GCHFFiQ(1).png|center]]<br />
<br />
<br />
Right off the bat, let's setup two local variables called "Is Daytime" and "Is Indoors". Both of those will be used later. We get the "Is Daytime" value directly from the Day Cycle Manger, and we can get the "Is Indoors" value from the "Is Indoors at Loc" built-in function.<br />
<br />
Note: I added a +100 offset in the Z direction (100 units up off the ground) so that the game didn't register the structure as being inside the foundation that it's placed on.<br />
<br />
Now for the fun part: We need to calculate the amount of battery power remaining.<br />
<br />
<br />
[[File:IAbuSZu(1).png|center]]<br />
<br />
<br />
In this piece, we take the usable number of batters (which was set earlier in the MULTICAST event), and we multiply by the number of seconds in an hour, and how many hours we want each battery to run for. Note: These are '''in-game''' hours, not real-life hours. We then add this value to the "Day Time End" (the time when night began) from the Day Cycle Manager, and subtract the current time. This gives us our countdown based on how many batteries we have in the solar panel's inventory. We take the "Max" value to guarantee that the timer will stop at zero, instead of going into negative numbers. This value is then assigned to the "Battery Time Remaining" local float variable on our main execution path.<br />
<br />
<br />
[[File:LAWBiZf(1).png|center]]<br />
<br />
<br />
Now for the fun part. We need to decide what message the HUD will display, based on the information we know (Is Indoors, Is Daytime, Number of Batteries, and Battery Time Remaining). What this ends up creating is a simple decision tree. I usually draw out the tree on graph paper before I start coding, which really helps me simplify the process in my head.<br />
<br />
<br />
[[File:KO9ihi5(1).png|center]]<br />
<br />
<br />
The tree starts on the right-hand side. If the solar panel is located indoors, then the panel overrides all previous message and issues a warning.<br />
<br />
If the structure in not indoors, then we check to see if it's currently daytime. If it is, then we check to see if we have any batters and display the appropriate message. If it's not daytime, then we check to see if we have any battery power remaining, and display the appropriate message (including a countdown timer to display the amount of battery power remaining).<br />
<br />
The last step of this function is to calculate whether or not the solar panel should have power, and what color the resulting HUD text should be.<br />
<br />
<br />
[[File:MiQCthj(1).png|center]]<br />
<br />
<br />
As you can see, the solar panel has to have either solar power or available battery power in order for "Power Available" to be true, otherwise it's false. If the power is on, we color the text orange, otherwise it's gray.<br />
<br />
<br />
Believe it or not, that's the end of the SolarPanel_BP graph! You did it!<br />
<br />
<br />
== Setting up the Solar Panel inventory component == <br />
<br />
Last, but not least, we'll need to make an inventory component for our solar panel. This will be where batteries are crafted and stored. Create a new blueprint called "PrimalInventoryBP_SolarPanel" and add it to your "SolarPanel_BP" blueprint, in the component's tab.<br />
<br />
Next, add the following items to your new inventory:<br />
<br />
<br />
[[File:Hwhezl8(1).png|center]]<br />
<br />
<br />
This is a pretty standard inventory. Not the following things:<br />
<br />
* BP Notify Item Added / Removed: We need to check these boxes, so that we can use thesefunction later.<br />
<br />
* Max Inventory Items: Make the panel as big as you want.<br />
<br />
* Remote Add Item Only Allow Item Classes: This allows us to limit the solar panel's inventory to only batteries, and the items that make the batteries. I consider this a good best practice for these types of structures, so players don't just throw random items in these types of inventories. Nobody's poop or spoiled meat should be in the solar panel. =)<br />
<br />
* All Default Inventory is Engrams: That's an important one. It means that all blueprints in the inventory are considered to be engram blueprints, meaning that they can't be removed from the station. Note: The "Battery" primal item is labeled as an "Always Learned Engram", which allows it to show up here, and be treated like an engram, even though the player did not unlock it in their engram list.<br />
<br />
Now, let's get back to those "BP Notify Item Added / Removed" functions we mentioned earlier.<br />
<br />
For the "Added" function, we want to detect when a battery has been deposited, and increment the solar panel's number of available batteries -- but only if it's daytime. Batteries added at night are not considered charged yet.<br />
<br />
<br />
[[File:DrZIm4V(1).png|center]]<br />
<br />
<br />
Similarly, with the "Removed" function, we need to verify that the current number is less than the existing number before we change the "number of charged batteries" count on the solar panel.<br />
<br />
<br />
[[File:9bdtWM5(1).png|center]]<br />
<br />
<br />
For example, if the solar panel started the evening with 5 batteries, then adding 10 more and removing 1 would trigger the "Remove" function to execute, and the structure would think that it had 14 batteries -- even though we still only consider 5 of them charged. In other words, when day flips to night, we cannot gain any "new" charged batteries until the next day, since batteries only recharge in sunlight.<br />
<br />
== Conclusion ==<br />
<br />
Finally, you'll need to create an engram entry for the panel, and update your PrimalGameData file with the "Additional Structure to Place" and the "Additional Engram Entry" and then you're done!<br />
<br />
You've made a fully functional solar panel with battery backup!<br />
<br />
Feel free to edit/change this project as much as you want for your own use.<br />
<br />
This project will be uploaded as a stand-alone mod, with a link to download the open-source code. Enjoy!<br />
<br />
<br />
-- RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1614Tutorial: Solar Panel2018-05-01T14:58:44Z<p>RedDwarf: /* Solar Panel: Defaults */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, as long as it's located outside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Due to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel. Create a new blueprint called "PrimalItemStructure_SolarPanel" that's parented to "Primal Item Structure Generic", and change the following defaults:<br />
<br />
<br />
[[File:2PqEKQE(1).png|center]]<br />
<br />
<br />
These settings just change the name of the item, the icon, crafting requirements, the structure to build, and which folder the engram will show up in.<br />
<br />
Feel free to adjust these values as desired!<br />
<br />
<br />
=== Rechargeable Battery ===<br />
<br />
Next, let's create the PrimalItem for the battery that players will be able to craft in the solar panel. Again, not very complicated -- just a simple item that has a good name/description/icon, and weight/crafting-requirements that make sense based on the context of the item.<br />
<br />
<br />
[[File:OxlOOm6(1).png|center]]<br />
<br />
<br />
I made the battery cost a little high, since they completely replace gasoline, and you only have to build them once.<br />
<br />
<br />
== Setting up the Solar Panel logic ==<br />
<br />
Buckle up, kids! We're about to go diving into all of the logic that makes the solar panel actually function. Don't worry, it's not too bad. =)<br />
<br />
Open up your "SolarPanel_BP" blueprint, and click on "Graph" on the top-right. Then click the "Event Graph" tab.<br />
<br />
Let's start here. <br />
<br />
<br />
[[File:SWitz9b(1).png|center]]<br />
<br />
<br />
Like most "Event Begin Play" events, we start with a small delay to give the code time to initialize everything. In many cases (but not all) this is considered a general best-practice in order to avoid problematic glitches down the road.<br />
<br />
We also check to see if the structure is currently a "Preview Structure" (this refers to the green placement structure) -- and we only want to continue if it's the real thing, and not a preview.<br />
<br />
Most of this logic will be run server-side, hence the "Switch Has Authority".<br />
<br />
One of the first things we do is call a custom function called "Check Panel Status". This function will check all of the details needed to determine if the solar panel should be on or not, and then set's the container active/inactive based the results, and this "Check Panel Status" function will be called multiple times, in multiple places.<br />
<br />
<br />
[[File:IHVR9Fr(1).png|center]]<br />
<br />
<br />
As you can see, most of this logic is contained in the "Get Solar Panel Status" function. We'll look into that in more detail later, but for now, let's stick with the "Event Being Play" logic.<br />
<br />
<br />
[[File:KOXL2N2(1).png|center]]<br />
<br />
<br />
The next thing we'll do is call the "Day Cycle Manger". This handles the in-game time system, and contains useful information about whether or not it's currently daylight outside, etc.<br />
<br />
One of the most important features of the Day Cycle Manger, is the ability to "bind delegates" to certain events. In this case, we're able to bind custom events to the "On Start Daytime" and "On Start Nighttime" events. This means that whenever Day Cycle Manager determines that it's daytime or nighttime has happened, it will trigger our custom events.<br />
<br />
We also have a check to see if it's currently nighttime. Why? Because if it's nighttime, we need to check to see if the batteries are still charged enough to keep the solar panel online, and if not, to disable the solar panel. To do that, we setup a looped timer which will call the "Check Panel Status" function every 10 seconds, which nicely equates to 5 minutes in-game.<br />
<br />
<br />
[[File:Qu7uA6G(1).png|center]]<br />
<br />
<br />
This shows our custom events that trigger when day or night happen.<br />
<br />
* When day starts: We clear the timer (since the batteries only run at night), and we run a "Check Panel Status" to trigger the switch to using solar power (instead of batteries), if sunlight is available.<br />
<br />
* When day ends: We count the number of batteries currently in the panels inventory, and we multicast that value to everyone, then set the looping timer and run another "Check Panel Status"<br />
<br />
<br />
[[File:D4BOYlN(1).png|center]]<br />
<br />
<br />
This "MULTICAST - Set Number of Batteries" function is important, and will be used in a few different places, as we'll see soon.<br />
<br />
Next, we need the ability to draw text at the bottom of the Solar Panel whenever a player looks at it, so that they can tell what the current status of the panel is. For example:<br />
<br />
<br />
[[File:FhfXMwd(1).png|center]]<br />
<br />
<br />
This shows that the panel has solar power, but there aren't any batteries available for charging.<br />
<br />
To achieve this HUD message, go to our "SolarPanel_BP" blueprint, and right-click the "Blueprint Draw HUD" function and click "Implement Function". Then we can add the following logic:<br />
<br />
<br />
[[File:Z00cwfJ(1).png|center]]<br />
<br />
<br />
As you can see, this function calls the main "Get Solar Panel Status" function again, which returns the desired HUD text color, as well as the HUD message.<br />
<br />
Then, all we have to do is offset the "Y" location by 100, which will push the text downwards. "BP Draw Text Centered" will keep the text nicely centered in the screen, regardless of character length.<br />
<br />
Okay, now for the big one!<br />
<br />
Let's look at the main "Get Solar Panel Status" function, which calculates whether or not the panel is able to be powered, how much battery life is remaining, and what HUD text/colors should be returned.<br />
<br />
<br />
[[File:GCHFFiQ(1).png|center]]<br />
<br />
<br />
Right off the bat, let's setup two local variables called "Is Daytime" and "Is Indoors". Both of those will be used later. We get the "Is Daytime" value directly from the Day Cycle Manger, and we can get the "Is Indoors" value from the "Is Indoors at Loc" built-in function.<br />
<br />
Note: I added a +100 offset in the Z direction (100 units up off the ground) so that the game didn't register the structure as being inside the foundation that it's placed on.<br />
<br />
Now for the fun part: We need to calculate the amount of battery power remaining.<br />
<br />
<br />
[[File:IAbuSZu(1).png|center]]<br />
<br />
<br />
In this piece, we take the usable number of batters (which was set earlier in the MULTICAST event), and we multiply by the number of seconds in an hour, and how many hours we want each battery to run for. Note: These are '''in-game''' hours, not real-life hours. We then add this value to the "Day Time End" (the time when night began) from the Day Cycle Manager, and subtract the current time. This gives us our countdown based on how many batteries we have in the solar panel's inventory. We take the "Max" value to guarantee that the timer will stop at zero, instead of going into negative numbers. This value is then assigned to the "Battery Time Remaining" local float variable on our main execution path.<br />
<br />
<br />
[[File:LAWBiZf(1).png|center]]<br />
<br />
<br />
Now for the fun part. We need to decide what message the HUD will display, based on the information we know (Is Indoors, Is Daytime, Number of Batteries, and Battery Time Remaining). What this ends up creating is a simple decision tree. I usually draw out the tree on graph paper before I start coding, which really helps me simplify the process in my head.<br />
<br />
<br />
[[File:KO9ihi5(1).png|center]]<br />
<br />
<br />
The tree starts on the right-hand side. If the solar panel is located indoors, then the panel overrides all previous message and issues a warning.<br />
<br />
If the structure in not indoors, then we check to see if it's currently daytime. If it is, then we check to see if we have any batters and display the appropriate message. If it's not daytime, then we check to see if we have any battery power remaining, and display the appropriate message (including a countdown timer to display the amount of battery power remaining).<br />
<br />
The last step of this function is to calculate whether or not the solar panel should have power, and what color the resulting HUD text should be.<br />
<br />
<br />
[[File:MiQCthj(1).png|center]]<br />
<br />
<br />
As you can see, the solar panel has to have either solar power or available battery power in order for "Power Available" to be true, otherwise it's false. If the power is on, we color the text orange, otherwise it's gray.<br />
<br />
<br />
Believe it or not, that's the end of the SolarPanel_BP graph! You did it!<br />
<br />
<br />
== Setting up the Solar Panel inventory component == <br />
<br />
Last, but not least, we'll need to make an inventory component for our solar panel. This will be where batteries are crafted and stored. Create a new blueprint called "PrimalInventoryBP_SolarPanel" and add it to your "SolarPanel_BP" blueprint, in the component's tab.<br />
<br />
Next, add the following items to your new inventory:<br />
<br />
<br />
[[File:Hwhezl8(1).png|center]]<br />
<br />
<br />
This is a pretty standard inventory. Not the following things:<br />
<br />
* BP Notify Item Added / Removed: We need to check these boxes, so that we can use thesefunction later.<br />
<br />
* Max Inventory Items: Make the panel as big as you want.<br />
<br />
* Remote Add Item Only Allow Item Classes: This allows us to limit the solar panel's inventory to only batteries, and the items that make the batteries. I consider this a good best practice for these types of structures, so players don't just throw random items in these types of inventories. Nobody's poop or spoiled meat should be in the solar panel. =)<br />
<br />
* All Default Inventory is Engrams: That's an important one. It means that all blueprints in the inventory are considered to be engram blueprints, meaning that they can't be removed from the station. Note: The "Battery" primal item is labeled as an "Always Learned Engram", which allows it to show up here, and be treated like an engram, even though the player did not unlock it in their engram list.<br />
<br />
Now, let's get back to those "BP Notify Item Added / Removed" functions we mentioned earlier.<br />
<br />
For the "Added" function, we want to detect when a battery has been deposited, and increment the solar panel's number of available batteries -- but only if it's daytime. Batteries added at night are not considered charged yet.<br />
<br />
<br />
[[File:DrZIm4V(1).png|center]]<br />
<br />
<br />
Similarly, with the "Removed" function, we need to verify that the current number is less than the existing number before we change the "number of charged batteries" count on the solar panel.<br />
<br />
<br />
[[File:9bdtWM5(1).png|center]]<br />
<br />
<br />
For example, if the solar panel started the evening with 5 batteries, then adding 10 more and removing 1 would trigger the "Remove" function to execute, and the structure would think that it had 14 batteries -- even though we still only consider 5 of them charged. In other words, when day flips to night, we cannot gain any "new" charged batteries until the next day, since batteries only recharge in sunlight.<br />
<br />
== Conclusion ==<br />
<br />
Finally, you'll need to create an engram entry for the panel, and update your PrimalGameData file with the "Additional Structure to Place" and the "Additional Engram Entry" and then you're done!<br />
<br />
You've made a fully functional solar panel with battery backup!<br />
<br />
Feel free to edit/change this project as much as you want for your own use.<br />
<br />
This project will be uploaded as a stand-alone mod, with a link to download the open-source code. Enjoy!<br />
<br />
<br />
-- RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1611Tutorial: Solar Panel2018-05-01T08:44:14Z<p>RedDwarf: /* The Plan! */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, as long as it's located outside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Do to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel. Create a new blueprint called "PrimalItemStructure_SolarPanel" that's parented to "Primal Item Structure Generic", and change the following defaults:<br />
<br />
<br />
[[File:2PqEKQE(1).png|center]]<br />
<br />
<br />
These settings just change the name of the item, the icon, crafting requirements, the structure to build, and which folder the engram will show up in.<br />
<br />
Feel free to adjust these values as desired!<br />
<br />
<br />
=== Rechargeable Battery ===<br />
<br />
Next, let's create the PrimalItem for the battery that players will be able to craft in the solar panel. Again, not very complicated -- just a simple item that has a good name/description/icon, and weight/crafting-requirements that make sense based on the context of the item.<br />
<br />
<br />
[[File:OxlOOm6(1).png|center]]<br />
<br />
<br />
I made the battery cost a little high, since they completely replace gasoline, and you only have to build them once.<br />
<br />
<br />
== Setting up the Solar Panel logic ==<br />
<br />
Buckle up, kids! We're about to go diving into all of the logic that makes the solar panel actually function. Don't worry, it's not too bad. =)<br />
<br />
Open up your "SolarPanel_BP" blueprint, and click on "Graph" on the top-right. Then click the "Event Graph" tab.<br />
<br />
Let's start here. <br />
<br />
<br />
[[File:SWitz9b(1).png|center]]<br />
<br />
<br />
Like most "Event Begin Play" events, we start with a small delay to give the code time to initialize everything. In many cases (but not all) this is considered a general best-practice in order to avoid problematic glitches down the road.<br />
<br />
We also check to see if the structure is currently a "Preview Structure" (this refers to the green placement structure) -- and we only want to continue if it's the real thing, and not a preview.<br />
<br />
Most of this logic will be run server-side, hence the "Switch Has Authority".<br />
<br />
One of the first things we do is call a custom function called "Check Panel Status". This function will check all of the details needed to determine if the solar panel should be on or not, and then set's the container active/inactive based the results, and this "Check Panel Status" function will be called multiple times, in multiple places.<br />
<br />
<br />
[[File:IHVR9Fr(1).png|center]]<br />
<br />
<br />
As you can see, most of this logic is contained in the "Get Solar Panel Status" function. We'll look into that in more detail later, but for now, let's stick with the "Event Being Play" logic.<br />
<br />
<br />
[[File:KOXL2N2(1).png|center]]<br />
<br />
<br />
The next thing we'll do is call the "Day Cycle Manger". This handles the in-game time system, and contains useful information about whether or not it's currently daylight outside, etc.<br />
<br />
One of the most important features of the Day Cycle Manger, is the ability to "bind delegates" to certain events. In this case, we're able to bind custom events to the "On Start Daytime" and "On Start Nighttime" events. This means that whenever Day Cycle Manager determines that it's daytime or nighttime has happened, it will trigger our custom events.<br />
<br />
We also have a check to see if it's currently nighttime. Why? Because if it's nighttime, we need to check to see if the batteries are still charged enough to keep the solar panel online, and if not, to disable the solar panel. To do that, we setup a looped timer which will call the "Check Panel Status" function every 10 seconds, which nicely equates to 5 minutes in-game.<br />
<br />
<br />
[[File:Qu7uA6G(1).png|center]]<br />
<br />
<br />
This shows our custom events that trigger when day or night happen.<br />
<br />
* When day starts: We clear the timer (since the batteries only run at night), and we run a "Check Panel Status" to trigger the switch to using solar power (instead of batteries), if sunlight is available.<br />
<br />
* When day ends: We count the number of batteries currently in the panels inventory, and we multicast that value to everyone, then set the looping timer and run another "Check Panel Status"<br />
<br />
<br />
[[File:D4BOYlN(1).png|center]]<br />
<br />
<br />
This "MULTICAST - Set Number of Batteries" function is important, and will be used in a few different places, as we'll see soon.<br />
<br />
Next, we need the ability to draw text at the bottom of the Solar Panel whenever a player looks at it, so that they can tell what the current status of the panel is. For example:<br />
<br />
<br />
[[File:FhfXMwd(1).png|center]]<br />
<br />
<br />
This shows that the panel has solar power, but there aren't any batteries available for charging.<br />
<br />
To achieve this HUD message, go to our "SolarPanel_BP" blueprint, and right-click the "Blueprint Draw HUD" function and click "Implement Function". Then we can add the following logic:<br />
<br />
<br />
[[File:Z00cwfJ(1).png|center]]<br />
<br />
<br />
As you can see, this function calls the main "Get Solar Panel Status" function again, which returns the desired HUD text color, as well as the HUD message.<br />
<br />
Then, all we have to do is offset the "Y" location by 100, which will push the text downwards. "BP Draw Text Centered" will keep the text nicely centered in the screen, regardless of character length.<br />
<br />
Okay, now for the big one!<br />
<br />
Let's look at the main "Get Solar Panel Status" function, which calculates whether or not the panel is able to be powered, how much battery life is remaining, and what HUD text/colors should be returned.<br />
<br />
<br />
[[File:GCHFFiQ(1).png|center]]<br />
<br />
<br />
Right off the bat, let's setup two local variables called "Is Daytime" and "Is Indoors". Both of those will be used later. We get the "Is Daytime" value directly from the Day Cycle Manger, and we can get the "Is Indoors" value from the "Is Indoors at Loc" built-in function.<br />
<br />
Note: I added a +100 offset in the Z direction (100 units up off the ground) so that the game didn't register the structure as being inside the foundation that it's placed on.<br />
<br />
Now for the fun part: We need to calculate the amount of battery power remaining.<br />
<br />
<br />
[[File:IAbuSZu(1).png|center]]<br />
<br />
<br />
In this piece, we take the usable number of batters (which was set earlier in the MULTICAST event), and we multiply by the number of seconds in an hour, and how many hours we want each battery to run for. Note: These are '''in-game''' hours, not real-life hours. We then add this value to the "Day Time End" (the time when night began) from the Day Cycle Manager, and subtract the current time. This gives us our countdown based on how many batteries we have in the solar panel's inventory. We take the "Max" value to guarantee that the timer will stop at zero, instead of going into negative numbers. This value is then assigned to the "Battery Time Remaining" local float variable on our main execution path.<br />
<br />
<br />
[[File:LAWBiZf(1).png|center]]<br />
<br />
<br />
Now for the fun part. We need to decide what message the HUD will display, based on the information we know (Is Indoors, Is Daytime, Number of Batteries, and Battery Time Remaining). What this ends up creating is a simple decision tree. I usually draw out the tree on graph paper before I start coding, which really helps me simplify the process in my head.<br />
<br />
<br />
[[File:KO9ihi5(1).png|center]]<br />
<br />
<br />
The tree starts on the right-hand side. If the solar panel is located indoors, then the panel overrides all previous message and issues a warning.<br />
<br />
If the structure in not indoors, then we check to see if it's currently daytime. If it is, then we check to see if we have any batters and display the appropriate message. If it's not daytime, then we check to see if we have any battery power remaining, and display the appropriate message (including a countdown timer to display the amount of battery power remaining).<br />
<br />
The last step of this function is to calculate whether or not the solar panel should have power, and what color the resulting HUD text should be.<br />
<br />
<br />
[[File:MiQCthj(1).png|center]]<br />
<br />
<br />
As you can see, the solar panel has to have either solar power or available battery power in order for "Power Available" to be true, otherwise it's false. If the power is on, we color the text orange, otherwise it's gray.<br />
<br />
<br />
Believe it or not, that's the end of the SolarPanel_BP graph! You did it!<br />
<br />
<br />
== Setting up the Solar Panel inventory component == <br />
<br />
Last, but not least, we'll need to make an inventory component for our solar panel. This will be where batteries are crafted and stored. Create a new blueprint called "PrimalInventoryBP_SolarPanel" and add it to your "SolarPanel_BP" blueprint, in the component's tab.<br />
<br />
Next, add the following items to your new inventory:<br />
<br />
<br />
[[File:Hwhezl8(1).png|center]]<br />
<br />
<br />
This is a pretty standard inventory. Not the following things:<br />
<br />
* BP Notify Item Added / Removed: We need to check these boxes, so that we can use thesefunction later.<br />
<br />
* Max Inventory Items: Make the panel as big as you want.<br />
<br />
* Remote Add Item Only Allow Item Classes: This allows us to limit the solar panel's inventory to only batteries, and the items that make the batteries. I consider this a good best practice for these types of structures, so players don't just throw random items in these types of inventories. Nobody's poop or spoiled meat should be in the solar panel. =)<br />
<br />
* All Default Inventory is Engrams: That's an important one. It means that all blueprints in the inventory are considered to be engram blueprints, meaning that they can't be removed from the station. Note: The "Battery" primal item is labeled as an "Always Learned Engram", which allows it to show up here, and be treated like an engram, even though the player did not unlock it in their engram list.<br />
<br />
Now, let's get back to those "BP Notify Item Added / Removed" functions we mentioned earlier.<br />
<br />
For the "Added" function, we want to detect when a battery has been deposited, and increment the solar panel's number of available batteries -- but only if it's daytime. Batteries added at night are not considered charged yet.<br />
<br />
<br />
[[File:DrZIm4V(1).png|center]]<br />
<br />
<br />
Similarly, with the "Removed" function, we need to verify that the current number is less than the existing number before we change the "number of charged batteries" count on the solar panel.<br />
<br />
<br />
[[File:9bdtWM5(1).png|center]]<br />
<br />
<br />
For example, if the solar panel started the evening with 5 batteries, then adding 10 more and removing 1 would trigger the "Remove" function to execute, and the structure would think that it had 14 batteries -- even though we still only consider 5 of them charged. In other words, when day flips to night, we cannot gain any "new" charged batteries until the next day, since batteries only recharge in sunlight.<br />
<br />
== Conclusion ==<br />
<br />
Finally, you'll need to create an engram entry for the panel, and update your PrimalGameData file with the "Additional Structure to Place" and the "Additional Engram Entry" and then you're done!<br />
<br />
You've made a fully functional solar panel with battery backup!<br />
<br />
Feel free to edit/change this project as much as you want for your own use.<br />
<br />
This project will be uploaded as a stand-alone mod, with a link to download the open-source code. Enjoy!<br />
<br />
<br />
-- RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1610Tutorial: Solar Panel2018-05-01T08:40:47Z<p>RedDwarf: /* Setting up the Solar Panel logic */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, if it's not build inside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Do to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel. Create a new blueprint called "PrimalItemStructure_SolarPanel" that's parented to "Primal Item Structure Generic", and change the following defaults:<br />
<br />
<br />
[[File:2PqEKQE(1).png|center]]<br />
<br />
<br />
These settings just change the name of the item, the icon, crafting requirements, the structure to build, and which folder the engram will show up in.<br />
<br />
Feel free to adjust these values as desired!<br />
<br />
<br />
=== Rechargeable Battery ===<br />
<br />
Next, let's create the PrimalItem for the battery that players will be able to craft in the solar panel. Again, not very complicated -- just a simple item that has a good name/description/icon, and weight/crafting-requirements that make sense based on the context of the item.<br />
<br />
<br />
[[File:OxlOOm6(1).png|center]]<br />
<br />
<br />
I made the battery cost a little high, since they completely replace gasoline, and you only have to build them once.<br />
<br />
<br />
== Setting up the Solar Panel logic ==<br />
<br />
Buckle up, kids! We're about to go diving into all of the logic that makes the solar panel actually function. Don't worry, it's not too bad. =)<br />
<br />
Open up your "SolarPanel_BP" blueprint, and click on "Graph" on the top-right. Then click the "Event Graph" tab.<br />
<br />
Let's start here. <br />
<br />
<br />
[[File:SWitz9b(1).png|center]]<br />
<br />
<br />
Like most "Event Begin Play" events, we start with a small delay to give the code time to initialize everything. In many cases (but not all) this is considered a general best-practice in order to avoid problematic glitches down the road.<br />
<br />
We also check to see if the structure is currently a "Preview Structure" (this refers to the green placement structure) -- and we only want to continue if it's the real thing, and not a preview.<br />
<br />
Most of this logic will be run server-side, hence the "Switch Has Authority".<br />
<br />
One of the first things we do is call a custom function called "Check Panel Status". This function will check all of the details needed to determine if the solar panel should be on or not, and then set's the container active/inactive based the results, and this "Check Panel Status" function will be called multiple times, in multiple places.<br />
<br />
<br />
[[File:IHVR9Fr(1).png|center]]<br />
<br />
<br />
As you can see, most of this logic is contained in the "Get Solar Panel Status" function. We'll look into that in more detail later, but for now, let's stick with the "Event Being Play" logic.<br />
<br />
<br />
[[File:KOXL2N2(1).png|center]]<br />
<br />
<br />
The next thing we'll do is call the "Day Cycle Manger". This handles the in-game time system, and contains useful information about whether or not it's currently daylight outside, etc.<br />
<br />
One of the most important features of the Day Cycle Manger, is the ability to "bind delegates" to certain events. In this case, we're able to bind custom events to the "On Start Daytime" and "On Start Nighttime" events. This means that whenever Day Cycle Manager determines that it's daytime or nighttime has happened, it will trigger our custom events.<br />
<br />
We also have a check to see if it's currently nighttime. Why? Because if it's nighttime, we need to check to see if the batteries are still charged enough to keep the solar panel online, and if not, to disable the solar panel. To do that, we setup a looped timer which will call the "Check Panel Status" function every 10 seconds, which nicely equates to 5 minutes in-game.<br />
<br />
<br />
[[File:Qu7uA6G(1).png|center]]<br />
<br />
<br />
This shows our custom events that trigger when day or night happen.<br />
<br />
* When day starts: We clear the timer (since the batteries only run at night), and we run a "Check Panel Status" to trigger the switch to using solar power (instead of batteries), if sunlight is available.<br />
<br />
* When day ends: We count the number of batteries currently in the panels inventory, and we multicast that value to everyone, then set the looping timer and run another "Check Panel Status"<br />
<br />
<br />
[[File:D4BOYlN(1).png|center]]<br />
<br />
<br />
This "MULTICAST - Set Number of Batteries" function is important, and will be used in a few different places, as we'll see soon.<br />
<br />
Next, we need the ability to draw text at the bottom of the Solar Panel whenever a player looks at it, so that they can tell what the current status of the panel is. For example:<br />
<br />
<br />
[[File:FhfXMwd(1).png|center]]<br />
<br />
<br />
This shows that the panel has solar power, but there aren't any batteries available for charging.<br />
<br />
To achieve this HUD message, go to our "SolarPanel_BP" blueprint, and right-click the "Blueprint Draw HUD" function and click "Implement Function". Then we can add the following logic:<br />
<br />
<br />
[[File:Z00cwfJ(1).png|center]]<br />
<br />
<br />
As you can see, this function calls the main "Get Solar Panel Status" function again, which returns the desired HUD text color, as well as the HUD message.<br />
<br />
Then, all we have to do is offset the "Y" location by 100, which will push the text downwards. "BP Draw Text Centered" will keep the text nicely centered in the screen, regardless of character length.<br />
<br />
Okay, now for the big one!<br />
<br />
Let's look at the main "Get Solar Panel Status" function, which calculates whether or not the panel is able to be powered, how much battery life is remaining, and what HUD text/colors should be returned.<br />
<br />
<br />
[[File:GCHFFiQ(1).png|center]]<br />
<br />
<br />
Right off the bat, let's setup two local variables called "Is Daytime" and "Is Indoors". Both of those will be used later. We get the "Is Daytime" value directly from the Day Cycle Manger, and we can get the "Is Indoors" value from the "Is Indoors at Loc" built-in function.<br />
<br />
Note: I added a +100 offset in the Z direction (100 units up off the ground) so that the game didn't register the structure as being inside the foundation that it's placed on.<br />
<br />
Now for the fun part: We need to calculate the amount of battery power remaining.<br />
<br />
<br />
[[File:IAbuSZu(1).png|center]]<br />
<br />
<br />
In this piece, we take the usable number of batters (which was set earlier in the MULTICAST event), and we multiply by the number of seconds in an hour, and how many hours we want each battery to run for. Note: These are '''in-game''' hours, not real-life hours. We then add this value to the "Day Time End" (the time when night began) from the Day Cycle Manager, and subtract the current time. This gives us our countdown based on how many batteries we have in the solar panel's inventory. We take the "Max" value to guarantee that the timer will stop at zero, instead of going into negative numbers. This value is then assigned to the "Battery Time Remaining" local float variable on our main execution path.<br />
<br />
<br />
[[File:LAWBiZf(1).png|center]]<br />
<br />
<br />
Now for the fun part. We need to decide what message the HUD will display, based on the information we know (Is Indoors, Is Daytime, Number of Batteries, and Battery Time Remaining). What this ends up creating is a simple decision tree. I usually draw out the tree on graph paper before I start coding, which really helps me simplify the process in my head.<br />
<br />
<br />
[[File:KO9ihi5(1).png|center]]<br />
<br />
<br />
The tree starts on the right-hand side. If the solar panel is located indoors, then the panel overrides all previous message and issues a warning.<br />
<br />
If the structure in not indoors, then we check to see if it's currently daytime. If it is, then we check to see if we have any batters and display the appropriate message. If it's not daytime, then we check to see if we have any battery power remaining, and display the appropriate message (including a countdown timer to display the amount of battery power remaining).<br />
<br />
The last step of this function is to calculate whether or not the solar panel should have power, and what color the resulting HUD text should be.<br />
<br />
<br />
[[File:MiQCthj(1).png|center]]<br />
<br />
<br />
As you can see, the solar panel has to have either solar power or available battery power in order for "Power Available" to be true, otherwise it's false. If the power is on, we color the text orange, otherwise it's gray.<br />
<br />
<br />
Believe it or not, that's the end of the SolarPanel_BP graph! You did it!<br />
<br />
<br />
== Setting up the Solar Panel inventory component == <br />
<br />
Last, but not least, we'll need to make an inventory component for our solar panel. This will be where batteries are crafted and stored. Create a new blueprint called "PrimalInventoryBP_SolarPanel" and add it to your "SolarPanel_BP" blueprint, in the component's tab.<br />
<br />
Next, add the following items to your new inventory:<br />
<br />
<br />
[[File:Hwhezl8(1).png|center]]<br />
<br />
<br />
This is a pretty standard inventory. Not the following things:<br />
<br />
* BP Notify Item Added / Removed: We need to check these boxes, so that we can use thesefunction later.<br />
<br />
* Max Inventory Items: Make the panel as big as you want.<br />
<br />
* Remote Add Item Only Allow Item Classes: This allows us to limit the solar panel's inventory to only batteries, and the items that make the batteries. I consider this a good best practice for these types of structures, so players don't just throw random items in these types of inventories. Nobody's poop or spoiled meat should be in the solar panel. =)<br />
<br />
* All Default Inventory is Engrams: That's an important one. It means that all blueprints in the inventory are considered to be engram blueprints, meaning that they can't be removed from the station. Note: The "Battery" primal item is labeled as an "Always Learned Engram", which allows it to show up here, and be treated like an engram, even though the player did not unlock it in their engram list.<br />
<br />
Now, let's get back to those "BP Notify Item Added / Removed" functions we mentioned earlier.<br />
<br />
For the "Added" function, we want to detect when a battery has been deposited, and increment the solar panel's number of available batteries -- but only if it's daytime. Batteries added at night are not considered charged yet.<br />
<br />
<br />
[[File:DrZIm4V(1).png|center]]<br />
<br />
<br />
Similarly, with the "Removed" function, we need to verify that the current number is less than the existing number before we change the "number of charged batteries" count on the solar panel.<br />
<br />
<br />
[[File:9bdtWM5(1).png|center]]<br />
<br />
<br />
For example, if the solar panel started the evening with 5 batteries, then adding 10 more and removing 1 would trigger the "Remove" function to execute, and the structure would think that it had 14 batteries -- even though we still only consider 5 of them charged. In other words, when day flips to night, we cannot gain any "new" charged batteries until the next day, since batteries only recharge in sunlight.<br />
<br />
== Conclusion ==<br />
<br />
Finally, you'll need to create an engram entry for the panel, and update your PrimalGameData file with the "Additional Structure to Place" and the "Additional Engram Entry" and then you're done!<br />
<br />
You've made a fully functional solar panel with battery backup!<br />
<br />
Feel free to edit/change this project as much as you want for your own use.<br />
<br />
This project will be uploaded as a stand-alone mod, with a link to download the open-source code. Enjoy!<br />
<br />
<br />
-- RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:9bdtWM5(1).png&diff=1609File:9bdtWM5(1).png2018-05-01T08:35:48Z<p>RedDwarf: </p>
<hr />
<div>asdf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:DrZIm4V(1).png&diff=1608File:DrZIm4V(1).png2018-05-01T08:33:34Z<p>RedDwarf: </p>
<hr />
<div>asdasdf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:RfFAQg4(1).png&diff=1607File:RfFAQg4(1).png2018-05-01T08:32:29Z<p>RedDwarf: </p>
<hr />
<div>adsf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:Hwhezl8(1).png&diff=1606File:Hwhezl8(1).png2018-05-01T08:24:59Z<p>RedDwarf: </p>
<hr />
<div>sazdfa</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1605Tutorial: Solar Panel2018-05-01T08:21:13Z<p>RedDwarf: /* Setting up the Solar Panel logic */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, if it's not build inside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Do to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel. Create a new blueprint called "PrimalItemStructure_SolarPanel" that's parented to "Primal Item Structure Generic", and change the following defaults:<br />
<br />
<br />
[[File:2PqEKQE(1).png|center]]<br />
<br />
<br />
These settings just change the name of the item, the icon, crafting requirements, the structure to build, and which folder the engram will show up in.<br />
<br />
Feel free to adjust these values as desired!<br />
<br />
<br />
=== Rechargeable Battery ===<br />
<br />
Next, let's create the PrimalItem for the battery that players will be able to craft in the solar panel. Again, not very complicated -- just a simple item that has a good name/description/icon, and weight/crafting-requirements that make sense based on the context of the item.<br />
<br />
<br />
[[File:OxlOOm6(1).png|center]]<br />
<br />
<br />
I made the battery cost a little high, since they completely replace gasoline, and you only have to build them once.<br />
<br />
<br />
== Setting up the Solar Panel logic ==<br />
<br />
Buckle up, kids! We're about to go diving into all of the logic that makes the solar panel actually function. Don't worry, it's not too bad. =)<br />
<br />
Open up your "SolarPanel_BP" blueprint, and click on "Graph" on the top-right. Then click the "Event Graph" tab.<br />
<br />
Let's start here. <br />
<br />
<br />
[[File:SWitz9b(1).png|center]]<br />
<br />
<br />
Like most "Event Begin Play" events, we start with a small delay to give the code time to initialize everything. In many cases (but not all) this is considered a general best-practice in order to avoid problematic glitches down the road.<br />
<br />
We also check to see if the structure is currently a "Preview Structure" (this refers to the green placement structure) -- and we only want to continue if it's the real thing, and not a preview.<br />
<br />
Most of this logic will be run server-side, hence the "Switch Has Authority".<br />
<br />
One of the first things we do is call a custom function called "Check Panel Status". This function will check all of the details needed to determine if the solar panel should be on or not, and then set's the container active/inactive based the results, and this "Check Panel Status" function will be called multiple times, in multiple places.<br />
<br />
<br />
[[File:IHVR9Fr(1).png|center]]<br />
<br />
<br />
As you can see, most of this logic is contained in the "Get Solar Panel Status" function. We'll look into that in more detail later, but for now, let's stick with the "Event Being Play" logic.<br />
<br />
<br />
[[File:KOXL2N2(1).png|center]]<br />
<br />
<br />
The next thing we'll do is call the "Day Cycle Manger". This handles the in-game time system, and contains useful information about whether or not it's currently daylight outside, etc.<br />
<br />
One of the most important features of the Day Cycle Manger, is the ability to "bind delegates" to certain events. In this case, we're able to bind custom events to the "On Start Daytime" and "On Start Nighttime" events. This means that whenever Day Cycle Manager determines that it's daytime or nighttime has happened, it will trigger our custom events.<br />
<br />
We also have a check to see if it's currently nighttime. Why? Because if it's nighttime, we need to check to see if the batteries are still charged enough to keep the solar panel online, and if not, to disable the solar panel. To do that, we setup a looped timer which will call the "Check Panel Status" function every 10 seconds, which nicely equates to 5 minutes in-game.<br />
<br />
<br />
[[File:Qu7uA6G(1).png|center]]<br />
<br />
<br />
This shows our custom events that trigger when day or night happen.<br />
<br />
* When day starts: We clear the timer (since the batteries only run at night), and we run a "Check Panel Status" to trigger the switch to using solar power (instead of batteries), if sunlight is available.<br />
<br />
* When day ends: We count the number of batteries currently in the panels inventory, and we multicast that value to everyone, then set the looping timer and run another "Check Panel Status"<br />
<br />
<br />
[[File:D4BOYlN(1).png|center]]<br />
<br />
<br />
This "MULTICAST - Set Number of Batteries" function is important, and will be used in a few different places, as we'll see soon.<br />
<br />
Next, we need the ability to draw text at the bottom of the Solar Panel whenever a player looks at it, so that they can tell what the current status of the panel is. For example:<br />
<br />
<br />
[[File:FhfXMwd(1).png|center]]<br />
<br />
<br />
This shows that the panel has solar power, but there aren't any batteries available for charging.<br />
<br />
To achieve this HUD message, go to our "SolarPanel_BP" blueprint, and right-click the "Blueprint Draw HUD" function and click "Implement Function". Then we can add the following logic:<br />
<br />
<br />
[[File:Z00cwfJ(1).png|center]]<br />
<br />
<br />
As you can see, this function calls the main "Get Solar Panel Status" function again, which returns the desired HUD text color, as well as the HUD message.<br />
<br />
Then, all we have to do is offset the "Y" location by 100, which will push the text downwards. "BP Draw Text Centered" will keep the text nicely centered in the screen, regardless of character length.<br />
<br />
Okay, now for the big one!<br />
<br />
Let's look at the main "Get Solar Panel Status" function, which calculates whether or not the panel is able to be powered, how much battery life is remaining, and what HUD text/colors should be returned.<br />
<br />
<br />
[[File:GCHFFiQ(1).png|center]]<br />
<br />
<br />
Right off the bat, let's setup two local variables called "Is Daytime" and "Is Indoors". Both of those will be used later. We get the "Is Daytime" value directly from the Day Cycle Manger, and we can get the "Is Indoors" value from the "Is Indoors at Loc" built-in function.<br />
<br />
Note: I added a +100 offset in the Z direction (100 units up off the ground) so that the game didn't register the structure as being inside the foundation that it's placed on.<br />
<br />
Now for the fun part: We need to calculate the amount of battery power remaining.<br />
<br />
<br />
[[File:IAbuSZu(1).png|center]]<br />
<br />
<br />
In this piece, we take the usable number of batters (which was set earlier in the MULTICAST event), and we multiply by the number of seconds in an hour, and how many hours we want each battery to run for. Note: These are '''in-game''' hours, not real-life hours. We then add this value to the "Day Time End" (the time when night began) from the Day Cycle Manager, and subtract the current time. This gives us our countdown based on how many batteries we have in the solar panel's inventory. We take the "Max" value to guarantee that the timer will stop at zero, instead of going into negative numbers. This value is then assigned to the "Battery Time Remaining" local float variable on our main execution path.<br />
<br />
<br />
[[File:LAWBiZf(1).png|center]]<br />
<br />
<br />
Now for the fun part. We need to decide what message the HUD will display, based on the information we know (Is Indoors, Is Daytime, Number of Batteries, and Battery Time Remaining). What this ends up creating is a simple decision tree. I usually draw out the tree on graph paper before I start coding, which really helps me simplify the process in my head.<br />
<br />
<br />
[[File:KO9ihi5(1).png|center]]<br />
<br />
<br />
The tree starts on the right-hand side. If the solar panel is located indoors, then the panel overrides all previous message and issues a warning.<br />
<br />
If the structure in not indoors, then we check to see if it's currently daytime. If it is, then we check to see if we have any batters and display the appropriate message. If it's not daytime, then we check to see if we have any battery power remaining, and display the appropriate message (including a countdown timer to display the amount of battery power remaining).<br />
<br />
The last step of this function is to calculate whether or not the solar panel should have power, and what color the resulting HUD text should be.<br />
<br />
<br />
[[File:MiQCthj(1).png|center]]<br />
<br />
<br />
As you can see, the solar panel has to have either solar power or available battery power in order for "Power Available" to be true, otherwise it's false. If the power is on, we color the text orange, otherwise it's gray.<br />
<br />
<br />
Believe it or not, that's the end of the SolarPanel_BP graph! You did it!</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:MiQCthj(1).png&diff=1604File:MiQCthj(1).png2018-05-01T08:18:30Z<p>RedDwarf: </p>
<hr />
<div>asdfa</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:KO9ihi5(1).png&diff=1603File:KO9ihi5(1).png2018-05-01T08:14:45Z<p>RedDwarf: </p>
<hr />
<div>sadfad</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:LAWBiZf(1).png&diff=1602File:LAWBiZf(1).png2018-05-01T08:10:00Z<p>RedDwarf: </p>
<hr />
<div>asdf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:IAbuSZu(1).png&diff=1601File:IAbuSZu(1).png2018-05-01T08:05:27Z<p>RedDwarf: </p>
<hr />
<div>asdf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:GCHFFiQ(1).png&diff=1600File:GCHFFiQ(1).png2018-05-01T08:01:24Z<p>RedDwarf: </p>
<hr />
<div>azsdaf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1599Tutorial: Solar Panel2018-05-01T07:58:09Z<p>RedDwarf: /* Rechargeable Battery */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, if it's not build inside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Do to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel. Create a new blueprint called "PrimalItemStructure_SolarPanel" that's parented to "Primal Item Structure Generic", and change the following defaults:<br />
<br />
<br />
[[File:2PqEKQE(1).png|center]]<br />
<br />
<br />
These settings just change the name of the item, the icon, crafting requirements, the structure to build, and which folder the engram will show up in.<br />
<br />
Feel free to adjust these values as desired!<br />
<br />
<br />
=== Rechargeable Battery ===<br />
<br />
Next, let's create the PrimalItem for the battery that players will be able to craft in the solar panel. Again, not very complicated -- just a simple item that has a good name/description/icon, and weight/crafting-requirements that make sense based on the context of the item.<br />
<br />
<br />
[[File:OxlOOm6(1).png|center]]<br />
<br />
<br />
I made the battery cost a little high, since they completely replace gasoline, and you only have to build them once.<br />
<br />
<br />
== Setting up the Solar Panel logic ==<br />
<br />
Buckle up, kids! We're about to go diving into all of the logic that makes the solar panel actually function. Don't worry, it's not too bad. =)<br />
<br />
Open up your "SolarPanel_BP" blueprint, and click on "Graph" on the top-right. Then click the "Event Graph" tab.<br />
<br />
Let's start here. <br />
<br />
<br />
[[File:SWitz9b(1).png|center]]<br />
<br />
<br />
Like most "Event Begin Play" events, we start with a small delay to give the code time to initialize everything. In many cases (but not all) this is considered a general best-practice in order to avoid problematic glitches down the road.<br />
<br />
We also check to see if the structure is currently a "Preview Structure" (this refers to the green placement structure) -- and we only want to continue if it's the real thing, and not a preview.<br />
<br />
Most of this logic will be run server-side, hence the "Switch Has Authority".<br />
<br />
One of the first things we do is call a custom function called "Check Panel Status". This function will check all of the details needed to determine if the solar panel should be on or not, and then set's the container active/inactive based the results, and this "Check Panel Status" function will be called multiple times, in multiple places.<br />
<br />
<br />
[[File:IHVR9Fr(1).png|center]]<br />
<br />
<br />
As you can see, most of this logic is contained in the "Get Solar Panel Status" function. We'll look into that in more detail later, but for now, let's stick with the "Event Being Play" logic.<br />
<br />
<br />
[[File:KOXL2N2(1).png|center]]<br />
<br />
<br />
The next thing we'll do is call the "Day Cycle Manger". This handles the in-game time system, and contains useful information about whether or not it's currently daylight outside, etc.<br />
<br />
One of the most important features of the Day Cycle Manger, is the ability to "bind delegates" to certain events. In this case, we're able to bind custom events to the "On Start Daytime" and "On Start Nighttime" events. This means that whenever Day Cycle Manager determines that it's daytime or nighttime has happened, it will trigger our custom events.<br />
<br />
We also have a check to see if it's currently nighttime. Why? Because if it's nighttime, we need to check to see if the batteries are still charged enough to keep the solar panel online, and if not, to disable the solar panel. To do that, we setup a looped timer which will call the "Check Panel Status" function every 10 seconds, which nicely equates to 5 minutes in-game.<br />
<br />
<br />
[[File:Qu7uA6G(1).png|center]]<br />
<br />
<br />
This shows our custom events that trigger when day or night happen.<br />
<br />
* When day starts: We clear the timer (since the batteries only run at night), and we run a "Check Panel Status" to trigger the switch to using solar power (instead of batteries), if sunlight is available.<br />
<br />
* When day ends: We count the number of batteries currently in the panels inventory, and we multicast that value to everyone, then set the looping timer and run another "Check Panel Status"<br />
<br />
<br />
[[File:D4BOYlN(1).png|center]]<br />
<br />
<br />
This "MULTICAST - Set Number of Batteries" function is important, and will be used in a few different places, as we'll see soon.<br />
<br />
Next, we need the ability to draw text at the bottom of the Solar Panel whenever a player looks at it, so that they can tell what the current status of the panel is. For example:<br />
<br />
<br />
[[File:FhfXMwd(1).png|center]]<br />
<br />
<br />
This shows that the panel has solar power, but there aren't any batteries available for charging.<br />
<br />
To achieve this HUD message, go to our "SolarPanel_BP" blueprint, and right-click the "Blueprint Draw HUD" function and click "Implement Function". Then we can add the following logic:<br />
<br />
<br />
[[File:Z00cwfJ(1).png|center]]<br />
<br />
<br />
As you can see, this function calls the main "Get Solar Panel Status" function again, which returns the desired HUD text color, as well as the HUD message.<br />
<br />
Then, all we have to do is offset the "Y" location by 100, which will push the text downwards. "BP Draw Text Centered" will keep the text nicely centered in the screen, regardless of character length.</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:Z00cwfJ(1).png&diff=1598File:Z00cwfJ(1).png2018-05-01T07:55:42Z<p>RedDwarf: </p>
<hr />
<div>asd</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:FhfXMwd(1).png&diff=1597File:FhfXMwd(1).png2018-05-01T07:53:12Z<p>RedDwarf: </p>
<hr />
<div>asdf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:D4BOYlN(1).png&diff=1596File:D4BOYlN(1).png2018-05-01T07:48:57Z<p>RedDwarf: </p>
<hr />
<div>asdf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:Qu7uA6G(1).png&diff=1595File:Qu7uA6G(1).png2018-05-01T07:45:01Z<p>RedDwarf: </p>
<hr />
<div>zsadf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:KOXL2N2(1).png&diff=1594File:KOXL2N2(1).png2018-05-01T07:38:20Z<p>RedDwarf: </p>
<hr />
<div>asdf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:IHVR9Fr(1).png&diff=1593File:IHVR9Fr(1).png2018-05-01T07:35:33Z<p>RedDwarf: </p>
<hr />
<div>sadf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:SWitz9b(1).png&diff=1592File:SWitz9b(1).png2018-05-01T07:29:28Z<p>RedDwarf: </p>
<hr />
<div>asdf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1591Tutorial: Solar Panel2018-05-01T07:21:49Z<p>RedDwarf: /* Solar Panel */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, if it's not build inside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Do to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel. Create a new blueprint called "PrimalItemStructure_SolarPanel" that's parented to "Primal Item Structure Generic", and change the following defaults:<br />
<br />
<br />
[[File:2PqEKQE(1).png|center]]<br />
<br />
<br />
These settings just change the name of the item, the icon, crafting requirements, the structure to build, and which folder the engram will show up in.<br />
<br />
Feel free to adjust these values as desired!<br />
<br />
<br />
=== Rechargeable Battery ===<br />
<br />
Next, let's create the PrimalItem for the battery that players will be able to craft in the solar panel. Again, not very complicated -- just a simple item that has a good name/description/icon, and weight/crafting-requirements that make sense based on the context of the item.<br />
<br />
<br />
[[File:OxlOOm6(1).png|center]]<br />
<br />
<br />
I made the battery cost a little high, since they completely replace gasoline, and you only have to build them once.</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:OxlOOm6(1).png&diff=1590File:OxlOOm6(1).png2018-05-01T07:20:41Z<p>RedDwarf: </p>
<hr />
<div>Battery</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:2PqEKQE(1).png&diff=1589File:2PqEKQE(1).png2018-05-01T07:16:14Z<p>RedDwarf: </p>
<hr />
<div>Defaults</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:409oJqi(1).png&diff=1588File:409oJqi(1).png2018-05-01T07:11:41Z<p>RedDwarf: </p>
<hr />
<div>PrimalItem</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1587Tutorial: Solar Panel2018-05-01T06:54:58Z<p>RedDwarf: /* Solar Panel: Components */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, if it's not build inside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Do to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)<br />
<br />
These components can be positioned however you like. I put the sound emitter in the middle of the battery box, and I aligned/scaled all of the meshes until it looked right to me. But the sky is the limit, you can add whatever you want. Be careful not to go too crazy -- adding components this way will increase the load on the users GPU more than a properly rendered single static mesh, so use these components sparingly if you can.<br />
<br />
<br />
== Setup the Primal Items ==<br />
<br />
Before we go any further, let's setup the PrimalItems that we'll need later. Primal Item's are blueprints that describe the item as it exists in your inventories, whereas structure blueprints define what is actually placed/built in the 3D world.<br />
<br />
<br />
=== Solar Panel ===<br />
<br />
Let's start with the Solar Panel.</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1586Tutorial: Solar Panel2018-05-01T06:42:03Z<p>RedDwarf: /* The Plan! */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, if it's not build inside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!<br />
<br />
<br />
== Setting up the Solar Panel structure ==<br />
<br />
Firstly, create a new directory under your "Mods" folder called "SpaceDay_SolarPanel" (or whatever you'd like your mod to be called), and create a new PrimalGameData file for it.<br />
<br />
Inside this mod folder, I usually create an "Assets" folder for sounds and meshes, and an "Items" folder for blueprints and in-game items.<br />
<br />
Like many modders, when creating a simple crafting structure, let's start by copying the Smithy ("StorageBox_AnvilBench") to our "Items" folder, and rename it "SolarPanel_BP".<br />
<br />
Now, before we begin, let's discuss a little trick that we're going to do. If you look at the reference picture at the top of the tutorial, you'll see that the solar panel is connected to the battery storage box by an electrical cable and junction box.<br />
<br />
<br />
[[File:9xAz76O(1).png|center]]<br />
<br />
<br />
Wouldn't it be nice if that electrical cable changed color when the power was on, as a visual indicator? We can do that! The devkit has an easy built-in way to change materials on it's default static mesh when the structure is activated. For example, a refrigerators green lights might come on, etc.<br />
<br />
So what we're going to do is assign the static mesh of our solar panel to be that cable (so that we can change it's color on activation), and we'll manually add the actual solar panel later as an additional static mesh component. Your "components" list will end up looking like this:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
<br />
More on that later!<br />
<br />
Next, let's take a look at how we should setup the "SolarPanel_BP" defaults.<br />
<br />
=== Solar Panel: Defaults ===<br />
<br />
As mentioned earlier, we're going to use an electrical cable mesh as the primary mesh for this solar panel, so that we can easily adjust it's materials when the solar panel is powered up, like so:<br />
<br />
<br />
[[File:Ok6UN5y(1).png|center]]<br />
<br />
<br />
* Active/Inactive Materials: Powered and unpowered cable materials (yellow vs. gray).<br />
<br />
* Disable Activation Underwater: Probably a good idea for players to not put their battery boxes underwater!<br />
<br />
* Powered Water Source when Active: This means that the structure will generate Power and Water when activated. We're only going to add snap points for electrical cables, but in theory you could also get water out of this structure if it had a snap-point to add water pipes. That doesn't sound safe!<br />
<br />
* Container Activated/Deactivated Sound: For this, I borrowed the pre-existing activation sounds from Aberration's Charge Lantern. This adds a nice mechanical sound to the structure when it turns on.<br />
<br />
* Dont Actually Snap Just Placement: The generator blueprint has this checked, so I'm following along. I believe this means that the structure cannot use existing electrical cables as "support".<br />
<br />
* Blueprint Draw HUD: Later we will be adding code to generate a nice "Status" message for the user when they look at the structure, so we'll need this box checked so that the graph function will be called.<br />
<br />
* Damage Type Adjusters: This structure doesn't take any special damage from anything.<br />
<br />
* Structure Settings Class: "Broken By Metal" is the "Wood Tier", meaning that you can break it with metal tools, which makes sense for a solar panel. This is also in keeping with the durability of the generator.<br />
<br />
<br />
[[File:LQ8UyN7(1).png|center]]<br />
<br />
<br />
* Consumes Primal Item: This should be setup to consume the PrimalItem that represents your SolarPanel_BP blueprint (we'll cover that in a moment).<br />
<br />
* Structure Snap Type Flags: This one is very important. This number serves as a bit-mask to tell the game which types of items can be snapped to it. For the full details, check out the [[Snap Points]] page.<br />
<br />
* Snap Points: The structure contains 4 snap-points, which are all identical except that their "Point Rot Offset" is rotated by 90 degrees each time. This allows you to snap cables in 4 directions. These cables have a "Point Loc Offset" which puts the cable snap point just under the battery box at the same height as a generator's snap point, for consistency's sake.<br />
<br />
Next, we setup the placement details, health, name etc:<br />
<br />
<br />
[[File:VHz9YTc(1).png|center]]<br />
<br />
<br />
* Placement Encroachment Check Offset / Box Extent / Trace Scale: These settings determine how much space your structure will need in order to be placed.<br />
<br />
* Placement Rotation Offset: This rotates the model 90 degrees so that it's facing us when we place it.<br />
<br />
* Requires Placement on Structure Floors: Do to the shape of the model, it would look very bad if placed on uneven ground, so this solar panel requires placement on a structure.<br />
<br />
* Placement Choose Rotation: Allow the player to rotate the structure.<br />
<br />
* Snap Requires Placement on Ground: The solar panel should always be on the ground.<br />
<br />
The remaining settings are default for a generator. The "Destroyed Mesh" is left empty, because destroyed meshes take up a lot of disk space and inflate the mod's size, so that's left off for most of the mods that I create.<br />
<br />
<br />
=== Solar Panel: Components ===<br />
<br />
As mentioned previously, your SolarPanel_BP structure will contain the following components:<br />
<br />
<br />
[[File:V1sGJJN(1).png|center]]<br />
<br />
* MyStaticMesh: "SM_CablesStraight" (The main mesh for the structure.)<br />
* JunctionBox: "SM_JuctionBox" (This is purely aesthetic, to show how power would get to the battery box.)<br />
* SolarPanel: "Solar_final" (This is the excellent solar panel model that Pleasant made for this tutorial.)<br />
* ActivatedEmitter: "SolarPanelEmitter" (This is a copy of the ActivatedEmitter from the Generator, modified with a free sound loop from [[https://freesound.org/ FreeSound.org]], which gives it an electrical buzz sound when activated.)</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:VHz9YTc(1).png&diff=1585File:VHz9YTc(1).png2018-05-01T06:28:25Z<p>RedDwarf: </p>
<hr />
<div>Defaults</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:LQ8UyN7(1).png&diff=1584File:LQ8UyN7(1).png2018-05-01T06:20:34Z<p>RedDwarf: </p>
<hr />
<div>Defaults</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:Ok6UN5y(1).png&diff=1583File:Ok6UN5y(1).png2018-05-01T06:10:03Z<p>RedDwarf: </p>
<hr />
<div>Defaults</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:V1sGJJN(1).png&diff=1582File:V1sGJJN(1).png2018-05-01T06:05:17Z<p>RedDwarf: </p>
<hr />
<div>Components</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:9xAz76O(1).png&diff=1581File:9xAz76O(1).png2018-05-01T05:58:11Z<p>RedDwarf: </p>
<hr />
<div>Cable</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1580Tutorial: Solar Panel2018-05-01T05:44:32Z<p>RedDwarf: /* The Plan! */</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, if it's not build inside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allows the panel to charge the batteries during the day and discharge the batteries at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Solar_Panel&diff=1579Tutorial: Solar Panel2018-05-01T05:43:28Z<p>RedDwarf: First release</p>
<hr />
<div>[[Category:Tutorials]]<br />
<br />
[[File:Evz2i4s(1).png|center|Solar Panel Preview]]<br />
<br />
<br />
== Introduction ==<br />
<br />
Hello there!<br />
<br />
The theme of the 4th modding tutorial competition was to create a mod for "Space Day", which celebrates science and technology. In keeping with that theme RedDwarf (myself) and Pleasure have teamed up to build a working solar panel for ARK, completely from scratch. Pleasure created an excellent youtube video tutorial in which he shows how the solar panel model was constructed. And this tutorial that you're reading now will walk you through how to setup the solar panel so that it can be used in-game.<br />
<br />
''' [https://www.youtube.com/watch?v=O4lIEe2L_gI Click Here] to watch the modeling tutorial by Pleasure! '''<br />
<br />
<br />
[[File:7kDp7HY(1).png|center|Youtube link|link=https://www.youtube.com/watch?v=O4lIEe2L_gI]]<br />
<br />
<br />
<br />
<br />
<br />
== The Plan! ==<br />
<br />
This solar panel will provide power during the day, if it's not build inside.<br />
<br />
Additionally, the player can build batteries inside the solar panel's inventory, which allow the panel to charge during the day and discharge their energy at night when no sunlight is available. Each battery extends the solar panel's power by 1 additional '''in-game''' hour. Players will need to build enough batteries to survive the night, if they want uninterrupted power.<br />
<br />
The charging methodology is vary simple: When night sets, the solar panel will count the number of batteries currently in it's inventory, and begin a countdown showing how much battery time is left. Any battery added during the daytime is considered charged when night sets, but any batteries added at night will be ignored (since they have not been charged by sunlight). Additionally, if batteries are removed at night, the timer will go down -- and if it hits zero, the solar panel will be out of juice and shut down until the sun rises the following morning. =)<br />
<br />
Let's get started!</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:7kDp7HY(1).png&diff=1578File:7kDp7HY(1).png2018-05-01T05:26:40Z<p>RedDwarf: </p>
<hr />
<div>Youtube link</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=File:Evz2i4s(1).png&diff=1577File:Evz2i4s(1).png2018-05-01T05:20:01Z<p>RedDwarf: </p>
<hr />
<div>Solar panels preview</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Rocket_Poop&diff=1573Tutorial: Rocket Poop2018-04-24T16:55:55Z<p>RedDwarf: Redirected page to Tutorial: Rocket Poop (buff)</p>
<hr />
<div>#REDIRECT [[Tutorial:_Rocket_Poop_(buff)]]</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Rocket_Poop_(buff)&diff=1571Tutorial: Rocket Poop (buff)2018-04-21T04:29:12Z<p>RedDwarf: /* Event Buff Tick Server: Apply Thrust, Consume Food/Health */</p>
<hr />
<div>[[Category:Tutorials]]<br />
[[Category:Buffs]]<br />
<br />
== Introduction ==<br />
<br />
Greetings, fellow modders!<br />
<br />
The theme of this modding competition was to create a “wacky, ridiculous buff.” Finally, my time has come!<br />
I decided that what I really missed about ARK was the ability to do the famous cartoony “double-jump” that Mario and many other video game characters have been able to do for decades.<br />
So, since real physics have already been thrown out the window, the real question became “How do I make this fit in the ARK universe?” – and the answer was simple: Add poop.<br />
Thus, the “Rocket Poop” buff was born!<br />
When this buff is enabled, pressing the poop key will rocket-propel a stream of poop out of your butt so fast, that you’ll take to the air in what can only be described as the world's first biological jetpack. Be warned! This will quickly empty your stomach/bowels and cause you to starve if used too much.<br />
<br />
== The Plan! ==<br />
<br />
* Make the “Rocket Poops” buff, with the following effects, when the player pushes the poop key:<br />
** Capture the player’s “poop key” command.<br />
*** Keep boosting if the player holds the "poop key" down.<br />
** Enable a flaming poop particle emitter at the players butt (PlayerPawn’s “PoopSocket”).<br />
** Play a pooping/flaming sound.<br />
** Propel player upwards.<br />
*** Make sure they don’t go too fast.<br />
*** Allow player to navigate in mid-air, by factoring in the player’s input.<br />
** Reduce the player’s food stat (pooping requires food).<br />
*** Subtract from the players health if they continue to poop on an empty stomach.<br />
* Make a consumable item called “Rotten Meat”, which give the “Rocket Poops” buff when eaten.<br />
<br />
== Setting up the “Rocket Poop” Buff ==<br />
<br />
Create a blueprint called “PrimalBuff_RocketPoop” which is parented to “Primal Buff”.<br />
<br />
Next, open the “PrimalBuff_RocketPoop” and click on the “Defaults” tab at the top, and change the following properties:<br />
<br />
<br />
[[File:CxLJ1oP(1).png|center]]<br />
<br />
<br />
These settings will allow the buff to last for 5 minutes (300 seconds), and also detail when/how the buff can be activated. The name, description, icon, and duration can be easily changed if you want to modify the look/feel of the item. For example, you may want to make this item look like a potion, or a magic curse, etc. It also has flags that prevent it from being used on a dino, and it is treated as a disease. And most importantly, the "Use Buff Tick Server" and "Use Buff Tick Client" have been checked -- more on that later.<br />
<br />
Note: We will be revisiting this buff to add all the remaining logic and functionality. <br />
<br />
But first, we need to create a consumable that will allow players to activate our buff. This will also be very helpful when testing the buff in the devkit, because this consumable can be spawned and used. For even easier testing, add the buff to the “Additional Default Buffs” array in your mod’s PrimalGameData file, and the buff will automatically appear every time you start the PIE (“Play in Editor”).<br />
<br />
== Setting up the “Rotten Steak” Consumable ==<br />
<br />
To do this, create a new blueprint called “PrimalItemConsumableGeneric_RottenSteak” with “Primal Item Consumable Generic” as its parent.<br />
<br />
Open your new “Rotten Steak” primal item and modify the following values to customize it to your needs:<br />
<br />
<br />
[[File:TBHQXWr(1).png|center]]<br />
<br />
<br />
Again, feel free to change the icons or descriptions to whatever you’d like. I made the recipe require 1x spoiled meat, just because that was an easy resource, and it fit thematically.<br />
<br />
Your Rotten Steak is done! Now you can spawn it in and use it to test your buff.<br />
<br />
Example spawn code (your path/names will probably vary): <br />
Admincheat giveitem “Blueprint'/Game/Mods/RocketPoop/Consumables/RottenSteak/PrimalItemConsumableGeneric_RottenSteak.PrimalItemConsumableGeneric_RottenSteak'” 20 0 0<br />
<br />
== Setup Assets ==<br />
<br />
Before we get too far into our graph code, we need to setup a few assets that our mod will need.<br />
<br />
<br />
=== "Rocket Poops" particle emitter ===<br />
<br />
For this emitter, I started with a copy of the flame-thrower's main flame-thrower effect, called "Flamethrower_PS".<br />
<br />
From this base, I disabled the larger flames and smoke, and angled the remaining particles 180 to point them downwards (since our thrust is always shooting down).<br />
<br />
I then added a new mesh emitter, which will spawn human poops, shoot them downwards, and gives them gravity and collision so that they can skip/bounce after hitting something solid.<br />
<br />
<br />
[[File:BqxWjUA(1).png|center]]<br />
<br />
<br />
Tweaking particle effects is slightly outside the scope of this tutorial, but feel free to download the source code for this mod and look at the values/options I've setup for yourself.<br />
<br />
There's also a great UE4 video that goes through particle effects in great detail, if you want to understand how they work: [https://www.youtube.com/watch?v=7hC_QT4GLiU&list=PLZlv_N0_O1gYDLyB3LVfjYIcbBe8NqR8t&index=4 Intro to Cascade: Creating a Sprite Emitter | 04 | v4.2 Tutorial Series | Unreal Engine]<br />
<br />
However, in order for your particle emitter to actually use the poop mesh, we have to copy the "MIC_HumanPoop" material, and enable "Used with Mesh Particles", like so:<br />
<br />
<br />
[[File:Qfrr2WF(1).png|center]]<br />
<br />
<br />
You'll also need to copy the "SM_HumanPoop", and apply this new material to it. I recommend keeping these files in an "Assets" folder within your mod, and renaming the files to include the mod name, such as "MIC_RocketPoops_HumanPoop_Particle" and "SM_RocketPoops_HumanPoop", so that they're easily searchable if you need to reference them later -- and you won't get them confused for the base-game versions.<br />
<br />
=== "Rocket Poops" looping Poop Sound Cue ===<br />
<br />
Next, we need sound. As you would expect, you can reuse the vanilla "Flamethrower_Start_Cue" loop without any alterations.<br />
<br />
However, the base-game "Poop_Cue" only plays a single poop sound, and it's highly irritating to play that too frequently. So let's setup a custom looping sound cue.<br />
<br />
Copy the "Poop_Cue" to your assets folder, and add the following nodes (feel free to tweak as-needed):<br />
<br />
<br />
[[File:RUUoQUG(1).png|center]]<br />
<br />
<br />
For my version, I modulated the pitch down to avoid the loud/squeaky noises, and I put a delay of 0.5 to 1.0 seconds to prevent the effect from being overly annoying.<br />
<br />
And that's it! You've now got all the assets you'll need to do this little mod.<br />
<br />
<br />
== Add the "Rocket Poop" Buff Components ==<br />
<br />
Now that we have our custom assets and the Rotten Steak item setup, we need to add a few base components to the “Rocket Poop” buff, which the logic can reference later. Head back to your “PrimalBuff_RocketPoop” blueprint and open it up. Once open, click on the “Components” tab on the top right.<br />
<br />
Here, you'll need to add a particle emitter and two audio emitters (for the flames sounds, and the poop sounds), like so:<br />
<br />
<br />
[[File:BytiVIO(1).png|center]]<br />
<br />
<br />
Note: It's important that all three of these components be changed so that "Auto Activate" is left unchecked. This means that they won't be playing when the buff first loads, leaving us the freedom to manually activate/deactivate them when the player presses the "poop key" later on.<br />
<br />
== Add the “Rocket Poop” Buff Graph Logic ==<br />
Next, click on the "Graph" tab of your buff and pull up the Event Graph.<br />
<br />
The very first thing we’ll need to do is setup our Event Begin Play ("EBP") event, to handle some standard buff start-up house-keeping for us. I've divided the code up into a sequence of four sections of code, so that the nodes are more readable, and so that each piece will be easier to discuss.<br />
<br />
Note: The small delay after Event Begin Play is a common method used to help ensure that everything has been initialized correctly and that the logic is ready to execute. Without the delay after Event Begin Play, players will often encounter odd bugs which are hard to troubleshoot.<br />
<br />
<br />
[[File:Helhpmf(1).png|center]]<br />
<br />
<br />
=== Event Begin Play: Re-Assign Owner===<br />
<br />
"Buff" actors have a long and sordid history of detaching from their target whenever the user logs out. So as a best practice, we'll re-assign the owner when the buff starts up.<br />
<br />
<br />
[[File:681oHuD(1).png|center]]<br />
<br />
<br />
<br />
=== Event Begin Play: Enable Keyboard Input===<br />
<br />
By default, the buff actor will ignore input events (such as keypresses). In order to intercept and utilize the "poop key" event, we'll need to enable the client-side input (and verify that it's valid).<br />
<br />
<br />
[[File:SBqDdmQ(1).png|center]]<br />
<br />
<br />
<br />
=== Event Begin Play: Attach to Poop Socket===<br />
<br />
For the sake of ease-of-use, and because it makes me laugh, let's go ahead and attach this "RocketPoop" buff to the player's PoopSocket on the player's skeletal mesh. This is the reference location that the game uses when spawning turds, so we might as well use it too. This allows all future effects/emitters follow the location of the player's butt as it's moving, making life easy for everybody.<br />
<br />
<br />
[[File:LIZKUoA(1).png|center]]<br />
<br />
<br />
<br />
=== Event Begin Play: Setup Variables===<br />
<br />
When working with large graphs, it's often desirable to store frequently used references in variables so that you can easily use them again later, without running messy wires all over your graph.<br />
<br />
In this case, we're going to setup the Owner Actor (the player), the Primal Character (the player, avoids future casts), the Pawn (the player's pawn), and the pawns Movement Component.<br />
<br />
<br />
[[File:HYGS7Bo(1).png|center]]<br />
<br />
<br />
<br />
Huzzah! You're done with the Event Begin Play logic. Now to get into the real fun!<br />
<br />
<br />
===Capturing the "Poop Key" press and release===<br />
<br />
When working in the Unreal Engine, it’s critical to always pay attention to where your code is being executed – either on the local client, or on the server. You will also have to pay close attention to data replication, which handles the transmission of data from the server to the clients.<br />
<br />
In our case, we're using "Input Action" events (keypresses) -- and these input actions always execute on the client. In order to execute the buff logic, these keypresses must be transmitted to the server. To do that, create two custom server-side events: One to start pooping, and one to stop. We will also set the "Pooping Active" boolean client-side as well. (This variable is never replicated, because it doesn't need to. The server will update it's own copy of this variable as well, as we'll see later.)<br />
<br />
Create custom events called “ROS_EnableRocketPooping” and “ROS_DisableRocketPooping”, with the following settings:<br />
<br />
<br />
[[File:HtNuCVQ(1).png|center]]<br />
<br />
<br />
Note: Many mod authors choose to write "ROS" (Run on Server), "ROC" (Run on Client), or "MULTICAST" at the beginning of their custom functions, to remind themselves where the code is being executed, and to make the nodes easier to read/understand.<br />
<br />
Note: It’s important to setup this input action to “consume” the input, which will prevent your character from also trying to poop the normal way, which would fill your screen with lots of “not ready to poop yet” messages.<br />
<br />
These ROS events will set the "Pooping Active" boolean on the server-side, and spawn a multicast emitter that will spawn the particle emitters and play the desired sounds. This is multicast so that all players in range will experience the event (see the stream of fire/poop, and hear the pooping sounds).<br />
<br />
Note: Particle emitters and sounds do not need to be "played" by the server, since there's no human at the server to experience them. If you're having trouble interacting with your emitters, remember that the server needs to spawn one for each of the clients in order for everyone to see it.<br />
<br />
<br />
[[File:RKHEwRN(1).png|center]]<br />
<br />
=== Toggle Sounds/Particles on the Clients ===<br />
<br />
In order to activate/deactivate the sounds and particle effects we need on the clients, we'll use our "Set Spawn Activation" multicast event. This event will also fade out the audio over 0.25 seconds, which will make the audio feel much more natural compared to a sharp cutoff.<br />
<br />
<br />
[[File:FWUqDSO(1).png|center]]<br />
<br />
<br />
Note: For similar datatypes you can pass multiple references to the same node. For example, the "Activate" node can accept references from 3 components, without needing 3 separate "Activate" nodes.<br />
<br />
<br />
<br />
<br />
=== Event Buff Tick Client: Capture User Input, Send to Server ===<br />
<br />
Rocketing yourself straight up is all well and good, but to really be fun/useful, players need the ability to steer while they're in the air. To do this, we need to capture the player's input, and transmit it to the server where it can be used later, like so:<br />
<br />
<br />
[[File:8jeylKF(1).png|center]]<br />
<br />
<br />
Warning: "Event Tick" events can be very taxing on your server. More on that in the next section.<br />
<br />
<br />
=== Event Buff Tick Server ===<br />
<br />
Next, we need to setup the "Event Buff Tick Server" to handle the physics of rocketing a player off the ground (without putting them into orbit).<br />
<br />
But first, a huge word of caution: "Tick" events execute every single "frame" of the server's execution, so if you put heavy logic inside this function (or if there are many copies of this logic being run in multiple places -- such as 50 or 60 players all with the same buff), it will have a significant effect on your server's performance. Imagine asking your computer to do a bunch of extra math and networking between every frame in a movie that you're watching -- if you pile on too many calculations, you'll eventually see your video stutter. The same is true with ARK servers -- if you ask too much, you'll get lag/slowdowns.<br />
<br />
Having said that, we'll be using the "Tick" event because the "Add Force" function requires it to run smoothly, and there isn't much in the way of heavy logic behind it.<br />
<br />
=== Event Buff Tick Server: Speed Suppression ===<br />
<br />
One of the first things we'll do is store the "Delta Time" (the time since the last tick) into a variable so we can access it later. Next, we'll check to see if the "Rocket Poop" is activated.<br />
<br />
If the "Rocket Poop" is off, then we need to apply a dampening force to slow the player's forward progress, otherwise players can sail across the map in weird ways, and it hampers control.<br />
<br />
<br />
[[File:JJENnXw(1).png|center]]<br />
<br />
<br />
As you can see, the first thing we do is calculate the magnitude of the X,Y velocity vectors, which gives us an accurate measure of how fast a player is traversing across the landscape.<br />
<br />
If the player is currently falling (but not boosting), and their speed is above a certain threshold, the dampening will kick in.<br />
<br />
To achieve a slowing effect, we use the "Add Force" node to apply a force in the oppose direction that we're going -- sort've like a strong head-wind pushing us backwards. Once we've slowed below the threshold, the effect will end.<br />
<br />
<br />
<br />
=== Event Buff Tick Server: Calculating the Main Thruster ===<br />
<br />
Now we're into the nitty gritty. =)<br />
<br />
<br />
[[File:5xM35Yb(1).png|center]]<br />
<br />
<br />
If the "Rocket Poop" thruster is on, the we need a way to scale an appropriate force vector (direction and magnitude) for our thrust, and apply it to the player. (See above)<br />
<br />
To do this, we're going to treat the X,Y axes separately from the Z axis. For the X,Y axes, we will multiply by the X,Y of our user input, to decide which way the player is wishing to move. This will allow for some mid-air control. Feel free to scale these values however you want, to gain more/less control.<br />
<br />
Next, we need to handle the Z axis. For this, we have a static force of 300,000. However, this makes it difficult to stop a fall, so in the interest of fun/usability, let's add additional thrust based on the current fall speed of the character. We do this by multiplying the players downward velocity by -300.0, and adding that to our static 300,000. This allows for a quick stop when falling from great heights.<br />
<br />
After we've got our desired thrust vector, we need to limit it's output to something reasonable (if the player isn't currently walking). The problem is that force can be cumulative, meaning that you'll keep gaining speed every time the force is re-added, and this can result in a player being rocketed off the map.<br />
<br />
To help with that, I've created a "Velocity Clamp" function, which compares the players current velocity, and limits their thrust vector if they're going too fast, like so:<br />
<br />
<br />
[[File:MOCVoNk(1).png|center]]<br />
<br />
<br />
As you can see, the horizontal thrust components are both clamped if either of them is higher than 600, and the main thruster (Z component) is limited to a upwards speed of 1200. For fun, you can tweak these clamps if you don't like the default handling.<br />
<br />
=== Event Buff Tick Server: Apply Thrust, Consume Food/Health ===<br />
<br />
Now that we know which way we're going, the only thing left to do is apply the force to the player, and consume food/health as fuel.<br />
<br />
<br />
[[File:It8QMu7(1).png|center]]<br />
<br />
<br />
As you can see, the "Consume Food" function takes in the "Delta Seconds" float variable -- which allows us to remove food/health based on how many seconds the player boosted during this tick.<br />
<br />
The "Consume Food" function:<br />
<br />
<br />
[[File:IPJhCua(1).png|center]]<br />
<br />
<br />
And that's it! You've successfully built "Rocket Poop" logic. Your parents will be so proud.<br />
<br />
You now have a very silly “Rocket Poop” buff which can launch you high into the sky, with nothing but yesterday’s digested meatloaf as fuel.<br />
<br />
If you have any questions, feel free to message me on the ARK Modding Discord chat (my username is "RedDwarf"), or on the “Rocket Poop” workshop page. I will be uploading this as a standalone open-source mod, so that you can download the source and play with it as an example.<br />
<br />
Happy modding!<br />
<br />
-- RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Rocket_Poop_(buff)&diff=1570Tutorial: Rocket Poop (buff)2018-04-21T04:23:18Z<p>RedDwarf: /* Event Buff Tick Server: Apply Thrust, Consume Food/Health */</p>
<hr />
<div>[[Category:Tutorials]]<br />
[[Category:Buffs]]<br />
<br />
== Introduction ==<br />
<br />
Greetings, fellow modders!<br />
<br />
The theme of this modding competition was to create a “wacky, ridiculous buff.” Finally, my time has come!<br />
I decided that what I really missed about ARK was the ability to do the famous cartoony “double-jump” that Mario and many other video game characters have been able to do for decades.<br />
So, since real physics have already been thrown out the window, the real question became “How do I make this fit in the ARK universe?” – and the answer was simple: Add poop.<br />
Thus, the “Rocket Poop” buff was born!<br />
When this buff is enabled, pressing the poop key will rocket-propel a stream of poop out of your butt so fast, that you’ll take to the air in what can only be described as the world's first biological jetpack. Be warned! This will quickly empty your stomach/bowels and cause you to starve if used too much.<br />
<br />
== The Plan! ==<br />
<br />
* Make the “Rocket Poops” buff, with the following effects, when the player pushes the poop key:<br />
** Capture the player’s “poop key” command.<br />
*** Keep boosting if the player holds the "poop key" down.<br />
** Enable a flaming poop particle emitter at the players butt (PlayerPawn’s “PoopSocket”).<br />
** Play a pooping/flaming sound.<br />
** Propel player upwards.<br />
*** Make sure they don’t go too fast.<br />
*** Allow player to navigate in mid-air, by factoring in the player’s input.<br />
** Reduce the player’s food stat (pooping requires food).<br />
*** Subtract from the players health if they continue to poop on an empty stomach.<br />
* Make a consumable item called “Rotten Meat”, which give the “Rocket Poops” buff when eaten.<br />
<br />
== Setting up the “Rocket Poop” Buff ==<br />
<br />
Create a blueprint called “PrimalBuff_RocketPoop” which is parented to “Primal Buff”.<br />
<br />
Next, open the “PrimalBuff_RocketPoop” and click on the “Defaults” tab at the top, and change the following properties:<br />
<br />
<br />
[[File:CxLJ1oP(1).png|center]]<br />
<br />
<br />
These settings will allow the buff to last for 5 minutes (300 seconds), and also detail when/how the buff can be activated. The name, description, icon, and duration can be easily changed if you want to modify the look/feel of the item. For example, you may want to make this item look like a potion, or a magic curse, etc. It also has flags that prevent it from being used on a dino, and it is treated as a disease. And most importantly, the "Use Buff Tick Server" and "Use Buff Tick Client" have been checked -- more on that later.<br />
<br />
Note: We will be revisiting this buff to add all the remaining logic and functionality. <br />
<br />
But first, we need to create a consumable that will allow players to activate our buff. This will also be very helpful when testing the buff in the devkit, because this consumable can be spawned and used. For even easier testing, add the buff to the “Additional Default Buffs” array in your mod’s PrimalGameData file, and the buff will automatically appear every time you start the PIE (“Play in Editor”).<br />
<br />
== Setting up the “Rotten Steak” Consumable ==<br />
<br />
To do this, create a new blueprint called “PrimalItemConsumableGeneric_RottenSteak” with “Primal Item Consumable Generic” as its parent.<br />
<br />
Open your new “Rotten Steak” primal item and modify the following values to customize it to your needs:<br />
<br />
<br />
[[File:TBHQXWr(1).png|center]]<br />
<br />
<br />
Again, feel free to change the icons or descriptions to whatever you’d like. I made the recipe require 1x spoiled meat, just because that was an easy resource, and it fit thematically.<br />
<br />
Your Rotten Steak is done! Now you can spawn it in and use it to test your buff.<br />
<br />
Example spawn code (your path/names will probably vary): <br />
Admincheat giveitem “Blueprint'/Game/Mods/RocketPoop/Consumables/RottenSteak/PrimalItemConsumableGeneric_RottenSteak.PrimalItemConsumableGeneric_RottenSteak'” 20 0 0<br />
<br />
== Setup Assets ==<br />
<br />
Before we get too far into our graph code, we need to setup a few assets that our mod will need.<br />
<br />
<br />
=== "Rocket Poops" particle emitter ===<br />
<br />
For this emitter, I started with a copy of the flame-thrower's main flame-thrower effect, called "Flamethrower_PS".<br />
<br />
From this base, I disabled the larger flames and smoke, and angled the remaining particles 180 to point them downwards (since our thrust is always shooting down).<br />
<br />
I then added a new mesh emitter, which will spawn human poops, shoot them downwards, and gives them gravity and collision so that they can skip/bounce after hitting something solid.<br />
<br />
<br />
[[File:BqxWjUA(1).png|center]]<br />
<br />
<br />
Tweaking particle effects is slightly outside the scope of this tutorial, but feel free to download the source code for this mod and look at the values/options I've setup for yourself.<br />
<br />
There's also a great UE4 video that goes through particle effects in great detail, if you want to understand how they work: [https://www.youtube.com/watch?v=7hC_QT4GLiU&list=PLZlv_N0_O1gYDLyB3LVfjYIcbBe8NqR8t&index=4 Intro to Cascade: Creating a Sprite Emitter | 04 | v4.2 Tutorial Series | Unreal Engine]<br />
<br />
However, in order for your particle emitter to actually use the poop mesh, we have to copy the "MIC_HumanPoop" material, and enable "Used with Mesh Particles", like so:<br />
<br />
<br />
[[File:Qfrr2WF(1).png|center]]<br />
<br />
<br />
You'll also need to copy the "SM_HumanPoop", and apply this new material to it. I recommend keeping these files in an "Assets" folder within your mod, and renaming the files to include the mod name, such as "MIC_RocketPoops_HumanPoop_Particle" and "SM_RocketPoops_HumanPoop", so that they're easily searchable if you need to reference them later -- and you won't get them confused for the base-game versions.<br />
<br />
=== "Rocket Poops" looping Poop Sound Cue ===<br />
<br />
Next, we need sound. As you would expect, you can reuse the vanilla "Flamethrower_Start_Cue" loop without any alterations.<br />
<br />
However, the base-game "Poop_Cue" only plays a single poop sound, and it's highly irritating to play that too frequently. So let's setup a custom looping sound cue.<br />
<br />
Copy the "Poop_Cue" to your assets folder, and add the following nodes (feel free to tweak as-needed):<br />
<br />
<br />
[[File:RUUoQUG(1).png|center]]<br />
<br />
<br />
For my version, I modulated the pitch down to avoid the loud/squeaky noises, and I put a delay of 0.5 to 1.0 seconds to prevent the effect from being overly annoying.<br />
<br />
And that's it! You've now got all the assets you'll need to do this little mod.<br />
<br />
<br />
== Add the "Rocket Poop" Buff Components ==<br />
<br />
Now that we have our custom assets and the Rotten Steak item setup, we need to add a few base components to the “Rocket Poop” buff, which the logic can reference later. Head back to your “PrimalBuff_RocketPoop” blueprint and open it up. Once open, click on the “Components” tab on the top right.<br />
<br />
Here, you'll need to add a particle emitter and two audio emitters (for the flames sounds, and the poop sounds), like so:<br />
<br />
<br />
[[File:BytiVIO(1).png|center]]<br />
<br />
<br />
Note: It's important that all three of these components be changed so that "Auto Activate" is left unchecked. This means that they won't be playing when the buff first loads, leaving us the freedom to manually activate/deactivate them when the player presses the "poop key" later on.<br />
<br />
== Add the “Rocket Poop” Buff Graph Logic ==<br />
Next, click on the "Graph" tab of your buff and pull up the Event Graph.<br />
<br />
The very first thing we’ll need to do is setup our Event Begin Play ("EBP") event, to handle some standard buff start-up house-keeping for us. I've divided the code up into a sequence of four sections of code, so that the nodes are more readable, and so that each piece will be easier to discuss.<br />
<br />
Note: The small delay after Event Begin Play is a common method used to help ensure that everything has been initialized correctly and that the logic is ready to execute. Without the delay after Event Begin Play, players will often encounter odd bugs which are hard to troubleshoot.<br />
<br />
<br />
[[File:Helhpmf(1).png|center]]<br />
<br />
<br />
=== Event Begin Play: Re-Assign Owner===<br />
<br />
"Buff" actors have a long and sordid history of detaching from their target whenever the user logs out. So as a best practice, we'll re-assign the owner when the buff starts up.<br />
<br />
<br />
[[File:681oHuD(1).png|center]]<br />
<br />
<br />
<br />
=== Event Begin Play: Enable Keyboard Input===<br />
<br />
By default, the buff actor will ignore input events (such as keypresses). In order to intercept and utilize the "poop key" event, we'll need to enable the client-side input (and verify that it's valid).<br />
<br />
<br />
[[File:SBqDdmQ(1).png|center]]<br />
<br />
<br />
<br />
=== Event Begin Play: Attach to Poop Socket===<br />
<br />
For the sake of ease-of-use, and because it makes me laugh, let's go ahead and attach this "RocketPoop" buff to the player's PoopSocket on the player's skeletal mesh. This is the reference location that the game uses when spawning turds, so we might as well use it too. This allows all future effects/emitters follow the location of the player's butt as it's moving, making life easy for everybody.<br />
<br />
<br />
[[File:LIZKUoA(1).png|center]]<br />
<br />
<br />
<br />
=== Event Begin Play: Setup Variables===<br />
<br />
When working with large graphs, it's often desirable to store frequently used references in variables so that you can easily use them again later, without running messy wires all over your graph.<br />
<br />
In this case, we're going to setup the Owner Actor (the player), the Primal Character (the player, avoids future casts), the Pawn (the player's pawn), and the pawns Movement Component.<br />
<br />
<br />
[[File:HYGS7Bo(1).png|center]]<br />
<br />
<br />
<br />
Huzzah! You're done with the Event Begin Play logic. Now to get into the real fun!<br />
<br />
<br />
===Capturing the "Poop Key" press and release===<br />
<br />
When working in the Unreal Engine, it’s critical to always pay attention to where your code is being executed – either on the local client, or on the server. You will also have to pay close attention to data replication, which handles the transmission of data from the server to the clients.<br />
<br />
In our case, we're using "Input Action" events (keypresses) -- and these input actions always execute on the client. In order to execute the buff logic, these keypresses must be transmitted to the server. To do that, create two custom server-side events: One to start pooping, and one to stop. We will also set the "Pooping Active" boolean client-side as well. (This variable is never replicated, because it doesn't need to. The server will update it's own copy of this variable as well, as we'll see later.)<br />
<br />
Create custom events called “ROS_EnableRocketPooping” and “ROS_DisableRocketPooping”, with the following settings:<br />
<br />
<br />
[[File:HtNuCVQ(1).png|center]]<br />
<br />
<br />
Note: Many mod authors choose to write "ROS" (Run on Server), "ROC" (Run on Client), or "MULTICAST" at the beginning of their custom functions, to remind themselves where the code is being executed, and to make the nodes easier to read/understand.<br />
<br />
Note: It’s important to setup this input action to “consume” the input, which will prevent your character from also trying to poop the normal way, which would fill your screen with lots of “not ready to poop yet” messages.<br />
<br />
These ROS events will set the "Pooping Active" boolean on the server-side, and spawn a multicast emitter that will spawn the particle emitters and play the desired sounds. This is multicast so that all players in range will experience the event (see the stream of fire/poop, and hear the pooping sounds).<br />
<br />
Note: Particle emitters and sounds do not need to be "played" by the server, since there's no human at the server to experience them. If you're having trouble interacting with your emitters, remember that the server needs to spawn one for each of the clients in order for everyone to see it.<br />
<br />
<br />
[[File:RKHEwRN(1).png|center]]<br />
<br />
=== Toggle Sounds/Particles on the Clients ===<br />
<br />
In order to activate/deactivate the sounds and particle effects we need on the clients, we'll use our "Set Spawn Activation" multicast event. This event will also fade out the audio over 0.25 seconds, which will make the audio feel much more natural compared to a sharp cutoff.<br />
<br />
<br />
[[File:FWUqDSO(1).png|center]]<br />
<br />
<br />
Note: For similar datatypes you can pass multiple references to the same node. For example, the "Activate" node can accept references from 3 components, without needing 3 separate "Activate" nodes.<br />
<br />
<br />
<br />
<br />
=== Event Buff Tick Client: Capture User Input, Send to Server ===<br />
<br />
Rocketing yourself straight up is all well and good, but to really be fun/useful, players need the ability to steer while they're in the air. To do this, we need to capture the player's input, and transmit it to the server where it can be used later, like so:<br />
<br />
<br />
[[File:8jeylKF(1).png|center]]<br />
<br />
<br />
Warning: "Event Tick" events can be very taxing on your server. More on that in the next section.<br />
<br />
<br />
=== Event Buff Tick Server ===<br />
<br />
Next, we need to setup the "Event Buff Tick Server" to handle the physics of rocketing a player off the ground (without putting them into orbit).<br />
<br />
But first, a huge word of caution: "Tick" events execute every single "frame" of the server's execution, so if you put heavy logic inside this function (or if there are many copies of this logic being run in multiple places -- such as 50 or 60 players all with the same buff), it will have a significant effect on your server's performance. Imagine asking your computer to do a bunch of extra math and networking between every frame in a movie that you're watching -- if you pile on too many calculations, you'll eventually see your video stutter. The same is true with ARK servers -- if you ask too much, you'll get lag/slowdowns.<br />
<br />
Having said that, we'll be using the "Tick" event because the "Add Force" function requires it to run smoothly, and there isn't much in the way of heavy logic behind it.<br />
<br />
=== Event Buff Tick Server: Speed Suppression ===<br />
<br />
One of the first things we'll do is store the "Delta Time" (the time since the last tick) into a variable so we can access it later. Next, we'll check to see if the "Rocket Poop" is activated.<br />
<br />
If the "Rocket Poop" is off, then we need to apply a dampening force to slow the player's forward progress, otherwise players can sail across the map in weird ways, and it hampers control.<br />
<br />
<br />
[[File:JJENnXw(1).png|center]]<br />
<br />
<br />
As you can see, the first thing we do is calculate the magnitude of the X,Y velocity vectors, which gives us an accurate measure of how fast a player is traversing across the landscape.<br />
<br />
If the player is currently falling (but not boosting), and their speed is above a certain threshold, the dampening will kick in.<br />
<br />
To achieve a slowing effect, we use the "Add Force" node to apply a force in the oppose direction that we're going -- sort've like a strong head-wind pushing us backwards. Once we've slowed below the threshold, the effect will end.<br />
<br />
<br />
<br />
=== Event Buff Tick Server: Calculating the Main Thruster ===<br />
<br />
Now we're into the nitty gritty. =)<br />
<br />
<br />
[[File:5xM35Yb(1).png|center]]<br />
<br />
<br />
If the "Rocket Poop" thruster is on, the we need a way to scale an appropriate force vector (direction and magnitude) for our thrust, and apply it to the player. (See above)<br />
<br />
To do this, we're going to treat the X,Y axes separately from the Z axis. For the X,Y axes, we will multiply by the X,Y of our user input, to decide which way the player is wishing to move. This will allow for some mid-air control. Feel free to scale these values however you want, to gain more/less control.<br />
<br />
Next, we need to handle the Z axis. For this, we have a static force of 300,000. However, this makes it difficult to stop a fall, so in the interest of fun/usability, let's add additional thrust based on the current fall speed of the character. We do this by multiplying the players downward velocity by -300.0, and adding that to our static 300,000. This allows for a quick stop when falling from great heights.<br />
<br />
After we've got our desired thrust vector, we need to limit it's output to something reasonable (if the player isn't currently walking). The problem is that force can be cumulative, meaning that you'll keep gaining speed every time the force is re-added, and this can result in a player being rocketed off the map.<br />
<br />
To help with that, I've created a "Velocity Clamp" function, which compares the players current velocity, and limits their thrust vector if they're going too fast, like so:<br />
<br />
<br />
[[File:MOCVoNk(1).png|center]]<br />
<br />
<br />
As you can see, the horizontal thrust components are both clamped if either of them is higher than 600, and the main thruster (Z component) is limited to a upwards speed of 1200. For fun, you can tweak these clamps if you don't like the default handling.<br />
<br />
=== Event Buff Tick Server: Apply Thrust, Consume Food/Health ===<br />
<br />
Now that we know which way we're going, the only thing left to do is apply the force to the player, and consume food/health as fuel.<br />
<br />
<br />
[[File:It8QMu7(1).png|center]]<br />
<br />
<br />
As you can see, the "Consume Food" function takes in the "Delta Seconds" float variable -- which allows us to remove food/health based on how many seconds the player boosted during this tick.<br />
<br />
The "Consume Food" function:<br />
<br />
<br />
[[File:IPJhCua(1).png|center]]<br />
<br />
<br />
And that's it! You've successfully built "Rocket Poop" logic. Your parents will be so proud.<br />
<br />
You now have a very silly “Rocket Poop” buff which can launch you high into the sky, with nothing but yesterday’s digested meatloaf as fuel.<br />
<br />
If you have any questions, feel free to message me on the ARK Modding Discord chat (my username is "RedDwarf"), or on the “Rocket Poop” workshop page. I will be uploading this as a standalone open-source mod, so that you can download the source and play with it as an example.<br />
<br />
Happy modding!<br />
<br />
--RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Rocket_Poop_(buff)&diff=1569Tutorial: Rocket Poop (buff)2018-04-21T04:21:20Z<p>RedDwarf: /* Capturing the "Poop Key" press and release */</p>
<hr />
<div>[[Category:Tutorials]]<br />
[[Category:Buffs]]<br />
<br />
== Introduction ==<br />
<br />
Greetings, fellow modders!<br />
<br />
The theme of this modding competition was to create a “wacky, ridiculous buff.” Finally, my time has come!<br />
I decided that what I really missed about ARK was the ability to do the famous cartoony “double-jump” that Mario and many other video game characters have been able to do for decades.<br />
So, since real physics have already been thrown out the window, the real question became “How do I make this fit in the ARK universe?” – and the answer was simple: Add poop.<br />
Thus, the “Rocket Poop” buff was born!<br />
When this buff is enabled, pressing the poop key will rocket-propel a stream of poop out of your butt so fast, that you’ll take to the air in what can only be described as the world's first biological jetpack. Be warned! This will quickly empty your stomach/bowels and cause you to starve if used too much.<br />
<br />
== The Plan! ==<br />
<br />
* Make the “Rocket Poops” buff, with the following effects, when the player pushes the poop key:<br />
** Capture the player’s “poop key” command.<br />
*** Keep boosting if the player holds the "poop key" down.<br />
** Enable a flaming poop particle emitter at the players butt (PlayerPawn’s “PoopSocket”).<br />
** Play a pooping/flaming sound.<br />
** Propel player upwards.<br />
*** Make sure they don’t go too fast.<br />
*** Allow player to navigate in mid-air, by factoring in the player’s input.<br />
** Reduce the player’s food stat (pooping requires food).<br />
*** Subtract from the players health if they continue to poop on an empty stomach.<br />
* Make a consumable item called “Rotten Meat”, which give the “Rocket Poops” buff when eaten.<br />
<br />
== Setting up the “Rocket Poop” Buff ==<br />
<br />
Create a blueprint called “PrimalBuff_RocketPoop” which is parented to “Primal Buff”.<br />
<br />
Next, open the “PrimalBuff_RocketPoop” and click on the “Defaults” tab at the top, and change the following properties:<br />
<br />
<br />
[[File:CxLJ1oP(1).png|center]]<br />
<br />
<br />
These settings will allow the buff to last for 5 minutes (300 seconds), and also detail when/how the buff can be activated. The name, description, icon, and duration can be easily changed if you want to modify the look/feel of the item. For example, you may want to make this item look like a potion, or a magic curse, etc. It also has flags that prevent it from being used on a dino, and it is treated as a disease. And most importantly, the "Use Buff Tick Server" and "Use Buff Tick Client" have been checked -- more on that later.<br />
<br />
Note: We will be revisiting this buff to add all the remaining logic and functionality. <br />
<br />
But first, we need to create a consumable that will allow players to activate our buff. This will also be very helpful when testing the buff in the devkit, because this consumable can be spawned and used. For even easier testing, add the buff to the “Additional Default Buffs” array in your mod’s PrimalGameData file, and the buff will automatically appear every time you start the PIE (“Play in Editor”).<br />
<br />
== Setting up the “Rotten Steak” Consumable ==<br />
<br />
To do this, create a new blueprint called “PrimalItemConsumableGeneric_RottenSteak” with “Primal Item Consumable Generic” as its parent.<br />
<br />
Open your new “Rotten Steak” primal item and modify the following values to customize it to your needs:<br />
<br />
<br />
[[File:TBHQXWr(1).png|center]]<br />
<br />
<br />
Again, feel free to change the icons or descriptions to whatever you’d like. I made the recipe require 1x spoiled meat, just because that was an easy resource, and it fit thematically.<br />
<br />
Your Rotten Steak is done! Now you can spawn it in and use it to test your buff.<br />
<br />
Example spawn code (your path/names will probably vary): <br />
Admincheat giveitem “Blueprint'/Game/Mods/RocketPoop/Consumables/RottenSteak/PrimalItemConsumableGeneric_RottenSteak.PrimalItemConsumableGeneric_RottenSteak'” 20 0 0<br />
<br />
== Setup Assets ==<br />
<br />
Before we get too far into our graph code, we need to setup a few assets that our mod will need.<br />
<br />
<br />
=== "Rocket Poops" particle emitter ===<br />
<br />
For this emitter, I started with a copy of the flame-thrower's main flame-thrower effect, called "Flamethrower_PS".<br />
<br />
From this base, I disabled the larger flames and smoke, and angled the remaining particles 180 to point them downwards (since our thrust is always shooting down).<br />
<br />
I then added a new mesh emitter, which will spawn human poops, shoot them downwards, and gives them gravity and collision so that they can skip/bounce after hitting something solid.<br />
<br />
<br />
[[File:BqxWjUA(1).png|center]]<br />
<br />
<br />
Tweaking particle effects is slightly outside the scope of this tutorial, but feel free to download the source code for this mod and look at the values/options I've setup for yourself.<br />
<br />
There's also a great UE4 video that goes through particle effects in great detail, if you want to understand how they work: [https://www.youtube.com/watch?v=7hC_QT4GLiU&list=PLZlv_N0_O1gYDLyB3LVfjYIcbBe8NqR8t&index=4 Intro to Cascade: Creating a Sprite Emitter | 04 | v4.2 Tutorial Series | Unreal Engine]<br />
<br />
However, in order for your particle emitter to actually use the poop mesh, we have to copy the "MIC_HumanPoop" material, and enable "Used with Mesh Particles", like so:<br />
<br />
<br />
[[File:Qfrr2WF(1).png|center]]<br />
<br />
<br />
You'll also need to copy the "SM_HumanPoop", and apply this new material to it. I recommend keeping these files in an "Assets" folder within your mod, and renaming the files to include the mod name, such as "MIC_RocketPoops_HumanPoop_Particle" and "SM_RocketPoops_HumanPoop", so that they're easily searchable if you need to reference them later -- and you won't get them confused for the base-game versions.<br />
<br />
=== "Rocket Poops" looping Poop Sound Cue ===<br />
<br />
Next, we need sound. As you would expect, you can reuse the vanilla "Flamethrower_Start_Cue" loop without any alterations.<br />
<br />
However, the base-game "Poop_Cue" only plays a single poop sound, and it's highly irritating to play that too frequently. So let's setup a custom looping sound cue.<br />
<br />
Copy the "Poop_Cue" to your assets folder, and add the following nodes (feel free to tweak as-needed):<br />
<br />
<br />
[[File:RUUoQUG(1).png|center]]<br />
<br />
<br />
For my version, I modulated the pitch down to avoid the loud/squeaky noises, and I put a delay of 0.5 to 1.0 seconds to prevent the effect from being overly annoying.<br />
<br />
And that's it! You've now got all the assets you'll need to do this little mod.<br />
<br />
<br />
== Add the "Rocket Poop" Buff Components ==<br />
<br />
Now that we have our custom assets and the Rotten Steak item setup, we need to add a few base components to the “Rocket Poop” buff, which the logic can reference later. Head back to your “PrimalBuff_RocketPoop” blueprint and open it up. Once open, click on the “Components” tab on the top right.<br />
<br />
Here, you'll need to add a particle emitter and two audio emitters (for the flames sounds, and the poop sounds), like so:<br />
<br />
<br />
[[File:BytiVIO(1).png|center]]<br />
<br />
<br />
Note: It's important that all three of these components be changed so that "Auto Activate" is left unchecked. This means that they won't be playing when the buff first loads, leaving us the freedom to manually activate/deactivate them when the player presses the "poop key" later on.<br />
<br />
== Add the “Rocket Poop” Buff Graph Logic ==<br />
Next, click on the "Graph" tab of your buff and pull up the Event Graph.<br />
<br />
The very first thing we’ll need to do is setup our Event Begin Play ("EBP") event, to handle some standard buff start-up house-keeping for us. I've divided the code up into a sequence of four sections of code, so that the nodes are more readable, and so that each piece will be easier to discuss.<br />
<br />
Note: The small delay after Event Begin Play is a common method used to help ensure that everything has been initialized correctly and that the logic is ready to execute. Without the delay after Event Begin Play, players will often encounter odd bugs which are hard to troubleshoot.<br />
<br />
<br />
[[File:Helhpmf(1).png|center]]<br />
<br />
<br />
=== Event Begin Play: Re-Assign Owner===<br />
<br />
"Buff" actors have a long and sordid history of detaching from their target whenever the user logs out. So as a best practice, we'll re-assign the owner when the buff starts up.<br />
<br />
<br />
[[File:681oHuD(1).png|center]]<br />
<br />
<br />
<br />
=== Event Begin Play: Enable Keyboard Input===<br />
<br />
By default, the buff actor will ignore input events (such as keypresses). In order to intercept and utilize the "poop key" event, we'll need to enable the client-side input (and verify that it's valid).<br />
<br />
<br />
[[File:SBqDdmQ(1).png|center]]<br />
<br />
<br />
<br />
=== Event Begin Play: Attach to Poop Socket===<br />
<br />
For the sake of ease-of-use, and because it makes me laugh, let's go ahead and attach this "RocketPoop" buff to the player's PoopSocket on the player's skeletal mesh. This is the reference location that the game uses when spawning turds, so we might as well use it too. This allows all future effects/emitters follow the location of the player's butt as it's moving, making life easy for everybody.<br />
<br />
<br />
[[File:LIZKUoA(1).png|center]]<br />
<br />
<br />
<br />
=== Event Begin Play: Setup Variables===<br />
<br />
When working with large graphs, it's often desirable to store frequently used references in variables so that you can easily use them again later, without running messy wires all over your graph.<br />
<br />
In this case, we're going to setup the Owner Actor (the player), the Primal Character (the player, avoids future casts), the Pawn (the player's pawn), and the pawns Movement Component.<br />
<br />
<br />
[[File:HYGS7Bo(1).png|center]]<br />
<br />
<br />
<br />
Huzzah! You're done with the Event Begin Play logic. Now to get into the real fun!<br />
<br />
<br />
===Capturing the "Poop Key" press and release===<br />
<br />
When working in the Unreal Engine, it’s critical to always pay attention to where your code is being executed – either on the local client, or on the server. You will also have to pay close attention to data replication, which handles the transmission of data from the server to the clients.<br />
<br />
In our case, we're using "Input Action" events (keypresses) -- and these input actions always execute on the client. In order to execute the buff logic, these keypresses must be transmitted to the server. To do that, create two custom server-side events: One to start pooping, and one to stop. We will also set the "Pooping Active" boolean client-side as well. (This variable is never replicated, because it doesn't need to. The server will update it's own copy of this variable as well, as we'll see later.)<br />
<br />
Create custom events called “ROS_EnableRocketPooping” and “ROS_DisableRocketPooping”, with the following settings:<br />
<br />
<br />
[[File:HtNuCVQ(1).png|center]]<br />
<br />
<br />
Note: Many mod authors choose to write "ROS" (Run on Server), "ROC" (Run on Client), or "MULTICAST" at the beginning of their custom functions, to remind themselves where the code is being executed, and to make the nodes easier to read/understand.<br />
<br />
Note: It’s important to setup this input action to “consume” the input, which will prevent your character from also trying to poop the normal way, which would fill your screen with lots of “not ready to poop yet” messages.<br />
<br />
These ROS events will set the "Pooping Active" boolean on the server-side, and spawn a multicast emitter that will spawn the particle emitters and play the desired sounds. This is multicast so that all players in range will experience the event (see the stream of fire/poop, and hear the pooping sounds).<br />
<br />
Note: Particle emitters and sounds do not need to be "played" by the server, since there's no human at the server to experience them. If you're having trouble interacting with your emitters, remember that the server needs to spawn one for each of the clients in order for everyone to see it.<br />
<br />
<br />
[[File:RKHEwRN(1).png|center]]<br />
<br />
=== Toggle Sounds/Particles on the Clients ===<br />
<br />
In order to activate/deactivate the sounds and particle effects we need on the clients, we'll use our "Set Spawn Activation" multicast event. This event will also fade out the audio over 0.25 seconds, which will make the audio feel much more natural compared to a sharp cutoff.<br />
<br />
<br />
[[File:FWUqDSO(1).png|center]]<br />
<br />
<br />
Note: For similar datatypes you can pass multiple references to the same node. For example, the "Activate" node can accept references from 3 components, without needing 3 separate "Activate" nodes.<br />
<br />
<br />
<br />
<br />
=== Event Buff Tick Client: Capture User Input, Send to Server ===<br />
<br />
Rocketing yourself straight up is all well and good, but to really be fun/useful, players need the ability to steer while they're in the air. To do this, we need to capture the player's input, and transmit it to the server where it can be used later, like so:<br />
<br />
<br />
[[File:8jeylKF(1).png|center]]<br />
<br />
<br />
Warning: "Event Tick" events can be very taxing on your server. More on that in the next section.<br />
<br />
<br />
=== Event Buff Tick Server ===<br />
<br />
Next, we need to setup the "Event Buff Tick Server" to handle the physics of rocketing a player off the ground (without putting them into orbit).<br />
<br />
But first, a huge word of caution: "Tick" events execute every single "frame" of the server's execution, so if you put heavy logic inside this function (or if there are many copies of this logic being run in multiple places -- such as 50 or 60 players all with the same buff), it will have a significant effect on your server's performance. Imagine asking your computer to do a bunch of extra math and networking between every frame in a movie that you're watching -- if you pile on too many calculations, you'll eventually see your video stutter. The same is true with ARK servers -- if you ask too much, you'll get lag/slowdowns.<br />
<br />
Having said that, we'll be using the "Tick" event because the "Add Force" function requires it to run smoothly, and there isn't much in the way of heavy logic behind it.<br />
<br />
=== Event Buff Tick Server: Speed Suppression ===<br />
<br />
One of the first things we'll do is store the "Delta Time" (the time since the last tick) into a variable so we can access it later. Next, we'll check to see if the "Rocket Poop" is activated.<br />
<br />
If the "Rocket Poop" is off, then we need to apply a dampening force to slow the player's forward progress, otherwise players can sail across the map in weird ways, and it hampers control.<br />
<br />
<br />
[[File:JJENnXw(1).png|center]]<br />
<br />
<br />
As you can see, the first thing we do is calculate the magnitude of the X,Y velocity vectors, which gives us an accurate measure of how fast a player is traversing across the landscape.<br />
<br />
If the player is currently falling (but not boosting), and their speed is above a certain threshold, the dampening will kick in.<br />
<br />
To achieve a slowing effect, we use the "Add Force" node to apply a force in the oppose direction that we're going -- sort've like a strong head-wind pushing us backwards. Once we've slowed below the threshold, the effect will end.<br />
<br />
<br />
<br />
=== Event Buff Tick Server: Calculating the Main Thruster ===<br />
<br />
Now we're into the nitty gritty. =)<br />
<br />
<br />
[[File:5xM35Yb(1).png|center]]<br />
<br />
<br />
If the "Rocket Poop" thruster is on, the we need a way to scale an appropriate force vector (direction and magnitude) for our thrust, and apply it to the player. (See above)<br />
<br />
To do this, we're going to treat the X,Y axes separately from the Z axis. For the X,Y axes, we will multiply by the X,Y of our user input, to decide which way the player is wishing to move. This will allow for some mid-air control. Feel free to scale these values however you want, to gain more/less control.<br />
<br />
Next, we need to handle the Z axis. For this, we have a static force of 300,000. However, this makes it difficult to stop a fall, so in the interest of fun/usability, let's add additional thrust based on the current fall speed of the character. We do this by multiplying the players downward velocity by -300.0, and adding that to our static 300,000. This allows for a quick stop when falling from great heights.<br />
<br />
After we've got our desired thrust vector, we need to limit it's output to something reasonable (if the player isn't currently walking). The problem is that force can be cumulative, meaning that you'll keep gaining speed every time the force is re-added, and this can result in a player being rocketed off the map.<br />
<br />
To help with that, I've created a "Velocity Clamp" function, which compares the players current velocity, and limits their thrust vector if they're going too fast, like so:<br />
<br />
<br />
[[File:MOCVoNk(1).png|center]]<br />
<br />
<br />
As you can see, the horizontal thrust components are both clamped if either of them is higher than 600, and the main thruster (Z component) is limited to a upwards speed of 1200. For fun, you can tweak these clamps if you don't like the default handling.<br />
<br />
=== Event Buff Tick Server: Apply Thrust, Consume Food/Health ===<br />
<br />
Now that we know which way we're going, the only thing left to do is apply the force to the player, and consume food/health as fuel.<br />
<br />
<br />
[[File:It8QMu7(1).png|center]]<br />
<br />
<br />
As you can see, the "Consume Food" function takes in the "Delta Seconds" float variable -- which allows us to remove food/health based on how many seconds the player boosted during this tick.<br />
<br />
The "Consume Food" function:<br />
<br />
<br />
[[File:IPJhCua(1).png|center]]<br />
<br />
<br />
And that's it! You've successfully built "Rocket Poop" logic. Your parents will be so proud.<br />
<br />
<br />
<br />
<br />
--------------------------------------------------------------------------- EDIT LINE<br />
<br />
<br />
<br />
<br />
[[File:FtduJki(1).png|center]]<br />
<br />
As you can see here, the looping timeline is setup to be 0.2 seconds long, with a “Attempt Poop” event at time 0.<br />
Next, create a function called “Rocket Pooping Function”, and add it to the graph as shown above. This is where most of our logic will reside. This function has been setup to accept the transform (location and rotation) of the player’s “PoopSocket” (a property of the players Skeletal Mesh), and a reference to the character, as “pass-by-reference” inputs (this will be important later).<br />
The “Rocket Pooping Function” will look like this, once we’re all said-and-done. Don’t let its size worry you, I’ll cover every piece in detail. I just want to give you the big picture before we move forward.<br />
<br />
[[File:PqggE90(1).png|center]]<br />
<br />
The first thing we’re going to do is setup reusable local variables which will hold the location of the poop socket, a reference to the primal character, the “Scaled User Input” (custom function, more on that later), and the poop impulse. Note: “Impulse” in Unreal Engine means an instantaneous force applied to an object once – like a bat hitting a baseball. We will be using custom vectors to determine the direction and strength of these impulses.<br />
<br />
[[File:RIK1tf5(1).png|center]]<br />
<br />
The “Get Pending Input Vector” gives us an indication of which direction the player wants to go (forwards, backwards, strafe left/right, etc). We can use this vector to allow the player some control while they’re in the air.<br />
The “Scale User Input” is a custom function, which scales the X and Y vectors, and creates an upward thrust vector for propelling the player. The function looks like this:<br />
<br />
[[File:YfZ0n7L(1).png|center]]<br />
<br />
Note: This is a “pure” function, so it does not need to be executed in the normal line of execution.<br />
Next, we need to calculate the impulse vector for the poop that we will be spawning in. This is done by adding the players current velocity with the velocity of the “Scaled User Input”, so that the poops rocket out of the players butt at the same speed that the player is moving – otherwise, the player would “out run” his own rocket poops, and that would look strange (or, even more strange than Rocket Poops).<br />
Once the vectors are added together, the final vector is passed through another custom function, called “Randomize Poop Impulse”. This function adds a small randomized amount of impulse on the X and Y axes, so that poops “splatter out” randomly, instead of just streaming out in a perfect line. It also adds a negative impulse in the Z axis, to ensure that poops are always shot downwards.<br />
<br />
Randomized Poop Impulse:<br />
<br />
[[File:ZvKCpEk(1).png|center]]<br />
<br />
Now that our local variables are setup, we can add the impulse to the player and spawn a poop.<br />
Note: The impulse will be by-passed if the player is currently crouching, which allows them to “squat” to poop on things.<br />
<br />
[[File:VbrMfKf(1).png|center]]<br />
<br />
Before the impulse is applied to the player, the player’s current velocity and their scaled input is run through another custom function called “Impulse Clamp”, which prevents the impulse from firing if the players current velocity is too high. Without this function, players could fly off into the distance at near-infinite speed, if they kept holding down the poop button.<br />
<br />
Impulse Clamp:<br />
<br />
[[File:VYYnOMg(1).png|center]]<br />
<br />
Now that the player has been “pushed” upwards, and the poop has been spawned, we need to push the newly spawned poop downwards. This can be done simply, with the built-in devkit functions, as seen below.<br />
<br />
[[File:Dxf4z7i(1).png|center]]<br />
<br />
Since the player just pooped, we will also need to subtract a small amount of food from their foot stat. If they do not have enough food, a small amount of health will be taken instead.<br />
To do this, create a custom function called “Consume Food” which accepts a “Primal Character” input, like so:<br />
<br />
[[File:Uq2fzFj(1).png|center]]<br />
<br />
The content of this function will look like this:<br />
<br />
[[File:X1U8FkK(1).png|center]]<br />
<br />
Now the only remaining step, add that delicious poop noise!<br />
This can be achieved very easily with a simple built-in function called “Actor Play Sound”.<br />
<br />
[[File:REMwgF2(1).png|center]]<br />
<br />
'''And you’re done!'''<br />
<br />
You now have a very silly “Rocket Poop” buff which can launch you high into the sky, with nothing but yesterday’s digested meatloaf as fuel.<br />
If you have any questions, feel free to message me on the ARK Modding Discord chat, or on the “Rocket Poop” workshop page. I will be uploading this as a standalone open-source mod, so that you can download the source and play with it as an example.<br />
Happy modding!<br />
<br />
--RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Rocket_Poop_(buff)&diff=1568Tutorial: Rocket Poop (buff)2018-04-21T04:20:48Z<p>RedDwarf: /* Add the “Rocket Poop” Buff Graph Logic */</p>
<hr />
<div>[[Category:Tutorials]]<br />
[[Category:Buffs]]<br />
<br />
== Introduction ==<br />
<br />
Greetings, fellow modders!<br />
<br />
The theme of this modding competition was to create a “wacky, ridiculous buff.” Finally, my time has come!<br />
I decided that what I really missed about ARK was the ability to do the famous cartoony “double-jump” that Mario and many other video game characters have been able to do for decades.<br />
So, since real physics have already been thrown out the window, the real question became “How do I make this fit in the ARK universe?” – and the answer was simple: Add poop.<br />
Thus, the “Rocket Poop” buff was born!<br />
When this buff is enabled, pressing the poop key will rocket-propel a stream of poop out of your butt so fast, that you’ll take to the air in what can only be described as the world's first biological jetpack. Be warned! This will quickly empty your stomach/bowels and cause you to starve if used too much.<br />
<br />
== The Plan! ==<br />
<br />
* Make the “Rocket Poops” buff, with the following effects, when the player pushes the poop key:<br />
** Capture the player’s “poop key” command.<br />
*** Keep boosting if the player holds the "poop key" down.<br />
** Enable a flaming poop particle emitter at the players butt (PlayerPawn’s “PoopSocket”).<br />
** Play a pooping/flaming sound.<br />
** Propel player upwards.<br />
*** Make sure they don’t go too fast.<br />
*** Allow player to navigate in mid-air, by factoring in the player’s input.<br />
** Reduce the player’s food stat (pooping requires food).<br />
*** Subtract from the players health if they continue to poop on an empty stomach.<br />
* Make a consumable item called “Rotten Meat”, which give the “Rocket Poops” buff when eaten.<br />
<br />
== Setting up the “Rocket Poop” Buff ==<br />
<br />
Create a blueprint called “PrimalBuff_RocketPoop” which is parented to “Primal Buff”.<br />
<br />
Next, open the “PrimalBuff_RocketPoop” and click on the “Defaults” tab at the top, and change the following properties:<br />
<br />
<br />
[[File:CxLJ1oP(1).png|center]]<br />
<br />
<br />
These settings will allow the buff to last for 5 minutes (300 seconds), and also detail when/how the buff can be activated. The name, description, icon, and duration can be easily changed if you want to modify the look/feel of the item. For example, you may want to make this item look like a potion, or a magic curse, etc. It also has flags that prevent it from being used on a dino, and it is treated as a disease. And most importantly, the "Use Buff Tick Server" and "Use Buff Tick Client" have been checked -- more on that later.<br />
<br />
Note: We will be revisiting this buff to add all the remaining logic and functionality. <br />
<br />
But first, we need to create a consumable that will allow players to activate our buff. This will also be very helpful when testing the buff in the devkit, because this consumable can be spawned and used. For even easier testing, add the buff to the “Additional Default Buffs” array in your mod’s PrimalGameData file, and the buff will automatically appear every time you start the PIE (“Play in Editor”).<br />
<br />
== Setting up the “Rotten Steak” Consumable ==<br />
<br />
To do this, create a new blueprint called “PrimalItemConsumableGeneric_RottenSteak” with “Primal Item Consumable Generic” as its parent.<br />
<br />
Open your new “Rotten Steak” primal item and modify the following values to customize it to your needs:<br />
<br />
<br />
[[File:TBHQXWr(1).png|center]]<br />
<br />
<br />
Again, feel free to change the icons or descriptions to whatever you’d like. I made the recipe require 1x spoiled meat, just because that was an easy resource, and it fit thematically.<br />
<br />
Your Rotten Steak is done! Now you can spawn it in and use it to test your buff.<br />
<br />
Example spawn code (your path/names will probably vary): <br />
Admincheat giveitem “Blueprint'/Game/Mods/RocketPoop/Consumables/RottenSteak/PrimalItemConsumableGeneric_RottenSteak.PrimalItemConsumableGeneric_RottenSteak'” 20 0 0<br />
<br />
== Setup Assets ==<br />
<br />
Before we get too far into our graph code, we need to setup a few assets that our mod will need.<br />
<br />
<br />
=== "Rocket Poops" particle emitter ===<br />
<br />
For this emitter, I started with a copy of the flame-thrower's main flame-thrower effect, called "Flamethrower_PS".<br />
<br />
From this base, I disabled the larger flames and smoke, and angled the remaining particles 180 to point them downwards (since our thrust is always shooting down).<br />
<br />
I then added a new mesh emitter, which will spawn human poops, shoot them downwards, and gives them gravity and collision so that they can skip/bounce after hitting something solid.<br />
<br />
<br />
[[File:BqxWjUA(1).png|center]]<br />
<br />
<br />
Tweaking particle effects is slightly outside the scope of this tutorial, but feel free to download the source code for this mod and look at the values/options I've setup for yourself.<br />
<br />
There's also a great UE4 video that goes through particle effects in great detail, if you want to understand how they work: [https://www.youtube.com/watch?v=7hC_QT4GLiU&list=PLZlv_N0_O1gYDLyB3LVfjYIcbBe8NqR8t&index=4 Intro to Cascade: Creating a Sprite Emitter | 04 | v4.2 Tutorial Series | Unreal Engine]<br />
<br />
However, in order for your particle emitter to actually use the poop mesh, we have to copy the "MIC_HumanPoop" material, and enable "Used with Mesh Particles", like so:<br />
<br />
<br />
[[File:Qfrr2WF(1).png|center]]<br />
<br />
<br />
You'll also need to copy the "SM_HumanPoop", and apply this new material to it. I recommend keeping these files in an "Assets" folder within your mod, and renaming the files to include the mod name, such as "MIC_RocketPoops_HumanPoop_Particle" and "SM_RocketPoops_HumanPoop", so that they're easily searchable if you need to reference them later -- and you won't get them confused for the base-game versions.<br />
<br />
=== "Rocket Poops" looping Poop Sound Cue ===<br />
<br />
Next, we need sound. As you would expect, you can reuse the vanilla "Flamethrower_Start_Cue" loop without any alterations.<br />
<br />
However, the base-game "Poop_Cue" only plays a single poop sound, and it's highly irritating to play that too frequently. So let's setup a custom looping sound cue.<br />
<br />
Copy the "Poop_Cue" to your assets folder, and add the following nodes (feel free to tweak as-needed):<br />
<br />
<br />
[[File:RUUoQUG(1).png|center]]<br />
<br />
<br />
For my version, I modulated the pitch down to avoid the loud/squeaky noises, and I put a delay of 0.5 to 1.0 seconds to prevent the effect from being overly annoying.<br />
<br />
And that's it! You've now got all the assets you'll need to do this little mod.<br />
<br />
<br />
== Add the "Rocket Poop" Buff Components ==<br />
<br />
Now that we have our custom assets and the Rotten Steak item setup, we need to add a few base components to the “Rocket Poop” buff, which the logic can reference later. Head back to your “PrimalBuff_RocketPoop” blueprint and open it up. Once open, click on the “Components” tab on the top right.<br />
<br />
Here, you'll need to add a particle emitter and two audio emitters (for the flames sounds, and the poop sounds), like so:<br />
<br />
<br />
[[File:BytiVIO(1).png|center]]<br />
<br />
<br />
Note: It's important that all three of these components be changed so that "Auto Activate" is left unchecked. This means that they won't be playing when the buff first loads, leaving us the freedom to manually activate/deactivate them when the player presses the "poop key" later on.<br />
<br />
== Add the “Rocket Poop” Buff Graph Logic ==<br />
Next, click on the "Graph" tab of your buff and pull up the Event Graph.<br />
<br />
The very first thing we’ll need to do is setup our Event Begin Play ("EBP") event, to handle some standard buff start-up house-keeping for us. I've divided the code up into a sequence of four sections of code, so that the nodes are more readable, and so that each piece will be easier to discuss.<br />
<br />
Note: The small delay after Event Begin Play is a common method used to help ensure that everything has been initialized correctly and that the logic is ready to execute. Without the delay after Event Begin Play, players will often encounter odd bugs which are hard to troubleshoot.<br />
<br />
<br />
[[File:Helhpmf(1).png|center]]<br />
<br />
<br />
=== Event Begin Play: Re-Assign Owner===<br />
<br />
"Buff" actors have a long and sordid history of detaching from their target whenever the user logs out. So as a best practice, we'll re-assign the owner when the buff starts up.<br />
<br />
<br />
[[File:681oHuD(1).png|center]]<br />
<br />
<br />
<br />
=== Event Begin Play: Enable Keyboard Input===<br />
<br />
By default, the buff actor will ignore input events (such as keypresses). In order to intercept and utilize the "poop key" event, we'll need to enable the client-side input (and verify that it's valid).<br />
<br />
<br />
[[File:SBqDdmQ(1).png|center]]<br />
<br />
<br />
<br />
=== Event Begin Play: Attach to Poop Socket===<br />
<br />
For the sake of ease-of-use, and because it makes me laugh, let's go ahead and attach this "RocketPoop" buff to the player's PoopSocket on the player's skeletal mesh. This is the reference location that the game uses when spawning turds, so we might as well use it too. This allows all future effects/emitters follow the location of the player's butt as it's moving, making life easy for everybody.<br />
<br />
<br />
[[File:LIZKUoA(1).png|center]]<br />
<br />
<br />
<br />
=== Event Begin Play: Setup Variables===<br />
<br />
When working with large graphs, it's often desirable to store frequently used references in variables so that you can easily use them again later, without running messy wires all over your graph.<br />
<br />
In this case, we're going to setup the Owner Actor (the player), the Primal Character (the player, avoids future casts), the Pawn (the player's pawn), and the pawns Movement Component.<br />
<br />
<br />
[[File:HYGS7Bo(1).png|center]]<br />
<br />
<br />
<br />
Huzzah! You're done with the Event Begin Play logic. Now to get into the real fun!<br />
<br />
<br />
===Capturing the "Poop Key" press and release===<br />
<br />
When working in the Unreal Engine, it’s critical to always pay attention to where your code is being executed – either on the local client, or on the server. You will also have to pay close attention to data replication, which handles the transmission of data from the server to the clients.<br />
<br />
In our case, we're using "Input Action" events (keypresses) -- and these input actions always execute on the client. In order to execute the buff logic, these keypresses must be transmitted to the server. To do that, create two custom server-side events: One to start pooping, and one to stop. We will also set the "Pooping Active" boolean client-side as well. (This variable is never replicated, because it doesn't need to. The server will update it's own copy of this variable as well, as we'll see later.)<br />
<br />
Create custom events called “ROS_EnableRocketPooping” and “ROS_DisableRocketPooping”, with the following settings:<br />
<br />
[[File:HtNuCVQ(1).png|center]]<br />
<br />
Note: Many mod authors choose to write "ROS" (Run on Server), "ROC" (Run on Client), or "MULTICAST" at the beginning of their custom functions, to remind themselves where the code is being executed, and to make the nodes easier to read/understand.<br />
<br />
Note: It’s important to setup this input action to “consume” the input, which will prevent your character from also trying to poop the normal way, which would fill your screen with lots of “not ready to poop yet” messages.<br />
<br />
These ROS events will set the "Pooping Active" boolean on the server-side, and spawn a multicast emitter that will spawn the particle emitters and play the desired sounds. This is multicast so that all players in range will experience the event (see the stream of fire/poop, and hear the pooping sounds).<br />
<br />
Note: Particle emitters and sounds do not need to be "played" by the server, since there's no human at the server to experience them. If you're having trouble interacting with your emitters, remember that the server needs to spawn one for each of the clients in order for everyone to see it.<br />
<br />
[[File:RKHEwRN(1).png|center]]<br />
<br />
<br />
=== Toggle Sounds/Particles on the Clients ===<br />
<br />
In order to activate/deactivate the sounds and particle effects we need on the clients, we'll use our "Set Spawn Activation" multicast event. This event will also fade out the audio over 0.25 seconds, which will make the audio feel much more natural compared to a sharp cutoff.<br />
<br />
<br />
[[File:FWUqDSO(1).png|center]]<br />
<br />
<br />
Note: For similar datatypes you can pass multiple references to the same node. For example, the "Activate" node can accept references from 3 components, without needing 3 separate "Activate" nodes.<br />
<br />
<br />
<br />
<br />
=== Event Buff Tick Client: Capture User Input, Send to Server ===<br />
<br />
Rocketing yourself straight up is all well and good, but to really be fun/useful, players need the ability to steer while they're in the air. To do this, we need to capture the player's input, and transmit it to the server where it can be used later, like so:<br />
<br />
<br />
[[File:8jeylKF(1).png|center]]<br />
<br />
<br />
Warning: "Event Tick" events can be very taxing on your server. More on that in the next section.<br />
<br />
<br />
=== Event Buff Tick Server ===<br />
<br />
Next, we need to setup the "Event Buff Tick Server" to handle the physics of rocketing a player off the ground (without putting them into orbit).<br />
<br />
But first, a huge word of caution: "Tick" events execute every single "frame" of the server's execution, so if you put heavy logic inside this function (or if there are many copies of this logic being run in multiple places -- such as 50 or 60 players all with the same buff), it will have a significant effect on your server's performance. Imagine asking your computer to do a bunch of extra math and networking between every frame in a movie that you're watching -- if you pile on too many calculations, you'll eventually see your video stutter. The same is true with ARK servers -- if you ask too much, you'll get lag/slowdowns.<br />
<br />
Having said that, we'll be using the "Tick" event because the "Add Force" function requires it to run smoothly, and there isn't much in the way of heavy logic behind it.<br />
<br />
=== Event Buff Tick Server: Speed Suppression ===<br />
<br />
One of the first things we'll do is store the "Delta Time" (the time since the last tick) into a variable so we can access it later. Next, we'll check to see if the "Rocket Poop" is activated.<br />
<br />
If the "Rocket Poop" is off, then we need to apply a dampening force to slow the player's forward progress, otherwise players can sail across the map in weird ways, and it hampers control.<br />
<br />
<br />
[[File:JJENnXw(1).png|center]]<br />
<br />
<br />
As you can see, the first thing we do is calculate the magnitude of the X,Y velocity vectors, which gives us an accurate measure of how fast a player is traversing across the landscape.<br />
<br />
If the player is currently falling (but not boosting), and their speed is above a certain threshold, the dampening will kick in.<br />
<br />
To achieve a slowing effect, we use the "Add Force" node to apply a force in the oppose direction that we're going -- sort've like a strong head-wind pushing us backwards. Once we've slowed below the threshold, the effect will end.<br />
<br />
<br />
<br />
=== Event Buff Tick Server: Calculating the Main Thruster ===<br />
<br />
Now we're into the nitty gritty. =)<br />
<br />
<br />
[[File:5xM35Yb(1).png|center]]<br />
<br />
<br />
If the "Rocket Poop" thruster is on, the we need a way to scale an appropriate force vector (direction and magnitude) for our thrust, and apply it to the player. (See above)<br />
<br />
To do this, we're going to treat the X,Y axes separately from the Z axis. For the X,Y axes, we will multiply by the X,Y of our user input, to decide which way the player is wishing to move. This will allow for some mid-air control. Feel free to scale these values however you want, to gain more/less control.<br />
<br />
Next, we need to handle the Z axis. For this, we have a static force of 300,000. However, this makes it difficult to stop a fall, so in the interest of fun/usability, let's add additional thrust based on the current fall speed of the character. We do this by multiplying the players downward velocity by -300.0, and adding that to our static 300,000. This allows for a quick stop when falling from great heights.<br />
<br />
After we've got our desired thrust vector, we need to limit it's output to something reasonable (if the player isn't currently walking). The problem is that force can be cumulative, meaning that you'll keep gaining speed every time the force is re-added, and this can result in a player being rocketed off the map.<br />
<br />
To help with that, I've created a "Velocity Clamp" function, which compares the players current velocity, and limits their thrust vector if they're going too fast, like so:<br />
<br />
<br />
[[File:MOCVoNk(1).png|center]]<br />
<br />
<br />
As you can see, the horizontal thrust components are both clamped if either of them is higher than 600, and the main thruster (Z component) is limited to a upwards speed of 1200. For fun, you can tweak these clamps if you don't like the default handling.<br />
<br />
=== Event Buff Tick Server: Apply Thrust, Consume Food/Health ===<br />
<br />
Now that we know which way we're going, the only thing left to do is apply the force to the player, and consume food/health as fuel.<br />
<br />
<br />
[[File:It8QMu7(1).png|center]]<br />
<br />
<br />
As you can see, the "Consume Food" function takes in the "Delta Seconds" float variable -- which allows us to remove food/health based on how many seconds the player boosted during this tick.<br />
<br />
The "Consume Food" function:<br />
<br />
<br />
[[File:IPJhCua(1).png|center]]<br />
<br />
<br />
And that's it! You've successfully built "Rocket Poop" logic. Your parents will be so proud.<br />
<br />
<br />
<br />
<br />
--------------------------------------------------------------------------- EDIT LINE<br />
<br />
<br />
<br />
<br />
[[File:FtduJki(1).png|center]]<br />
<br />
As you can see here, the looping timeline is setup to be 0.2 seconds long, with a “Attempt Poop” event at time 0.<br />
Next, create a function called “Rocket Pooping Function”, and add it to the graph as shown above. This is where most of our logic will reside. This function has been setup to accept the transform (location and rotation) of the player’s “PoopSocket” (a property of the players Skeletal Mesh), and a reference to the character, as “pass-by-reference” inputs (this will be important later).<br />
The “Rocket Pooping Function” will look like this, once we’re all said-and-done. Don’t let its size worry you, I’ll cover every piece in detail. I just want to give you the big picture before we move forward.<br />
<br />
[[File:PqggE90(1).png|center]]<br />
<br />
The first thing we’re going to do is setup reusable local variables which will hold the location of the poop socket, a reference to the primal character, the “Scaled User Input” (custom function, more on that later), and the poop impulse. Note: “Impulse” in Unreal Engine means an instantaneous force applied to an object once – like a bat hitting a baseball. We will be using custom vectors to determine the direction and strength of these impulses.<br />
<br />
[[File:RIK1tf5(1).png|center]]<br />
<br />
The “Get Pending Input Vector” gives us an indication of which direction the player wants to go (forwards, backwards, strafe left/right, etc). We can use this vector to allow the player some control while they’re in the air.<br />
The “Scale User Input” is a custom function, which scales the X and Y vectors, and creates an upward thrust vector for propelling the player. The function looks like this:<br />
<br />
[[File:YfZ0n7L(1).png|center]]<br />
<br />
Note: This is a “pure” function, so it does not need to be executed in the normal line of execution.<br />
Next, we need to calculate the impulse vector for the poop that we will be spawning in. This is done by adding the players current velocity with the velocity of the “Scaled User Input”, so that the poops rocket out of the players butt at the same speed that the player is moving – otherwise, the player would “out run” his own rocket poops, and that would look strange (or, even more strange than Rocket Poops).<br />
Once the vectors are added together, the final vector is passed through another custom function, called “Randomize Poop Impulse”. This function adds a small randomized amount of impulse on the X and Y axes, so that poops “splatter out” randomly, instead of just streaming out in a perfect line. It also adds a negative impulse in the Z axis, to ensure that poops are always shot downwards.<br />
<br />
Randomized Poop Impulse:<br />
<br />
[[File:ZvKCpEk(1).png|center]]<br />
<br />
Now that our local variables are setup, we can add the impulse to the player and spawn a poop.<br />
Note: The impulse will be by-passed if the player is currently crouching, which allows them to “squat” to poop on things.<br />
<br />
[[File:VbrMfKf(1).png|center]]<br />
<br />
Before the impulse is applied to the player, the player’s current velocity and their scaled input is run through another custom function called “Impulse Clamp”, which prevents the impulse from firing if the players current velocity is too high. Without this function, players could fly off into the distance at near-infinite speed, if they kept holding down the poop button.<br />
<br />
Impulse Clamp:<br />
<br />
[[File:VYYnOMg(1).png|center]]<br />
<br />
Now that the player has been “pushed” upwards, and the poop has been spawned, we need to push the newly spawned poop downwards. This can be done simply, with the built-in devkit functions, as seen below.<br />
<br />
[[File:Dxf4z7i(1).png|center]]<br />
<br />
Since the player just pooped, we will also need to subtract a small amount of food from their foot stat. If they do not have enough food, a small amount of health will be taken instead.<br />
To do this, create a custom function called “Consume Food” which accepts a “Primal Character” input, like so:<br />
<br />
[[File:Uq2fzFj(1).png|center]]<br />
<br />
The content of this function will look like this:<br />
<br />
[[File:X1U8FkK(1).png|center]]<br />
<br />
Now the only remaining step, add that delicious poop noise!<br />
This can be achieved very easily with a simple built-in function called “Actor Play Sound”.<br />
<br />
[[File:REMwgF2(1).png|center]]<br />
<br />
'''And you’re done!'''<br />
<br />
You now have a very silly “Rocket Poop” buff which can launch you high into the sky, with nothing but yesterday’s digested meatloaf as fuel.<br />
If you have any questions, feel free to message me on the ARK Modding Discord chat, or on the “Rocket Poop” workshop page. I will be uploading this as a standalone open-source mod, so that you can download the source and play with it as an example.<br />
Happy modding!<br />
<br />
--RedDwarf</div>RedDwarfhttps://wiki.arkmodding.net/index.php?title=Tutorial:_Rocket_Poop_(buff)&diff=1567Tutorial: Rocket Poop (buff)2018-04-21T04:19:46Z<p>RedDwarf: /* Event Buff Tick Server */</p>
<hr />
<div>[[Category:Tutorials]]<br />
[[Category:Buffs]]<br />
<br />
== Introduction ==<br />
<br />
Greetings, fellow modders!<br />
<br />
The theme of this modding competition was to create a “wacky, ridiculous buff.” Finally, my time has come!<br />
I decided that what I really missed about ARK was the ability to do the famous cartoony “double-jump” that Mario and many other video game characters have been able to do for decades.<br />
So, since real physics have already been thrown out the window, the real question became “How do I make this fit in the ARK universe?” – and the answer was simple: Add poop.<br />
Thus, the “Rocket Poop” buff was born!<br />
When this buff is enabled, pressing the poop key will rocket-propel a stream of poop out of your butt so fast, that you’ll take to the air in what can only be described as the world's first biological jetpack. Be warned! This will quickly empty your stomach/bowels and cause you to starve if used too much.<br />
<br />
== The Plan! ==<br />
<br />
* Make the “Rocket Poops” buff, with the following effects, when the player pushes the poop key:<br />
** Capture the player’s “poop key” command.<br />
*** Keep boosting if the player holds the "poop key" down.<br />
** Enable a flaming poop particle emitter at the players butt (PlayerPawn’s “PoopSocket”).<br />
** Play a pooping/flaming sound.<br />
** Propel player upwards.<br />
*** Make sure they don’t go too fast.<br />
*** Allow player to navigate in mid-air, by factoring in the player’s input.<br />
** Reduce the player’s food stat (pooping requires food).<br />
*** Subtract from the players health if they continue to poop on an empty stomach.<br />
* Make a consumable item called “Rotten Meat”, which give the “Rocket Poops” buff when eaten.<br />
<br />
== Setting up the “Rocket Poop” Buff ==<br />
<br />
Create a blueprint called “PrimalBuff_RocketPoop” which is parented to “Primal Buff”.<br />
<br />
Next, open the “PrimalBuff_RocketPoop” and click on the “Defaults” tab at the top, and change the following properties:<br />
<br />
<br />
[[File:CxLJ1oP(1).png|center]]<br />
<br />
<br />
These settings will allow the buff to last for 5 minutes (300 seconds), and also detail when/how the buff can be activated. The name, description, icon, and duration can be easily changed if you want to modify the look/feel of the item. For example, you may want to make this item look like a potion, or a magic curse, etc. It also has flags that prevent it from being used on a dino, and it is treated as a disease. And most importantly, the "Use Buff Tick Server" and "Use Buff Tick Client" have been checked -- more on that later.<br />
<br />
Note: We will be revisiting this buff to add all the remaining logic and functionality. <br />
<br />
But first, we need to create a consumable that will allow players to activate our buff. This will also be very helpful when testing the buff in the devkit, because this consumable can be spawned and used. For even easier testing, add the buff to the “Additional Default Buffs” array in your mod’s PrimalGameData file, and the buff will automatically appear every time you start the PIE (“Play in Editor”).<br />
<br />
== Setting up the “Rotten Steak” Consumable ==<br />
<br />
To do this, create a new blueprint called “PrimalItemConsumableGeneric_RottenSteak” with “Primal Item Consumable Generic” as its parent.<br />
<br />
Open your new “Rotten Steak” primal item and modify the following values to customize it to your needs:<br />
<br />
<br />
[[File:TBHQXWr(1).png|center]]<br />
<br />
<br />
Again, feel free to change the icons or descriptions to whatever you’d like. I made the recipe require 1x spoiled meat, just because that was an easy resource, and it fit thematically.<br />
<br />
Your Rotten Steak is done! Now you can spawn it in and use it to test your buff.<br />
<br />
Example spawn code (your path/names will probably vary): <br />
Admincheat giveitem “Blueprint'/Game/Mods/RocketPoop/Consumables/RottenSteak/PrimalItemConsumableGeneric_RottenSteak.PrimalItemConsumableGeneric_RottenSteak'” 20 0 0<br />
<br />
== Setup Assets ==<br />
<br />
Before we get too far into our graph code, we need to setup a few assets that our mod will need.<br />
<br />
<br />
=== "Rocket Poops" particle emitter ===<br />
<br />
For this emitter, I started with a copy of the flame-thrower's main flame-thrower effect, called "Flamethrower_PS".<br />
<br />
From this base, I disabled the larger flames and smoke, and angled the remaining particles 180 to point them downwards (since our thrust is always shooting down).<br />
<br />
I then added a new mesh emitter, which will spawn human poops, shoot them downwards, and gives them gravity and collision so that they can skip/bounce after hitting something solid.<br />
<br />
<br />
[[File:BqxWjUA(1).png|center]]<br />
<br />
<br />
Tweaking particle effects is slightly outside the scope of this tutorial, but feel free to download the source code for this mod and look at the values/options I've setup for yourself.<br />
<br />
There's also a great UE4 video that goes through particle effects in great detail, if you want to understand how they work: [https://www.youtube.com/watch?v=7hC_QT4GLiU&list=PLZlv_N0_O1gYDLyB3LVfjYIcbBe8NqR8t&index=4 Intro to Cascade: Creating a Sprite Emitter | 04 | v4.2 Tutorial Series | Unreal Engine]<br />
<br />
However, in order for your particle emitter to actually use the poop mesh, we have to copy the "MIC_HumanPoop" material, and enable "Used with Mesh Particles", like so:<br />
<br />
<br />
[[File:Qfrr2WF(1).png|center]]<br />
<br />
<br />
You'll also need to copy the "SM_HumanPoop", and apply this new material to it. I recommend keeping these files in an "Assets" folder within your mod, and renaming the files to include the mod name, such as "MIC_RocketPoops_HumanPoop_Particle" and "SM_RocketPoops_HumanPoop", so that they're easily searchable if you need to reference them later -- and you won't get them confused for the base-game versions.<br />
<br />
=== "Rocket Poops" looping Poop Sound Cue ===<br />
<br />
Next, we need sound. As you would expect, you can reuse the vanilla "Flamethrower_Start_Cue" loop without any alterations.<br />
<br />
However, the base-game "Poop_Cue" only plays a single poop sound, and it's highly irritating to play that too frequently. So let's setup a custom looping sound cue.<br />
<br />
Copy the "Poop_Cue" to your assets folder, and add the following nodes (feel free to tweak as-needed):<br />
<br />
<br />
[[File:RUUoQUG(1).png|center]]<br />
<br />
<br />
For my version, I modulated the pitch down to avoid the loud/squeaky noises, and I put a delay of 0.5 to 1.0 seconds to prevent the effect from being overly annoying.<br />
<br />
And that's it! You've now got all the assets you'll need to do this little mod.<br />
<br />
<br />
== Add the "Rocket Poop" Buff Components ==<br />
<br />
Now that we have our custom assets and the Rotten Steak item setup, we need to add a few base components to the “Rocket Poop” buff, which the logic can reference later. Head back to your “PrimalBuff_RocketPoop” blueprint and open it up. Once open, click on the “Components” tab on the top right.<br />
<br />
Here, you'll need to add a particle emitter and two audio emitters (for the flames sounds, and the poop sounds), like so:<br />
<br />
<br />
[[File:BytiVIO(1).png|center]]<br />
<br />
<br />
Note: It's important that all three of these components be changed so that "Auto Activate" is left unchecked. This means that they won't be playing when the buff first loads, leaving us the freedom to manually activate/deactivate them when the player presses the "poop key" later on.<br />
<br />
== Add the “Rocket Poop” Buff Graph Logic ==<br />
Next, click on the "Graph" tab of your buff and pull up the Event Graph.<br />
<br />
The very first thing we’ll need to do is setup our Event Begin Play ("EBP") event, to handle some standard buff start-up house-keeping for us. I've divided the code up into a sequence of four sections of code, so that the nodes are more readable, and so that each piece will be easier to discuss.<br />
<br />
Note: The small delay after Event Begin Play is a common method used to help ensure that everything has been initialized correctly and that the logic is ready to execute. Without the delay after Event Begin Play, players will often encounter odd bugs which are hard to troubleshoot.<br />
<br />
[[File:Helhpmf(1).png|center]]<br />
<br />
=== Event Begin Play: Re-Assign Owner===<br />
<br />
"Buff" actors have a long and sordid history of detaching from their target whenever the user logs out. So as a best practice, we'll re-assign the owner when the buff starts up.<br />
<br />
[[File:681oHuD(1).png|center]]<br />
<br />
<br />
=== Event Begin Play: Enable Keyboard Input===<br />
<br />
By default, the buff actor will ignore input events (such as keypresses). In order to intercept and utilize the "poop key" event, we'll need to enable the client-side input (and verify that it's valid).<br />
<br />
[[File:SBqDdmQ(1).png|center]]<br />
<br />
<br />
=== Event Begin Play: Attach to Poop Socket===<br />
<br />
For the sake of ease-of-use, and because it makes me laugh, let's go ahead and attach this "RocketPoop" buff to the player's PoopSocket on the player's skeletal mesh. This is the reference location that the game uses when spawning turds, so we might as well use it too. This allows all future effects/emitters follow the location of the player's butt as it's moving, making life easy for everybody.<br />
<br />
[[File:LIZKUoA(1).png|center]]<br />
<br />
<br />
=== Event Begin Play: Setup Variables===<br />
<br />
When working with large graphs, it's often desirable to store frequently used references in variables so that you can easily use them again later, without running messy wires all over your graph.<br />
<br />
In this case, we're going to setup the Owner Actor (the player), the Primal Character (the player, avoids future casts), the Pawn (the player's pawn), and the pawns Movement Component.<br />
<br />
[[File:HYGS7Bo(1).png|center]]<br />
<br />
<br />
Huzzah! You're done with the Event Begin Play logic. Now to get into the real fun!<br />
<br />
<br />
===Capturing the "Poop Key" press and release===<br />
<br />
When working in the Unreal Engine, it’s critical to always pay attention to where your code is being executed – either on the local client, or on the server. You will also have to pay close attention to data replication, which handles the transmission of data from the server to the clients.<br />
<br />
In our case, we're using "Input Action" events (keypresses) -- and these input actions always execute on the client. In order to execute the buff logic, these keypresses must be transmitted to the server. To do that, create two custom server-side events: One to start pooping, and one to stop. We will also set the "Pooping Active" boolean client-side as well. (This variable is never replicated, because it doesn't need to. The server will update it's own copy of this variable as well, as we'll see later.)<br />
<br />
Create custom events called “ROS_EnableRocketPooping” and “ROS_DisableRocketPooping”, with the following settings:<br />
<br />
[[File:HtNuCVQ(1).png|center]]<br />
<br />
Note: Many mod authors choose to write "ROS" (Run on Server), "ROC" (Run on Client), or "MULTICAST" at the beginning of their custom functions, to remind themselves where the code is being executed, and to make the nodes easier to read/understand.<br />
<br />
Note: It’s important to setup this input action to “consume” the input, which will prevent your character from also trying to poop the normal way, which would fill your screen with lots of “not ready to poop yet” messages.<br />
<br />
These ROS events will set the "Pooping Active" boolean on the server-side, and spawn a multicast emitter that will spawn the particle emitters and play the desired sounds. This is multicast so that all players in range will experience the event (see the stream of fire/poop, and hear the pooping sounds).<br />
<br />
Note: Particle emitters and sounds do not need to be "played" by the server, since there's no human at the server to experience them. If you're having trouble interacting with your emitters, remember that the server needs to spawn one for each of the clients in order for everyone to see it.<br />
<br />
[[File:RKHEwRN(1).png|center]]<br />
<br />
<br />
=== Toggle Sounds/Particles on the Clients ===<br />
<br />
In order to activate/deactivate the sounds and particle effects we need on the clients, we'll use our "Set Spawn Activation" multicast event. This event will also fade out the audio over 0.25 seconds, which will make the audio feel much more natural compared to a sharp cutoff.<br />
<br />
<br />
[[File:FWUqDSO(1).png|center]]<br />
<br />
<br />
Note: For similar datatypes you can pass multiple references to the same node. For example, the "Activate" node can accept references from 3 components, without needing 3 separate "Activate" nodes.<br />
<br />
<br />
<br />
<br />
=== Event Buff Tick Client: Capture User Input, Send to Server ===<br />
<br />
Rocketing yourself straight up is all well and good, but to really be fun/useful, players need the ability to steer while they're in the air. To do this, we need to capture the player's input, and transmit it to the server where it can be used later, like so:<br />
<br />
<br />
[[File:8jeylKF(1).png|center]]<br />
<br />
<br />
Warning: "Event Tick" events can be very taxing on your server. More on that in the next section.<br />
<br />
<br />
=== Event Buff Tick Server ===<br />
<br />
Next, we need to setup the "Event Buff Tick Server" to handle the physics of rocketing a player off the ground (without putting them into orbit).<br />
<br />
But first, a huge word of caution: "Tick" events execute every single "frame" of the server's execution, so if you put heavy logic inside this function (or if there are many copies of this logic being run in multiple places -- such as 50 or 60 players all with the same buff), it will have a significant effect on your server's performance. Imagine asking your computer to do a bunch of extra math and networking between every frame in a movie that you're watching -- if you pile on too many calculations, you'll eventually see your video stutter. The same is true with ARK servers -- if you ask too much, you'll get lag/slowdowns.<br />
<br />
Having said that, we'll be using the "Tick" event because the "Add Force" function requires it to run smoothly, and there isn't much in the way of heavy logic behind it.<br />
<br />
=== Event Buff Tick Server: Speed Suppression ===<br />
<br />
One of the first things we'll do is store the "Delta Time" (the time since the last tick) into a variable so we can access it later. Next, we'll check to see if the "Rocket Poop" is activated.<br />
<br />
If the "Rocket Poop" is off, then we need to apply a dampening force to slow the player's forward progress, otherwise players can sail across the map in weird ways, and it hampers control.<br />
<br />
<br />
[[File:JJENnXw(1).png|center]]<br />
<br />
<br />
As you can see, the first thing we do is calculate the magnitude of the X,Y velocity vectors, which gives us an accurate measure of how fast a player is traversing across the landscape.<br />
<br />
If the player is currently falling (but not boosting), and their speed is above a certain threshold, the dampening will kick in.<br />
<br />
To achieve a slowing effect, we use the "Add Force" node to apply a force in the oppose direction that we're going -- sort've like a strong head-wind pushing us backwards. Once we've slowed below the threshold, the effect will end.<br />
<br />
<br />
<br />
=== Event Buff Tick Server: Calculating the Main Thruster ===<br />
<br />
Now we're into the nitty gritty. =)<br />
<br />
<br />
[[File:5xM35Yb(1).png|center]]<br />
<br />
<br />
If the "Rocket Poop" thruster is on, the we need a way to scale an appropriate force vector (direction and magnitude) for our thrust, and apply it to the player. (See above)<br />
<br />
To do this, we're going to treat the X,Y axes separately from the Z axis. For the X,Y axes, we will multiply by the X,Y of our user input, to decide which way the player is wishing to move. This will allow for some mid-air control. Feel free to scale these values however you want, to gain more/less control.<br />
<br />
Next, we need to handle the Z axis. For this, we have a static force of 300,000. However, this makes it difficult to stop a fall, so in the interest of fun/usability, let's add additional thrust based on the current fall speed of the character. We do this by multiplying the players downward velocity by -300.0, and adding that to our static 300,000. This allows for a quick stop when falling from great heights.<br />
<br />
After we've got our desired thrust vector, we need to limit it's output to something reasonable (if the player isn't currently walking). The problem is that force can be cumulative, meaning that you'll keep gaining speed every time the force is re-added, and this can result in a player being rocketed off the map.<br />
<br />
To help with that, I've created a "Velocity Clamp" function, which compares the players current velocity, and limits their thrust vector if they're going too fast, like so:<br />
<br />
<br />
[[File:MOCVoNk(1).png|center]]<br />
<br />
<br />
As you can see, the horizontal thrust components are both clamped if either of them is higher than 600, and the main thruster (Z component) is limited to a upwards speed of 1200. For fun, you can tweak these clamps if you don't like the default handling.<br />
<br />
=== Event Buff Tick Server: Apply Thrust, Consume Food/Health ===<br />
<br />
Now that we know which way we're going, the only thing left to do is apply the force to the player, and consume food/health as fuel.<br />
<br />
<br />
[[File:It8QMu7(1).png|center]]<br />
<br />
<br />
As you can see, the "Consume Food" function takes in the "Delta Seconds" float variable -- which allows us to remove food/health based on how many seconds the player boosted during this tick.<br />
<br />
The "Consume Food" function:<br />
<br />
<br />
[[File:IPJhCua(1).png|center]]<br />
<br />
<br />
And that's it! You've successfully built "Rocket Poop" logic. Your parents will be so proud.<br />
<br />
<br />
<br />
<br />
--------------------------------------------------------------------------- EDIT LINE<br />
<br />
<br />
<br />
<br />
[[File:FtduJki(1).png|center]]<br />
<br />
As you can see here, the looping timeline is setup to be 0.2 seconds long, with a “Attempt Poop” event at time 0.<br />
Next, create a function called “Rocket Pooping Function”, and add it to the graph as shown above. This is where most of our logic will reside. This function has been setup to accept the transform (location and rotation) of the player’s “PoopSocket” (a property of the players Skeletal Mesh), and a reference to the character, as “pass-by-reference” inputs (this will be important later).<br />
The “Rocket Pooping Function” will look like this, once we’re all said-and-done. Don’t let its size worry you, I’ll cover every piece in detail. I just want to give you the big picture before we move forward.<br />
<br />
[[File:PqggE90(1).png|center]]<br />
<br />
The first thing we’re going to do is setup reusable local variables which will hold the location of the poop socket, a reference to the primal character, the “Scaled User Input” (custom function, more on that later), and the poop impulse. Note: “Impulse” in Unreal Engine means an instantaneous force applied to an object once – like a bat hitting a baseball. We will be using custom vectors to determine the direction and strength of these impulses.<br />
<br />
[[File:RIK1tf5(1).png|center]]<br />
<br />
The “Get Pending Input Vector” gives us an indication of which direction the player wants to go (forwards, backwards, strafe left/right, etc). We can use this vector to allow the player some control while they’re in the air.<br />
The “Scale User Input” is a custom function, which scales the X and Y vectors, and creates an upward thrust vector for propelling the player. The function looks like this:<br />
<br />
[[File:YfZ0n7L(1).png|center]]<br />
<br />
Note: This is a “pure” function, so it does not need to be executed in the normal line of execution.<br />
Next, we need to calculate the impulse vector for the poop that we will be spawning in. This is done by adding the players current velocity with the velocity of the “Scaled User Input”, so that the poops rocket out of the players butt at the same speed that the player is moving – otherwise, the player would “out run” his own rocket poops, and that would look strange (or, even more strange than Rocket Poops).<br />
Once the vectors are added together, the final vector is passed through another custom function, called “Randomize Poop Impulse”. This function adds a small randomized amount of impulse on the X and Y axes, so that poops “splatter out” randomly, instead of just streaming out in a perfect line. It also adds a negative impulse in the Z axis, to ensure that poops are always shot downwards.<br />
<br />
Randomized Poop Impulse:<br />
<br />
[[File:ZvKCpEk(1).png|center]]<br />
<br />
Now that our local variables are setup, we can add the impulse to the player and spawn a poop.<br />
Note: The impulse will be by-passed if the player is currently crouching, which allows them to “squat” to poop on things.<br />
<br />
[[File:VbrMfKf(1).png|center]]<br />
<br />
Before the impulse is applied to the player, the player’s current velocity and their scaled input is run through another custom function called “Impulse Clamp”, which prevents the impulse from firing if the players current velocity is too high. Without this function, players could fly off into the distance at near-infinite speed, if they kept holding down the poop button.<br />
<br />
Impulse Clamp:<br />
<br />
[[File:VYYnOMg(1).png|center]]<br />
<br />
Now that the player has been “pushed” upwards, and the poop has been spawned, we need to push the newly spawned poop downwards. This can be done simply, with the built-in devkit functions, as seen below.<br />
<br />
[[File:Dxf4z7i(1).png|center]]<br />
<br />
Since the player just pooped, we will also need to subtract a small amount of food from their foot stat. If they do not have enough food, a small amount of health will be taken instead.<br />
To do this, create a custom function called “Consume Food” which accepts a “Primal Character” input, like so:<br />
<br />
[[File:Uq2fzFj(1).png|center]]<br />
<br />
The content of this function will look like this:<br />
<br />
[[File:X1U8FkK(1).png|center]]<br />
<br />
Now the only remaining step, add that delicious poop noise!<br />
This can be achieved very easily with a simple built-in function called “Actor Play Sound”.<br />
<br />
[[File:REMwgF2(1).png|center]]<br />
<br />
'''And you’re done!'''<br />
<br />
You now have a very silly “Rocket Poop” buff which can launch you high into the sky, with nothing but yesterday’s digested meatloaf as fuel.<br />
If you have any questions, feel free to message me on the ARK Modding Discord chat, or on the “Rocket Poop” workshop page. I will be uploading this as a standalone open-source mod, so that you can download the source and play with it as an example.<br />
Happy modding!<br />
<br />
--RedDwarf</div>RedDwarf