squeek

  • Content Count

    533
  • Joined

  • Last visited

 Content Type 

Profiles

Forums

Downloads

Klei Bug Tracker

Game Updates

Hot Lava Bug Reporter

Everything posted by squeek

  1. @SyntaxError01 this is not compatible with Don't Starve Together. Use http://steamcommunity.com/sharedfiles/filedetails/?id=345692228 for DST.
  2. Very true. To be clear, Minecraft has no autodownloading features at all for mods (mods are all third-party, there is no official modding API, and there is no singular trusted host for mods). I think I really bungled up my post back there, and I take it all back. Adding support for autosyncing mods uploaded to these forums would indeed be nice.
  3. @Silentdarkness1, for mods not on the Workshop, clients would just need to sync their mods with the server before joining it. Note that this is how Minecraft handles things to this day and it seems to do alright in terms of modding. It's convenience-based functionality you're talking about, not core functionality. Everything will still work fine if mods are not on the Workshop; it'll just be less convenient for clients, as they'll have to manually download/install the mods that the server is using in order to be able to join it (hence the rise of modpacks within Minecraft modding).
  4. Nice work. Added to the The Big List Of Mod-Related Code Suggestions.
  5. G) See LocoMotor:UpdateGroundSpeedMultiplier in components/locomotor.lua. Changing the player's locomotor component's slowmultiplier variable to 1 should remove the slowness on creep (webs). E) AddPrefabPostInit. See the API Examples mod.
  6. Why not study game files? A) see components/kramped.lua B) see components/builder.lua's DoBuild function. You can listen for the "builditem" or "buildstructure" event on the player, or, if it's a custom item that's being crafted, you can use the OnBuilt function of the prefab. C) STRINGS.PIG_TALK_FOLLOWWILSON = {"Changed strings"} D) see stategraphs/SGwilson.lua's "frozen" state
  7. Yes, as I was trying to get at, there's no way to make a 'template' function for overriding tuning variables. They are all used in different ways, so you have to figure out how they are used in order to make sure that your change will have the intended effect. The timeout variable is specific to the autosaver component. Most of the TUNING.*_TIME variables are used in components/clock.lua, but SEG_TIME is used all over the place.To properly change the total day time, you'll have to overwrite all variables that depend on it. A very basic start would be: local function MultiplyTuningVariableBy(keypath, multiplier) assert(type(keypath) == "string") -- table.getfield and table.setfield are non-standard functions defined in util.lua -- they allow for getting and setting child keys using a string -- table.getfield(tbl, "a.b.c") would get the value of tbl["a"]["b"]["c"] local cur_value = table.getfield(TUNING, keypath) if cur_value ~= nil then table.setfield(TUNING, keypath, cur_value*multiplier) endendlocal tuning_variables_affected_by_total_day_length = { "SEG_TIME", "TOTAL_DAY_TIME", "WILSON_HUNGER_RATE", "BLUEAMULET_FUEL", -- etc, there are a ton that would need to be in this table, see tuning.lua}function c_dayspeed(new_day_length) -- get the ratio of new:old day length local day_length_ratio = new_day_length/TUNING.TOTAL_DAY_TIME -- multiply all relevant variables by that ratio for _,keypath in ipairs(tuning_variables_affected_by_total_day_length) do MultiplyTuningVariableBy(keypath, day_length_ratio) endendBut that's only the beginning. You'd now have to go through each and every one of the affected variables and see how it's used and check if you need to do anything further to make sure it'd work properly. For example, you'd probably want to do a dummy call to Clock:SetSegs to force it to update it's variables using the new SEG_TIME value. local clock = GetClock()clock:SetSegs(clock:GetDaySegs(), clock:GetDuskSegs(), clock:GetNightSegs())As you can probably tell, you've chosen a much more difficult task that you might have first thought. Day length was not written to be adjustable on-the-fly, and to allow it to be, you're going to have to modify a whole lot of stuff every time the day length changes.If you don't already, I'd highly suggest using a text editor that has good find-in-files support because that's the best way to find all references to a variable in the Don't Starve code. Something like Notepad++ or Sublime Text would work.
  8. Those values are not actually controlled by the recipe, they are controlled by the prefab (the recipe hunger/health/sanity settings are only used to set the values of the prefab at startup). To modify them, you'd want to use a PrefabPostInit like so: -- in modmain.luaAddPrefabPostInit("powcake", function(inst) inst.components.edible.healthvalue = 0 inst.components.edible.hungervalue = 0 inst.components.edible.sanityvalue = 0end)
  9. Calling Tune (not sure why you have it all caps, it's defined as Tune in tuning.lua) will just reset all tuning variables to their defaults. You don't want to do that. For each variable, you need to see how it's used in the game code to be able to determine how you need to modify it. For example, TUNING.AUTOSAVE_INTERVAL is used in components/autosaver.lua and only gets referenced when the component is first created and whenever an autosave is actually performed. So, any changes you make to TUNING.AUTOSAVE_INTERVAL will only take effect after the next autosave. To have it take effect immediately, you'd want to do: local default_autosave_interval = TUNING.AUTOSAVE_INTERVAL function c_test(l_minutes) local autosave_interval = l_minutes or default_autosave_interval TUNING.AUTOSAVE_INTERVAL = autosave_interval -- set the next save to be one interval length from now -- alternatively you could call GetPlayer().components.autosaver:DoSave() to force a save GetPlayer().components.autosaver.timeout = autosave_intervalend
  10. I don't really understand what you're trying to do in a lot of the code you've posted, so it's hard to help (for example, why try to emulate tuning_override.lua? What does it do that you also want to do?). Here's some code that would add a console command (console commands are just global functions) that would set SEG_TIME to the number of minutes passed to it or, if it's called with no parameters, would reset SEG_TIME to the default value: local default_seg_time = TUNING.SEG_TIMEfunction c_dayspeed(l_minutes) -- "condition and val_if_true or val_if_false" is Lua's version of the ternary operator local seg_time = l_minutes and (l_minutes * 30 / 8) or default_seg_time TUNING.SEG_TIME = seg_timeend
  11. Modifying game files directly should never be done. See this post for how you could modify a recipe using the proper methods.
  12. I'm unfamiliar with almost everything dealing with animation, but are you familiar with the Animation Commandline Tool? It converts anim.bin/build.bin files into plaintext and back. I used it before Spriter came about (and still use it because I haven't bothered to learn much about Spriter or the autocompiler), but it includes some documentation about the build/anim formats and the C++ source code of the tool. Just throwing it out there. No clue if it's of any use to you.
  13. That's only a partial fix because you can't add strings to all possible characters; any custom characters will still potentially crash. The true fix would be to patch the GetDescription function until it gets patched by Klei (my code should work, but feel free to double check that it makes sense). GetDescription is just a global function so it's easy to override.
  14. That's a vanilla bug. Info here: http://forums.kleientertainment.com/topic/33105-repairable-objects-inspect-string-can-cause-crashes/
  15. It doesn't work with prefabs; they are loaded differently (see the function LoadPrefabFile in mainfunctions.lua).
  16. Isn't DoPeriodicTask basically a shortcut for that code you posted?