rezecib

Registered Users
  • Content count

    3,856
  • Joined

  • Last visited

Everything posted by rezecib

  1. You can also do things like this with the sea lab, yard, etc, because aquatic recipes don't check collision with Builder:CanBuildAtPoint
  2. This may not be the best place to put this, but I've been updating Geometric Placement to play better with the new structures. However, the way that they are implemented with placeTestFn makes it very difficult to incorporate them. For the Tar Extractor, placeTestFn is responsible for both checking for nearby tar slicks and then also repositioning the provided inst onto it. This is problematic because the repositioning is "silent"-- by calling the function you can't tell if it's been repositioned or not (except by seeing whether it returned true for whether the build position was valid, but the other users of this function also use this). For the fish farm, placeTestFn is doing two things: Hiding some animation symbols Doing its own separate check for nearby structures within 5 range The hiding animation symbols part is problematic because I would like to be able to run these checks for my grid points as well, and these don't have these animation symbols. The separate check part just seems unnecessary-- why doesn't it simply use the recipe's min_spacing parameter? There would be a small functional difference (it would also be blocked by non-structures), but it would be much cleaner. (and a side note about min_spacing, that "finalling hack" for chests in components/builder could be rolled into the recipe too; the code around that hack could also be improved by precomputing min_rad*min_rad instead of doing it every iteration). Perhaps it would be better to have the tar extractor use a "findValidPlace" function which explicitly returns the valid position or nil if none is found. The fish farm's placeTestFn's code could all be moved elsewhere (e.g. a postinit function parameter for MakePlacer for the anims, and then using min_spacing), making it unnecessary. This would allow me to disable the grid when "findValidPlace" is populated, which makes sense because there's only going to be one nearby place, but still have a grid for fish farms, for which it makes sense to show the possible valid locations. Edit: So I guess the reason it isn't using min_spacing is because aquatic recipes actually ignore it in favor of their isShore, nearShore, tooClose check. This check actually has some pretty strange behavior and would benefit from being rewritten. I see that it looks like the intent was for ballphin palaces to not be buildable near land, but because the check is just checking various points around the edge of a square, certain islands allow placing ballphin palaces by shore (screenshot attached). Perhaps a better approach would be to precompute shore distances for all tiles in the world? For simplicity this could be done with Manhattan distance in at worst O(n^2) time by first checking each tile to see if it's shore, and then doing a recursive crawl outwards and assigning the minimum of the current distance for that tile and the current recursive depth. Alternatively, this kind of square check works fine as long as it's not checking distances over 4 (as this could allow it to miss inner tiles), and would work almost perfectly for distances up to maybe 12 or so. But the current 100 (25 tile!) distance for ballphin palaces doesn't make any sense with this method. Rather than adding this new function for basically doing the same min_spacing check, perhaps aquatic recipes should just do both the shore check and the normal collision check? I marked in red the points I believe it is checking to see if they are water for the tooClose predicate.
  3. I completely agree, the fact that it's percentage based makes it feel awful on the lower-hp boats. It also feels bad to just sit there and wait for it to be repaired. I'd much rather have a slower repair rate and be able to leave a boat there to be repaired (so you could just keep two boats and swap at the sea yard, and come back to a repaired one).
  4. Try to keep the "I have a problem with my mod" posts to their own topics. I read literally everything in this subforum, so I will see it. First off, I know this is a really long post. The thing is, modding is complicated, and there are a bajillion directions you can go with it, so just trying to cover the basics is still quite a lot of stuff. I tried to organize it so that you can skip to parts that are relevant to you, though. Unfortunately, I don't think I can fix the within-post links, which worked in the old forum software but there doesn't seem to be a way to repair them now. If you're skipping this because it's too long, or are only going to skim for parts you want, here's the minimal set of things I recommend you read: Introduction General Advice Basic Lua guide (you have to open the spoiler for this before you can jump to its sub-entries) LuaGuideLooseTyping'>Loose Typing LuaGuideMinimal'>Minimal Evaluation LuaGuideTables'>Tables LuaGuideObjects'>Tables as objects (and how to modify their functions nicely) Reading the code Start with another mod or game files Tips on fixing crashes Transitioning from Don't Starve to Don't Starve Together Using the same code for both games New TheThings New stuff in the modinfo List of things that are mosty the same (with notes on minor differences) Differences New things in prefabs Informal explanation of major engine differences (replicas, classifieds, netvars, and RPCs) Component Actions Other miscellaneous differences List of things that are currently not (nicely) moddable Other guides for DST Selected useful guides from the single-player mod forums Introduction I decided to write this modding tutorial because when I was getting started modding, none of the tutorials really did it for me. I don't want to devalue the effort that was put into the other tutorials-- and there are many (here's a compilation of guides for DS), and many of them are great at explaining how to do specific things. The reason why there aren't any good tutorials on generally getting started is that getting started is actually really hard, and there are a lot of directions you could go, so it's really hard to cover them all. Hopefully this tutorial at least helps with that a little. General Advice I think most people get started with an idea. So you have a thing you'd like to mod into the game, maybe a new item or character. How do you get started? Well, the first thing is you have to know how to write code (that is, in general, in any language). There are lots of tutorials/lessons/etc around the internet for learning that. Next, you need to be able to read and write Lua code specifically. Personally, being told to "go learn Lua" isn't something that works for me. If it does for you, then definitely go do that! It'll probably give you a well-rounded understanding of the language. If it doesn't work for you, though, then you probably need to dig into some existing Lua code. The best place to do that is the game's code. Think of things in the game that are similar to what you want to do, find them in the files, and keep reading/poking at them until you understand how they work. At first, this will be hard-- there are aspects to Lua you may not understand. You'll just have to look them up as you go. As for general information on how the game logic is put together, the thing that I found most helpful was Wots The Diff??. Basic Lua Guide A few aspects of Lua are really, really important, though, so I've written a little very informal guide on some of them: Minimal evaluation (or short-circuit evaluation): Tables: Tables as objects (and how to modify their functions nicely): Reading the code Next, you have to be able to read the game's code. I can't stress this enough; how can you expect to mod something if you can't even go about figuring out how it works in the first place? You don't have to understand how ALL the code works, but you need to be able to understand at least the part you're modifying. I think the biggest problem people have here is that they don't know how to go about looking at the game's code. So I'll give some recommendations. Start with another mod or game files Once you're about to start writing the code for the mod, I wouldn't recommend just starting completely fresh. It's way simpler and easier to take the most similar mod you know of, or the most minimal mod you know of, copy that folder, then rename and change things. This ensures you have all the pieces you need (modmain, modinfo, etc), and then you can see what you need to change. Similarly, when you're making a new item or creature, start by copying over the most similar item/creature from a mod or the game files. This ensures that you aren't missing crucial stuff. So, for example, you want to make a new equippable; start by copying over spear.lua, and look at a mod that adds an item to see that you need to add it to the PrefabFiles table in the modmain. Once you have the copy, you can start renaming things and changing the assets or properties. Tips on fixing crashes Transitioning from Don't Starve to Don't Starve Together So all of that covers most of the stuff I can think of for how to generally approach modding. Now let's cover the differences from DS to DST (because there are plenty of tutorials for how to do specific stuff in DS). Using the same code for both games New TheThings New stuff in the modinfo List of things that are mosty the same (with notes on minor differences) Differences New things in prefabs Informal explanation of major engine differences (replicas, classifieds, netvars, and RPCs) Classifieds: Networked variables: Remote Procedure Calls (RPCs): Simplex's explanation of the purposes of replicas and classifieds: Components previously attached to players The main other engine change that I'm aware of is that some components that were before attached to the player are now attached to the world, instead (such as hounded, hunter, and kramped). Additionally, many of the components attached to the world have been rewritten to sync over the network and are currently pretty unmoddable (that includes clock, weather, ambientlighting, etc). As part of this, some things that were previously handled by ListenForEvent are now handled by WatchWorldState. Looking at worldstate.lua (in components) is the best way to see what was changed, but pretty much any clock/weather related events are now accessed by WatchWorldState. Component Actions Other miscellaneous differences Probably a few more things that aren't occurring to me now. List of things that are currently not (nicely) moddable Other guides for DST Selected useful guides from the single-player mod forums Hopefully this guide was helpful, and if you have anything you think I should add (especially more things we specifically can't do, or need to be done slightly differently in DST), definitely let me know!
  5. When a circuit overloads, the bridges are targeted first. However, CircuitManager assigns wire bridges to the circuit they cross over, rather than the circuit they are linked to. This means that wire bridges don't overload if there's no circuit under them, and overload at the wrong time. I've attached a save demonstrating this. It consists of a heavi-watt circuit and a normal circuit, each with more than 1 kW power drain. The wire bridge on the left should be part of the heavi-watt circuit, but overloads when the normal circuit is powered. If it's removed, the two wire bridges on the right do not overload, but a wire does instead. I believe this is due to the following part of CircuitManager.Rebuild: HashSet<UtilityNetworkLink>.Enumerator enumerator3 = this.bridges.GetEnumerator(); while (enumerator3.MoveNext()) { UtilityNetworkLink current3 = enumerator3.Current; int cell = Grid.PosToCell(current3.transform.position); ushort circuitID3 = this.GetCircuitID(cell); if (circuitID3 != 65535) { this.circuitInfo[(int)circuitID3].bridges.Add(current3); } } It uses the center cell of the wire bridge to determine which circuit it's attached to. Instead it could use UtilityNetworkLink.GetCells() to get the cells the bridge is actually linked to, and use one/both of those to determine the circuit. WireBridgeBug.sav
  6. I propose something like a switch that can operate on the power grid. It consists of two items: a radio transmitter and a radio switch. Each of them can be set to respond to a particular radio frequency. The transmitter takes, say, 10W of power and transmits at that frequency. The radio switch can be set to disable its wire like other switches when receiving (or not receiving) that frequency. This would allow for wireless broadcasting of temperature/pressure conditions across the map. It would be easy to chain with the existing switches, so for example you could put a thermo switch before a transmitter, to broadcast when a temperature has been reached.
  7. Huh, at the time I did that it was debug-diggable and I had no crash issues.
  8. Geometric Placement

    @LucazST15 O que o crash diz? Verifique se as pastas são "mods / GeometricPlacement / modmain.lua"
  9. Geometric Placement

    Version 2.2.2

    29,677 downloads

    This should work with all versions of the game (vanilla, Reign of Giants, Shipwrecked, and Don't Starve Together). Also available on the Steam Workshop (single-player, DST). Snaps objects to a grid when placing and displays a build grid around it (unless you hold ctrl). Credits to zkm2erjfdb and Levorto for writing the original single-player versions (Architectural Geometry and Assisted Geometry). This mod is a replacement for those mods; if you have one of them enabled as well, unpredictable things will happen. Description of the options: CTRL Turns Mod: "On" makes it so that the mod is off by default, but turns on while holding CTRL. "Off" does the opposite, temporarily disabling the mod while holding CTRL. Options Button: By default, "B" (for controllers, right-stick click in single-player and left-stick click from the scoreboard in DST). Brings up a menu for changing these options. Note that it cannot save these options in-game like it can on the configuration menu, so if you find new favorite settings with this, you should make those changes in the configuration menu too. Toggle Button: By default, "V" (no binding for controllers). Toggles between the most recently used geometries (it will guess if it doesn't know, which should only happen if you just transferred between the caves and the surface or joined the game). In-Game Menu: If set to "On" (default), the options button will bring up the menu. If set to "Off", the button will simply toggle the mod on and off (like it did before the menu was added). Show Build Grid: Determines whether it shows the grid at all. Grid Geometry: The shape and layout of the grid. Square is the normal one, aligned with the game's X-Z coordinate system. The hexagonal geometries allow you to do the tightest possible plots. Walls and turf always use the square geometry. Refresh Speed: How much of the available time to use for refreshing the grid. Turning this up will make the grid update faster, but may cause lag. Hide Placer: If set to on, the ghost-version of the thing you're about to place is hidden, and instead the point where you'll place it is marked. Hide Cursor: If set to on, the item you're placing won't show up on the cursor while you're placing it (sometimes it gets in the way of being able to see where you'll put it). Fine Grid Size: The number of points in each direction that it uses for things with a fine grid (most things). Wall Grid Size: The number of points in each direction that it uses for walls. Sandbag Grid Size: The number of points in each direction that it uses for sandbags. Turf Grid Size: The number of points in each direction that it uses for turf/pitchfork. Colors: Red/Green is the game's normal color scheme. Red/Blue should be more readable to players with red-green colorblindness. Black/White is there for fully colorblind players, or players who want the grid to be more readable at night. Outlined uses black and white with outlines to give the best visibility in all situations. Tighter Chests: Allows chests to be placed more closely together. This doesn't always work in DST. I keep this only as a legacy setting because the other geometry mods override a special case the game makes for chests. Controller Offset: Allows you to disable the usual offset that rotates around the player when placing objects. Defaults to off. Hide Blocked Points: Instead of showing red/black points where you can't place things, this can set it to hide those points instead. Show Nearest Tile: In addition to showing each of the points, this can set it to show the outline of the nearest tile, making it easier to align placement with the turf.
  10. Hmm, well technically the hatch consumption rate is affected by their animations, so it's a bit hard to get exact. But they could produce up to 1000 g/s, and each fertilizer maker makes 120 g/s. So at max capacity you would need 8.33 fertilizer makers per hatch. If you can keep a natural gas complex's temperature below 70C (should be quite feasible, probably don't need to do anything actually), then two hatches could eat all the fertilizer, giving about 1.92 kg/s of coal, which if taken to (two) coal generators would give almost 1.2 kW of power. Removing the coal would be somewhat annoying and uncomfortable to the dupes, though, so you might want to have a hydraulic timer system (Klei add real timers pls <3) to periodically unpower a door so that the access controls get disabled and dupes can enter to sweep up the coal.
  11. Because succulent_picked is missing an entry in STRINGS.NAMES, when recipepopup looks for STRINGS.NAMES.SUCCULENT_PICKED, it finds nil. This results in the ingredient tile for it having no tooltip. If a STRINGS.NAMES entry were added, then this line could also be removed from prefabs/succulent_plant.lua: inst.name = STRINGS.NAMES.SUCCULENT_PLANT
  12. I don't think so actually. Hmm perhaps. Since it's an item, it's probably using the Sublimates component, which means mechanically it would function more like slime in terms of production of polluted oxygen. It doesn't seem like it would be that hard to mass-produce bottles, you'd just need a row of wash basins and have duplicants walk by frequently. But... I'm not sure it would really be worth the time, because the animation for the wash basin is a bit long, and basins require water to be delivered as well. Although it takes a lot of space to evaporate polluted water, it is extremely easy to scale up and is pretty much entirely maintenance-free once it is scaled.
  13. Summary: Farming: New harvest system: plants have a requirement for air pressure, *body temperature* (not air temperature as before), illumination, atmosphere (set of allowed gases), and presence of liquid. If any of these are not met, plants won't grow. Seeds are produced with a % chance on each harvest. Farming research has been split into 3-- Basic Farming (Tier 1) as before, Meal Prep (T2, Cooking Station, Refrigerator, Farm Tile), and Agriculture (T3, Fertilizer Maker, Hydroponic Farm, ?Seed Splicer?). It looks like Aquatic Farm Tiles are gone. Mushrooms are now called Dusk Caps and look pretty and purple. Swamp Lilies are now called Balm Lilies and show up in the Caustic/purple biome. They produce flowers with "medicinal properties". Liquids: We saw the Liquid Bottler before, which is built over a liquid and allows dupes to bottle the liquid. We also have a Bottle Emptier now, to which dupes can deliver bottles to release the liquid. You can set which liquid the Emptier accepts. It empties bottles at a certain rate (seems to be somewhere in 1-10 kg/s) Bottled polluted water will evaporate, making polluted oxygen. Mopping makes bottled liquids. Diseases: As before we saw the overlay, with germs being shown on cells, dupes, and having sources like outhouses. Current diseases: Food Poisoning, Trench Stench, The Spores, and Slimelung (seems to be in the Caustic/purple and Swamp/green biomes). Things like hypothermia that aren't germ-based are separate and still exist, may get called "Ailments". Duplicants have an "immunity meter" that can be monitored in the vitals panel, and contact with germs depletes immunity. When it hits zero, they get the disease. They appear to innately replenish 10 per cycle. The Immunity stat gives them extra immunity meter. Germs die faster when the area is heated up. New Wash Basin building. Duplicants use it if they walk by it (in a particular configurable direction), allowing you to control when they use it by controlling duplicant pathing. Water is delivered to wash basins, and when used they produce bottles of polluted water (with the germs in the bottle). The hand sanitizer uses the same walk-by system, but destroys the germs instead of moving them. Polluted Water and Oxygen aren't sources of disease anymore, but they allow germs to spread very quickly. Slimelung seems to reduce breath capacity and causes them to produce slime. Miscellaneous: New Trait, Caregiver, appears to increase Medicine New negative traits, Squeamish and Trypophobia. Presumably affect stress generation in some way. Storage Compactors now have a slider for how much you want to store in them (can request less than the full 20 tons). Plumbing and Ventilation now have separate building tabs. Priority overlay has been removed from the overlay strip, but using the priority tool still shows it. New creature, Shine Bug, emits light and has +10 Decor like other creatures. Daily report now breaks down travel time, and time spent doing different tasks. Helps figure out what duplicants are spending time on (like delivering)
  14. Exact numbers depend on the pressure that the wheezewort output reaches, since that determines the backflow along the wheezewort staircase. I don't think anyone has a model for how gas flow over pressure gradients actually works in the game right now. If we get one then you should be able to get a theoretical calculation of its efficiency. Perhaps a good experiment for someone to try :P. I would do it but I will be out running around in the sweltering heat today
  15. CO2 is also a good choice because dupes entering and leaving won't leave little pockets of CO2 messing up the pressure. What's your setup? The way Kasuha has it, it has to pass the input of the thermo regulator to get to the overflow bridge. Packets always enter an input if they can, so they should always enter the thermo regulator unless it is stopped. Although perhaps if you are a bit over-capacity then some may bypass it because the output of the thermo regulator may be blocked.
  16. I ran mine for over 100 cycles without needing to do anything about the heat (granted, mine wasn't 100% thermodynamically sealed-- I had some doors). If you want, you can try dripping the 40C polluted water coming out of the scrubbers to cool the rest, but for the most part the fixed-temperature outputs of the fertilizer makers do a lot to keep the temperature stable. As long as you build everything out of gold amalgam it should be fine, and stabilize around 60-80C.
  17. @natemiddleman Yup, I've built it before. I put up the math and a guide on the wiki. Edit: Also, fun fact I calculated last night was that polluted water on its own is worth a net of up to 3.72 J per gram, using a triple system (scrubber + fertilizer maker + natural gas generator) like this. Edit 2: Also, it uses less water. Only 1919 g/s-- the only water input required is for the scrubbers, and two scrubbers can only use 2 kg/s total.
  18. This looks to be intended. Looking at the code, that seems to be the case. In CircuitManager.Rebuild, this is what I see for the part about bridges: HashSet<UtilityNetworkLink>.Enumerator enumerator3 = this.bridges.GetEnumerator(); while (enumerator3.MoveNext()) { UtilityNetworkLink current3 = enumerator3.Current; int cell = Grid.PosToCell(current3.transform.position); ushort circuitID3 = this.GetCircuitID(cell); if (circuitID3 != 65535) { this.circuitInfo[(int)circuitID3].bridges.Add(current3); } } So it's deciding which circuit it's a part of based on the cell it's in. But which cell is it actually in? WireBridgeConfig lists the connection points at offsets from the main position: utilityNetworkLink.link1 = new CellOffset(-1, 0); utilityNetworkLink.link2 = new CellOffset(1, 0); So we know that the actual position (offset 0,0) is the center of the bridge. (this isn't the case for all world objects) I also looked into how GetCircuitID works, and it was a long path but seems to all work as expected.
  19. I just responded to your post on Reddit, but might as well repeat here. The issue seems to be that the report doesn't count Power Usage: Removed correctly. It only counts towards that when power is removed directly from a generator/transformer, and ignores batteries. So the reason you see it doubling is probably because the generators are not doing their short bursts at the same time, so you're seeing twice as much power being removed directly from them without a battery as an intermediary. I submitted a bug report on this with a save file demonstrating it and a suggested code fix. Edit: To do the math on it, you produced 282 kg of oxygen. This means consuming 317 kg of water. 31.7 s of uptime for the water pump (pumping 317 kg at 10 kg/s) 634 s of combined uptime for the gas pumps (pumping 317 kg of gas at 0.5 kg/s) 317 s of combined uptime for the electrolyzers (using 317 kg of water at 1 kg/s) Of course, the pumps might actually run at slightly lower efficiency, but if they were perfect, then this would be about 198 kJ of power removed. So it's definitely under-reporting, and when you connected the two you got it to under-report slightly less by reducing how much it was drawing from the batteries.
  20. The Power Usage report adds to the Added count when a generator generates power, but it only adds to the Removed count when power is removed directly from the generator (by a consumer). This means that any power that's removed from batteries isn't counted; so you can have batteries draining with non-negative Net Power Usage. I've attached a save showing batteries draining with zero Power Usage: Added, Power Usage: Removed, and Power Usage: Net. I believe this could be fixed by adding to the report in CircuitManager.PowerFromBatteries: private float PowerFromBatteries(float joules_needed, IList<Battery> batteries) { int num; float batteryJoulesAvailable = this.GetBatteryJoulesAvailable(batteries, out num); float a = batteryJoulesAvailable * (float)num; float num2 = Mathf.Min(a, joules_needed); // begin added code ReportManager.Instance.ReportValue(ReportManager.ReportType.EnergyCreated, -num2, null); // end added code joules_needed -= num2; float joules = num2 / (float)num; for (int i = batteries.Count - num; i < batteries.Count; i++) { Battery battery = batteries[i]; battery.ConsumeEnergy(joules); } return joules_needed; } PowerUsageRemovedBug.sav
  21. It looks like you based everything on a single-player mod. You'll run into fewer hiccups if you look at the DST code and mods as a reference instead. For example, in the modinfo you have an API version of 6, but DST uses 10. But I think your main problem is that you never add networking to sooty. Look at a simple prefab like the spear as a reference.
  22. Yes, painting requires you to unpause briefly before it takes effect.
  23. Not in the list. Looking at the code for it (DebugPaintElementScreen), it seems that all loaded elements should be there (there is a flag for excluding from the list but nothing seems to set it), but... it's not. I was able to edit the IL code to substitute the manually-specified CO2 for SlimeMold, and that let me paint it, though.
  24. It's actually shorthand for mole :P. It's basically a specific number of atoms (Avogadro's number), the number chosen so that the total mass is the about the same number of grams as there are particles in the atomic nuclei. So a mole of water is 18 grams, because each of the two hydrogens has just one proton, and the oxygen has 8 protons and 8 neutrons, for a total of 18. (the numbers actually end up being very slightly different because it's averaging over the frequency of different isotopes, which can have extra/fewer neutrons-- in the case of oxygen it sometimes has one or two extra neutrons, but ~99.8% of the time it just has 8) But yeah, I'm definitely having a blast with the math in this game
  25. The best way to absorb the heat is probably polluted water. Drop polluted water down there, let it turn into steam, find a zone where the temperature gets low enough to pump, and pump it into a void.