Proximity triggers confirmed. They talked about them in the teaser video yesterday. Go to 6:20 (tried to link to that time, but it wouldn't let me).
so... we have the new scripting which I must say is a bit overwhelming in terms of wrapping my head around all of the possibilities! As for auto-doors and other proximity triggered events, here is something I tried last night which had some success. Sorry no video or screens... maybe later. <note, a better scheme is shown below in a subsequent post> Goal: Sliding door (two pieces sliding opposite directions - picture Star Trek sliding door). Stay open when a player is in path of door closing or very near. Door should not move an additional #units if triggered multiple times. Door not get confused by repeated open close signals, causing to go "off track" in any way. (which will occur if multiple players are near area) Door should not need respawning in order to fix position. Door pieces: Check Alpha On > Move X units Multi-check: Check Alpha Off On Message Received, Barvo > (it is currently misspelled in PC version at least ) Reset position Boundary Enter: Use a block above or below door area you want to use as your proximity zone. If above doorway, use Boundary Top 0, bottom 20 or whatever, and give it some length and width. This is your "trigger zone". It can be scripted with enter and exist scripts. However, I suggest only using entry. Block w/ boundary zone: On Boundary Check Enter, Player, Check every .10 or .20 > Set Alpha ON As mentioned previously, do not use Exit boundary to close the door. That will violate goal color coded above. Spawn/respawn timer block: CHeck Alpha On > Despawn Respawn setting of 1 sec (you'll see why so short in a moment) On SPawn > Set Alpha Off Check to see if player present at door path (opting to use old method of a block which cannot respawn. There may be a better way now, but this works perfectly and as stated previously, exiting the prox boundary is problematic as a trigger for making sure player is out of the way. vehicle blocker, placed inside door path. Test to find perfect size for situation. Note, very large doors may need another method, as the "I won't spawn" tendency seems to be centered around the movement arrows for the piece. Vehicle blocker - Note, I use these because players can always pass through them. Check Alpha On > Despawn Respawn setting 2sec (slightly longer than block respawn) On Spawn > Send message Barvo The above creates a situation where after 1 sec the door WANTS to close, but will only close if the vehicle blocker has also spawned. Any thoughts or improvements?
<I've toyed with this a bit more, and have made some improvements> Here is a much more clean and simple version which is nearly perfect. If someone could help with the remaining issue I have, that would be appreciated! Zone piece - again, used a block placed as trim over doorway and sized it to extend to both sides of doorway. This could be a target or invisible blocker placed away from view, but whose boundary extends into the affected area. on Boundary Continuous, Set Alpha Power ON, check every .10 Targets - set up a target (new item found in scripting menu) with a label, and on power On, instruct the door to move to the position of the target. This prevents the door from ever moving additional #units if a player enters the zone a 2nd time while the door is already partially/fully opened. Target(s) - use two if double sliding door. target - label = User Alpha target - label = User Bravo Door scripts: On Power Alpha On, move/offset to target = User Alpha/Bravo On Power Alpha Off, reset position Script brain: on timer, delay 1 (or whatever works) repeat 1 (or whatever works), set Alpha Off This avoids having to use respawning blocks as timers, as almost as soon as the player is out of the boundary, it closes. It also negates the need for a respawning invisible block in the path of the door to test whether a player is present in the path of the door. It also makes the repeated movement of the door open/close cycle more consistent, and goes off track less. Because the "move x units" option would move the same number of units even if the door was already partially/fully open, the door would sometimes slam shut when returning, with strange results. Now, because the targets are always in the same place, they will always try to go there, and no further! The ONE thing that is still a little glitchy (Please help) is that while the door hangs open waiting for the player to move, it trys to shut and stops over and over, looking strange. I want it to be smart enough not to try and close until the player is gone. I believe there is a way with "number change" and "number check" actions/conditions that would somehow check to see if any players are in the zone. If players >0 open, else close Can someone instruct me how to do that?
Much cleaner the second time! Suggestion, why not set a second boundary enter script to trigger just past the door that turns alpha off? Instead of checking whether the player is in the first zone, check if the player has passed through the second zone. Then, if there are more players still in the zone, it'll just re-open itself again. Turn off condition interrupts on your scripts, and have the alphaff script check less frequently than the alphan.
I fear that the "on exit" condition will be buggy and inconsistent, causing confusion in the scripts... to test extremes, I walk back and forth on the boundary lines and watch the doors freak out... I could see it missing the fact that a player has left the outer "close door" zone and leave the door open forever... I will do some more testing, though. THANKS! (I will also try the counting logic that someone posted in another thread, to see when players in the zone are > 0) That would really be the cleanest, fewest scripts, and fewest pieces.
So don't use On Exit - I'm saying use a second zone entirely, and place it beyond the door. If you were going to use on exit, add another action at the end of the open/close using "Wait" and with a sufficient cooldown (say 5 seconds). If you turn off Condition Interrupt (first checkbox) it'll cut the jitter by a lot. The counting logic sounds like a good solution though. Would love to see how you lay it out!
Alright, i think i found the best way to create such a trigger: When: Boundary- Continuous Players 0.05 Do: Power Set: Alpha On Wait 0.1 Power Set Alpha Off Condition interrupt- On What this does is turns Alpha on every 0.05 seconds a player is within the boundary, and when all player leave, the boundary continues past the wait script (no longer being interrupted) and turns it off.
ahh, I had never thought of making one script both turn on and off the power channel. based on the timing, this does a pretty good job of making sure that the door operates correctly. One suggestion, as it is something I ran into doing the testing with the "counting" method, is that in order to get a very clean application of auto-door behavior, one must add an additional power channel check which makes sure the door has fully opened or fully closed before repeating. (I tried merely changing your "wait" value above to 0.5, but that did not fully fix the problem, and didn't provide for some of the other nice features.) To accomplish this, use multi-channel checks on the doors such as: Door Script #1 multi power check min 2 check alpha ON and check barvo OFF move door (to target is my recommendation) wait .4 set power barvo ON Door Script #2 multi power check min 2 check alpha OFF and check barvo ON reset door position wait .3 set power barvo OFF (the reason the barvo is check for OFF status to begin, is so we do not need another script setting barvo ON at match/round start) This prevents what occurs with just the proximity check to influence the behavior of the door, which is that a player can quickly enter/exit the boundary area and trick the door into getting stuck open forever, or stuck partially open and/or not re-open when closing and a player is already present within the boundary. This was the final piece that allowed the counting method to work perfectly, and it appears to also make your "continuous ON, Wait, Off" method perfect now too! Your method is just as clean and successful as the counting method, and saves 1 or 2 scripts! (not to mention saving a global variable which could in theory now be used for something else) Great job!
here is the counting method, in case anyone wants to try it for use with a door or another type of proximity situation... https://www.forgehub.com/threads/ch...teraction-or-other-event.154773/#post-1669156 One addition to this would be to add to the Object count list "Objects Exclude", which removes all objects but players from the list. Otherwise, normal phys objects and even dropped weapons could keep the door open! To prevent doors within the boundary area to trigger opening said doors, add "Label exclude{1}" to the list, and label both of your doors with this same user label. This, with the 2nd power channel check mentioned in the previous post, makes a perfect auto-door. The implementation of your door may dictate whether you choose the "counting method" or the "continuous ON, wait, OFF" method.
Not so much a correction as one of the things you would add to the basic circuit to make it include or exclude specific objects. All I showed was how to generate a count that didn't include the boundary object itself and how to attach that to a power channel. I could have been more specific in that more filters were needed to actually use it. Also, physics settings don't seem to interfere with an object being counted, so your phased floors, or walls, etc, could get counted if the boundary intersects them.
fixed edit: Oh, I see what you mean by the physics comment. all I was saying, is that normal physics objects, which can be pushed around by a player or vehicle, are the main concern.