Timer Behavior No Longer Functioning As Before. Triggered Actions Not Happening on Time.
Good day.
The following was all done in experimental mode, with no mods of any kind enabled.
I've been working on antenna and signal systems in pure vanilla SE for quite a while. For quite a long time the following configuration worked reliably since the signal update but no longer works at all.
The antenna toggling system utilizes three antennas, one configured at 50000m range (LRM(Long Range Mode)), one at 5000m (SRM(Short Range Mode)), and one at 1m (SLEEP). Three timers are used to toggle between the antenna states. First, a SLEEP Timer toggles the LRM and SRM antennas off. The LRM SEND Timer turns on the LRM antenna, and turns off the SRM and SLEEP antennas, while starting the SLEEP Timer. The SRM SEND turns on the SRM antenna while turning off the LRM and SLEEP antennas and starting the SLEEP Timer.
This antenna toggling system has been primarily used in conjunction with action relays. Because an antenna with a broadcast range of 1m can still receive an action relay signal, a signal received can trigger further actions. In this case, to respond, the action relay triggers a response timer.
The response timer has two actions. First, it triggers the LRM SEND Timer or the SRM SEND Timer, depending on the range needed for the response. Second, the "Send" or "Set and Send" function of an action relay is used to send a response signal.
Previously, I used this configuration in many builds, creating drone systems and command and control systems for the drones, all of which used these protocols to communicate reliably for many months of gameplay, over the course of many updates to the game.
Now, I can't get signals to send in this manner without doubling any input. Automated responses using this protocol are inoperable. Sending signals via buttons requires repeating the input rapidly or manually enabling the long-range antenna first.
An easily replicable demonstration can be achieved via this workshop link:
https://steamcommunity.com/sharedfiles/filedetails/?id=3580815725
It is configured with the systems described above in a fashion that was previously reliable. To replicate the issue, place two copies of the above-mentioned grid greater that 1m apart in any environment. Ensure suit broadcasting is enabled to see broadcast controller output. Press the button on one of the two remotes. Pressing the button twice in rapid succession will let the signal send but is not the desired or expected behavior.
I hope that this is helpful in isolating the change that has broken this behavior. I relied upon it heavily and would like to see it make a return to viability.
Thanks,
I have the same bug
Hello Engineer!
We apologize for the delay in response cause by the increased workload and want to thank you for your patience!
The issue was successfully reproduced on our side and put into our internal system. Thank you for providing the blueprint, it was very helpful during the investigation!
Kind Regards,
Keen Software House
QA Department
Hello Engineer!
We apologize for the delay in response cause by the increased workload and want to thank you for your patience!
The issue was successfully reproduced on our side and put into our internal system. Thank you for providing the blueprint, it was very helpful during the investigation!
Kind Regards,
Keen Software House
QA Department
Hey,
Thank you for looking into this. I have a pair of further examples that are directly related to this issue.
Here is an example of a rework that I have put together that successfully executes the signal chain by removing the LRM and SRM send timers from the chain. Instead, it toggles the antenna of choice on directly, sends the signal, and starts the SLEEP timer in one hotbar. While this is functional, I have dozens of builds that rely upon the LRM and SRM send protocols for every single programmed action, so it would be nice to not need to rework them all from the ground up.
https://steamcommunity.com/sharedfiles/filedetails/?id=3613125586
Initially, when .208 launched, I thought that the new "Set Broadcast Radius" function would make this whole triple-antenna mechanism unnecessary. Unfortunately, it seems that the "Set Broadcast Radius" function also executes more slowly than the "Send Signal" action. I have prepared an alternative version of the signal chain demo to show how it seems to be affected by the same delay that the original example was. The actions don't trigger fast enough, or in the right order to function.
https://steamcommunity.com/sharedfiles/filedetails/?id=3613126856
Considering that the "Toggle Block On/Off" antenna function triggers in time to send a signal when the actions are together on the same hotbar, I have hope that there might be a solution to make these kinds of signal chains more consistent.
Thanks for your time.
Hey,
Thank you for looking into this. I have a pair of further examples that are directly related to this issue.
Here is an example of a rework that I have put together that successfully executes the signal chain by removing the LRM and SRM send timers from the chain. Instead, it toggles the antenna of choice on directly, sends the signal, and starts the SLEEP timer in one hotbar. While this is functional, I have dozens of builds that rely upon the LRM and SRM send protocols for every single programmed action, so it would be nice to not need to rework them all from the ground up.
https://steamcommunity.com/sharedfiles/filedetails/?id=3613125586
Initially, when .208 launched, I thought that the new "Set Broadcast Radius" function would make this whole triple-antenna mechanism unnecessary. Unfortunately, it seems that the "Set Broadcast Radius" function also executes more slowly than the "Send Signal" action. I have prepared an alternative version of the signal chain demo to show how it seems to be affected by the same delay that the original example was. The actions don't trigger fast enough, or in the right order to function.
https://steamcommunity.com/sharedfiles/filedetails/?id=3613126856
Considering that the "Toggle Block On/Off" antenna function triggers in time to send a signal when the actions are together on the same hotbar, I have hope that there might be a solution to make these kinds of signal chains more consistent.
Thanks for your time.
Hello SteppedZeus582,
Thank you for taking the time to document this, and for sharing your setups!
We investigated this thread once again internally, and would like to provide to you some additional details: the behavior where an antenna with 1m broadcast range could still receive action relay signals is no longer valid - that interaction was intentionally fixed previously. As a result, designs that depend on that behavior will unfortunately no longer function in the same way. We understand how frustrating it might be, considering you have multiply setups set with previous logic in mind, and we would like to sincerely apologize for the inconvenience, but, as of right now, this is no longer expected behavior.
Additionally, after reviewing the original setup once more, we think that what seems to be happening is a timing and order-of-operations issue. The first timer triggers a second timer intended to enable the long-range antenna, but the original timer is already attempting to send the signal before that antenna has actually been activated. From the game’s perspective, everything is occurring in the expected order, even though the outcome isn’t what you’re aiming for. If you’d like this to work on the first button press, the logic will need to be adjusted so that the signal and broadcast message are sent one step later, after the antenna is confirmed to be active. Adding an additional short-delay layer (rather than sending everything in the same timer chain) should help achieve that.
If you still feel something isn’t behaving correctly after restructuring the logic, we would ask you to share a simplified blueprint focused only on the signaling behavior, ideally without timer blocks. The current grids are quite complex and perform many actions at once, which makes it difficult to isolate a potential issue.
- You can access your blueprints files by typing %appdata% into your Windows search bar and you will be redirected to the hidden Roaming folder. After that just follow: \Roaming\SpaceEngineers\Blueprints. Select the correct folder where your blueprint is saved (local or cloud), zip the file and attach it here.
Thank you again for the detailed report and for your patience.
Kind Regards,
Keen Software House
QA Department
Hello SteppedZeus582,
Thank you for taking the time to document this, and for sharing your setups!
We investigated this thread once again internally, and would like to provide to you some additional details: the behavior where an antenna with 1m broadcast range could still receive action relay signals is no longer valid - that interaction was intentionally fixed previously. As a result, designs that depend on that behavior will unfortunately no longer function in the same way. We understand how frustrating it might be, considering you have multiply setups set with previous logic in mind, and we would like to sincerely apologize for the inconvenience, but, as of right now, this is no longer expected behavior.
Additionally, after reviewing the original setup once more, we think that what seems to be happening is a timing and order-of-operations issue. The first timer triggers a second timer intended to enable the long-range antenna, but the original timer is already attempting to send the signal before that antenna has actually been activated. From the game’s perspective, everything is occurring in the expected order, even though the outcome isn’t what you’re aiming for. If you’d like this to work on the first button press, the logic will need to be adjusted so that the signal and broadcast message are sent one step later, after the antenna is confirmed to be active. Adding an additional short-delay layer (rather than sending everything in the same timer chain) should help achieve that.
If you still feel something isn’t behaving correctly after restructuring the logic, we would ask you to share a simplified blueprint focused only on the signaling behavior, ideally without timer blocks. The current grids are quite complex and perform many actions at once, which makes it difficult to isolate a potential issue.
- You can access your blueprints files by typing %appdata% into your Windows search bar and you will be redirected to the hidden Roaming folder. After that just follow: \Roaming\SpaceEngineers\Blueprints. Select the correct folder where your blueprint is saved (local or cloud), zip the file and attach it here.
Thank you again for the detailed report and for your patience.
Kind Regards,
Keen Software House
QA Department
Thanks for continuing to look into this.
"the behavior where an antenna with 1m broadcast range could still receive action relay signals is no longer valid** - that interaction was intentionally fixed previously. As a result, designs that depend on that behavior will unfortunately no longer function in the same way. We understand how frustrating it might be, considering you have multiply setups set with previous logic in mind, and we would like to sincerely apologize for the inconvenience, but, as of right now, this is no longer expected behavior."
I understand that there are reasons for the decisions made as developers working within your game engine. However, I strongly believe that losing this functionality ( the behavior where an antenna with 1m broadcast range could still receive action relay signals), will be a serious degradation in the quality of life of gameplay.
It was a revolutionary moment to discover and utilize this not as a bug to exploit, but a mechanic to embrace. Especially when working with drones or geographically diverse infrastructure, being able to engineer a functional solution to extreme quantities of signals cluttering the screen was a game changer. I understand that there are HUD toggle modes to disable signals. I don't want to disable ALL signals, just reduce my own signal spam. This way, I can still see new enemy signals and neutral signals as they appear without being overwhelmed by my fleet of drones following behind and activate antennas only when needed.
I accept the order of operations inefficiency of the original design and have already spent many long hours reworking core systems of drones and automated control systems to work with a more refined order of operations.
If this change goes into effect, it will invalidate the entire last year of eager development of systems that rely entirely on a solution like this to function, rendering all of my efforts pointless.
Additionally, I believe that It makes sense from a physics perspective to allow this functionality. A cell phone or home/car radio antenna picks up the broadcast from a stronger emitting radio with a passive antenna.
I believe that it makes sense from a gameplay perspective to retain this functionality, as it provides two distinct modes. One where a grid is "listening" in a power saving state (1m broadcast) and another where the antenna is "off" (Toggle Off...).
Unless a more intentionally designed mechanic is being implemented to solve these problems, I cannot say that I am pleased with the outcome. If it is removed in the next update, I will regret having brought the matter to your attention in such detail, leading to it's removal.
I hope to continue utilizing this an equivalent mechanic as a core mechanic moving forward.
Thanks,
Thanks for continuing to look into this.
"the behavior where an antenna with 1m broadcast range could still receive action relay signals is no longer valid** - that interaction was intentionally fixed previously. As a result, designs that depend on that behavior will unfortunately no longer function in the same way. We understand how frustrating it might be, considering you have multiply setups set with previous logic in mind, and we would like to sincerely apologize for the inconvenience, but, as of right now, this is no longer expected behavior."
I understand that there are reasons for the decisions made as developers working within your game engine. However, I strongly believe that losing this functionality ( the behavior where an antenna with 1m broadcast range could still receive action relay signals), will be a serious degradation in the quality of life of gameplay.
It was a revolutionary moment to discover and utilize this not as a bug to exploit, but a mechanic to embrace. Especially when working with drones or geographically diverse infrastructure, being able to engineer a functional solution to extreme quantities of signals cluttering the screen was a game changer. I understand that there are HUD toggle modes to disable signals. I don't want to disable ALL signals, just reduce my own signal spam. This way, I can still see new enemy signals and neutral signals as they appear without being overwhelmed by my fleet of drones following behind and activate antennas only when needed.
I accept the order of operations inefficiency of the original design and have already spent many long hours reworking core systems of drones and automated control systems to work with a more refined order of operations.
If this change goes into effect, it will invalidate the entire last year of eager development of systems that rely entirely on a solution like this to function, rendering all of my efforts pointless.
Additionally, I believe that It makes sense from a physics perspective to allow this functionality. A cell phone or home/car radio antenna picks up the broadcast from a stronger emitting radio with a passive antenna.
I believe that it makes sense from a gameplay perspective to retain this functionality, as it provides two distinct modes. One where a grid is "listening" in a power saving state (1m broadcast) and another where the antenna is "off" (Toggle Off...).
Unless a more intentionally designed mechanic is being implemented to solve these problems, I cannot say that I am pleased with the outcome. If it is removed in the next update, I will regret having brought the matter to your attention in such detail, leading to it's removal.
I hope to continue utilizing this an equivalent mechanic as a core mechanic moving forward.
Thanks,
Replies have been locked on this page!