Registered Users
  • Content count

  • Joined

  • Last visited

Community Reputation

3,101 Excellent

About rezecib

  • Rank


Visited by the Title Fairy
  • Visited by the Title Fairy
Don't Starve Together
  • Contributor

Recent Profile Visitors

11,309 profile views
  1. TheWorld doesn't have a birdattractor component, it's attached to the players instead. Similarly the birdspawner component is written with the idea that only players will make birds spawn, which makes your job here somewhat difficult. Some approaches that would work: Hook into birdspawner and get it to recognize other things (this looks pretty difficult just glancing at the component) Have birdy detect nearby players (e.g. with playerprox), and modify their birdattractor Override birdattractor.spawnmodifier.CalculateModifierFromKey to look for nearby birdys, and return a higher value if so
  2. The colorful coral tiles generally seem to be considered shallow water by most of the game, but technically aren't GROUND.OCEAN_SHALLOW. So seaweed spawns there naturally, but if you remove it with a trawl net you can't replant it there.
  3. Sea Yard is a bit slow

    Time is money. Or repair kits, in this case.
  4. Sea Yard is a bit slow

    It looks like you're right about that. Which makes waiting for the Sea Yard even more boring, because it costs you to dance around it... function BoatHealth:DoUpdate( dt ) if self.consuming and self.moving then self:DoDelta(-dt*self.rate) end if self:IsEmpty() then self:StopConsuming() end if self.updatefn then self.updatefn(self.inst) end end In any case, the value of a repair kit is somewhere between the two values I posted, depending on how much you move around the Sea Yard, I guess.
  5. Sea Yard is a bit slow

    Boat degradation rate is defined in a rather weird way-- each boat is set to lose all of its health over some number of days. So this results in different hp and %hp loss rates for each boat. I ended up putting this in a spreadsheet (lol), but as a result of boats degrading while they're being repaired, repair kits are actually worth a bit more for each boat.
  6. Sea Yard is a bit slow

    What do you mean? The calculations there are correct. The Sea Yard doesn't repair x hp per second, it repairs 0.5% hp per second. So how long it takes to repair 300 hp on the boat is what I listed (e.g. 240s for a row boat). I was giving the value of a repair kit in sea yard time for each boat, so the idea is that if you can get a boat repair kit in less time than that, then it's better to use a repair kit. Edit: Although I didn't account for boat degradation during the time the sea yard is repairing...
  7. Sea Yard is a bit slow

    It takes 200s (a little under half a day) to fully repair a boat. So it's a bit strange in that its efficiency compared to repair kits depends on the max health of the boat. Row Boat, 250hp: a repair kit is worth 240s of sea yard time Armoured Boat, 500hp: a repair kit is worth 120s of sea yard time Encrusted Boat, 800hp: a repair kit is worth 75s of sea yard time For trees, it takes ~20s to do the whole cycle of chopping, digging the stump, picking up the drops, and planting the pine cones, and yields one board worth of wood. For grass, it takes ~5s to harvest one rope worth of grass. Stingers can be automated much more easily, but you still have to pick them up. So let's overestimate that it's 5s per 2 stingers over all (including the time it takes to walk over there). So overall it takes around 55s to farm a repair kit. Even if you're not very efficient about it, it shouldn't take more than 120s. So for anything other than an Encrusted Boat, repair kits clearly win on time efficiency. For the Encrusted Boat, you have to be pretty efficient to beat the sea yard, but it's doable. But I think the real problem is that it doesn't feel very good to sit there. So you either need massive investment into sea yards everywhere (which probably shouldn't be able to be placed as close together as they are now anyway, which means that when that gets fixed it'll make planting them everywhere get in the way of placing other things). And for those saying it's fine because you sit there overnight anyway... a lot of players don't sit somewhere overnight, it's a huge waste of time you could be spending getting places, at the very least. Light is cheap, especially in SW where you have yet another slot you can put a light in. Personally I'd much rather it repair one nearby boat at a time regardless of whether it's occupied, and have it take much more fuel (maybe 4x, although that depends on whether they make tar harder to get-- right now it seems bugged and I always come back to multiple stacks) and repair more slowly (a full day or even two to repair the boat). Then you could have a fleet of boats and swap them at the sea yard, which seems like a pretty natural thing to do.
  8. You can also do things like this with the sea lab, yard, etc, because aquatic recipes don't check collision with Builder:CanBuildAtPoint
  9. 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).
  10. 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.
  11. Huh, at the time I did that it was debug-diggable and I had no crash issues.
  12. Geometric Placement

    @LucazST15 O que o crash diz? Verifique se as pastas são "mods / GeometricPlacement / modmain.lua"
  13. 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.
  14. 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: = STRINGS.NAMES.SUCCULENT_PLANT
  15. 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