Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
I wanted to say it's also an Engineer's entrance, but the docking port is unusable, so you can't just wire it open from outside. Sloppy solution in my book, making a visible thing unclickable!
Sure that port could be turned into an airlock. But I feel it's better if you do it instead of a patch. Vanilla-subs are better without optimization. Such imperfections inspire engineers to take things apart and ask smart questions, like you just did! I feel this function is even more important than being able to dock a shuttle!
Hmm... So it's for docking with other vessels, then? I wasn't aware that multiple vessels could exist in the same instance. So let me get this straight - another vessel trying to dock would send a signal to the docking port, causing it to dock. When docked, the docking port would constantly send a signal out, causing the custom hatch to stay open. When the other vehicle undocks, that would cut the signal to the docking port causing it to undock, which would then cut the signal to the hatch causing it to close, potentially flooding the airlock slightly. Do I have that right?
If so, doesn't that allow foreign vessels to dock without permission? Is there any way to block a docking port from responding to an external signal?
For some odd reason, docking ports are not interactive in-game, despite being set to be interactive in the editor. It has a Connection Pannel which is set to NOT locked and YES allow in-game editing, with a "screwdriver" prerequisite.
The only thing I can figure is the docking port is classed as a generally non-interactive object the same way air ducts and wall segments are. In fact, the docking port... Isn't really a docking port. It's a "Docking Hatch" with a "Docking Port" segment attached to it. It also has a section for "Wiring" which appears unusad and redundant with the "Connection Pannel" section. Maybe there's some particular technical limitation that this redundancy is getting around, but so far I don't know what to make of the docking port. Hopefully further documentation on the editor would help.
I disagree. Players who are prone to dig under the hood of a game will do so regardless of whether they have to. My crew and I resolved to simply not use the bottom hatch, which is what most people I've seen on YouTube did. I dug into the sub's wiring because I was curious. I had reason to suspect that the game simulates wiring in some fashion as I kept wires strung all over the place and random wifi and motion sensor and water sensor gizmos. I have a background in applied mathematics and programming and am dabbling into Shenzhen I/O currently, so this sort of thing was just interesting to me regardless.
I very much appreciate games which let you tinker. I don't, however, agree that they should leave deliberate unannounced flaws in their designs for players to further optimise, because it turns into an ARG. Is this a bug or a feature? Did the developers screw up or was I intended to fix it? Or is there some hidden use I'm not aware of?
Besides, the Orca is far too cleverly designed for me to believe this particular bit was intentional. Its power, air and water management systems are expertly done and all of the doors are wired to motion sensors which shut them down after 1 second of being open. There's nothing about that sub which suggests to me that I should be looking for bad design that I need to fix. I might want to change the design in case I don't like it - such as people ripping sensors off of doors to keep them permanently open, or adding extra automated bilge pumps to rooms which don't have them.
Moreover, what I did is well outside the bounds of the actual game. There's no real way to troubleshoot or explore a sub's wiring in the actual game, since most of it is hidden inside the walls. I had to go into the editor in order to be able to even see what's going on. There are better ways to teach players about wiring (like the actual wiring tutorial) and push us into experimenting than having us dig through an undocumented workshop asset editor.
And even with all of that said, I still can't actually DO anything about that bottom hatch. In theory I could wire buttons to toggle it, but I can't actually place buttons outside the sub. There are very few structures which will take buttons, and there's no system by which to REMOVE buttons outside once placed. Interior buttons you can "remove" via use of a wrench. Once you're outside, however, that option is unavailable. So the hatch presents me with a problem that the game lacks the mechanics to actually solve.
I apologise for being negative like this. It's just I don't feel that something this simple should be this hard to understand or fix.
The docking port will continuously push 0 along its state_out output when undocked, and it's connected to the set_state input of the hatch. That means the hatch can only ever open when something is docked to the bottom airlock. At any other time, the hatch receives a continuous "close and stay closed" signal. I wired a button to its toggle_state input, but without further changes this does nothing. The swaps its state to "open" but the docking port immediately overrides this and returns this state to "closed." It appears that all logic is executed on the same tick, so no change actually takes place.
The only way I found to actually open the bottom hatch was to entirely disconnect it from the docking port and wire its toggle_state to a separate button I installed myself. This works to open and close the hatch manually, but means that if a sub docked to mine, I'd have to manually navigate in and open the hatch from the inside - it won't swing open automatically. The bilge pump in there also doesn't seem to be connected to anything and will probably keep trying to drain water even if the hatch is open - I noticed the upper airlock's pumps is connected to the hatch, and will pump only when the hatch is closed. And even then, I can't open it from the outside because I can't mount a button on the outside.
From what I've seen so far, the game's "docking" mechanics are hacked together from different parts and byzantine logic. It seems like they intended for the docking port to have its own integrated hatch (which is why it's called a "Docking Hatch" with a "Docking Port" addon), and I feel this would be the way to go. Get rid of the independent hatch and integrate the hatch into the port, with internally set delays for opening and closing the hatch in relation to docking, and possibly for manual overrides on the hatch. Having it be one item rather than two items clipping into each other and making it hard to click on them is not ideal.
For a button on the outside you can extend a shell board or other exterior piece to stick a button onto (like the default Remora has on its bottom hatch).
Yes, the Bunyip sub seems to have a hatch that can be opened with an interior button. I looked through that one, and I am completely lost as to what the wiring is even attempting to do... It has broadly the same wiring as the top hatch of the Orca, except with an additional Relay (still not sure how these work). The problem is that I'm completely confused as to how the top hatch on even the Orca works.
Docking is straightforward. There's an AND component which looks for signal that the port is undocked (NOT signal from the port) and a signal from Navigation. Once those two signals arrive, it forwards a signal to the docking port, which causes it to attempt to do. So far so good. The problem is the "everything else."
The docking port is constantly broadcasting its status to the above-mentioned NOT component, an AND component which appears responsible for undocking it and a Delay component which opens the actual hatch. That same Delay component is also hooked to the AND component which initially orders the docking - both to the Delay component's signal_in bolt. Why are both needed? Is it not simpler to run the hatch entirely off the state of the docking port? Open if docked, closed if undocked with Delay blocks sprinkeld around to ensure the airlock doesn't flood during the transition?
That second AND component - the one responsible for undocking - REALLY confuses me. I know it's responsible for undocking because it only fires when there's a signal from Navigations and the docking port is doneck. It triggrs a timer before undocking during which the hatch closes, but it also manually triggers the hatch... and the hatch is also triggered by the state of the docking port... Why all the redundancy? I mean, clearly it works, but I don't know how, or why it was donethis way.
This right there - the docking port and its overlapping hatch - are by FAR the most complex system in the entire sub, and I'm including the rat's nest of junction boxes. Sure, those have a lot of power cables which go everywhere - fair enough. But the logic there isn't nearly as labyrinthine. If I want to rewire my bottom airlock to open when docked with another sub but also by using a button, I'd need to know how docking hatches in general work, and I can't wrap my head around it.
*edit*
And incidentally, what happens when multiple signal wires are hooked to the same bolt? Am I correct to assume that if multiple lines are hooked to the same input, then signal along ANY of them will trigger it? That if multiple lines are hooked to the same output, a trigger from it will push signal along ALL of them? Trying to make sense of the wiring system is a bit tricky.
I never really dug into docking ports, so I believe you know more than I do at this point. I do agree they are more complicated than it should be for general purposes. But I prefer an overcomplicated part or mechanic over one I have no control over. I know people make elevators and stompy-battlemechs where the moving parts are essentially shuttles. Not sure if a simplified docking port would allow such (again I'm no expert of them).
I know the latter is correct, and I think the former too. I know that adder component adds up things you wire to the same pin.
No no, I get that much. I was more trying to wrap my head around why airlock works like it does. I also think I got the devices mixed around. As before, I kept mixing the "Docking Hatch" (i.e. the docking port) with the "Custom Hatch" (i.e. the actual hatch). This caused me to see wiring feedback loops where there were none. I applaud the compactness of the developers in fitting this much wiring nonsense inside the hull walls, but DAMNED if it isn't hard to read for a layman.
To aid me in this, I drafted a flowchart representing the schematic. Keep in mind that I'm no electrician so I have no idea if I used the correct notation. Still, have a look:
https://www.draw.io/#DOrca%20Docking%20Airlock
Here, each component of the system is drawn as a box, output is drawn as arrows leaving the box and input as arrows entering the box. Dashed arrows represent delayed signals, while blue boxes and lines represent signal being sent to those items. I've drawn three steps - the first is just the diagram with no power. I've labelled this "Undocked," though it's not entirely accurate. Below this is what happens when "Order Dock" is sent from Navigation, up to the moment that docking is achieved. Once that happens, the signal from Navigation stops, leading us to the third flowchart - "Docked."
This is what the ship looks like when docked and standing by. My question - then - is what happens when I issue another "Order Dock" command. So what happens next? Obviously, the bottom AND triggers, sending a signal to the already open hatch (why?), then sending another signal to the hatch with a 1.0s delay, then sending another signal to the docking port with an 0.6 second delay. Why is any of this done? Why send two signals to the hatch? Why the delay? I know from experience that this in some way causes the hatch to close and the docking port to undock, but I just can't tell how or why this is happening.
I suspect it may have something to do with how multiple signals to the same input interact with each other, or potentially how the Delay Component works, but I haven't the foggiest idea why this schematic works at all.
You were right to be suspicious. The former is correct, but the latter definitely IS NOT. Signals going into the same bolt DO NOT stack. Instead, they are interpreted in the sequence in which you wired them (so from the top wire down). Wires will pulse in sequence within the same "tick," with each subsequent signal fully overriding the previous one. Here's my testing environment:
I purchased two Switches - the ones which will constantly broadcast either 1 or 0. I wired both of them to the same light, top switch first. I tested the following situations:
When both switches are off:
* Turning on the top switch does nothing, turning it back off does nothing as well.
* Turning on the bottom switch turns the light on, turning it off turns the light back off.
When both switches are on:
* Turning off the top switch causes the light to dim, turning it back on again causes it to flicker.
* Turning off the bottom switch turn the light off, turning it on turns the light back on.
In terms of binary logic, that's a right projection - the signal is true IF AND ONLY IF the right signal is true. The left signal is irrelevant. I still don't know if not broadcasting a 1 is the same as broadcasting a 0, but it appears to be.
This then brings us to the Delay Component. I unwired the two switches from the light and wired them both to a single Delay Component with a 1 second delay. The order was the same - top switch first, then bottom switch. Under normal conditions, the Delay Component works the same as the direct connection, just on... You know, a 1 second delay. Setting the Delay Component to "Reset when Different Signal Received," though - that changed things quite a bit.
When both switches are off:
* Turning the top switch on does nothing, turning it off again does nothing either.
* Turning the bottom switch on does nothing, turning it off again does nothing either.
* Turning BOTH switches on turns the light on.
When both switches are on:
* Turning the top switch off does nothing, turning it on again does nothing either.
* Turning the bottom switch off does nothing, turning it on again does nothing either.
* Turning BOTH switches off turns off the light.
Now, I'm not sure what exactly the "Reset when Different Signal Received" option does for the Delay Component. However, when multiple binary signal sources are hooked onto its input bolt, that option seems to cause it to broadcast a new signal only when all sources are broadcasting the SAME signal. If both lines come in at 0, it broadcasts 0. If both lines come in as 1, it broacasts 1. If the two lines come in with different values, it does nothing. Essentially, behaves like an XNOR combonent hooked onto a switch.
So, if we now go back to orca, we discover that one of the Delay Components - the one which multiple inputs and outputs hooked to it - is set to "Reset when Different Signal Received." It takes signal from the docking port and from the AND compoenent which trips when an "undock" command is sent. That the delay component will constantly broadcast a signal until the sub is undocked and no "undock" command is sent, or else when the sub is docked and an "undock" command is sent, but not in any other situation.
So when the ship is docked an an undock command is sent, the AND component will send a command to shut the hatch. Because I suspect this is wired second, it'll take precedence over the 1 second Delay Component keeping it open and shut it down. It'll then send a 0.6 delay order to the dock to release and attempt to change the state of the 1.0 Delay Block keeping the hatch closed. This won't actually trigger until the dock is released and confirms the change in state of the delay block, which will then be switched over to prevent it from opening the hatch all over again once the signal from Navigation has stopped.
I THINK that's how it works, anyway. I suspect the developers are using the Delay Component WELL outside of its intended purpose - both as a constant signal broadcast unit and as a de-facto logical block and signal switch. That might be there to save on slapping together even more components... I'll continue looking into this, but I'm finally starting to understand what the hell is going on :)
*edit*
And another edge case. So far, I've been experimenting with components which always broadcast a 1 or a 0. And Components don't do that by default. They broadcast 1 if true, and nothing otherwise. A "nothing" signal isn't the same as a "0" signal. 0 has a value, nothing is simply not considered - the device getting no imput acts as though the wire is disconnected.
So I hooked a switch and an AND component to a Delay Component. The switch always broadcasts 1 or 0, and I hooked the AND component to broadcast 1 or nothing. I set the Delay Component to "Reset when Different Signal Received." These are the results:
When AND broacasts nothing, its input is ignored. The switch controls the Delay component as normal, causing it to rebroadcast 1 when switched on and 0 when switched off. When AND broadcasts 1, however, things change. If switch was off, then the light stays off until the switch is pressed. Doing so turns the light on, and the switch can no longer turn it off regardless of its position. Only when AND stops broadcasting again does the switch resume control of the light.
In other words, with AND disabled, the switch can both turn the light on and turn it off. When AND is broadcasting, the switch can only turn it on but not off. So it seems like the Delay Component when set to Different Signal will switch on matching signals but ignore no signal. Now I'm starting to see what's going on.
I also feel too weak to process such walls of text you like to post. And I could point out at the very start that when I said 'latter', I meant the wiring you described after the first, eg "if multiple lines are hooked to the same output, a trigger from it will push signal along ALL of them" - and that's true as I said.
I still saved the above for a time when I decide to get to understand how to use and exploit multiple inputs.. But I'd still prefer doing so with having the same circuitry loaded ingame.
EDIT:
Wait, I understand. So wires that added later overwrite the signal coming in the same tick from earlier wires. That's wonderful - it will save me some relay-components the next time I'm wiring something complicated.
I still can't get myself to dig into the secrets of docking..
That's exactly what I found, yes :) The component will read inputs in order and execute all of them in order. I'm not positive that this is done in the same tick, but I suspect that it is. Most components will behave as though they've disregarded all but the final input.
Lights will flicker if you feed them a 0 followed by a line which is constantly broadcasting a 1, but I suspect this is because that particular component has an "activeate" and "deactivate" animation attached to its sprite. Though the light never actually loses power, it does go into the "off" state at least once, which forces it to go through its light-up animation.
Components without such transition animations do not demonstrate this. If you feed a 1 and a 0 to a closed door in the same tick, it will not respond at all. So yes, you should be able to use this to your advantage. Different components seem to order the wires differently, but in my experience the order you hook them to the bolt is the order in which they'll fire.
I actually figured it out, finally. It relies on a bunch of quirks of the Delay Block. The way they're using it to close the hatch when undocking is a "dirty hack." The docking port will constant push 1 to a 1.0 s Delay Component. Ordering the sub to "undock" will push a 0 to it. It won't cause the component to push a 0 because the docking port will override it, but that push will reset its delay, so it will idle for 1s. The undocking order will also circumvent it and push a 0 to the hatch directly, once. Before the timer times out, a different Delay Component with an 0.6s duration will fire, undocking the sub and switching the docking port's state to 0. The docking port will then push 0 to the 1.0 s Delay Component, resetting it AGAIN, and eventually pushing through a 0 to an already closed hatch.
It's a very weird workaround that's taken me now a third day to disambiguate, but I finally know how it works. To save you the time, I finalised the schematic[www.draw.io] from before. It now describes a full cycle from stable undocked through a docking event, through stable docked, through an undocking event and back to start. That's basically how the developers' circuit works.
Hah! I'll have a look :) Do you know of an easy way to test stuff, by the way? So far I've been reloading a single player save and buying components, which is a really cumbersome way to test. Can I run a simulation straight from the editor?
Yes, and no. You can use the console command "game" in the editor that starts a game with the whole thing in it. But you still need console commands to spawn a character and take control of it, the method may be buggy and experts not advise saving after using it.
I just start a singleplayer campaign every time when testing something. By the way - you only need a floor, a hull object (iconless invisible one) and a spawn point besides the thing you are testing, so setting up a test-environment is quick.
Well, that is disappointing. Clearly there's something I don't understand with how that site works. I exported the thing to an 85KB PNG file and reuploaded it to a Dropbox location. This WILL work:
https://www.dropbox.com/s/s4hcb1w0j6y8f95/Orca%20Docking%20Airlock.png?dl=0
Hmm... So make a sub or use a copy of an existing one, make changes, then start a single-player game using it. Interesting. I thought for sure you'd need at least a docking port for the thing to spawn near a station, but seems like I was wrong. Either way, that's not a bad idea, and thank you kindly for the suggestion :)
Well, testing a sub needs a sub. But just to play with a box of components, or check if you can make a junction box catch fire with batteries, all you need is spawn to spawn, a hull to keep water out, and a floor to prevent you from falling out of it.
Also, I came up with a decent idea of how to wire the bottom hatch to both work when docked AND open with a button - it just needs to be a switch. Should be as simple as wiring the hatch signal_in to an OR block, which would take information from the docking port and a switch. If the sub is hatch opens. If I flip the switch, hatch opens. If neither is true, hatch closes. The lack of timers means the actual airlock will tend to flood slightly when decoupling, but I can't be arsed to fix that.
See, the thing is I have a semi-long-running campaign with a friend of mine, and that doesn't seem to want to let me swap submarines, so doing changes via the sub editor isn't viable for that particular game. We've managed to survive some insane nonsense so far, so I kind of don't want to reset our progress... Plus we already have the sub reordered and stocked the way we like it. Would feel bad if it reset with default items :)
Oh, and one final thought. I think I know why the Barotrauma devs wired the top airlock the way they did. The goal was to have a constant "clossed" signal pushed into the exterior airlock hatch when the sub is undocked. That way, even if something were to open the hatch with the sub undocked, it'll still automatically close again in 1 second.