Hi there Another dumb question from me sorry. I don't know if it is possible mostly without timer but that is I want to do: I have a structure. When someone activate sensor, it turn on after 1' s LCD screen, and after 5' s activate portal. I want them back (LCD and portal) to off state after 60' s delay without doing anithing. Sensor-> then 1s later LCD on, 5s later portal on -> 60s delay -> LCD AND portal turn off. I had read a similar post but it won't help me. https://empyriononline.com/threads/...turn-on-immediately-but-delay-turn-off.52175/ Here a screen for what I have tried. Actually, it's build like that: sensor is a motion sensor (tried with trigger plate but it will be better with motion sensor I guess) and TxSignal is: "detectRA" 2 delays set in circuit Signal detectRA in imput, then 1 sec delay give signal LCDON Signal detectRA in imput, then 5 sec delay give signal PORTALON Condition these two devices are considered ON with circuit AND so: LCDON & PORTALON ====> result signal ACTIVEDEVICE Then after 60 seconds it must turn off so: ACTIVEDEVICE delay 60 sec give signal CONDITIONOFF At this moment I lost my mind... I had try to set a reset and test some things: (I tried invert detectRA has "R" and detectRA (is S) CONDITIONOFF (is R) ====> Q is signal .OFF I tried to make my sensor to folow mode (also tried toggle mode) signal .OFF At best, one passage in the sensor field turn on, and another turn my devices off. If I do some changes I obtained obligation to stay into the sensor field to keep my devices on, but it's not really good. Thanks for reading.
Just to be clear do you want the portal and LCD to turn off ONLY after 60 seconds or after 60s OR when the trigger zone is empty? --- Edit --- I think this is what you want. Blueprint attached. If you want to remove the "cool down time" it will require extra logic though.
In fact, I need my LCD and my portal turn on, BUT not immediatly and they must turn off after 60 seconds. Thats the problem, I can with the signal created by the sensor separate it into 2 others with delay, add an other delay of 60 sec, but after that I need to cancel it and turn off LCD and portal. To repect the first condition, activate LCD then portal, no problem, LCD and portal toggle (if I select follow it turn off when I am not in the sensor range) signal Tx input coming from sensor The more I try to solve that problem, the more I think my system can't work. For that, a device must me modified by dev to follow 2 signals and not just one.
I was able to get this same setup to work. I forget my exact setup however. You can use a hidden door to hold a signal active, if that helps you figure out how to do it.
This is possible using the current signal logic. If you haven't already then download the blueprint I attached to my last post and take a look at how I set the logic up. Its not perfect but it gets the job done. There are just a few things to be aware of You can play with the timing on the delays to get the effect you want. You can ignore the lRSLatch signal. Its just a leftover form a previous test that I forgot to remove. The second LCD I have that displays the cooldown message is optional but its kind of a nice touch to toggle the text displayed so I left it in. The circuit doesn't actually reset until all players leave the trigger zone to prevent looping. It takes 2*(delay of lDeactivater) for the circuit to fully reset due to the way the game handles delay logic. I haven't really looked into if there is a way around this problem.
I did not understand everything, I had test it, if you leave sensor field, it did not work, so you have to stay into the sensorfield. So your system shuntown when your are also into the sensorfield. For once, in this case, should we not just let the portal and LCD in folow mode ? I attached my epb file. As you cans see, one crossing activate device, one other turn it off. 2 solutions: set as follow mode existing circuits. add a second sensor to cross which give signal toggle the first circuit after final delay. I will test it.
Well, no matter how hard I look, no solution is satisfactory. In the current state, you just have to leave the signal delayed and put the devices in follow on it and therefore you have to extend the detection field in order to stay in and keep the devices active. I hope devs read this post, and think about these suggestions: - create a timer (but not necessarily the most useful as it is) - modify the signals so that one signal can be modified by another at the output (photo attached) - the same device can be in follow on 2 signals: -> Device ON with signal A, Device OFF with signal B (is the best solution i think) mabe making reset more easier to use like this: (is Q usefull ?) [signal A] == > RESET ===> [the signal you want to be reseted ] making a new possybility to add a AND or a OR with reset. [signal A] == > RESET ===> [the signal you want to be reseted ] [signal B] == > RESET
I posted an example late yesterday but I deleted it when someone else posted his solution. No need to drown you in info, and Inappropriate rose a question I did not think of, and some things are not clear about what you want to achieve. Because you basically want the motion sensor to detect the player and right after that ignore the player, this requires a circular logic, which the feature manages pretty badly. You might get a sophisticated system to work once correctly, but it will eventually break and act nonsensical after a few tries. I tried several setups yesterday, a few others this morning, and none work consistently. At some point all delays are mixed up, likely because the logic regarding these is completely independant from the rest of the circuits logic. I can have delays completely inverted after a while, even if the whole system "shuts down" at one point. This should reset all delays, but on the next triggering (player still in sensor zone) the devices (2 colored lights) turn on and off erratically, in wrong order, etc. See how simple things like ramps and hangar doors get bug reports regularly for staying open on reloads or being in the wrong state on game reloads, and this should give you an idea how "scripted delays" and scripted logic is broken compared to more "basic" game functions like player motion and bullet physics. Apart from simple circuits that run once and wait, "alive" circular logic is very flaky, because the developers did not intend signals to run in circles, and these processes don't have top priorities in the whole game loop. One of my last tries this morning, including a door (to "keep signals alive" like @ravien_ff suggested) that relays the "turn on" command for the motion sensor through a delay in a 2x OR switch ( motion sensor "off " state is triggered with 1st light "on" delay). No "resets" in there, just basic delays and 2x OR switches that accept both the on and off "delays" for each device, apart from the door which just serves as relay to send the "motion sensor ON" signal. All devices are on "toggle" mode. This works almost reliably, less so when the player stays in the motion sensor range : sometimes the lights obey the delays, sometimes nothing happens though the motion sensor is turned back on.
Thanks @ravien_ff and Kassonnade. Well I have to admit that actually the best is to expand my sensor field and set my device on follow. Am I the only one to think signals and circuits could (and should )be improved ?
Guess the right answer ; you have a 50% chance of getting the right one... I believe many problems are PC related, as faster PCs may experience less "flakyness" in circuit logic (and general scenario/ dialogs triggering) than slower PCs. Obviously delays are not "snappy" and lights/ devices take variable time to react to signals, so when adding delays this adds to the feeling that something is not right in there. Having logic work once or twice in some way, then suddenly stop working or go nuts on following attempts, that's not reliable enough to have scenarios or events resting on these components.
Keep in mind on thing as well. The more complicated your signal logic is, the more likely it won't work in multiplayer mode. Complicated signal logic usually works without many issues in SP mode, but in MP mode even basic signal logic fails most times. Hopefully they work on this soon because it wasn't always like this. Currently though signal logic has major issues in MP. I don't know if you plan on using this in SP or MP, but just throwing the info out there just in case.
^ is there a way to reset the signal logic when it breaks. I have a base in creative that I was doing some testing on and it broke without cause, just stopped working all of the sudden. Power cycling does not seem to work and resetting everything back to the original place also does not work. Do I need to scrap the entire thing to make it work again?
It's quite hard to guess what the problem can be without seeing the whole circuit. Usually exiting/ reloading the game can solve the problem, but if it's a logic kind of "bottleneck" it may not solve the issue.
Set up a few group tags that manage to fix the issue both in MP and SP. Pretty sure it was not a 'bottleneck' problem as much as a latency one - I am using them in conjunction with a gravity cannon and your character moves quite quickly. Unfortunately, such required a dozen set/reset signals so the signal logic is overly complex.
One issue is that a device can only get triggered by 1 signal with 1 effect. This makes signal logic messy, since have to add extra expressions to build up a stack of triggers and then send the required one as the final, until something creates an update to the stack. Also might have to use several sensors or "tricks" to get a working "circuit", that can create design issues (in small/compact builds). For some a course in Boolean expressions and workings might help achieve the above. Is very important to understand if to code effectively. Sometimes can "reset" a broken circuit by remove and replace a device or several. Sometimes (also) rename trigger-labels, along remove - add signal steps, where place it in right position in the flow.
