• Content Count

  • Joined

  • Last visited

Community Reputation

37 Excellent

About blubuild

  • Rank
    Junior Member


Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The relevant code is in mound.lua and trinkets.lua. Unfortunately, some of the relevant stuff is defined locally, such as parts of the loot list, but there are some function(s) you can hook into by overriding to change it without resorting to replacing one of the files with a custom version. For example, the function PickRandomTrinket() is completely global, so it can be overridden easily, and 50% of the time this function directly determines the loot item of a grave mound. Note that particular function is also used in determining a random trinket dropped by damaging Ancient Pseudoscience Stations. Klei doesn't seem to be interested in making this better, so I'm working on a modding library that (among other things) should make this easier, by providing a kind of convenient API to do stuff like modifying various loot lists that aren't easily extensible, including grave mounds' and tumbleweeds', so once that's done, you should have an easy time with it, if you choose to use it. @DarkXero , maybe you know or can figure out a clever way to access the loot lists of mounds or tumbleweeds (and catcoons . . . etc?) from a mod, using the debug library or some such, so you don't need to manually copy and paste it to your mod and keep that duplication up to date (like f.ex. every tumbleweed loot mod seems to do)? Haven't started on this part yet, right now my current plan is actually to parse through the respective file and capture it that way... Should work, at least.
  2. You can read the prints in the server's log (search for "server_log.txt" under your Documents\Klei folder). Although, That doesn't sound quite right. Yes, that happens when you host a world with caves, but only then. A world without hosted from in-game is still a "combined server and client", and you are able to see printed output from it in both the console and the "client_log.txt" file. So it could be convenient to test your mod under a caveless server most of the time, and occasionally test it with caves, as well as when it is near-finished. Or, you could do what CarlZalph said. Wrap it in a function so that it's easier to type: local function pchat(msg,allshards) --short for printchat return GLOBAL.TheNet:SystemMessage(msg,allshards or false) end --usage: pchat("my message") I guess you could even automatically convert all uses of print() in your modmain.lua to chat output by putting this at the top of the file, if you wanted: local function print(...) --remove "local" to affect other files that are modimport()ed, too. local msg, argnum = "","#",...) for i = 1, argnum do local v =,...) msg = msg .. tostring(v) .. ( (i < argnum) and "\t" or "" ) end return GLOBAL.TheNet:SystemMessage(msg,true) end
  3. All or most Shipwrecked content should be in plain-text Lua too, so it's possible to copy over some code to use as a starting point. Although the way the sea works would probably be much different in DST/RoG, but still. Sure, your idea might work too, with some overrides or hacks to allow the "Beefalo" and mounted player to move freely on the sea (and also to make that "Beefalo" never throw you off, probably would be an easy part). We won't know until someone tries.
  4. I don't really think so... running code can modify a container's contents while it's opened by a player with no issues. The container's UI even updates in realtime. And not sure about this one, but I think I might remember multiple players being able to open a container once, when DST was beta? Or maybe I'm just remembering Minecraft. There are too many needed items in this game. Mods that increase item's maximum stack sizes also help. In the near future I'm going to release one that allows full customization of every individual item's stack size (via creating a Lua config file, although there are also various more limited in-game configuration options), along with a few small conveniences that make keeping inventory, such as freely combining stacks of Logs and Boards in your inventory (same for the other refined items), essentially allowing to convert them at will, too (by default, only if you've already unlocked the Refine recipe). It will also depend on a mod library I'm making to make writing mods more convenient and a little easier... The containers in the game are also ridiculously small indeed, which leads to even singleplayer DS worlds requiring bases with ridiculous numbers of chests. But fortunately mods are already available to take care of this problem. Same for private items. There's also a "Buried Treasure" mod that allows players to 'bury' items in a hidden secret container you must remember the location of in order to access, not sure if it still works, though.
  5. This goes for learning any language and perhaps most things, but: read documentation, read explanations, read examples (in particular, you can open any existing mod and any default game file and see how they work and how they do things, since it is all plain-text), practice and experiment, and you will improve with time. It's not that there are no resources available at all; there are tutorials, guides and bits of knowledge and hints on DS/T modding scattered throughout this very forum, and there are many different mods available to read or imtiate and start modding by modifying (a common thing to do when creating a mod is find some that do something within the same ballpark or at least somehow similar, and check out how they do it, first). For Lua itself, since it's a widespread, popular language, there's a virtually endless amount of resources (books, even) in addition to the official documentation, just use a web search. For experimentation, there are also websites that allow executing and viewing Lua code results in your browser, and you can also download a local Lua intepreter for Windows/your OS and use that. But you can also just use DST itself directly to experiment, which may or may not be more convenient for you. If feasible, it may be worth it to move the DST installation to a SSD drive to shorten startup times... From my experience, the main roadblocks at the start are Lua grasp and understanding it properly and intuitively, and knowing which functions are in the game and how things are done with it specifically, since there's no official reference with everything and pretty much no official documentation. Thankfully, as mentioned, even without this forum, you can at least read any mod and game file to gradually accumulate knowledge... Using a tool that can search for an expression or text in multiple text files (and folders) is often very, very handy here. So (again this really applies to most anything, I guess), take it slow at start, make good use of file search, web search and the forum search, and when you're stuck or when you have a specific question that you can't figure out, then if searching for it on the web and forum in multiple different ways/keywords didn't help, you can always make a new post or thread here. For editing Lua files, if you're using a simple text editor like Notepad, I recommend using a good and convenient text editor that also supports Lua syntax highlighting, instead (and associating it with .lua files). Myself, I use and recommend "Notepad++". It's the above, and it's also a powerful, extensible and popular (meaningful if you want to web search on how to do something with it or something related to it) program, too, and it also includes the essential search through files feature ("Find in Files") in it. It also allows you to install plugins for advanced stuff (probably won't need to), use regular expressions in the Find and Replace features, and change color themes for more convenience and easiness on the eyes during extended reading (try the "Solarized" themes that come with it, as well as this different version of them). For starters and giving some quick resources, I can share these forum posts with you off the top of my head. They have some useful links and data. Reading the whole thread can also be useful. Also check out the pinned topics in this subforum and the DS modding subforum, of course. Good luck! Not really sure what to say about these observations. The only meaningful thing there is that DS/T content and mods are written in Lua.
  6. @Serpens: That works perfectly as a workaround, for now. Giving an option hover = "\n" forces it to never have any tooltip at all, not a carried-over one nor even an ugly blank one. Thanks for sharing!
  7. If you only give a "hover" key to some choices in an options list, then in-game, if the player mouses over an option with a hover text, that same hover text will remain stuck if he switches to other options, until he reaches an option with a "hover" key or re-opens the mod configuration window. example (modinfo.lua) local number_options = { {description = "0", data = 0, hover = "Minimum."} } for n = 1,10 do number_options[#number_options + 1] = {description = ""..n, data = n} end number_options[#number_options + 1] = {description = "99", data = 99, hover = "Maximum."} number_options[5+1].hover = "middle" configuration_options = { { label = "My option 1", name = "myopt1", hover = "Please choose a number.", options = number_options, default = 0, }, { label = "My option 2", name = "myopt2", hover = "Please choose a letter.", options = { {description = "A", data = 1}, {description = "B", data = 2}, {description = "C", data = 3}, {description = "D", data = 4, hover = "Dandelion"}, -- once you choose this option (scroll to it), it will cause all other options to have this same hover text, until you reopen the config window. {description = "E", data = 5}, {description = "F", data = 6}, }, default = 1, }, } This seemingly can't really be worked around at the moment, as giving the options you don't want to have a hover text a hover = "" or hover = " " will work to bypass this, but both will show an ugly small empty background graphic on option mouseover, instead of nothing.
  8. For DS modding guides and documentation, true (even though there's a bit of stuff on this site: (EDIT: site is down - archived version) and also scattered throughout this forum, of course), sadly... For Lua usage and understanding, which is very helpful and pretty essential, there are naturally heaps of resources on the web, though. Not sure why the OP would peruse the links he gave but not, for example, the immediately-findable official online free guide book and official reference, which I find are good resources. I also second the Notepad++ reccomendation (and recommend associating .lua files with it), both for the Find in Files feature (use "*.lua" as the filter, of course) and the Lua syntax highlighting. Then there are also extra conveniences including code block folding and file tabs, and just being an all-around good program/file editor.
  9. Upon trying to disable a server mod under the server screen, instead of the checkbox becoming unticked, the warning for enabling the mod appears.
  10. What ways are available to make a mod configuration with more than a couple of settings more organized? For example, is a way have a blank line between groups of related settings, or a header/title for a group of settings, or even different tabs or pages or something similar? For the moment, I'm using a dummy setting for an empty line or a title to help a bit, as I saw done in other mods, which of course isn't really ideal, but it works, and is better than nothing: configuration_options = { {...}, --various options here... {name = "blank", label =" === Misc settings", options = { {description = "===", data = 0}, }, default = 0,}, {...}, --various options here... It appears there's no way to do these sorts of things, but I could be wrong, or there could be some clever way (perhaps related to overriding something in modstab.lua, even?). Could there also be a way to nest options, or make options dependent on other options? In other words, make an option only show up or be accessible/editable if a different option is currently set to a specific setting. I'm interested to hear about any techniques in general for making a mod configuration with many settings tidier or more organized. Also, what in general is available and unavailable to access/do within modinfo.lua? And is there a documentation for these things anywhere? Thanks.
  11. Whoa! Yeah, simple indeed. That's pretty ingenious, using the debug function to access a local table like that. Much thanks!!! The required method here is pretty involved! I definitely wouldn't have been able to figure all of this out. Well-commented, too. Needless to say, you're awesome.
  12. As the title says, I want to give a specific item a new maximum stack size in a mod. While this is joyfully (or maybe ridiculously) simple to do in Don't Starve: modmain.lua: local function changestackA(inst) inst.components.stackable.maxsize = 12 end local function changestackB(inst) inst.components.stackable.maxsize = 53 end AddPrefabPostInit("poop",changestackA) --manure now stacks up to 12 AddPrefabPostInit("cutgrass",changestackB) --cut grass now stacks up to 53 ...I can't manage to do the same in Don't Starve Together. Whatever I thought to attempt only caused an error related to stackable_replica.lua or just had no discernible effect. I tried to look into it and it appears that in DST item stack sizes may be based on predefined amounts in a local table in stackable_replica.lua. I'm quite stumped, as I'm not sure how to go about dealing with that, or if netcode is related to my problems... Does anyone know how to accomplish this? Thanks for any help.
  13. Ehh... Ignoring that you made a definitely-wrong sweeping generalization... Yeah, right, maybe you're not missing anything, unless they took something of yours, or attacked you, then ended up logging off after you retaliated. Besides, just being denied the kill itself can hurt the play experience. More so if you've spent time and effort into it (damaging and chasing the guy or whatever). Nice post count!
  14. There are multiple ways to implement it, with indeed different effects. I was presenting different options, the first of which had already been detailed by Hexicube.
  15. Nah, it is actually pretty easy to all but completely eliminate as a problem. Simply leave the player's character in the game for X amount of time after the player leaves. X can be half a minute, a minute, or however long you want. To be less harsh, you could also make this only happen if the player isn't at full health, or the game has determined that the player was recently in combat or in danger, at the time that he leaves. FlareV2 and Hexicube are on the right direction.