nickwest

Awesome, thanks!

@Ipsquiggle I just went through and fixed Pickle It and have a question. Direct access to terrain.rooms is going away, but what about terrain.filter? Pickle It adds new plants to the world and it looks like to prevent them from spawning on roads and what-not I'm doing this: GLOBAL.terrain.filter.beet_planted = {GLOBAL.GROUND.ROAD, GLOBAL.GROUND.WOODFLOOR, GLOBAL.GROUND.CARPET, GLOBAL.GROUND.CHECKER, GLOBAL.GROUND.ROCKY, GLOBAL.GROUND.MARSH} Will this stay accessible? Or will we be gaining a method similar to AddRoomPreInit() for modifying filters? note: It's been about a year since I've really poked around DST mod code, so I don't remember exactly what's going on. Our new modworldgenmain.lua is accessible here, if you want to check it out: https://github.com/mariewest/Pickle-It-Dont-Starve-Together-Mod/blob/master/modworldgenmain.lua

So it would seem that containers.widgetsetup(...) has changed at some point in the last few months. It gained a third parameter, making things a bit easier on modders who want to have custom containers. Unfortunately, a lot of modders have overridden this function in such a way that it only accepts and carries through the first two parameters. Luckily lua gives us a better way to override base functions so we can better ensure our mods don't break future mods. When overriding this function (or any function): function containers.widgetsetup(container, prefab, data) -- Original code in hereend We should be doing the following:local oldwidgetsetup = containers.widgetsetupcontainers.widgetsetup = function(container, prefab, data, ...) if container.inst.prefab == "my_awesome_new_container" or prefab == "my_awesome_new_container" then data = my_awesome_new_container_data end return oldwidgetsetup(container, prefab, data, ...)endAdding ... to the end of the param list and carrying that through to the return future proofs your override and insures that all params will be passed through. In fact, you only need to list out the params you're using and ... the rest. If you're not using any of the params you can just do my_method(...) return original_method(...) and you never have to worry about the param count. The problem I've run into is that a lot of folks have overriden it this way: The problem with the method above is that the addition of parameters in future API versions are dropped in your code. With the lua maigic of ,... added at the end of your param list, you future proof your overrides. Unfortunately this error in older mods makes future mods look like the culprit, since the crash or malfunction happens when their code uses the new params but they're not passed through by your old mod code that didn't carry those new params forward. This is also an acceptable override: local oldwidgetsetup = containers.widgetsetupcontainers.widgetsetup = function(container, prefab, ...) if container.inst.prefab == "my_awesome_new_container" or prefab == "my_awesome_new_container" then -- Something happens here that modifies container directly end oldwidgetsetup(container, prefab, ...)endNow, it's probably not super likely we'll see additional parameters added often, or that those additional parameters will be found and used, but in this case that is exactly what happened.

Ya the only way I'd really imagine them merging would be by making single player actually running client/server but only allowing local connections when playing single player; basically the same way minecraft did it. It'd simplify the codebase for Klei too, but it almost certainly would break DS mods without adding a translation layer for things like GetPlayer() and other single player calls. Thanks for sharing that condition, I hadn't stumbled upon that yet. I'm still not sure if I want to try to maintain a single codebase or just do two and make changes in two spots, or just freeze the single player mod and keep new features to DST.

Hi folks, I'm just curious what you all are doing with your repos to support modules that work in both DS and DST. Are you creating separate repos, or are you maintaining separate branches for each version? We just updated our mod, Pickle It, to work with DST and so far have maintained the DST code in a new branch, but now we want to back port some of our fixes into the DS version so we're staring at our repo wondering if we should keep 2 separate production branches, one for each version's code base, or if we should just make a new repo for DST and work in them separately. My hope would be that DS and DST would converge on one API version eventually. Any word on DS and DST converging on one API version in the future or will they stay forever different?

Will Don't Starve Together support mods? I'm hoping I haven't seen this addressed because it's an obvious yes, but confirmation would make me happy

Well this will certainly reinvigorate my interest in Don't Starve. Without multiplayer it's been tough. My wife and I game together, and work on mods for games together. Don't starve is awesome; we love the genre, we love the aesthetic, we love don't starve, and we love modding for Don't Starve. Our interest wained fairly quickly though, since we couldn't be in a world together, but now... holy moly. All of those other mod ideas might actually come to fruition. If nothing else though, I sure know we'll be playing a bunch more. I can't wait to see what you guys do to balance it and how death and PvP is going to work. Just please, please, please keep modding support for multi-player.