Modders: Your new friend at Klei!

[RazvanM]

@Ipsquiggle - I see you had a LOT of work after the weekend, glad you are still holding on, and you are still helping us.

- Destroy issue, yes eventually I found that I can track the "killed" event and used that.

- Regarding custom data, well, this is more involved, I have an idea about custom scripts on custom maps, I guess currently there is no need for custom storage, even if I need it I will just replace the Save / Load methods.

@tehMugwump - It should work, I got a chance to test it

AddComponentPostInit("pickable", function(comp)      comp.Fertilize = function(fertilize)           print "we are here!"           comp.cycles_left = comp.max_cycles           comp:MakeEmpty()      endend)AddComponentPostInit("pickable", fertilize)

well I think I know why it is not working. The first AddComponentPostInit is placing a custom method on the pickable component, the second one is placing "nil" (fertilize I assume is not defined anywere), just keep the first one

AddComponentPostInit("pickable", function(comp)      comp.Fertilize = function(fertilize)           print "we are here!"           comp.cycles_left = comp.max_cycles           comp:MakeEmpty()      endend)

Edited May 28, 2013 by RazvanM

[tehMugwump]

@tehMugwump - It should work, I got a chance to test it

AddComponentPostInit("pickable", function(comp)      comp.Fertilize = function(fertilize)           print "we are here!"           comp.cycles_left = comp.max_cycles           comp:MakeEmpty()      endend)AddComponentPostInit("pickable", fertilize)

well I think I know why it is not working. The first AddComponentPostInit is placing a custom method on the pickable component, the second one is placing "nil" (fertilize I assume is not defined anywere), just keep the first one

AddComponentPostInit("pickable", function(comp)      comp.Fertilize = function(fertilize)           print "we are here!"           comp.cycles_left = comp.max_cycles           comp:MakeEmpty()      endend)

[MENTION=23863]RazvanM[/MENTION], thanks for looking at this. What I need it to do, though, is NOT remove the poop when you use it (I have other uses for it, haha). Placed in the modmain, this may over write the existing function (I can't tell because I'm not getting my print statement), but I don't think it's nullifying the fertilizer:Remove() line...

[Heavenfall]

I know it sounds strange, but I don't think the fertilizer:Remove() line is actually removing the poop. I removed it from the game's .lua and the poop still disappears. So I think there's something else going on, some function moving the poop somewhere or using it somehow.The remove() line is probably added to delete the poop once it ends up in this "limbo".

Edited May 28, 2013 by Heavenfall

[RazvanM]

@tehMugwump - Following is the solution, just copy / paste in modmain

AddComponentPostInit("pickable", function(comp)      comp.Fertilize = function(self, fertilizer)           GLOBAL.GetPlayer().components.inventory:GiveActiveItem(fertilizer)           self.cycles_left = self.max_cycles           self:MakeEmpty()      endend)

Heavenfall is correct, the fertilizer is removed from inventory before the Fertilize method is called. So you need to give it back to the player.

PS. Forgot something, in order for this to work you need to have only one AddComponentPostInit for the "pickable" component, and in general for every component, if you have another one

AddComponentPostInit("pickable" ..... replace fertilize)

AddComponentPostInit("pickable" ..... something else)

The last one will be executed and taken into account, just merge them. I believe that is why you did not get the print msg.

Edited May 28, 2013 by RazvanM

[zeidrich]

Because I like to go over this myself to understand, I'll do it out loud because that's fun.The poop prefab has the fertilizer component added to it.The fertilizer component collects user actions for the entities with crop, grow, and pickable components when appropriate and assigns them the ACTIONS.FERTILIZE action.ACTIONS.FERTILIZE is

ACTIONS.FERTILIZE.fn = function(act)    if act.target.components.crop and not act.target.components.crop:IsReadyForHarvest() and act.invobject and act.invobject.components.fertilizer then		local obj = act.doer.components.inventory:RemoveItem(act.invobject)        if act.target.components.crop:Fertilize(obj) then			return true		else			act.doer.components.inventory:GiveItem(obj)			return false		end    elseif act.target.components.grower and act.target.components.grower:IsEmpty() and act.invobject and act.invobject.components.fertilizer then		local obj = act.doer.components.inventory:RemoveItem(act.invobject)        act.target.components.grower:Fertilize(obj)	elseif act.target.components.pickable and act.target.components.pickable:CanBeFertilized() and act.invobject and act.invobject.components.fertilizer then		local obj = act.doer.components.inventory:RemoveItem(act.invobject)        act.target.components.pickable:Fertilize(obj)		return true			endend

Where the first line is local obj = act.doer.components.inventory:RemoveItem(act.invobject)RazvanM's solution is good. Adding it back in is probaby the best way, if you wanted to worry about the other things you can fertilize, apart from grass and bushes, I'd add:

local function ReplaceFertilizer(comp)      local oldFertilize = comp.Fertilize      comp.Fertilize = function(self, fertilizer)           oldFertilize(self, fertilizer)           GLOBAL.GetPlayer().components.inventory:GiveActiveItem(fertilizer)      endendAddComponentPostInit("pickable", ReplaceFertilizer(comp))AddComponentPostInit("grower", ReplaceFertilizer(comp))AddComponentPostInit("crop", ReplaceFertilizer(comp))

The other thing I'd be a bit concerned about is that really anyone can be a fertilizer. A pig for instance could fertilize a crop if its little piggy brain could support it. However, the pickable.Fertilize function doesn't pass the doer, it only passes the object that's used to fertilize the crop. This would pose a problem if any other entity ever fertilized a crop, as it would put all of that fertilizer into the player's inventory.[e] Actually, looking over Razvan's code I did decide to make a change. Rather than rewrite the whole function, I just call the original function and add the fertilizer back to the player afterwards. This is more important when I'm doing the same thing for three different components. Edited May 28, 2013 by zeidrich

[RazvanM]

@zeidrich - I don't think that will work, calling the old handler means that fertilizer:Remove will be called, Remove will actually take out the item from the gameworld, adding it back might not really work.

[tehMugwump]

Because I like to go over this myself to understand, I'll do it out loud because that's fun.The poop prefab has the fertilizer component added to it.The fertilizer component collects user actions for the entities with crop, grow, and pickable components when appropriate and assigns them the ACTIONS.FERTILIZE action.ACTIONS.FERTILIZE is

ACTIONS.FERTILIZE.fn = function(act)    if act.target.components.crop and not act.target.components.crop:IsReadyForHarvest() and act.invobject and act.invobject.components.fertilizer then		local obj = act.doer.components.inventory:RemoveItem(act.invobject)        if act.target.components.crop:Fertilize(obj) then			return true		else			act.doer.components.inventory:GiveItem(obj)			return false		end    elseif act.target.components.grower and act.target.components.grower:IsEmpty() and act.invobject and act.invobject.components.fertilizer then		local obj = act.doer.components.inventory:RemoveItem(act.invobject)        act.target.components.grower:Fertilize(obj)	elseif act.target.components.pickable and act.target.components.pickable:CanBeFertilized() and act.invobject and act.invobject.components.fertilizer then		local obj = act.doer.components.inventory:RemoveItem(act.invobject)        act.target.components.pickable:Fertilize(obj)		return true			endend

Where the first line is local obj = act.doer.components.inventory:RemoveItem(act.invobject)RazvanM's solution is good. Adding it back in is probaby the best way, if you wanted to worry about the other things you can fertilize, apart from grass and bushes, I'd add:

local function ReplaceFertilizer(comp)      local oldFertilize = comp.Fertilize      comp.Fertilize = function(self, fertilizer)           oldFertilize(self, fertilizer)           GLOBAL.GetPlayer().components.inventory:GiveActiveItem(fertilizer)      endendAddComponentPostInit("pickable", ReplaceFertilizer(comp))AddComponentPostInit("grower", ReplaceFertilizer(comp))AddComponentPostInit("crop", ReplaceFertilizer(comp))

The other thing I'd be a bit concerned about is that really anyone can be a fertilizer. A pig for instance could fertilize a crop if its little piggy brain could support it. However, the pickable.Fertilize function doesn't pass the doer, it only passes the object that's used to fertilize the crop. This would pose a problem if any other entity ever fertilized a crop, as it would put all of that fertilizer into the player's inventory.[e] Actually, looking over Razvan's code I did decide to make a change. Rather than rewrite the whole function, I just call the original function and add the fertilizer back to the player afterwards. This is more important when I'm doing the same thing for three different components.

 

Currently using this in the modmain:

GLOBAL.ACTIONS.FERTILIZE.fn = function(act)    if act.target.components.crop and not act.target.components.crop:IsReadyForHarvest() and act.invobject and act.invobject.components.fertilizer then        --local obj = act.doer.components.inventory:RemoveItem(act.invobject)        local obj = act.invobject        if act.target.components.crop:Fertilize(obj) then			return true		else			act.doer.components.inventory:GiveItem(obj)			return false		end    elseif act.target.components.grower and act.target.components.grower:IsEmpty() and act.invobject and act.invobject.components.fertilizer then		--local obj = act.doer.components.inventory:RemoveItem(act.invobject)        local obj = act.invobject        act.target.components.grower:Fertilize(obj)	elseif act.target.components.pickable and act.target.components.pickable:CanBeFertilized() and act.invobject and act.invobject.components.fertilizer then		--local obj = act.doer.components.inventory:RemoveItem(act.invobject)        local obj = act.invobject        act.target.components.pickable:Fertilize(obj)		return true			endend

Yeah, I've done the adding back thing as a last resort. What the point of this while endevor is, I'm adding finiteuses to poop, so one poop (for example) will have 10 uses. Got it all working except for the remove line. Giving it back will probably lose the count tho...Thanks, all, for the help. Should be able to make something work out of all this.

Edited September 26, 2013 by JoeW

[zeidrich]

@zeidrich - I don't think that will work, calling the old handler means that fertilizer:Remove will be called, Remove will actually take out the item from the gameworld, adding it back might not really work.

You're right of course, I missed that because I quickly went back and changed that without looking at the Fertilize method when I considered that crops and growers and pickables might fertilize differently.

I prefer to augment functionality than replace it, but it's not always reasonable. I think the way you might go about that would be something like:

 

local function ReplaceFertilizer(comp)      local oldFertilize = comp.Fertilize      comp.Fertilize = function(self, fertilizer)            newfertilizer = CloneFertilizer(self, fertilizer) -- This creates a new fertilizer entity with its durability decremented             oldFertilize(self, fertilizer)             GLOBAL.GetPlayer().components.inventory:GiveActiveItem(newfertilizer)      endend

Probably not worth it though.

[Ipsquiggle]

@Ipsquiggle can you please consider making the height of the CraftTabs (crafting.lua) dynamic after the amount of different RECIPETABS? Currently, if we want to add a new craft tab, it will push itself outside the background of the crafttabs, and we have to provide an override for crafting.lua with our mods as a result.

Cool. There are quite a number of areas where things are hard-coded that could be flexible, and it's my mission to root them all out -- it makes your lives much easier... and ours as well! I've added this to the list. No promises on when though...

[Muffinsforever]

I had this idea a while back, and with the implementation of caves, it became more obvious as a possibility. Would it be feasible to make a house, now that we can have a world and instances attached to them?And with the coding, can both worlds run along side each other or will one essentially stop if the character/player isn't in that instance? I'm assuming "no" unless one is a coding guru, and even then interaction of the world with the house would be an interesting prospect.And yes, I know this is a survival game, but if you get a modding scene going, it can become a lot more than that.Also... on a more unrelated topic, is it possible for a fuction/script to be added that allows the game to duplicate itself and files to another location on the computer while playing, and with constant updating? Random I know, but it would be cool for multiple purposes.

[_Q_]

[MENTION=55]Ipsquiggle[/MENTION] Or someone who knows. How to alter class definition from modmain file?

[Ipsquiggle]

A class is just a table like any other ( see scripts/class.lua for how our classes are made! )So you can modify its data just by reading and writing like any other table. Like this:

-- a class is defined somewhereFoo = Class(function(self)  print("Basic constructor")end)-- note that when a class method is defined with a colon : it automatically-- gets "self" as its first parameter, invisiblyfunction Foo:Action(num)  print("Basic action")  print(num)endmyFoo = Foo()myFoo:Action(1)-- then modify it-- So when you overwrite it, you have to manually mention self as the first param.Foo.Action = function(self, num)  print( "Modded action")  print(num)end-- The constructor is hidden in the ._ctor value:Foo._ctor = function(self)  print( "Modded constructor")endmyFoo = Foo()myFoo:Action()

Does that make sense?

[zeidrich]

I like to play with terrain generation. I got my hopes up when I looked at the pitchfork and saw how easy it could terraform.Then I looked at the map folder and got my hopes back down again. The map is a Voronoi graph, which is kind of necessary because of the lock and key story system. I'm fine with that but I was hoping that there was some way that I could manipulate the terrain data of an individual node in world gen.I look at something like the GROUND.GROUND_NOISE type, which seems to use some kind of noise function which you can see in game when in many surface tasks, but I can't track down any reference to any script doing anything with that. the Map class has a few Perlin noise functions, but I can't see if or where they are used. In fact, I'm not even certain where or if map.lua is used. I almost want to just start removing chunks from it and seeing what breaks. Is it possible in some way to change the terrain fill function of a graph node by a script override? Or is that something all hidden away in WorldSim?I mean, I suppose I could do some map manipulation after world gen, something like creating a terrain type that's something unused, like GROUND.WALL_ROCKY on the surface, defining a terrain type that uses this type, then iterating over the whole map and using SetTile to apply my own function, and rebuild the layers. I suppose if I wanted different types of environments I could use some of the other cave-related stuff, like guano on map-gen and replace them, so I could have different parameters and replace them with different function's results.This is probably too esoteric to be a feature request, I just want to know if there's another way to do what I'm trying to do in map generation. Most terrain nodes are flood filled, but the BGNoise (and I think BGNoisyCave and BGNoisyFungus do too) uses some noise function. Is there any way I can manipulate that noise function? I'm thinking the answer is "not easily". I might try something like my previous idea. I'll report back, seems like a fun puzzle!

[borrisb]

A lot of us are getting to corners of the code in an analogous evolution sort of way. I have been curious if my following thoughts about what a biome is vs the cosmetic view (turf) of the biome is. Can someone confirm or deny if the following assumptions are correct in the current game?When an individual square in a Biome is created (assuming the game recognizes the concept of an individual square before it's turf is changed), and let's say this individual square is savannah, that savannah square will always be treated as a savannah no matter what turf is on it. When I use the pitchfork on the savannah square, I only change it's view, not the underlying model (some isSavannah flag still equals true). That is why I can't move grass over to the savannah, plant bee boxes, plant lots of butterflies, and no matter how long I let it sit, even if I have replaced lots of savannah turfs with grass turfs, the fact that the underlying square isSavannah is what controls flower spawning. I will never see a flower spawn because I'm in a savannah biome.

[zeidrich]

It's not really a biome, it's a node.http://mathworld.wolfram.com/VoronoiDiagram.htmlWhat happens is this:First you have a story. A story is what the map gets generated by. The story is something like this:You will have the tasks:Make a PickMeet the KingThe HuntersYou may have 2 of these tasksMagic MeadowNecronomiconThe Deep ForestSo then you look at tasks. Tasks have locks and keys. A task provides a key when the map generator goes through it, but will only be generated after it's own lock has been unlocked by a key.So for instance you might spawn in the Make a Pick area, which grants the tier 1 key. Meet the King might require a tier 1 key and grant a tier 2 key. The Hunters may require a tier 2 key. Magic Meadow might require a tier 1 key.So in that case, you would know that you would have to go from Make a Pick to Meet the King, and then The Hunters, but the Magic Meadow could branch off of any of the three tasks.So then once the tasks are defined the map sort of gets generated. A grid is defined with some distribution of points. The points are connected by lines corresponding to the graph generated by the story. These tasks each have "rooms" in them. The tasks spawn points around them corresponding to the rooms, there's also special consideration for the entrance room.The rooms are what are generally defined in terrain_types.lua, they're the sort of "this is a foresty area with few trees" kind of definitions. Some kind of displacement algorithm is applied to adjust the spacing of the rooms to account for size tunings. So then you have a voronoi graph constructed around those points.Then each of these rooms get filled in with some algorithm, typically just a flood fill, except in the noisy cases I mentioned in my post above. After that, entities get added to the nodes, I think that's done by script through graphnode.lua. Some of the network building that puts together the story graph I think might get done in network.lua.Roads are added roughly along delaunay edges.Then the map gets saved.I am not sure how much of that data gets preserved after map generation. I would look through and play with things like area_aware.lua to try and find anything else, but I'm getting the impression that all it gathers is tile data, and I think it's used for things like detecting what terrain the player is on to decide what sounds to make or how fast to go, or other types of "what is the player standing on now" events. Most of the world gen stuff is compiled though, so it's hiding. Some of the code in the scripts folder I'm pretty sure is vestigial, so it's confusing. So I guess my point is, the "biomes" are kind of rooms. They probably don't retain any memory of what they were intended to be, but I am not certain, someone who has written a map editor could tell you. I think the completed map is pretty much a 2d array. I think map floor data actually might be saved as a giant string of letters.

[borrisb]

So I guess my point is, the "biomes" are kind of rooms. They probably don't retain any memory of what they were intended to be, but I am not certain, someone who has written a map editor could tell you. I think the completed map is pretty much a 2d array. I think map floor data actually might be saved as a giant string of letters.

If it is saved, it might look something like what is found in the scripts/map/static_layouts folder, which is the main map area that I've been interested in editing. It hasn't bubbled to the top of my todo list yet, but it'll get there. What I'm most interested in is how to reliably spawn a static_layout for testing, but that's asking a question before I've looked at the code to try to figure out anything for myself.Zeidrich, you clearly have some years of experience in this field. It's good to have you in the forums.

[zeidrich]

I'm not really that good, I'm just over-excitable when something gets me interested. Plus, my own hobby projects have been in this area. I get excited about procedural generation, and I really like the survival genre, so this is sort of the perfect storm. I just like to type when I'm excited and you guys get to be my victims.I think the static layout stuff is pretty different. I think it just gets a special loader in WorldSim.I think the way the static layouts work is basically: Topology and navigation get generated, static layout's topology is placed over the existing terrain, entities are placed for the static layouts, then entities are placed for the general terrain. The thing is, even the static layouts need to hold more data than actually needs to be saved with the map, because some of that data is important when trying to fit it into the world, or fit other things around it, but is unimportant once generation is complete. At that point only the map state matters.Anyways, one interesting thing I came up with playing with this last night is that it would be possible to do something like:When a bird drops a seed on the ground (you could restrict it so that players can't do this intentionally) the seed, if left undisturbed for a period of time, turns into some piece of vegetation native to the ground type that it's left on.So for instance, maybe in a swamp a seed turns into a reed or a tentacle, in the grass it turns into a flower or a berry bush, in the savannah it turns into a grass, in the forest it turns into a mushroom or a tree.That might be kind of interesting, I'm not sure how I would balance it. You'd have to keep other birds away from eating it for potentially a long time. You could even have special things that grow unusually. But it would allow you to potentially create a small swamp and have your own reeds. But the construction of that would be very time consuming as you'd need to wait for birds to drop seeds in the swamp and then protect the seeds from being disturbed. Maybe you could create a checkerboard tile and from there a marble tree could grow. My thoughts right now are that you'd have to wait for the whole rot time of the seed for it to grow. It would be really easy to make that too strong.The other issue I would have is that birds only spawn around the player, and far away entities deactivate. I'm not sure if it would be jarring to have it happen so localized, and I also don't know if it would be too easy to "care for" a seed by letting it get dropped and then leaving the area so it goes to sleep and no birds spawn. But I think there could be some neat features based on underlying terrain. You might have monsters that can't deal with certain terrains well, or speed up in others. Maybe a monster that's really fast and hard to deal with but really slow in the swamp. Maybe a monster that heals when they're in the swamp but not when they've been lead out of it. I haven't tried any of these things but I think the parts are all there. My biggest issue with modding actually is how it's so easy to accidentally make the game easier. Once you've got it figured out, the game's simple enough. I want to add more without having them just be punishments, but also without giving the player more power, and more importantly, making the later game more complex and less stable and I've been thinking a lot about how to do that.

[kiopho]

I'm not really that good, I'm just over-excitable when something gets me interested. Plus, my own hobby projects have been in this area. I get excited about procedural generation, and I really like the survival genre, so this is sort of the perfect storm. I just like to type when I'm excited and you guys get to be my victims.I think the static layout stuff is pretty different. I think it just gets a special loader in WorldSim.I think the way the static layouts work is basically: Topology and navigation get generated, static layout's topology is placed over the existing terrain, entities are placed for the static layouts, then entities are placed for the general terrain. The thing is, even the static layouts need to hold more data than actually needs to be saved with the map, because some of that data is important when trying to fit it into the world, or fit other things around it, but is unimportant once generation is complete. At that point only the map state matters.Anyways, one interesting thing I came up with playing with this last night is that it would be possible to do something like:When a bird drops a seed on the ground (you could restrict it so that players can't do this intentionally) the seed, if left undisturbed for a period of time, turns into some piece of vegetation native to the ground type that it's left on.So for instance, maybe in a swamp a seed turns into a reed or a tentacle, in the grass it turns into a flower or a berry bush, in the savannah it turns into a grass, in the forest it turns into a mushroom or a tree.That might be kind of interesting, I'm not sure how I would balance it. You'd have to keep other birds away from eating it for potentially a long time. You could even have special things that grow unusually. But it would allow you to potentially create a small swamp and have your own reeds. But the construction of that would be very time consuming as you'd need to wait for birds to drop seeds in the swamp and then protect the seeds from being disturbed. Maybe you could create a checkerboard tile and from there a marble tree could grow. My thoughts right now are that you'd have to wait for the whole rot time of the seed for it to grow. It would be really easy to make that too strong.The other issue I would have is that birds only spawn around the player, and far away entities deactivate. I'm not sure if it would be jarring to have it happen so localized, and I also don't know if it would be too easy to "care for" a seed by letting it get dropped and then leaving the area so it goes to sleep and no birds spawn. But I think there could be some neat features based on underlying terrain. You might have monsters that can't deal with certain terrains well, or speed up in others. Maybe a monster that's really fast and hard to deal with but really slow in the swamp. Maybe a monster that heals when they're in the swamp but not when they've been lead out of it. I haven't tried any of these things but I think the parts are all there. My biggest issue with modding actually is how it's so easy to accidentally make the game easier. Once you've got it figured out, the game's simple enough. I want to add more without having them just be punishments, but also without giving the player more power, and more importantly, making the later game more complex and less stable and I've been thinking a lot about how to do that.

Such things being localized is a key mechanics not only for the intended unaltered gameplay (without mods) but also for slower computers. My wife plays on a notebook and I can tell you it struggles to maitain 30 FPS when there are many entities displayed at the same time. If it also had to calculate stuff happening away from the player's view that could be a further hit on the processor.But I like that idea of seeds turning into vegetations (not tentacles though nor trees).

[borrisb]

My biggest issue with modding actually is how it's so easy to accidentally make the game easier. Once you've got it figured out, the game's simple enough. I want to add more without having them just be punishments, but also without giving the player more power, and more importantly, making the later game more complex and less stable and I've been thinking a lot about how to do that.

I have a penchant for roguelikes. I've mainly played Nethack, Dungeon Crawl Stone Soup, and Tales of Maj'eyal. Of these three, DCSS went from being my favorite to being the one I now dislike. The DCSS devs have done exactly what you talk about: they simply add punishments (my opinion) and remove variety in their ever forward march for balance and controlled difficulty. Inversely, Nethack and Tales still remain fun games to play because, while they might be "easier", they also have more varied chaos and are actually not as balanced.It's difficult to discuss Don't Starve in terms of easy vs. difficult unless we add temporality to the game. I think it's a fair assertion that if you can survive the first winter, and you are an overachiever (maximizing your spare time by building and preparing for the future, not just living hand to mouth), you will "win" don't starve in survival mode each and every time without undue punishments added to the game.A game design idea I've always liked, and one I think would add more danger to Don't Starve: give someone more variety to mess with, make things more variable and interesting, not less, and you will provide a noose that your player will hang themselves with. This isn't always the case, as there will always be the most tactical power player who cannot be deterred from "winning," but I believe even they are subject to distractions via the "SQUIRREL!" syndrome, as long as the squirrel is awesome enough, and might even be taken down if the squirrel has sharp teeth, and tentacle spikes.To me, I think your idea fits well within the world of Don't Starve. It provides a changing world and a changing layout, which makes traversing previously explored areas NOT safe for various reasons. The chaos might be directly dangerous -- tentacles -- or less -- terraformed savannah that hosts a bunch of killer bee hives that weren't there before."Hey, wait, there weren't reeds near my base before.""And hey, green mushrooms are in the swamp, too!""SQUIRREL!"All the while the hidden tentacle beats you senseless because you forgot to put on your armor.

[zeidrich]

I had a very long writeup on the design of survival games like this, but I chose not to post it because I make this forum suffer through enough of my rambling. It was in the vein of "responsible mod authorship" in sort of a "you might be making the game easier without realizing it" way.The reason a game like this is fun is the learning that takes place. This means that the game will become boring regardless. THIS IS OK. As soon as you try to avoid that factor, you start making progress artificial; based on some experience points system or a time based system. All of a sudden it doesn't matter what you've learned; you can't do X because you're only level Y. As it is, that's not the case. In my games I often eat Meaty Stew as my first meal. I often don't build a fire pit until I've found gold. The game is about efficiency and optimizing your time and resources, and if there's artificial gating, your personal skill gets less rewarding. That said, there's a limited number of actions you can take in the game. And when you get proficient, you've removed any of the slough, and you're only at risk of screwing up or losing focus. Like you said with the tentacle beast.Klei is actually really good at implementing things that give you more actions without either punishing or overpowering the character. Take caves: The primary things you can do in caves is get a lantern, helmet and armor. You can also get gems, marble and rocks, but that's not really the selling feature. You can also explore them, and you can do funny things with bunny men. However, nothing about the caves makes the character significantly stronger, and those things that do come at a debt. To get the armors you need to be down there for a while, and that will drain your food and sanity. Since time doesn't pass on the surface, your crops aren't growing and your resources aren't replenishing (but neither is your food spoiling). So you need to spend resources to exist down there. The armor, however, is not significantly different from that which you can make above ground. Wearing a shelmet and a snurtle armor gives you the same protection as wearing night armor and a football helmet. But one set looks cooler, and the snail armor doesn't drain your sanity. They also degrade forcing you to repeat the process to replace them.Likewise the lantern is a very good tool over ground, but you have no means of refilling it without going to the caves. Caves are generally more dangerous and resource consuming than the overworld, even if you can't outright die. So the power creep has been stymied, but they're still enticing enough to enter. They give you a new area to explore, and new challenges, but they don't make other content significantly easier. I think I mentioned before that I think a more in-depth sanity system might be nice. Let the player go deeper into insanity, but make it a challenge to stay that insane, and make it so that the more insane you are, the more your established play habits have to change to adapt. Maybe normal food restores too much sanity; now you have to come up with a new process to feed yourself let you go sane. It doesn't impact the game in general, and the things that I would let the player bring back to the sane world would be things that maybe helped you go back insane more easily. Maybe some convenience things, like you could gather really cool looking insane bricks that you could use to make a fortification. In power these might be no stronger than stone walls, but they look cooler, and it gives the player a reason to delve deep into this challenging insanity mode to gather enough to build a castle or monument to their insanity.Caves do this to an extent. Something simple that would be cool to add to caves would be maybe in lower levels just having new floor textures (coming full circle to pitchforks) that the player could dig up and bring to the surface. Maybe they give you a slight movement speed buff like cobblestones, or maybe they just look neat. But if I could go down and get a bunch of turf to change the look of my overworld camp, and get challenged doing it, that could be fun.Another thing that I think has merit is companions. Companions would be cool because they could consume resources. It's easy to keep enough food for yourself, but if you need three times the food because you need to feed your companions, then food becomes a point of tension again. There's so many options, and that's why I love this game. The mod system is so open that I can play with pretty much any of these ideas.

[Ipsquiggle]

[MENTION=38597]zeidrich[/MENTION] You're pretty accurate about how the system currently works. I do know, however, that [MENTION=7]Alia[/MENTION] is working on some hot changes... I don't know precisely what they are, but from what I've seen so far you're going to be very pleased with them. But importantly, you are right that after map gen time, most of the data is chucked and only the map representation remains. (In GetWorld().topology there are some interesting things, such as the polygons of the nodes...) [MENTION=44717]borrisb[/MENTION] As far as I know, the ground is just the ground at runtime, there is no "saved" information at all. If you turn a tile from savannah into swamp, that tile is now swamp. There's not much in the game that actually is concerned with ground type right now, but a few things do if you're looking for an example...

[zeidrich]

[MENTION=55]Ipsquiggle[/MENTION] I love hot changes! YOU IS GOOD! YOU FRIEND!

[Irontaco]

Hey [MENTION mention=55]Ipsquiggle, i've just starting coding my first mod and it has gone pretty well, but i have suddenly run into a problem.My modification was based around the idea of build-able phonographs, that would highen sanity when turned on. Now, i've got stuff done to make them buildable, destroyable, and all, but, i've run into problems with making it have a sanity aura when turned on.Since i'm pretty much a newbie, i've been using a few templates and examples from codes in other areas of the game, now, what i tried to do for making it have a sanity aura is:

local function sanityup(inst) FindNearestEntityWithTag("phonograph1") if inst.components.machine:IsOn() then inst.components.sanityaura.aura = TUNING.SANITYAURA_HUGE elseend

This inmediately crashes the game, no error messages, nothing, i know i probably did a very stupid newbie mistake or something but i can't really identify what it is.My complete phonograph prefab is: (Currently using placeholders as placers!)

require "prefabutil"local assets ={ Asset("ANIM", "data/anim/phonograph.zip"), Asset("SOUND", "data/sound/maxwell.fsb"), Asset("SOUND", "data/sound/music.fsb")}local function onhammered(inst, worker) if inst.components.lootdropper and inst:HasTag("phonograph1") then inst.components.lootdropper:DropLoot() end SpawnPrefab("collapse_small").Transform:SetPosition(inst.Transform:GetWorldPosition()) inst.SoundEmitter:PlaySound("dontstarve/common/destroy_metal") inst:Remove()endlocal function onhit(inst, worker)inst.AnimState:PlayAnimation("idle") inst.SoundEmitter:KillSound("ragtime") inst.SoundEmitter:PlaySound("dontstarve/music/gramaphone_end")endlocal function play(inst) inst.AnimState:PlayAnimation("play_loop", true) inst.SoundEmitter:PlaySound(inst.songToPlay, "ragtime") if inst.components.playerprox then inst:RemoveComponent("playerprox") end inst:PushEvent("turnedon")endlocal function stop(inst) inst.AnimState:PlayAnimation("idle") inst.SoundEmitter:KillSound("ragtime") inst.SoundEmitter:PlaySound("dontstarve/music/gramaphone_end") inst:PushEvent("turnedoff")endlocal function sanityup(inst) FindNearestEntityWithTag("phonograph1") if inst.components.machine:IsOn() then inst.components.sanityaura.aura = -TUNING.SANITYAURA_SMALL elseendlocal function fn() local inst = CreateEntity() local trans = inst.entity:AddTransform() local anim = inst.entity:AddAnimState() local sound = inst.entity:AddSoundEmitter() MakeObstaclePhysics(inst, 0.1) anim:SetBank("phonograph") anim:SetBuild("phonograph") anim:PlayAnimation("idle") inst.songToPlay = "dontstarve/maxwell/ragtime" inst:AddTag("phonograph1") inst:AddComponent("inspectable") inst:AddComponent("lootdropper") inst:AddComponent("sanityaura") inst:AddComponent("workable") inst.components.workable:SetWorkAction(ACTIONS.HAMMER) inst.components.workable:SetWorkLeft(3) inst.components.workable:SetOnFinishCallback(onhammered) inst.components.workable:SetOnWorkCallback(onhit) inst:AddComponent("machine") inst.components.machine.turnonfn = play inst.components.machine.turnofffn = stop inst.entity:SetSleepRadius(1000) return instendreturn Prefab( "common/objects/phonograph1", fn, assets), MakePlacer("common/phonograph1_placer", "winter_meter", "winter_meter", "idle" )

Also, i wanted to have different phonographs that play different music tracks, but, let's say i want to make a phonograph play Work To Be Done, i've tried doing this: inst.songToPlay = "dontstarve/music/music_work"In-game, it doesn't play anything. Maybe i could make it not play anything at the beggining, and when turned on:inst.SoundEmitter:PlaySound( "dontstarve/music/music_work") Maybe? I don't really think it would work either. The mistake must just be a directory-related thing. Also, what's the directories and names for music like Danger, EFS, Creepy Forest, DR Style, and others in the code?

[zeidrich]

local function sanityup(inst)	FindNearestEntityWithTag("phonograph1")	[B][U]if[/U][/B] inst.components.machine:IsOn() then	inst.components.sanityaura.aura = TUNING.SANITYAURA_HUGE	[B][U]else[/U][/B]end

Should be if, end. Not if, else.

[borrisb]

Another thing that I think has merit is companions. Companions would be cool because they could consume resources. It's easy to keep enough food for yourself, but if you need three times the food because you need to feed your companions, then food becomes a point of tension again. There's so many options, and that's why I love this game. The mod system is so open that I can play with pretty much any of these ideas.

If you do make companions, I want an option for a companion volleyball [MENTION=55]Ipsquiggle[/MENTION](sorry for combining two things into a single post)The main thing that I'm curious about, and once again this is not from code diving but from things I've read on the wiki, is "flowers only spawn in the grass biome." Which seems to be true. Flowers will spawn in the large grassland boundary areas. I've seen this because my first year in the game (~36-40 days) usually has me picking gobs of flowers and making lots of garlands to restore my sanity. The game generates with flowers almost everywhere, but they only regenerate in the grassland areas. When I go back to the same area, after the flowers have spawned, if I don't pick the flowers, they are in the same spot.Of course, that's the only example I have. What I'd like to do is sort of the reverse of what zeidrich is proposing. I like terraforming, but I'd like a player to wear out the land they overuse over a long period of time. Too many fires, the land turns to savannah, and potentially rockland. Too much bloodshed in a particular area, ghosts begin to appear.These are just ideas right now, and I'm not even close to implementing them, but I would bet zeidrich and I are not the only wants who might want to be able to effect a more dynamic world, and have certain things happen magically off camera as they do on camera.