I was able to find some bugs with just one person. I bet it's the same cause. I strongly recommend doing something more like this, which is a combo of me and @Agent Zero85 working on the problem of a good auto-door, which can be used for any type of pressure plate / zone type of trigger. I've made variations of it for a few maps out there... (also see @Agent Zero85 's post directly above this one, for how the main aspect of it works) https://www.forgehub.com/threads/halo-5-forge-proximity-triggers.149633/page-2#post-1670265 You are using (I think) 2 message sends to decide when each door should open & close respectively. That introduces the possibility (read, "eventuality") that someone can trigger the door to open when it is already open, and vise versa. In short, your pieces (even one single door being tested) can get stuck open or stuck closed and the player is not aware of the precise manner in which they need to walk around the room to trigger it to do something else again (to reset the sequence). The above method uses two good tricks to make a really good auto-door. One big difference is that it uses a channel on/off instead of a message send. This is because a channel can't be set to On when it is already On, while a message can be sent whenever the conditions are met again. This helps you have a beginning and ending to your door open/close sequences. The next bit is to make it constantly try to close itself but be interrupted by the open command more frequently than it can finish trying to close. Thus, when the player leaves the zone, it instantly (or add delay) closes. It also keeps it open if the player stays indefinitely. It then also will more easily re-open. Also, sending each piece to a destination, an object with a label, rather than "move x units" makes damn sure it goes nowhere else, cuz multi-triggers can move it waaaaayyyy off position and slam shut suddenly. (this will require creativity with your doors) The final bit is something I added, which is to have a secondary channel check for each door (2 channels used per door, but it is worth it). At the end of each open or close command (actions 1,2 etc.) you have a switch of channel on/off so that the game knows the door is FINISHED opening or closing. That prevents a lot of buggy behavior. These things can all be tweaked to find the perfect behavior that is intuitive, convenient for the player, consistent and bug-free. It will need some adaptation to your special door style (which is really cool btw) so that the things vanish/move when you want them to. BUt basically just testing it on your own in spartan mode should find all the bugs. To your original line of inquiry... as long as you are using different pairs of channels per door, then you should never have one triggered by the other. I think what you saw was really this flaw of having things trigger at inopportune times, that is the culprit.
Yoo, thanks a lot, man! I was using channels in H2A all the time, don't know why I never bothered in Halo 5, they're obviously useful. Thanks for reminding me of them, haha. I'll try to implement the script with the destination, if the other stuff already doesn't fix everything. Never made offsets with objects as destinations to be honest.
The advice i am giving to builders now is that moving pieces should not contain scripts. Label/SpawnOrder them, then off load the scripts to brains using TARGET and OBJECT.
Part 2 becausw there’s a 22 image limit (only got pics of this spaceship map after lighting ruined the original atmosphere) and something I was not planning on showing because it never passed blockout phase....but **** it Concept Art (also not finished) There's like 10 other maps I never took screenshots of that I wanted to add and I've seen about this many from @SaltyKoala. Most of those had playable layouts that hit some sort of budget. The urge has been strong to finish something, but I'm not buying Xbox Live lol. Hopefully that inspires someone who wants to keep grinding. As for me, see you all in Unreal.
Is there a tutorial for said technique? Am I still using the Move:Offset action, just with what you said? Or is it something else? Does the offset work, even if you don't change the actual x-y-z values? I've got so many questions. I'm not new to scripting, if I know the basic concept of this, I can figure it out myself. Just a little bit more info would be great. @ExTerrestr1al @NOKYARD
YO perfectionist! Quit your whining and just submit these so we can run around on them. They all look freakin good.
Here are the basics... (read "wall of text") People tend to assume you need to put a "move" script on each piece that is moving, you don't. Label them and have a brain do the Move action, using the "Object" of that label instead of "This" as the thing to move. All grouped objects with the label will move together, saving at least 1 script per piece. (another cool advantage, is if you need to change speed, timing of door, you can do without ungrouping your door and changing things. More of it can be edited remotely, just like it is instructed to Run remotely) Also, rather than moving "x units", set a target object for each to move to, as mentioned earlier... these put the Origin of the moving piece to origin of the target piece. However, an offset alters the destination if needed. If you need the target to be in a certain spot, but need to align your door pieces slightly differently for instance. The tricky part for your doors... is that it is multiple pieces moving in different directions, and thus different destinations. You may be able ot use one target at the center of the doorway, and then instruct each to move to an "offset" of that position that is the same as you are currently using. Make sense? As far as cycling of channels goes, you'll want to make sure doors don't close again until they are fully open, and the items you have despawning, just do the same exept it's not a movement action but a spawn/despawn scheme. Getting it all tuned well will take time but it will be amazing when you are done EDIT: I forgot to mention a cool option that may save you some headaches. You can default the doors to open on start, then instruct them to close a the start of the match. This just reverses the polarity of the door and makes the "reset position" script the one that opens the door, and the "Move to target" script is the one closing it. This might be a great way to use one target as the destination ofr closing all the door pieces, rather than trying to open them sending them to different places. Either this or the offset idea bove will work. (When testing the channel behavior, quickly walk in/out of the detection zone and see if you can get it to glitch in any way. The only negative side-effect of this scheme is that you might have the door shut on you but immediately open. If you don't like that, I have another numbers based method I can share with you.)
I have a really stupid question. I hear about and see these awesome looking maps some of you guys started in unreal engine. Once you make maps, do you play the new unreal tournament on them? I want to try making something in a new engine, but gameplay in fc5 is so bad ive already given up on it. I like how you move in UT so I could see myself dedicating some time to that if thats what you guys are making the maps for. If so, is getting testing lobbies together pretty easy?
I don't even think goat has a computer that can run unreal lol When I use it, I make blockouts. The terrain tool is really fun and you can spend all day making whatever geometry you can imagine, but if you want to decorate, there are a million free assets you can download for free. Forge and map making has literally never been my artistic outlet because I draw and play music so most of my creativity goes there, but I'm trying to change that, and It's coming quickly. the lighting is also extremely easy. It's basically the point/spotlight system of forge just with a lot more control
It's very simple to set maps up for UT when building in unreal. You can also drop in drop out like in forge which helps get the feel of it quicker. I don't have experience adding bots, but I'm fairly positive that there's an easy way to make your maps have bot support, so testing shouldn't be an issue if you don't want to get into serious meta skill. Aside from that, I'd imagine that the game has a much larger player count, especially for custom maps, than halo does. I'd say go for it! If you just want to build blockouts (and not fully fleshed out ready to play maps) with 3d software I'd recommend using unity though. Much quicker to get out prototypes, better UI and all around better when trying to build AAA quality products in the long wrong but you can't just drop in and test sadly without making it yourself or joining a team with a solid project.
Sure, just give me one second. Haha No, but really, I can't wait to show off more stuff. We are fairly transparent in our updates, I sadly can't show anything more than that stuff though. Here's a concept art from a few weeks ago. It's a map that people may recognize. I'm happy that we are bringing it to the game refreshed and with a whole new personality that forge could never truly provide for us.