When you are moving the objects back, are you using a Position/Rotation: Reset, if you are make sure Velocity: Reset is switched to "On", otherwise when you start moving your object back before the first script has ended the velocity of the object will be maintained which will cause the object to go past or stop before its original position. If you aren't using Position/Rotation: Reset I would probably recommend it.
Suggestion: The ability to Toggle whether Scripts should run while in Forge. It can be quite frustrating when you have scripting behaviour that despawns/moves objects while you're in Forge; having some sort of Menu Option that allows us to disable the Scripting while we Forge would remedy this. Note that this option would need to persist in some way, so that when we load up a map in Forge we can ensure that none of its "On Match Start" or "On Round Start" Scripts fire - if it's an Option that we always have to Toggle On after loading the map, then we'll never be able to disable those Scripts.
Is anyone having any success with scripting rotating objects? I've had all these cool ideas floating around since I heard it would be possible to rotate objects in forge with scripting, but almost all have been failures due to forge's inability to maintain rotation axes, particularly with welded objects. Even single objects behave inconsistently with even the simplest scripting. With one activation the object will rotate as intended. With the next activation, it will do something different. Currently, with the inconsistency, scripting object rotation in Halo 5 is nearly useless to me. I'm hoping possibly there's something I just don't understand, but I haven't seen many examples of rotation scripting so far beside the rotating crane.
I tried to remake Zanzibar's wheel and the pieces started drifting away. The rotate action is so broken that it somehow turned rotational motion into translational motion.
Suggestion: Ability to incorporate Randomness into our Scripts. Here's me just spit-balling a way this could be implemented such that it doesn't go way beyond the Scripting systems that have already been put in place: New "Random: Send" Action, with the following properties: - Channel: This would be the channel to send this Random message on - same concept as the Power or Message channel (but they shouldn't interfere with each other, i.e The "Alpha" Power Channel shouldn't in any way impact the "Alpha" Random channel, and vice versa). - Maximum Range: A number, which represents the range of values that could be sent, e.g A Maximum Range of 5 would mean that when the "Random: Send" Action triggers, it will randomly set the associated channel to a Range Value between 1 and 5. New "On Random: Received" Condition, with the following properties: - Channel: The channel to listen to for a random message. - Range Value: The number to specifically listen for from the range of values that could be received, e.g A Range Value of 3 would mean that this Condition would trigger if its associated channel was set to a Range Value of 3 by a "Random: Send" Action on the same channel. Usage Example: Switch Condition: On Interaction Action: Random: Send - Channel: Alpha - Maximum Range: 3 Block 2x2x2 Script 1: Condition: On Random: Received - Channel: Alpha - Range Value: 1 Action: Color: Set - Primary: Red Script 2: Condition: On Random: Received - Channel: Alpha - Range Value: 2 Action: Color: Set - Primary: Green Script 3: Condition: On Random: Received - Channel: Alpha - Range Value: 3 Action: Color: Set - Primary: Blue Behaviour: Each time the switch is activated, it will cause the block to randomly change colour between Red, Green, and Blue (not the most inspiring of examples I know, but you get the idea lol). Extra "Nice to Have" functionality with this Randomness Script: - Incorporate the condition into the "On Message/Power Multi" Condition too. Note that this would also provide us with a convenient way to add "Weighting" to the randomness. - A "Minimum Range" Property on the Action, so that we could have more fine-grain control over the randomness.
Suggestion: A dual purpose Multi/Random action that lets you give a single script multiple actions and/or have random functionality. Condition: Any condition Action: Multi/Random - {Count: #} - {Action 1} - {Action 2} - {Action 3} - {Action 4} The count # indicates the minimum number of actions that will occur. If it's set to 4, then all 4 actions will occur. If it's set to 1, then only 1 of 4 actions will occur. For instance: Condition: (Any condition) Action: Multi/Random - {Count: 1} - {Send a message to channel B} - {Do nothing} - {Do nothing} - {Do nothing} Since count is set to 1, 1 of the 4 actions will be chosen at random. Thus, there's a 25% chance of a message being sent to B and a 75% chance of nothing happening. The other practical use is optimization. For example: Condition: (Channel A receives a message) Action: Multi/Random - {Count: 4} - {Send a message to channel B} - {Send a message to channel C} - {Do nothing} - {Do nothing} When channel A receives a message, the action occurs. Since count is set to 4, all 4 actions are guaranteed to occur, even if two of them do nothing. The result is that a message is sent to both channel A and channel B. Ordinarily, it would take 2 scripts to do the same thing, 4 if all 4 action slots were used. With this action, it could be achieved with 1. (And for the sake of convenience, count should be 4 by default.)
Been finding that when I have lots of different groups (in this case welded) they all group together after exiting forge and reloading the map. I am breaking the 64 object rule with some groups. This also effects the map when loaded into a custom game. Any way to avoid this? Also when setting the welded group to normal physics, parts can rotate or move a little bit leaving everything looking poorly forged.
Can anybody tell me if there is a way to script an object to move as you get a certain distance from it? I am trying to make a map with automatic opening doors as you approach them (think grocery store sliding doors). As far as I can tell, there is no proximity switch.
There's not currently any proximity sensor or switch in forge to do that. If you could get something to despawn as you approach it, like an explosive or making picking up weapon ammo, maybe that could work. I don't know if picking up a weapon counts as a despawn and can be scripted upon.
I know I've mentioned it before, but I feel the need to give it more emphasis. We could really do with having more than 26 channels to work with. It's become my main bottleneck when trying to create more complicated scripts, or create any kind of script-heavy map (like a puzzle map). Ironically, there are things I could create in MCC that I can't create in Halo 5 because MCC gave me considerably more channels to work with.
You can always set an invis switch to move down so it isnt interactable anymore after it is used. Obviously doesnt work for the visible switches, but its something.
Also check the Forgehub tutorial on pressure plates: I thought someone said the invisible switches don't move or Despawn when scripted, but I hope I just read that wrong. We can despawn the visible switches, right? I was thinking we might be able to store and manipulate information by spawning, despawning, and moving inaccessible objects to track stuff. There might be some way to use the spawn or despawn conditions along with the fact that some objects can't respawn when something is in the way or that the (On Despawn) condition won't fire if the object is already gone. The only thing I can think of to relay the info is buddhacrane's method of signalling with multiple messages. Haven't tested any of this yet and I'd rather us just get more channels.
Could there possibly be a way to play sound effects when pressing a switch? Say you script a door or window to open and you want want to place an alarm letting folks know that it's opening.
I too would like to request some useful sounds for scripting. Not sure if sounds are the Forge team's area, but any sounds that aren't background noises would be great: music notes, alarms, screams, existing game dialog especially the dumb stuff marines say, and some smooth jazz that follows @Psychoduck around. I haven't tried using scripts to despawn and Spawn the sound fx since the sounds I checked out weren't usable, so I don't know if they're able to be despawned... Objects like invisible switches won't despawn. That method might work if there's a usable sound. We can definitely script explosives to explode {Damage: Ratio=1.0} or have metal objects move into each other to produce enough noise to know that something's going on.
Randomizer: ***Timer*** or object/color/motion ect... at **random** time, spawn **random** weapon at **random** time, spawn **random** vehicle at **random** time, despawn object (release a massive bolder at random) at **random** time, **randomize** color (discoball?) at **random** time, move object . . . . . Imagine how dangerous some of those obstacle courses could get. at **random** time, start script
I'd personally like to see scripting more involved with objective pieces. At the moment there isn't anything special with scripting the objectives. I'd like to see something like (when referring to strongholds): Stronghold A Condition: On Capture Action: Send Message Weapon Pad Condition: On Messaged Recieved Action: Spawn With that combination alone, you could theoretically create the Gametype Dominion. Or alternatively when referring to CTF: Blue Flag Condition: On Flag Taken Action: Send Message All Doors / Exits From Building Condition: On Message Recieved Action: Move Vertical: -10.00 Light Beacon Condition: On Message Recieved Action: Rotate With this second example it's much like a robbery in real life. When you take something the alarms go off and the doors close. You could also add another script with a switch to re open the doors to allow the person with the flag to escape. In addition to that you could script a spawn zone to appear inside the building so the defenders don't spawn inside and create a 1v4+ scenario. There's quite a lot of potential for this kind of scripting with the Assault / Ball gametype as well. At the moment though, when you try and script a CTF object, it won't spawn at all when you go into custom games. Mind you, I haven't tried all of the options.
SOME ON HEALTH: BELOW CONDITIONS ARE BUGGED Destructible shields take damage from both players and Damage Ratio scripts, but only the Damage scripts seem to count towards the On Health: Below condition. I can knock down a shield with four punches or two punches plus a Damage Ratio: 0.50 script. That does trigger the On Destroyed condition now. It seems as though different variables are used for object health and the On Health Below scripts. Or (more probable?) some events, like player-caused damage, aren't hooked into the On Health condition event chain. Grenades are similar, I think. They get despawned when I script the damage to 1.00 or when multiple scripts bring the health to or below zero, but they don't explode. They do trigger On Despawn conditions. Also when the player picks them up. Grenades are also fun because precision weapons and some others, like the Hydra, blow them up with one shot, but spray weapons make them impervious to precision weapon fire. I guess you can call what the splinter grenade does "exploding". VELOCITY NUMBERS ALL SET TO -500 Sometimes this happens, which takes a long time to get them back to zero. I think sometimes I can set the action to [none], back out, go back to the script and scroll the action left and it gives me zeros again. BALL SCORING It would be nice if we had scoring events, or as a workaround if the ball scoring boom did some damage again. Chesus came up with the idea of using that, but we couldn't find any effect that could be sensed by scripts. Bummer.
Fix object movement, make it smoother, i hate that jittering back and forth ****, it should move there smoothly.