Modders: Your new friend at Klei!

[Ipsquiggle]

From WX78 this gives him his perk: inst.components.eater.ignoresspoilage = trueBut it's limited to food that didn't turn into rot. Idon't know how to make rot give hunger to my character.

Right: What I mean is, look at the way the ignorespoilage flag is used through the eating process to alter the amount of hunger a food gives the character. You could add an "ignorerot" flag that works similarly, replacing the health and hunger values when the food being eaten is a spoiled_food.

[infernalthing]

Right: What I mean is, look at the way the ignorespoilage flag is used through the eating process to alter the amount of hunger a food gives the character. You could add an "ignorerot" flag that works similarly, replacing the health and hunger values when the food being eaten is a spoiled_food.

How can I make it change the values of TUNING.SPOILED_HEALTH and TUNING.SPOILED_HUNGER?

[BURNY26]

Hey, welcome to the forum! :)Depending on your level of skill: If you've programmed before in other languages, the Lua Manual is a good place to start for understanding the language. http://www.lua.org/manual/5.1/If you've never programmed, I recommend http://www.codecademy.com/ for an introduction to the basics.As far as the Don't Starve API, well, there isn't really one... modders have access to basically any function in the game, so the best way to learn is to find an existing object in the game or a mod that's similar to what you envision, and start picking it apart. Start with something simple, not your boldest plan, and see if you can make it happen. As you work with the system it'll start becoming more clear to you how things are accomplished and where to look for functions and features.Also, don't be afraid to ask specific questions in these forums!

I see ,thank you for your reply ;very much appreciated

[tehMugwump]

[MENTION=55]Ipsquiggle[/MENTION] I've been trying to figure this out since caves. I can't get all the different types of stalagmites and stalagmite_talls to spawn, only the base versions:

{text = "Stalagmite 1", data = "stalagmite"}, --works{text = "Stalagmite 2", data = "stalagmite_med"}, --crash{text = "Stalagmite 3", data = "stalagmite_low"}, --crash---- Tall Stalagmites{text = "Stalagmite 4", data = "stalagmite_tall"}, --works{text = "Stalagmite 5", data = "stalagmite_tall_med"}, --crash{text = "Stalagmite 6", data = "stalagmite_tall_low"}, --crash

This seems to be the only thing in the lua to grab.

lua files:

return Prefab("cave/objects/stalagmite_full", fullrock, stalagmite_assets, prefabs),Prefab("cave/objects/stalagmite_med", medrock, stalagmite_assets, prefabs),Prefab("cave/objects/stalagmite_low", lowrock, stalagmite_assets, prefabs),Prefab("cave/objects/stalagmite", fullrock, stalagmite_assets, prefabs) return Prefab("cave/objects/stalagmite_tall_full", fullrock, stalagmite_tall_assets, prefabs),Prefab("cave/objects/stalagmite_tall_med", medrock, stalagmite_tall_assets, prefabs),Prefab("cave/objects/stalagmite_tall_low", lowrock, stalagmite_tall_assets, prefabs),Prefab("cave/objects/stalagmite_tall", fullrock, stalagmite_tall_assets, prefabs)

HOWEVER, grabbing the same names in the rocks.lua file works as expected:

{text = "Boulder 1", data = "rock1"}, --works	{text = "Boulder 2", data = "rock2"}, --works	{text = "Boulder 3", data = "rock_flintless"}, --works

rocks.lua:

return Prefab("forest/objects/rocks/rock1", rock1_fn, rock1_assets, prefabs),        Prefab("forest/objects/rocks/rock2", rock2_fn, rock2_assets, prefabs),        Prefab("forest/objects/rocks/rock_flintless", rock_flintless_fn, rock_flintless_assets, prefabs)

Edited June 14, 2013 by tehMugwump

[zeidrich]

Hey [MENTION=10028]tehMugwump[/MENTION],The game doesn't use those prefabs, and their functions are incorrectly written. They use the value TUNING.ROCKS which is undefined. If you put somewhere in the front of modmain

TUNING = GLOBAL.TUNINGTUNING.ROCKS = TUNING.ROCKS_MINE

I think that would correct the issue. The game actually only spawns stalagmites and uses the workcallback to change animation to show semi-depleted versions.

[zeidrich]

So last night I was doing some work on my zombie stuff.Making walls in the game right now is tedious and a bit clunky, so I wanted to clear that up. I identified 3 issues I wanted to correct.1) The placer is overridden by entities under the mouse cursor, so you often end up targeting the wall and repairing, or losing the placer because of things partially occluding the space.2) If you right click to place while your cursor is over the player, you will place the object but the stack will return to your inventory.3) The deploy action has the player move to the center position of the wall you're placing, places it, and turns on collision pushing the player away. This creates a jerky camera action which makes it hard to place a straight line of walls. I was able to correct all actions except #3 , but with each I had some issues.1) The solution for this is in playeractionpicker. Particularly in PlayerActionPicker:DoGetMouseActions line 264. I changed

local ents = TheInput:GetAllEntitiesUnderMouse()

To

local 

To allow for player to override selecting world entities by holding the shift key. However, the least intrusive way I could find to override that was by going:

AddComponentPostInit("playeractionpicker", function(PlayerActionPicker)function PlayerActionPicker:DoGetMouseActions( )        local highlightdude = nil    local action = nil    local second_action = nil        --if true then return end    local hud = TheInput:GetHUDEntityUnderMouse()    if not hud then            local target = nil        local ents = ents = (function() if not TheInput:IsKeyDown(GLOBAL.KEY_SHIFT) then TheInput:GetAllEntitiesUnderMouse() else {} end)()---snip the rest of the function but it's copy/pastedendend)

Which requires a whole load of imports from GLOBAL to let the copy/pasted stuff work properly. Right now I have a supplementary lua file that mostly handles just imports. 2) This was more annoying. The issue causing the player to drop their stack when they right click on a valid placement location (but over the player) is due to widgets\inventorybar.lua:72

    self.inst:ListenForEvent("rightmousedown", function(inst, data) self:Cancel() end, self.owner)

I wanted to just remove the listener, but damn it if for the life of me I couldn't remove that callback. The RemoveEventCallback method requires the function assigned as a parameter. Since the function is inline, that wasn't trivial for me to access. I tried everything I could think of, including iterating through inv.inst.entitity_listeners and inv.inst.entity_listening and trying to get a reference to the function. Nothing worked.Ultimately, what I ended up doing was creating a postinit for the player where I overrode GetPlayer().HUD.controls.inv.Cancel so it did nothing. I don't know what sort of overall impact that will have so it requires more testing. But inv:Cancel() doesn't get called frequently, so I think it's a solvable problem. What can I do in that sort of circumstance?3) This one wasn't solvable, at least not last night. I learned a lot about the interactions between locomotor/ actions/ stategraphs/ depolyable. Unfortumately, what I learned wasn't that helpful. The problem is just that the deployment creates a sort of stack on bufferedactions to send the player to the exact center point and then place the wall there, essentially on top of the player and rely on the physics to push the player out of the way. I could make the player place walls without moving, but I couldn't easily move the player nearby and place when the player is within range. This is because the way locomotor passes the destination to the deployment action. If I change the destination, I change where the deployment happens. What I'd like to do is have the player walk to a point that is point-radius, and then deploy at point. My next attempt was trying to disable physics for a short period of time, a second or two. This had the initial hilarious effect of just having the walls fall through the floor. I fixed that though, and it worked in practice, but had a different issue. There is no test for the wall placer. The way the wall placement works is basically just as long as the placer is on the map, it assumes it's valid. The game relies on the fact that if you try to place on top of another wall you will either not path to it, or you will not be able to select that ground location because the mouse will be over another entity and overriding the right-click action. Since I had implemented #1 already, that meant that you could hold shift and place multiple walls in the same location. I think to properly fix it I would need to implement some real test to tell whether the wall placement location is valid. Then I could disable player collision while placing. I would like to be able to implement that "place from maximum radius" feature, but I'd still have to fix the placement question anyways. If I didn't do that, you'd still be able to place multiples since it just relies on the fact that the player cant get there. I think it might be possible to use GetWorld().Pathfinder to help with the wall testing, if I have to iterate through all world entities with the "wall" tag that would be annoying, probably not horrible though since you only call it once per second or so while deploying.It was pretty fun to work through, but I wonder if any of those things I could do better. Right now wall placement feels much nicer, especially with the broken #3 turned on (so you can place multiple walls on the same point). But it seemed like I had to make too sweeping of changes. I had to replace the entirety of a pretty key PlayerActionPicker function, I had to disable a function because I couldn't figure out how to unregister the callback. I would be curious about better ways to deal with these problems.

[tehMugwump]

[MENTION=38597]zeidrich[/MENTION], yeah I noticed the stalagmites are being pulled from animation files now. This makes it impossible to place the other variations with Test Tools and also makes it impossible to mine them and throw the drops in your inventory via Insta Rocks and Trees because they aren't defined as individual prefabs.

Adding the TUNING lines didn't help since I'm calling the prefabs from outside the files and the prefabs, really, don't exist.

Evergreens, mushtrees and regular rocks all work great and are written in the same way, but I guess someone found a fancier way to do the stalagmites.

Hey [MENTION=10028]tehMugwump[/MENTION],

The game doesn't use those prefabs, and their functions are incorrectly written.

They use the value TUNING.ROCKS which is undefined. If you put somewhere in the front of modmain

TUNING = GLOBAL.TUNINGTUNING.ROCKS = TUNING.ROCKS_MINE

I think that would correct the issue. The game actually only spawns stalagmites and uses the workcallback to change animation to show semi-depleted versions.

[zeidrich]

[MENTION=38597]zeidrich[/MENTION], yeah I noticed the stalagmites are being pulled from animation files now. This makes it impossible to place the other variations with Test Tools and also makes it impossible to mine them and throw the drops in your inventory via Insta Rocks and Trees because they aren't defined as individual prefabs.

Adding the TUNING lines didn't help since I'm calling the prefabs from outside the files and the prefabs, really, don't exist.

Evergreens, mushtrees and regular rocks all work great and are written in the same way, but I guess someone found a fancier way to do the stalagmites.

Sure the prefabs exist. Their problem is that their init functions are broken.

I noticed the first issue, which was the TUNING.ROCKS which was nil, but the other issue is that it's doing isnt.components.workable:SetWorkLeft()

local function fullrock()	local inst = commonfn()	inst.components.lootdropper:SetLoot({"rocks", "rocks", "rocks", "goldnugget", "flint"})	inst.components.lootdropper:AddChanceLoot("goldnugget", 0.25)	inst.components.lootdropper:AddChanceLoot("flint", 0.6)	inst.AnimState:PlayAnimation("full")	return instendlocal function medrock()	local inst = commonfn()	isnt.components.workable:SetWorkLeft(TUNING.ROCKS * (2/3))	inst.AnimState:PlayAnimation("med")	inst.components.lootdropper:SetLoot({"rocks", "rocks", "flint"})	inst.components.lootdropper:AddChanceLoot("goldnugget", 0.5)	inst.components.lootdropper:AddChanceLoot("flint", 0.6)	return instendlocal function lowrock()	local inst = commonfn()	isnt.components.workable:SetWorkLeft(TUNING.ROCKS * (1/3))	inst.AnimState:PlayAnimation("low")	inst.components.lootdropper:SetLoot({"rocks", "flint"})	inst.components.lootdropper:AddChanceLoot("goldnugget", 0.25)	inst.components.lootdropper:AddChanceLoot("flint", 0.3)	return instend

Why not just define your own prefabs for those two rock states? Regular rocks use animations just the same as stalagmites to show partially mined out rocks. They don't have prefabs which are partially mined either. For instance, rocks are just rock1, rock2 and rockflintless, which correspond to nitre rocks, gold rocks and boulders. There's no rock1_med prefab, and no need for one really.

[tehMugwump]

Yeah, I think this may be the way to go. I may be over/under thinking this. Got things partially working so there may be hope. One thing that may be throwing me is there's different images for the same stalagmite, so it may not be so bad after all...

Sure the prefabs exist. Their problem is that their init functions are broken.

I noticed the first issue, which was the TUNING.ROCKS which was nil, but the other issue is that it's doing isnt.components.workable:SetWorkLeft()

local function fullrock()	local inst = commonfn()	inst.components.lootdropper:SetLoot({"rocks", "rocks", "rocks", "goldnugget", "flint"})	inst.components.lootdropper:AddChanceLoot("goldnugget", 0.25)	inst.components.lootdropper:AddChanceLoot("flint", 0.6)	inst.AnimState:PlayAnimation("full")	return instendlocal function medrock()	local inst = commonfn()	isnt.components.workable:SetWorkLeft(TUNING.ROCKS * (2/3))	inst.AnimState:PlayAnimation("med")	inst.components.lootdropper:SetLoot({"rocks", "rocks", "flint"})	inst.components.lootdropper:AddChanceLoot("goldnugget", 0.5)	inst.components.lootdropper:AddChanceLoot("flint", 0.6)	return instendlocal function lowrock()	local inst = commonfn()	isnt.components.workable:SetWorkLeft(TUNING.ROCKS * (1/3))	inst.AnimState:PlayAnimation("low")	inst.components.lootdropper:SetLoot({"rocks", "flint"})	inst.components.lootdropper:AddChanceLoot("goldnugget", 0.25)	inst.components.lootdropper:AddChanceLoot("flint", 0.3)	return instend

Why not just define your own prefabs for those two rock states? Regular rocks use animations just the same as stalagmites to show partially mined out rocks. They don't have prefabs which are partially mined either. For instance, rocks are just rock1, rock2 and rockflintless, which correspond to nitre rocks, gold rocks and boulders. There's no rock1_med prefab, and no need for one really.

[simplex]

3) The deploy action has the player move to the center position of the wall you're placing, places it, and turns on collision pushing the player away. This creates a jerky camera action which makes it hard to place a straight line of walls.

I believe I came up with a solution, even though it's more hackish than I'd like. It consists on extending a bit the behaviour of the component PlayerActionPicker by allowing a component to return a BufferedAction from CollectPointActions, and not only Actions which will only later be turned into BufferedActions with hardcoded parameters given to the constructor. By doing this modification, I was able to provide a value to the "distance" parameter in the BufferedAction constructor, creating the effect that you wanted. In order to make the code base work with this modification, all I had to do was tweak PlayerActionPicker:SortActionList a bit, since that's the only place in the entire game code that uses the return values from CollectPointActions.

local BufferedAction = GLOBAL.BufferedActionlocal ACTIONS = GLOBAL.ACTIONSlocal Action = GLOBAL.Actionfunction deployablepostinit(Deployable)	function Deployable:CollectPointActions(doer, pos, actions, right)		if right then			print(self.min_spacing)			table.insert(actions, BufferedAction(doer, nil, ACTIONS.DEPLOY, self.inst, pos, nil, math.max(self.min_spacing, 1)))		end	endendfunction playeractionpickerpostinit(PlayerActionPicker)	function PlayerActionPicker:SortActionList(actions, target, useitem)		if #actions > 0 then			local function AsAction(a)				if a:is_a(BufferedAction) then					return a.action				else					return a				end			end				table.sort(actions, function(l, r) return AsAction(l).priority > AsAction(r).priority end)				local ret = {}			for k,v in ipairs(actions) do				if v:is_a(BufferedAction) then					table.insert(ret, v)				elseif not target then			                table.insert(ret, BufferedAction(self.inst, nil, v, useitem))				elseif target:is_a(EntityScript) then			                table.insert(ret, BufferedAction(self.inst, target, v, useitem))		            	elseif target:is_a(Vector3) then			                table.insert(ret, BufferedAction(self.inst, nil, v, useitem, target))				end			end			return ret		end	endendAddComponentPostInit("deployable", deployablepostinit)AddComponentPostInit("playeractionpicker", playeractionpickerpostinit)

A minor digression: when I was toying with the above code I found that when the distance parameter of the BufferedAction constructor is zero (and by zero I mean really zero, not nil), the character just keeps spinning above the destination point (probably due to some lacking test regarding epsilon correction in f.p. arithmetic, but I'll have to check locomotor.lua more carefully). It looks exactly like the current bug with bees and butterflies spinning above flowers, so maybe that's the cause... Anyway, I'll have to check it later when I have the time.

Edited June 14, 2013 by simplex

[zeidrich]

Yeah, I considered something like that, but I wasn't really sure how to go about it. That's pretty clever, but I agree, pretty hackish.The other thing I was considering was storing some value with the entity that would basically augment the value of the position when the player walks to the point, but not for where the deployment happens. Similar setup, I was just going to use a property of the entity rather than finding a way to send another parameter. Your way probably works more reliably, I threw my idea out because I don't know when the BufferedAction's going to execute, and having some random offset to walk positions is opening a can of worms. Only passing the extra parameter on deployment makes it more comfortable. I think Buffered Actions and Event Listeners are pretty tricky to work with right now. I need to pay them some more attention. I wish I was better at lua; I'm still clumsy with tables. Thanks for the help, I'll maybe see if I can get it to do what I want it to using that method.

[simplex]

Yeah, I considered something like that, but I wasn't really sure how to go about it. That's pretty clever, but I agree, pretty hackish.The other thing I was considering was storing some value with the entity that would basically augment the value of the position when the player walks to the point, but not for where the deployment happens. Similar setup, I was just going to use a property of the entity rather than finding a way to send another parameter. Your way probably works more reliably, I threw my idea out because I don't know when the BufferedAction's going to execute, and having some random offset to walk positions is opening a can of worms. Only passing the extra parameter on deployment makes it more comfortable. I think Buffered Actions and Event Listeners are pretty tricky to work with right now. I need to pay them some more attention. I wish I was better at lua; I'm still clumsy with tables. Thanks for the help, I'll maybe see if I can get it to do what I want it to using that method.

Yeah, I wish there was a less hackish way, but I don't believe there is. Those BufferedActions are never exposed, they are collected and then used. So a mod can't really change what's going on as long as it just behaves "nicely". It would be interesting, regarding mods, if the API was extended so as to allow the attachment of filters to a queue within the PlayerActionPicker component, that would be applied through the list of gathered BufferedActions (I mean, the list of default BufferedActions built from the collected Actions) when any of the PlayerActionPicker:Get<SOMETHING>Actions methods were called. That way one could just attach a filter that would change the distance of some BufferedActions, for instance.It's a coincidence really that I've been working on a mod that basically only deals with Actions and Events, so I got somewhat used to them. The mod I'm working on is a tool for automating repetitive tasks that become quite frustrating in old worlds with big bases, such as "pickup all inventoryitems within some radius satisfying some condition", "pick all grass within some radius", "harvest all crops within some radius and, after harvesting a crop, replant it if carrying a matching crop seed", "dig all stumps within some radius and, after digging a stump, replant the tree if carrying a pine cone", and other stuff like that. Most of the mod code is really about approximating a solution to the Traveling Salesman Problem, without any mention to the DS API whatsoever, but the rest is all about Actions and Events. The mod functionality is actually complete, and it has been working flawlessly (at least for me) through a console interface for a bit under two weeks now. I just have to summon the will to design a graphical interface in order to release it... And since GUIs are really not my thing, that may take a while.

[zeidrich]

It's funny. I wrote an essay about how this game is essentially a traveling salesman problem. It was much deeper than that, but at it's core the fact that it's a TSP and that the TSP is NP-hard is the reason that it makes a good game. You have a number of resource nodes scattered around the world, you have increasing stresses on you, so you are required to gather your resources as efficiently as problem. It's fun because humans are good at finding a "pretty-good" solution to the problem intuitively, but there's always room for improvement, and you can never really tell if you're doing it optimally or not. Now, of course, the traveling salesman problem gets a lot easier when the salesman can take a shovel and uproot all of his customers' houses and plant them back down in a ring, but still. I think all of that action/event learning would be really useful for making interesting brain behavior. The brain nodes and stategraphs are something else I want to spend a bit more time understanding. I think that having a pet that automated repetitive tasks for you would be more interesting than compelling the player to do it anyways.

[simplex]

It's funny. I wrote an essay about how this game is essentially a traveling salesman problem. It was much deeper than that, but at it's core the fact that it's a TSP and that the TSP is NP-hard is the reason that it makes a good game. You have a number of resource nodes scattered around the world, you have increasing stresses on you, so you are required to gather your resources as efficiently as problem. It's fun because humans are good at finding a "pretty-good" solution to the problem intuitively, but there's always room for improvement, and you can never really tell if you're doing it optimally or not.

I feel the same way. Playing DS is essentially trying to solve the TSP problem where each edge's weight is a random variable, whose distribution you learn to estimate as you get better at the game. Can I find this essay anywhere?

I think all of that action/event learning would be really useful for making interesting brain behavior. The brain nodes and stategraphs are something else I want to spend a bit more time understanding.

I also want to take a closer look at it. But by my overlook of it, it seems like a standard finite-state automaton. There is the attribute statemem, though. That may change the field completely. It may allow the brain to operate as a stack-based automaton.

I think that having a pet that automated repetitive tasks for you would be more interesting than compelling the player to do it anyways.

That's a really good idea! And trivially implementable on top of my mod, since it operates on an arbitrary EntityScript, which only takes GetPlayer() as a default value. The "minion" only needs to have the required components.

[Ipsquiggle]

Hey fellas. Sorry, I started looking into some solutions for zeidrich's questions, got distracted by some server issues, and then all this was here ^^^ :DBufferedActions are a bit, er, gnarly. If you don't have a satisfactory answer yet, I can look into it next week.

[eLe]

How would I change the container slot background tint in modmain.lua (or alternately, how would I make an addon widget.lua to containwidget.lua?).

[ggolddragonn]

When test tools will come for It's not a Rock! version? I don't use it on survival, but I use it to learn the game, try something, and more. Using console is really long and boring.

[tehMugwump]

When test tools will come for It's not a Rock! version? I don't use it on survival, but I use it to learn the game, try something, and more. Using console is really long and boring.

It's already out here >>

[infernalthing]

I have questions about anim.bin found in the animation zip files.Do they require build rennamer?I tried to create a new equipable item and it doesn't show up on the ground.Edit: It also doesn't show up in hand. Only inventory image.

Edited June 15, 2013 by infernalthing

[no_signal]

How would I change the container slot background tint in modmain.lua (or alternately, how would I make an addon widget.lua to containwidget.lua?).

Is this what you're talking about.image

code

local function classPostInit(name, postInit)	local class = GLOBAL[name]	local constructor = class._ctor	class._ctor = function (self, ...)		constructor(self, ...)		postInit(self, ...)	end	mt = GLOBAL.getmetatable(class)	mt.__call = function(class_tbl, ...)                local obj = {}                GLOBAL.setmetatable(obj, class)                if class._ctor then                        class._ctor(obj, ...)        end        return obj    endend------local function InvSlotPostInit(self)--                   SetTint(r,g,b,a)	self.bgimage:SetTint(0.2, 0.2, 1, 1)endGLOBAL.require "widgets/inventoryslot" classPostInit("InvSlot", InvSlotPostInit)

[eLe]

Something like that, yeah thanks. Gonna test that right now. UuU

Edit: Alright, that works for colouring every inv slot. How would I go about doing something like this:

Here's the code: http://pastebin.com/mPqmD9yu

Edited June 15, 2013 by eLe

[no_signal]

Something like that, yeah thanks. Gonna test that right now. UuU

Edit: Alright, that works for colouring every inv slot. How would I go about doing something like this:

Here's the code: http://pastebin.com/mPqmD9yu

try replacing

local function InvSlotPostInit(self)--               SetTint(r,g,b,a)	self.bgimage:SetTint(0.2, 0.2, 1, 1)end

with

local function InvSlotPostInit(self, num, bgim, owner, container)	if container.widgetbgimagetint then                self.bgimage:SetTint(                        container.widgetbgimagetint.r,                        container.widgetbgimagetint.g,                        container.widgetbgimagetint.b,                        container.widgetbgimagetint.a                )        endend

[eLe]

[awesome stuff]

Oh mannn it works! Now to try cleaning up the code, an' releasing it, all before I have to leave for work. :U

[BURNY26]

Is it possible to use Netbeans for IDE for luafiles? I was able to install a plugin for Netbeans but unfortunatly i cant start a new project in lua (since i cant see it between the options) and even if i open an alrdy existing file from DS in netbeans I cant let it run.What am i doing wrong? Is it even possible to 'run' a luafile for bugs?Do I need to use another IDE ?

[eLe]

[netbeans stuff]

Actually, you can can use notepad++ with the lua checker plugin (haven't tested it yet; I'll make an edit in a sec post test though UuU).You can also try lua-checker or LuaEdit to check if the syntax is correct. UuUEdit: Ok the notepad++ syntax checker seems to work. :U Edited June 16, 2013 by eLe