Build: 1.4.2 3266 20-03:31 Mode: Any Reproducibility: Always Severity: Moderate Type: Signal, blueprint, repair to template Summary: Motion Sensor and Laser Tripwire signal state save with blueprint Description: Motion Sensor and Laser Tripwire signal state save with blueprint and template repair. If any Motion Sensor or Laser Tripwire signals are TRUE when the save is created the will be stuck in the TRUE state after being spawned in or repaired to until they are manually triggered again. Depending on the complexity of the signal logic used this can be REALLY annoying to try to fix and in some cases appears to break the signal logic to the point that you have to completely remove and redo the logic to get it working again. I would suggest only saving Lever signal state and not Motion Sensor or Tripwire signal state in blueprints/R2T. Maybe also add a check box to the blueprint save dialog box to save trigger area state similar to the way block damage can be saved. Steps to Reproduce: Create any structure and ensure it has power. Add a Motion Sensor or Tripwire. Set the trigger volume to the smallest possible size. Add a signal to the Sensor/Tripwire. Add a light to the structure. Assign the signal you created to the light. Enter the sensor trigger area. Ensure the the light turns on. Do NOT exit the trigger area. While in the trigger area save the structure to a blueprint. Move away form or destroy the structure so that it isn't in the way. Spawn in the blueprint. Note the light is still on. Enter then exit the trigger area and ensure that the light turns off. Screenshots, Crash Logs, any other Relevant Information or Download links: This is the test base that I created. I have also attached this blueprint in case you need to examine the actual file.
I have issues similar to this but I think the issue is broader or more complicated. I have a very simple motion sensor with an OR gate so I can enter a "power save" mode on my solar powered bases, which is basically all of my base designs. I have an MS that turns off power save when I am in the base and then saves power (turns off lights and devices) when I leave. I also have a soft switch under SIGNALS to manually force power save mode if my batteries are low and I want to save power even though I'm in the base. NOT gates aside, it's basically an OR of these two signals (MS and Force switch). I have had a lot of problems with this over the last year with lights and devices not turning on, not turning off, and basically just not responding to either the switch or motion sensor. It doesn't follow the initial or saved state problem mentioned here but it certainly could appear that way. For example, it looks like what is mentioned in this post until I change one of the device's "On/Off" follow signals. When I change it to something else and then back to the desired follow signal, all devices will respond for one state change, i.e. turn on, and then go back to no longer be responsive. Revision after revision this has remained an issue. It has been reported almost a year ago. Also initial states, like when first entering a playfield, have been a problem with signal logic for several years, which may be related but it's hard to know without knowing how the game is programmed. I've even uninstalled and reinstalled the game to make sure it wasn't file corruption, etc. I've been told to empty out old save games, which I did, but that is also not an adequate solution to actually fixing the underlying programming issue nor does it yield a long term solution because the problem always comes back.
Yeah, there seems to be some major problems with OR and NOT gates completely breaking the logic but I can't reproduce it reliably. If you can come up with a use case I'd love to hear about it so I can avoid it in my builds until the devs can fix the underling issue.
Yesterday I had to unbind the Signal, rename the Signal and bind it again in order to fix it. There was no boolean operators in the build with the problem, only the signal had a "/" in the name, that I removed prior to the re-bind, after this the signal begun to work fine. I do not know if this was by chance or if the name of the signal plays any role in these kind of issues. Any change did not work while the signal was keeping the original name with the '/' in the middle. My advice: Avoid using mathematical symbols in your signal names, just in case.
On further testing I still cant nail down and exact use case to trigger this. I believe it is actually the result of multiple bugs in the signal logic code but obviously there is no way to be sure with out seeing the source code. Here is what I know so far: This bug dose NOT happen to me in single player. I have only ever seen it on the small server I run. I have NOT tested on the official servers so have no way of knowing if it is some thing about my setup that is causing this. This does not appear to be related to ping but may be related to the somewhat inferior hardware on the server. Im useing an old HP Pavilion 23-q114 I had sitting around for the server. Logic with ONE or TWO layers of complexity always seems to work. In other words: If (a) and If (a && b) will always(?) work consistently. Logic with MORE THEN two layers of complexity fails in an inconstant manor. In other words: If ((a && b) && (c || d)) will sometimes (but not always) become stuck. The portion of the logic that becomes stuck always seems to link back to a motion sensor. I have NEVER seen this happen with a lever. I never use laser tripwires in my builds so I cant really comment on them. Removing the stuck signal and re-adding it under a different name SOMETIMES temporally resolves the issue but the exact same logic will break again after several uses. Removing the trigger device that the stuck signal is attached to and than re-adding it (using a different name) ALWAYS temporally resolves the issue but the exact same logic will break again after several uses. I always use strictly alphanumeric signal names. No symbols or special characters. There seems to be multiple ways to trigger this: Simply entering and exiting an effected trigger area over time. In this case the logic seems to become permanently stuck. While inside a trigger area, entering a cockpit, opening then closing the control panel, then exiting the cockpit. In this particle case most devices worked as expected but one that had more complex logic using nested ORs failed to update. Exiting and re-entering one of the trigger areas got it working again. Stuck signals sometime very rarely and mysteriously become unstuck when when the attached vessel warps to another playfield? I may be miss remembering this.
I have experienced frequent problems with signal logic on servers. It even happens quite often in a creative server. For example I set up our gravity generator to be controlled by both motion sensor and landing gear, so that it only turns on both when the ship is not landed and someone is walking around the ship. I also added an override signal to disable the automatic control if for some reason you need to. In single player it basically works flawless. In multiplayer it was so broken we just had to set the gravity generator back to a simple on/off signal.
