Search the Community

This is going to be a long write-up about how you can make your own auras. I invite criticism, because I am not a master of Lua as such. I just know these approaches work, and I keep having to teach people how to do these, so I thought I'd just do a write-up, so they can educate themselves and try something out before asking. It's not simple stuff for newcomers, so I've tried to comment as much as I can about gotcha's and such. They may be a bit hard to follow, but I have tried to comment everything in them to help you understand how they work. If something is very unclear or you have noticed something that would label me as a colossal idiot, please do point it out. I'm only trying to help, so if my efforts lead to the opposite of help, I would like to be notified Nice to know about auras There are a few ways to implement auras. One is to make a component, like the sanityaura component that you may have seen while looking for clues in the game code. While it is often a good thing to extrapolate such a thing as an aura into a separate component, there is a hidden catch to how the sanityaura component works, which makes it hard for modders to replicate. It simply has a value indicating how much sanity is to be applied per second, but you can also instead give it a function which calculates that value by whatever influences you want. You may have noticed that the sanityaura component doesn't actually apply the sanity anywhere. This is because the effect of the sanityaura component is integrated into the frame-by-frame sanity-calculations done in the sanity component. If you were to use this method for your own component, you would have to somehow integrate the same kind of change to the calculations done in the component for whatever you want to change, e.g., health or hunger, and the game code is not very open for that kind of thing. The calculations are usually very large functions which do the calculations AND the application of the result in one function, so there's no way for you to hook directly into the calculations. There is a way to do this as a component, though, and I will add a template and examples of this later, but for now I will focus on another way. Another way to do these auras is to use periodic tasks, which will be the focus of the first couple of examples. How to use periodic tasks A periodic task is a task which we can start on an entity, with or without an initial delay, which then calls a given function every X seconds. The function declaration looks like this: DoPeriodicTask(timeBetweenCallsToTheFunction, myFunction, initialDelayTime, ...) So, first parameter is time in seconds between consecutive calls of the given function, myFunction. Setting it to 0 makes the function get called every frame. The myFunction parameter is the function we want to periodically call. The initialDelayTime parameter is the time in seconds we want to delay before starting the periodic task, i.e., the time to wait before calling myFunction the first time. The ... means that it can take a number of extra parameters, and all these extra parameters are also sent to the given function when it is called. See example below. This would be a simple periodic task, periodically calling the given parameterless function every 1.0 second: local myFunction = function(inst) -- Do something end inst:DoPeriodicTask(1.0, myFunction) Notice that the inst is always automatically passed as the first parameter to the given function, without us specifically telling it to. This is a convenience given to us by Klei and Lua, but it is also something you must remember to include when writing up your function parameters. Here is an example of a periodic task, periodically calling the given function every 1.0 second, with an initial delay of 3.0 seconds and extra parameters: local myFunction = function(inst, myVariable, myOtherVariable) -- Do something end local myVariable = "some string" local myOtherVariable = 5.0 inst:DoPeriodicTask(1.0, myFunction, 3.0, myVariable, myOtherVariable) If you do not want an initial delay, you can just write nil instead of a number for the initialDelayTime parameter. WARNING: Periodic tasks should be used with care. Try not to make them call their given function too often. For example, to give 1 health every second, you can, e.g., give 1 health every 1 second, or you can give 0.1 health every 0.1 seconds. The latter is 10 more function calls and so it is 10 times heavier to run. Also, the task-timing is not 100% accurate, since the tasks are called on a frame-by-frame basis, so they are never called EXACTLY at the amount of time you have given it, but simply at the first frame after the time has run out, so it may be delayed by 0-50+ ms, and that delay happens for each consecutive scheduled call of the given function. Keep that in mind, so you don't try to do several cooperating tasks requiring perfect timing. So, now we know how to START a periodic task, but usually we also want to know how to END it again. For that, we can store the task we've made in a variable, and use that variable to cancel / stop the task later. local myFunction = function(inst) -- Do something end -- You can save the task in a local variable, e.g., if the life-time of the task is controlled in the same file (or you know what you are doing)... local myUniqueTaskVariableName = inst:DoPeriodicTask(1.0, myFunction) -- OR you can save the task to a variable on your instance. inst.myUniqueTaskVariableName = inst:DoPeriodicTask(1.0, myFunction) -- Later, in some other part of the code, where you have access to the same inst or variable, -- you can cancel the task by calling Cancel() on it, so depending on how you saved the task: myUniqueTaskVariableName:Cancel() -- OR inst.myUniqueTaskVariableName:Cancel() IMPORTANT NOTE: It is advised to set your task-variable to nil after cancelling it, so you can do a nil-check before trying to cancel a task that might not be running (not that it would be catastrophic, but it is extra needless work for the CPU). This also makes the task-variable function as a sort of state-variable, so if the task is not nil, you know it is active. You might be able to use that for some checks elsewhere in your code. Now we can start making auras Let us start with a simple aura, where I can explain the whole concept without too much complexity. It introduces a few things, like the FindEntities function and entity tags, which are explained in further detail following this first example. Basic constant stat regen aura Below is an example of a never-ending aura which provides health regeneration to players around the entity with the aura (but you can make it affect anything you want, within any range/distance you want). You can add the following code directly in your entity's Lua file, at the bottom of the fn() or master_postinit() function. I say "entity" because this aura can be added to any player, monster, item or whatever other entity. It runs forever, even when the entity is dead, so we have a check that makes sure it does nothing if it has a health-component and is dead. We could have taken care of this by cancelling the task when the entity died, and then started it again when the entity was revived (mostly useful for players). There are events you can listen to for both of those events, so when the entity dies you can access your task-variable on the entity to cancel the task. However, the task is automatically removed when the entity is removed from the world. Anyway, this is the simplified version with lots of comments. Tags? Each entity has a bunch of tags, labelling it as whatever it is. Think of it as post-its on all entities defining them as "lightsource", "flammable", "tree", "creaturehome" or whatever. They aren't functional in and of themselves, but are used in the code to categorize things which need to behave similarly, so we can use a function like FindEntities to find all entities within an area that are a light source or flammable or perhaps just all trees or all players. Tags are used for MUCH more than that, but this is one way to leverage the tag-system. All you have to do, is find out which tags you want to target, by examining the game code to see which tags the target entities have, or will have, if you're looking for dynamic tags, like "hurt" or "burnt" or whatever. The game is full of tags and I can't cover all of them. What does the "INLIMBO" tag mean? "INLIMBO" is a tag that is put on entities that aren't "active in the scene" but still exist in the game. Two examples are: items in containers/inventories, and entities which get deactivated when outside of a certain range of players. For example, when no players are near or when put into a container, rabbits and rocks and such "go to limbo", i.e., they deactivate, and then get this tag. Stripping them from your search makes sure you don't accidentally get inactive entities in your results, and by the looks of how much Klei uses them, I think it also makes the search faster. Other common tags Other common tags to omit, are the "FX" tag which is found on things like fire and fireflies, and "DECOR" which covers decorative entities. There is also "NOCLICK", but I believe this is mostly used when dealing with interactions. For example, when a thing is used and it does an animation before it can be used again, that thing usually gets the "NOCLICK" tag put on it during the animation. But it is NOT just for player interactions. Quite a lot of animals also consider anything with the "NOCLICK" tag untargetable, which leads me to believe it is used for omitting the entity from not only player input interactions, but ANY interactions, kind of "hiding" them in plain sight. I've never used "NOCLICK" myself, but it seems to have many uses. Blowdarts get "NOCLICK" after being thrown *shrugs* I don't know its exact meaning. FindEntities Performance Tip When using TheSim:FindEntities continuously, like in our periodic tasks, you have to consider that every time we do our FindEntities-call, we create new lists for our tag-lists (mustHaveTags, cantHaveTags and mustHaveOneOfTheseTags). This is not ideal if they will be the same every time. To alleviate this, cache your tag-lists somewhere outside the DoPeriodicTask-call, and use those variables in your FindEntities-call. Here is an example with the list-variables being declared outside the function call and then used inside of it. Watch out for the naming of these local variables if you use the same code multiple times within the same scope. If you find yourself reusing the same tag-lists again and again, you can also define some general tag-lists that are available throughout your mod, but that's outside the scope of this guide. Triggered, timed aura template This template doesn't do anything out-of-the-box, but it keeps calling an application function, called onApplyAura, which has the ability to add an effect to entities within range of our entity, and then uses DoTaskInTime to schedule another function, onEndAura, to be called after X time. As long as the other entities stay within range of our entity when it triggers its aura (by calling the function applyAuraInRange), the duration is renewed on the affected entities. It then uses DoTaskInTime to end the task after a while, removing the effects of the aura. Keep an eye on the comments! They indicate where you should add code to add an effect to this aura and where to remove it again. See below for examples of how to use this template! All the code between the "START OF AURA CODE" comment and the "END OF AURA CODE" comment should be added ABOVE the fn() or master_postinit() function of your prefab, and then one of the triggering mechanisms (described at the bottom of the example) should be added at the bottom of the fn() or master_postinit() function of your prefab. Triggered, timed sanity regen aura This is an example of an implementation using the template above. I add a never-ending sanity regeneration task to the players that are within range, and remove it again when they have been out of range of the aura-emitting entity for more than 10 seconds. This is done using a combination of tasks: one DoPeriodicTask to continuously apply the sanity aura-effect and another similar type of task, DoTaskInTime, which ends the task after a while, cancelling the periodic sanity aura task. All the code between the "START OF AURA CODE" comment and the "END OF AURA CODE" comment should be added ABOVE the fn() or master_postinit() function of your prefab, and then one of the triggering mechanisms (described at the bottom of the example) should be added at the bottom of the fn() or master_postinit() function of your prefab. Triggered, timed sanity regen and damage reduction aura, triggered by attacking something This is an example of an implementation using the template above. I add a never-ending sanity regeneration task to the players that are within range, and remove it again when they have been out of range of the aura-emitting entity for more than 10 seconds. For this example, I have also added a damage reduction of 15%. This is done using a combination of tasks: one DoPeriodicTask to continuously apply the sanity aura-effect and another similar type of task, DoTaskInTime, which ends the task after a while, cancelling the periodic sanity aura task. The damage reduction is simply applied and removed in onApplyAura and onEndAura, respectively. Another change for this example, is that the aura is triggered by the entity attacking something. All the code between the "START OF AURA CODE" comment and the "END OF AURA CODE" comment should be added ABOVE the fn() or master_postinit() function of your prefab, and then one of the triggering mechanisms (described at the bottom of the example) should be added at the bottom of the fn() or master_postinit() function of your prefab.

Hey guys! So, I've been trying my hand on this mod that creates different types of areas of effect when dropped on the ground. Intended effect as of the moment: Spawns flowers in a small radius around it. But the thing is, for this particular item, I tried toying around with its prefab.lua and these were the following results: 1.) The item was doing its effect even when it wasn't placed on the ground. 2.) The item wasn't initially doing its effect, upon ground placement, effect fired but kept doing so. 3 and current iteration.) Not doing its effect at all. These were the following topics that I used as reference in developing this mod: http://steamcommunity.com/sharedfiles/filedetails/?id=787954095 File attachments: flutterfly.lua

If there are other characters nearby, then their mind is reduced. My character is demon )

Recently I asked how to reduce the mind to other players. When my character "x" is next to another character "y", his sainaty is restored. How can this be done?

Hi there folks! I'm working on a character who emits a sanity aura for people around him. Problem is, the aura ALSO affects him. I would like the aura to only affect OTHER people, and not him. Currently the sanity script is very rudimentary, here it is: -- Sanity aura! inst:AddComponent("sanityaura") inst.components.sanityaura.aura = TUNING.SANITYAURA_SMALL Also; How do you get rid of the noise? Whenever his sanity aura is used, it makes the noise of rejuvinating sanity. I would prefer it to be a passive and silent effect, so any help is appreciated! Thanks in advance!