UrmaneHendrake

  • Content Count

    19
  • Joined

  • Last visited

Community Reputation

1 Neutral

About UrmaneHendrake

  • Rank
    Junior Member
...

Recent Profile Visitors

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

Enable
  1. aaaand that's why I have powered filters I've had time to look through the thread Saturnus posted, that and Yanru's pictures are far simpler. The complication I had came from two input pipes - reducing it to one allows the much simpler setup. I'll use gas filters until the loops are primed, then just deconstruct them and put in two bridges. BTW, I'm building blueprints in my sandbox - that's why I had both paths initially, the idea was build it once and done ... but it went down the rabbit hole Thanks all, I really appreciate it!
  2. How does one assure that you get the right gases, and on the right loops? For instance, what if you get O2 in both?
  3. I'll look at the pliers mod, thanks! Here's a markup showing where I had questions: markup The yellow box shows where I need to route around the gas filter output. I had thought I could run that pipe through that green square, but I guess I just never noticed one cannot? The red boxes show different behavior - on the left, packets can flow past the bridge entrance if they can't go over. On the right they cannot, that extra loop is needed.
  4. Thank you 0xFADE and Saturnus, I will look carefully at those - an automatic splitter with *no* power would be even better Yunru and dallion, it is a mess Here's some more pics to try to explain (tho it looks like the other suggestions may be better, so perhaps this is moot). Here we see input bottom right of the picture, and the right-hand gas filter, set to hydrogen, priming the right-hand mechanical filter. The left-hand filter will do the same with the oxygen when it gets there: Priming the mechanical filters Here we see the oxygen mechanical filter primed, to the left of the center pipe, and the hydrogen mechanical filter primed to the right. Inputs are still going thru the gas filters, into the mechanical filters, and O2 and H2 exit the mechanical filters up out the top of this picture. We also see down the center O2 and H2 that came in the "wrong" input pipe get a second chance to hit the mechanical filters - that big H2 packet right in the middle will go over the bridge to the H2 loop and exit up. This was a big goal for me in trying to make this. System primed and running Here the outermost gas valves have been opened, and the path bypasses the gas filters - the system will continue to run with no power, filtering O2 and H2, even if they get mixed in the input pipes. Any contaminant gases, in either input pipe, exit down (not shown). Running with no power Thank you for your comments - this was a fun mental exercise, and I appreciate your comments, even if there's already a better way
  5. I'm moving away from centrally processed gas separation to more filter-at-source, and I'm also trying to reduce power consumption. I put this oxygen and hydrogen filtering mechanism together for my early-game electrolyzer setup, and thought I'd share for feedback and hopefully answer a few questions before cratering testing on a real base. double mechanical filter Piping schematic Input pipes bottom right. Output oxygen and hydrogen on top. Contaminant gases out bottom middle. The rest is a mirror-imaged setup of two hybrid electric/mechanical filters. Inside are two mechanical filters a la PVD's post. Outside that are two gas filters to prime them. Outside that are two gas valves to bypass the gas filters. Set the inside gas valves to 1g, the outside gas valves to zero, and the filters to hydrogen and oxygen, aligned to which input pipe you normally expect each gas to come in on (I have at least two pumps in my electrolyzer room). After the inner loops are primed, set the two outer valves to 999g. This will bypass the gas filters and continue to run both using no power. Since my electrolyzer gasses always seem to unbalance, the additional bridges in the middle allow oxygen and hydrogen to recombine and properly output if they get pulled in the wrong source gas pump. Contaminant gases will (usually) cause the gas filters to turn back on until they are flushed. Questions: - The pipes top left and top right must route around the gas filter output. If I run it through that square, it locks up - is that normal, and I just never noticed? - The tiny little bump on the right seems to be required because gasses that fail to go over that bridge won't go travel to the pipe above, instead they lock up ... unless that extra loop is there, then they alternate paths. Any idea why that is? Like I said, haven't tested it live, only sandbox, but I'm liking it - it's spaghetti, but it's just a bunch of pipes and it'll save a lot of power if it's sturdy. Thanks!
  6. In case it's useful, this is the shard mod config I used to use in my dedicated server, for 3 forest worlds and 1 caves, all interconnected: ["workshop-595764362"] = { -- Shard Configuration Mod enabled = true, configuration_options = { ["SyncFromMaster"] = true, ["Connections"] = { -- only point higher, not lower;must be the same in every shard; 2ways list only one side! ["1"] = { "2", "2", "2", "2", "3", "3", "3", "4", "4", "4" }, ["2"] = { "3", "3", "3", "3", "4", "4", "4", "4" }, ["3"] = { "4", "4", "4" }, --["4"] = { }, }, -- ["OneWayConnections"] = { -- ["1"] = { "2", "2" }, -- }, }, Unfortunately, too many of the other mods I use couldn't handle the multiple forests, and even fewer could handle multiple forests with different configs (I wanted 3 unique worlds, not 3 identical worlds).
  7. The steam client update today appears to have fixed this for me. I've resumed Gorging
  8. I had similar problem, players not able to join existing dedicated server with a world started before The Gorge - we had all players Enter The Gorge and play a match, and then all players were able to join.
  9. Same/similar issue, Gentoo linux, Steam. I play daily, and played a 45 minute Gorge game just yesterday. There was a Steam update today, IIRC. Have done "steam --reset", validated DST local game files integrity. This is the output I get when trying to run: GameAction [AppID 322330, ActionID 4] : LaunchApp changed task to ProcessingInstallScript with "" GameAction [AppID 322330, ActionID 4] : LaunchApp changed task to SynchronizingCloud with "" GameAction [AppID 322330, ActionID 4] : LaunchApp changed task to SiteLicenseSeatCheckout with "" GameAction [AppID 322330, ActionID 4] : LaunchApp changed task to CreatingProcess with "" GameAction [AppID 322330, ActionID 4] : LaunchApp waiting for user response to CreatingProcess "" GameAction [AppID 322330, ActionID 4] : LaunchApp continues with user response "CreatingProcess" Opted-in Controller Mask: 32 Game update: AppID 322330 "", ProcID 18203, IP 0.0.0.0:0 >>> Adding process 18203 for game ID 322330 GameAction [AppID 322330, ActionID 4] : LaunchApp changed task to WaitingGameWindow with "" ERROR: ld.so: object '/home/urmane/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. /bin/sh: -c: line 0: unexpected EOF while looking for matching `'' /bin/sh: -c: line 1: syntax error: unexpected end of file GameAction [AppID 322330, ActionID 4] : LaunchApp changed task to Completed with "" >>> Adding process 18204 for game ID 322330 Game removed: AppID 322330 "", ProcID 18203 No cached sticky mapping in ActivateActionSet. I understand that ld.so error is to be expected, but the next two /bin/sh lines look fishy. EDIT: Plain Don't Starve works fine - appears limited to DST.
  10. Regardless of why, see http://steamcommunity.com/sharedfiles/filedetails/?id=595764362 for a way to address what appears to be your overall issue (starting more than 2 shards). I currently run a dedicated server with three forests and one cave, all interconnected via sinkholes.
  11. First time modder here, and I'd like to ask about ranges and events. I've forked snekoo's PartyHUD mod here: http://steamcommunity.com/sharedfiles/filedetails/?id=1233501056 and it appears that teammate's badges are only visible/updated when within range, meaning a player only gets relevant events when that other player is within range. This sorta makes sense, as I understand other actors in the game work differently when inside/outside a player's range. That logic doesn't appear to be in the module, so I'm assuming it's part of the base game normal operation. Two questions then: Is that range assumption basically correct? Is there a way around that?