Files posted by simplex
This mod, if enabled on both a server a client, gives that client remote Lua execution privileges if they press up, up, down, down, left, right, left, right, B, A. On a keyboard, the directions can be given with either WASD or the arrow keys. This mod also has controller support, accepting directions from both the analog stick and the d-pad.
It is not necessary to have each client install this mod. Instead, as long as the mod is installed on the server, clients without the mod will just not have remote Lua execution privileges on the server (unless they are in fact a regular admin).
This is meant as a testing aid, with the primary aim of easing testing in offline dedicated servers. Regular users should see no utility in this mod.
Setting the mod option "Up up down left... what?" to "no" will give remote Lua execution privileges without requiring the input of the special secret cheat code. But that's no fun.
This mod improves upon the Lua console in Don't Starve Together. It was started as a collaboration between this author and @squeek.
Extended and configurable command history. Each history line is editable (that is, scrolling past a previous line will save any modifications to it), and the command history is preserved saved between game sessions. Console log is scrollable Console keeps focus when you'd expect it to Console doesn't close after each line entered Added basic CTRL+A select all support (hitting backspace after CTRL+A will delete all the text) Added support for multi-line inputs (useful for e.g. function definitions and for loops) Many general useability improvements, bugs that have been fixed, and small but useful tweaks Better, more informative and less cluttered error handling Minor features
Dedicated server support
This mod has essentially two elements: extending the console UI and extending the processing and execution of Lua code. The former makes sense only in a client, and requires only the client to cooperate, and this is why this is a client mod. However, it may still be enabled in servers, including dedicated servers (though force enabling from modsettings.lua may be required). If that is done, the extensions to the execution of Lua code (including syntax extensions and all that was discussed in the "Technical features" section) will be applied to the server, both for code transmitted to it via a remote console by an admin user and for code read by a dedicated server from its terminal input.
Repository on GitHub (branch together)
This mod forces Don't Starve Together to run in offline mode. When clicking on the Play button on the mainscreen, no popup is shown and the game goes right into the main menu under offline mode, that is, only being able to see, join and host LAN servers.
The is primarily meant as a tool for other modders, wishing to reduce iteration times when mod testing.
IMPORTANT: Starting with version 4.3.0, the Windows binary release requires Microsoft's Visual C++ 2013 Redistributable Package (previously, the 2010 one was required). See the bottom of this description for more information.
ktools is a set of cross-platform (Linux, Mac and Windows) modding tools for Don't Starve. It consists of the following command-line tools:
ktech: a bidirectional converter between TEX texture and PNG; krane: a anim.bin/build.bin decompiler, whose output is a Spriter project. More detailed information about these tools may be found in the README, in the project's GitHub repository.
ktools primary release format is as source code, compilable under every platform using CMake, as per the instructions in the README. A Windows binary release is also included (the ZIP ending with "-win32").
When compiling from source, if libzip is found then the ktools are compiled with zip support, so that zip archives may be given as input in the same way directories may. The binary Windows release does not have zip support.
If you have issues running the Windows binary release, make sure you have Microsoft's Visual C++ 2013 Redistributable Package (the 32 bit version, that is, download the file called vcredist_x86.exe). It's very likely already installed, but in case of any errors first make sure that is in fact the case.
Makes tooth traps as responsive as they were before the "All's Well that Maxwell" game update (2013-10-22), with a nearby target being checked for every 0.4 seconds, instead of the current 2 seconds. This prevents the rather common scenario of an enemy walking over a tooth trap without triggering it.
Additionally, it makes tooth traps less CPU hungry by having they only check for targets every 15 seconds when they are offscreen by a significant distance*.
* Put precisely, this conservative mode is enabled at the same conditions where the game freezes world activity due to the player being too far away.
Both the target check delay for when a tooth trap is onscreen and for when it is not are configurable, via the options "Target Check Period" and "Offscr. Targ. Check Period". Setting the latter to "inf" will disable offscreen target checking.
Suppresses the warning about having mods enabled.
Special thanks to nailertn for the tip that now this should be possible.
While enabled, suppresses the automatic updating of Steam Workshop mods, adding a button to the Mods screen for that purpose.
Prevents Woodie from triggering his curse on a full moon if he sleeps through the night.
Upon death, politely asks if you *really* want to die.
This dialog will only be presented if you don't have a regular resurrection method available, such as a Meat Effigy (including one on the surface, if inside a cave).
Reloading a save takes you back to the last point the game saved. Resurrecting gives you the option to instantly resurrect at the spot you're at or on the next day, at the nearest Fire Pit. Both methods of resurrection give you 10 seconds of invulnerability.
Being a permadeath game is a big part of Don't Starve's appeal, so use at your own discretion.
Icon by @Willette.
Special thanks to @bobbyblade, the author of Camp Res, for the idea of using Fire Pits as resurrection spots.
Prevents F from attacking walls when Ctrl is held.
(also works under alternate keybindings)
Clicking on them with Ctrl held still performs an attack as usual.
Icon by @Silentdarkness1.
Maintaining an effective killing field of tooth traps is a time consuming process. Recent advancements in gear technology have lead to self-resetting traps: the Clockwork Tooth Trap, dealing 55 points of damage and having 21 uses, automatically resetting itself 8 seconds after being sprung.
This trap is more convenient than it's more primitive counterpart, but that comes at a cost: Clockwork Traps run on hound's teeth as "fuel", and when the trap runs out of fuel it stops resetting (but does not vanish). Fueling it with a hound's tooth restores 7 uses. A tooth is only accepted if the remaining uses are 14 or less, to prevent resource waste.
Dealing slightly less damage and costing more teeth to upkeep, regular traps are still more resource efficient.
You gain the ability to set traps that you never need to worry about replacing. Have some beautiful designs made of death and they will always stay that way. To increase cleanup, the traps are pickup on right-click only. This means you can left-click or hold spacebar to your heart's content near them.
It requires an Alchemy Engine for crafting, costing 1 log, 1 gear and 3 hound's teeth.
Concept by Ortorin, art by Xjurwi and strings by TooMuchHoneyHam.
@GRNCeleryStick was kind enough to make a video spotlighting the mod, check it out:
Tired picking grass by clicking on one tuft at a time? Tired of holding the space bar for no end chopping wood whenever you want to build some wooden flooring for your base? Then this mod is for you!
This mod allows you to queue a sequence of actions by holding SHIFT and dragging the mouse, forming a selection box enclosing all your targets. This allows you to automate the process of picking, harvesting, chopping, digging, shaving Beefalo and many more repetitive tasks, by simply selecting all your targets and then sitting back (offensive actions such as attacking are not performed, to avoid... accidents).
To use this mod, hold SHIFT, press a mouse button and drag the selection box, releasing the mouse button when you're done selecting. You may use either the left or right mouse buttons: only the actions normally performed by that button are executed in each case (excluding some actions, like attacking, as mentioned before). If you simply click an entity while SHIFT is held, that entity will be toggled from the selection (included if it weren't, removed if it were). To cancel a series of tasks, simply click anywhere on the ground or press any movement key (but managing your inventory will not cancel the queue).
When you perform a selection, the queued actions are those of the tool you have equipped, if any, as well as "inherent" ones which do not depend on tools (such as picking grass). If you have a selected item (as is done for razors, when shaving Beefalo), only the actions corresponding to this item will be performed, granting you a finer grained selection of what should be performed.
When using a right click selection, no objects will be picked up from the ground. Left click selection will also not pick up tooth traps, armed bee mines and untriggered (rabbit) traps.
Fixes the memory spike which happens when large mods are enabled, which happens due to all mod assets being loaded to RAM regardless of them being used or not.
Most notably, this fixes the crash that may happen when large mods are enabled, due to the total RAM usage exceeding the available RAM (this is most notable in the Windows version of Don't Starve, since it is limited to using at most 2GB of RAM). This crash may present itself with one of the following errors (printed to log.txt):
Error processing render buffer command GenerateMapor
ERROR: HWTexture::DeserializeTexture failed on MinimapBG. glGetError returned 0x505or
out of memorybut may also happen silently, with the game simply crashing with no meaningful information printed to log.txt.
As a side effect, this fix also prevents the large slowdown in the game's startup time caused by having large mods enabled.
This sample mod provides a file, savable_infinity.lua, which when modimport'ed allows storing correctly the following numerical values as savedata:
Plus and minus infinity (i.e., math.huge and -math.huge);
NaN (Not a Number, i.e., the result of invalid arithmetical operations, such as 0/0).
The game's save system is patched transparently, so other than modimport'ing savable_infinity.lua no other steps need to be taken: simply feel free to store the above values in savedata.
The patching of the game's DataDumper function uses the fact that Don't Starve's savedata is simply Lua code to store these values as arithmetical expressions: plus infinity is saved as 1/0, negative infinity as -1/0 and NaN as 0/0. The method used for the patching is more hackish than I would like (making heavy use of Lua's debug library), but it is the cleanest method of doing so I could think of, other than simply overriding vanilla's dumper.lua.
The rest of the mode code, beyond savable_infinity.lua, is just a test suite to see the added functionality in action.
The file savable_infinity.lua is modimport'ed in modworldgenmain.lua, so that all savedata is stored correctly (but it can safely be modimport'ed in modmain.lua instead, if worldgen savedata is not a concern).
In modmain.lua, the global variable ENCODE_SAVES is set to false, causing save files to be stored as plain Lua instead of zip compressed Lua, allowing visual inspection of the saves' contents. Furthermore, modmain.lua adds the included infinitysavetest component to the world entity: this component simply returns the mentioned values in its OnSave method and checks the validity of the loaded savedata in its OnLoad method, which prints the following to log.txt:
../mods/SavableInfinity/scripts/components/infinitysavetest.lua(17,1) Running InfinitySaveTest:OnLoad() for [100013 - cave] ../mods/SavableInfinity/scripts/components/infinitysavetest.lua(28,1) Testing savedata entry 'positive infinity'... PASSED ../mods/SavableInfinity/scripts/components/infinitysavetest.lua(28,1) Testing savedata entry 'negative infinity'... PASSED ../mods/SavableInfinity/scripts/components/infinitysavetest.lua(28,1) Testing savedata entry 'NaN'... PASSED ../mods/SavableInfinity/scripts/components/infinitysavetest.lua(30,1) Ran InfinitySaveTest:OnLoad()
This mod shows how to add a custom tile (ground) type to the game, to the map and minimap.
The actual work is encapsulated in the file tile_adder.lua, which may just be plopped into your mod and modimport'ed. It exports the function AddTile(), whose usage is exemplified in modworldgenmain.lua (note, however, that the tile texture assets must be declared in modmain.lua).
As an example, a new tile type GROUND.MODTEST is added. The mod will also spawn in the player's inventory an infinite turf item which places the new tile type (to make testing easier, it does not require digging up the original turf with a pitchfork).
The numerical id passed as the second argument to AddTile (which becomes the value of GROUND.YOURNEWTILETYPE) must be unique, not conflicting with with game's own values (specified in vanilla's constants.lua) as well as with other mods. It must also be less than 128 (the value of GROUND.UNDERGROUND), otherwise the game assumes the new tile represents a wall type. The AddTile function checks the given numerical id for validity, raising an error if the check fails. With regard to intercompatibility between mods adding tiles, it is important to choose numerical ids not conflicting with the choice of other mods. Ideally the ids would be generated automatically and stored/restored as map savedata, but since mods run before any savedata is loaded this would add a number of pitfalls for the modder to be aware of, and generally increase the complexity of the code required for adding a new tile, so I kept the manual specification. The sample tile is added with an id of 80, while Up and Away uses consecutive ids starting from 64.
The mod formerly known as "simplex testing".
Its goal is to aid in mod testing (being aimed at modders), focusing on being extensible through custom code to suit a particular purpose.
To add custom code, place it in a file inside submodules/ and add that file's name (minus the ".lua" extension) to the Submodules.Include call in modmain.lua. Such code will have access to the variable imports performed in imports.lua and the conveniences defined in conveniences.lua, alongside the usual mod environment capabilities.
The default submodules do (at least) the following:
Enable debug keys.
Add a new row of buttons to error screens, with a button for reloading the game state (like the previous mod) and another one for going straight to the main menu (without any saving).
Run consolecommands.lua and export a few additional console utilities, listed below.
Export an utility function called regen_level(), which regens the current level (erasing it).
The additional console functions are:
This mod will be listed as outdated in the Steam version. This is necessary to keep compatibility with standalone.
Sample mod showing how to add a custom tech branch. In this example, the fire pit is used as the prototyper for a recipe of rocks (in the Magic tab).
Due to a game change made to have recipes not requiring a prototyping structure cease to be prototypable (see this), unfortunately it was necessary to override the method Builder:KnowsRecipe() from the Builder component. More generally, the hardcoded logic in the Builder component prevented this implementation from being as clean and simple as I'd like. It is functional, nevertheless.
Thanks to Heavenfall for originally looking into this.
Improves the information shown in game crashes by displaying information about the entity that triggered it.
Disclaimer: This mod is primarily meant for other modders. While its use is simple (since it simply needs to be enabled) and the information it presents might help tracking down the cause of bugs even in vanilla Don't Starve, the discussion below, explaining what the presented information means, assumes some level of familiarity with the inner workings of Don't Starve.
Whenever a crash occurs, this mod will attempt to find the entity "responsible" for it and show a set of information about it, in order to help to track down the root cause of the issue. Scenarios where the entity is found include crashes triggered within prefab files, components, stategraphs and brains*.
The following information about the entity is shown:
Its number (its GUID) and its prefab name;
Its variable name, within the function that triggered the crash (this may be an "indirect" variable name, such as self.inst);
Whether the entity is valid;
Whether the entity is in limbo (i.e., whether it was removed from the scene);
Whether it's asleep (in the sense that it is not active);
How long it's been alive (i.e., how long it has been since it was spawned, noting that reloading a save respawns all entities);
Its position (as world coordinates);
Its distance to the player.
In the error screen, the entity information is presented on the right of the stack trace (hence dividing the usual text region into two columns). See the attached screenshot for an example (obtained by replicating this bug with the mod enabled). In the same example, the following is printed in log.txt:
Note that, unfortunately, usage of this mod causes two "LUA ERROR stack traceback" blocks to be printed per error (the second being a "continuation" of the first). This happens because for the mod to work it needs to catch an error and then rethrow it.
* The general condition is the following: the mod takes a look at the first parameter passed to the function that caused the crash (the "self" parameter, if any, counts as the first); if this parameter is an entity, this entity's information is displayed; otherwise, if this parameter is a table with an entity stored in its "inst" field, this entity's information is displayed. This convention is adopted because most (all?) function in the Don't Starve code that operate on an entity either receive that entity as its first argument, or receive a "self" first parameter which stores the entity in self.inst.
Based on this thread, I decided to write a version of require() for mods. The use() function works just like require(), but looks for files taking the (root) mod directory as a base and runs them inside the mod environment.
Feel free to just drop use.lua into your mods. Below is some documentation on its behaviour, and I attached a simple sample mod ("usage") to show how to use it in practice.
Why "use" and not "modrequire"?