Ultroman

  • Content count

    348
  • Joined

  • Last visited

Community Reputation

99 Excellent

4 Followers

About Ultroman

  • Rank
    Senior Member

Recent Profile Visitors

777 profile views
  1. Custom Attack speed,

    Yes. The stategraphs handle all the cooldowns, using number of frames. "attack" is just one of the states. There's also "throw" and "blowdart" etc. Each has their own animation(s) being played (which are a certain number of frames) and they also adhere to the inst.components.combat.min_attack_period using math.max. It's no small feat what you're trying to do. Also, there are usually animation chains, so there's a "pre_attack" animation, and then the actual attack-animation which is "pushed" to play after the "pre_attack" animation has finished. It's quite complex.
  2. I think it's the same thing. You just need to look at how prefabs like walls are done, in order to make it placeable while still having it be an inventory item. There's also something called "Heavy Object Physics" or something like that. I think it's on boulders. And you need to make sure you get a collision mesh on there. Most of this should be on the wall prefabs.
  3. Custom Attack speed,

    Are you sure? You might be cheated by the animation still running at the same speed. Or maybe the next attack is delayed until the attack animation has played. That could be something to look into. You might have to somehow make the animations shorter as well, or at least play faster if that's possible, to make this work.
  4. REQUEST (pls help :( )

    I asked the author.
  5. REQUEST (pls help :( )

    Did you ask the original author?
  6. Command Blocks

    You can make a mod that does something when you push a certain key on your keyboard, if that helps. Also, you don't have to type the whole command each time. DST supports copy/paste, so if you write the command in a text document, and just CTRL-C the line before you start playing, it's ready to be pasted into the console with CTRL-V. If you want to start modding, I recommend taking at least the LUA Crash Course. From there, you can look at any mod that does keyboard commands (or search this forum) to find out how to execute code at the push of a button.
  7. That's easy just extend (not override) the Blink function in the component. -- Store the original Blink function (this will keep it compatible with other mods which might also have extended this function, -- and allow it to work even if Klei updates the code in it) local old_Blink = inst.components.blinkstaff.Blink -- Replace the Blink function with a new one. Notice that we add "self" to it, since the function is declared with a :. inst.components.blinkstaff.Blink = function (self, pt, caster) if caster.components.hunger and caster.components.hunger.current < 10 then return end -- Run the original Blink function, if your check above has not already returned from our function. old_Blink(self, pt, caster) end Just add that right after your line inst.components.blinkstaff.onblinkfn = onblink
  8. You don't have to do that. You can just do a DoTaskInTime and postpone it until the player has teleported. local dosanityreduction = function(inst) if not inst.is_teleporting then if caster.components.hunger and caster.components.hunger.current > 0 then caster.components.hunger:DoDelta(-10) end else inst:DoTaskInTime(0.1, dosanityreduction) end end local function onblink(staff, pos, caster) dosanityreduction(caster) end This will keep calling the dosanityreduction function every 0.1 seconds, until it successfully applies the hunger change.
  9. Well, time to do more debug printing, then. print("Has hunger component: "..(caster.components.hunger ~= nil)) print("Current hunger: "..(caster.components.hunger.current)) print(caster)
  10. Yes, if you accept the impacts I described in my last post.
  11. True. That'll also make mosquitos and wasps neutral to the character, though. It'll also change the impact sound when not wearing armor, because his target-type will be determined as "insect_" instead of "flesh_". If those things are acceptable, then this is definitely the easiest and least intrusive solution.
  12. EDIT: I looked into it more, and the two functions in your snippets are actually "attached" to the combat-components of the bees using the SetRetargetFunction function, and their original function is stored in a variable which you have access to (I think). The problem with just attaching a new retarget-function to each type of bee (i.e. you just copy the code, and change it a bit, and attach your new function using the SetRetargetFunction function), is that if Klei ever changes something in the way the bees work, your mod might stop working or introduce weird bugs, since you would be overriding the original code instead of extending it. What are the chances of this? They're probably not high, but we never know. Overriding means you have to keep tabs on whether Klei updates their code. Extending means you don't have to care (unless they completely change things, so the function is removed or something like that). If you don't care about that, you can override the retarget functions using the SetRetargetFunction function, and simply add your tag to the "ignore"-tags: local function KillerRetarget(inst) return GLOBAL.FindEntity(inst, GLOBAL.SpringCombatMod(8), function(guy) return inst.components.combat:CanTarget(guy) end, { "_combat", "_health" }, { "insect", "INLIMBO", "beefriend" }, -- <=== there { "character", "animal", "monster" }) end local function SpringBeeRetarget(inst) return TheWorld.state.isspring and GLOBAL.FindEntity(inst, 4, function(guy) return inst.components.combat:CanTarget(guy) end, { "_combat", "_health" }, { "insect", "INLIMBO", "beefriend" }, -- <=== there { "character", "animal", "monster" }) or nil end And then do: AddPrefabPostInit("bee", function(inst) if inst.components.combat then inst.components.combat:SetRetargetFunction(2, SpringBeeRetarget) end end) AddPrefabPostInit("killerbee", function(inst) if inst.components.combat then inst.components.combat:SetRetargetFunction(2, KillerRetarget) end end)
  13. Adding the tag in onbecamehuman will add the tag every time the character is revived or joins the game. Just add it to the character at the top of your character's fn() function. Looking at the code in the combat-component, it seems to me that you should take a look at the IsValidTarget function in the combat-component of the bees. Extend that function, and return false if the character is your character. Here's an example for the normal bee. To also change the killer bees, copy this, and change "bee" to "killerbee". AddPrefabPostInit("bee", function(inst) if inst.components.combat then -- Store the original IsValidTarget function (this will keep it compatible with other mods which might also have extended this function) local old_IsValidTarget = inst.components.combat.IsValidTarget -- Replace the IsValidTarget function with a new one. Notice that we add "self" to it, since the function is declared with a :. inst.components.combat.IsValidTarget = function (self, target) if owner.prefab ~= "YOUR_CHARACTER_PREFAB_NAME" return false end -- Run the original IsValidTarget function, if your check above has not already returned from our function. return old_IsValidTarget(self, target) end end end) The two functions in the code snippets you provided are both local functions, which makes them hard to extend. To do it right, meaning not just copying them and replacing them, there would have to be non-local functions available to change those local functions in the bees, and there aren't.
  14. VergilRainOut is wrong. You just check whether the moisture component is on the player, and if it is not nil, you don't do anything. The moisture component never goes anywhere. It's always there. Just check if inst.components.moisture:GetMoisture() == 0
  15. Not really. Look at the chest prefab, or one of the many chest mods out there. There's also a bunch of mods which add more Chesters, and even one that makes it possible for everyone to have their own Chester from the start of the game.