Halo 5 Scripting Infodump

Wouldn't you just set it to move in two directions at once? X and Y, X and Z or Y and Z? Or even all three axes at the same time

 

None of this would be necessary if there was a proper player proximity switch...

That is exactly what i do now, including using the Zulu Channel.

I believe if you place the item with Movement Translation set to Object it will move along it's own axis. I placed an item on Deadlock which moves, and resets, at a 45 degree angle.

 

The above is true. These are placed at a 45 degree angle and set to only move on the Y axis.

 

What do you mean by the order which scripting actions trigger? Won't all scripts happen simultaneously unless you set delays? Can you give an example of how the order matters? Just curious. Thanks.

 

I gotta say this is some nice logic reduction by buddhacrane. Did anyone here study digital logic? I'm seeing posts by people here who could more than hack it in computer engineering. Now that I've looked at this for some HOURS (still a forge n00b for the most part), I'm gonna see if I can do a quick summary (messing around with some shorthard). Took a good while but I finally found an optimization.

buddhacrane quote paraphrased:
------------------------------------------------------------------
- 1 Object used, which has 4 Scripts, Properties {Despawn:OnTimer=On:Timer=8}
- 2 Message Channels Used: Alpha to send out the timed broadcast (which we'd have our gameplay objects listen for) and Bravo to send behind-the-scenes messages 8 seconds after the start of each round (or usually when the Object despawns)
- 1 Power Channel Used (Alpha) to track whether or not the first 8s Despawn has occurred (ignore the first one)

Script 2: 16 seconds into the match, a message is sent to Alpha.
Condition (OnTimer:InitialDelay=16:RepeatTimer=0)
Action [MessageSend:Alpha]

Script 1: 8 seconds into the start of every round, a message is sent to Bravo.
Condition (OnDestroyedDespawn)
Action [MessageSend:Bravo]

Script 3: After the "Match Start" Timer has activated, the Alpha channel will be turned On.
Condition (OnMessage:Alpha)
Action [PowerSet:Alpha:On]

Script 4: When the 8 second Despawn Timer activates, and only after the "Match Start" Timer has also activated, a message is sent to Alpha. This means that this Script only sends a message to Alpha 8 seconds into subsequent rounds.
Condition (OnMulti:Minimum=2) (OnPower:Alpha:On) (OnMessage:Bravo)
Action [MessageSend:Alpha]
------------------------------------------------------------------

I've noticed a couple of things about using the Channels. The Power for each channel is a state that can be checked after it is changed (mostly good for the Multi Conditions), but it's also a Broadcast (like Messages) when it's state changes (but not when something attempts to set it to the state it's already in).

By letting the first Despawn event Toggle the Alpha power, we can just use the Alpha Off as the Broadcast objects can listen for with the (OnPower:Alpha:Off) Condition. That means we use just the Alpha Power Channel and three scripts. A 4th script plus another Channel would be needed if using a Channel is desired.

Script 1: fires 8s after each round start, first round it toggles Alpha On, later rounds Off
Condition (OnDestroyedDespawn)
Action [PowerSet:Alpha:Toggle]

Script 2: only fires once 16s after match start
Condition (OnTimer:InitialDelay=16:RepeatTimer=0)
Action [PowerSet:Alpha:Off]

Script 3: Power Alpha back On when it's turned off so the next script 1 turns it Off
Condition (OnPower:Alpha:Off)
Action [PowerSet:Alpha:On]

(Script 4 isn't needed if objects use the Alpha Off trigger as the timer signal)
Script 4: also send timer message thru Alpha when Alpha powers Off
Condition (OnPower:Alpha:Off)
Action [MessageSend:Alpha]

Another thing I noticed is that, while the normal (OnPower:Channel) Condition can only listen for Channel On/Off Broadcasts, the Multi Conditions can listen for On/Off/Toggle! Crazy!

EDIT: Ugh, I think I somehow hosed the quote mechanism? Here's the bits of quote:
------------------------------------------------------------------
Note: It's actually possible to tweak this slightly to use one less Script, but it enters the realms of "voodoo script science" by leveraging a quirk in the behaviour of the "On Message/Power Multi" condition when sharing message and power channels, so I figured it best to just save you all the headache for the sake of one Script budget, lol!

Edit: I also have a more robust/complicated version of this Script (requires more Channels and Scripts), for handling the scenario where you want a delay that's later into a round and it's possible for the round to end before that delay occurs. Currently, both mine and Nokyard's approaches will go screwy in that scenario. I'll only post the fix for that though if anyone's bothered, because of how much more complicated it is (took me a few hours to figure out the logic for that one).
------------------------------------------------------------------

I'd like to see both of these, especially any voodoo behavior! I'll add my notes that I think can be useful in another post.

 

POSSIBLY USEFUL SCRIPTING NOTES

OnMulti Condition
The OnMulti:Minimum specification has some real potential when setting it lower than the number of Conditions. I can't recall something like that in digital logic.

Of course, it provides OR logic, like do something when either Channels Alpha, Bravo, OR Charlie Broadcast:
Condition (OnMulti:Minimum=1) (OnMessage:Alpha) (OnMessage:Bravo) (OnMessage:Charlie)

Since it has an OnPower:Toggle Condition, you can get rid of one OnPower:On/Off script (I don't know if we should ever use the normal OnPower:On/Off or OnMessage Conditions!):
Condition (OnMulti:Minimum=1) (OnPower:Alpha:Toggle)

If you want to perform an action when a Power Channel is turned On OR when some Message is Broadcast any time that Channel is powered On, add the Power On Condition twice:
Condition (OnMulti:Minimum=2) (OnPower:Alpha:On) (OnPower:Alpha:On) (OnMessage:Bravo)

If you want to test for a series of actions that must be completed in the proper order, use Power Channels and Multi Conditions:
Barrel 1 Script 1
Condition (OnDestoryedDespawned)
Action [PowerSet:Alpha:On]
Barrel 2 Script 1
Condition (OnDestoryedDespawned)
Action [MessageSend:Zulu]
Barrel 2 Script 2
Condition (OnMulti:Minimum=2) (OnPower:Alpha:On) (OnMessage:Bravo)
Action [PowerSet:Bravo:On]
Barrel 3 Script 1
Condition (OnDestoryedDespawned)
Action [MessageSend:Zulu]
Barrel 3 Script 2
Condition (OnMulti:Minimum=2) (OnPower:Bravo:On) (OnMessage:Charlie)
Action [PowerSet:Charlie:On]
... until Tannis Rides again

If you want to save some Power Channels, you could try to use them like digital counters... two channels with On/Off give you a count of four (00,01,10,11)... three channels counts eight (000,001,010,011,100,101,110,111)... etc. The Multi conditions seem perfect for that.

As noted before, the Multi Condition OnPower Conditions can listen for OnPower:Toggle, unlike the single OnPower Conditions. I don't see any reason to use the single OnMessage or OnPower Conditions, since Multi does it all and leaves you prepared for additional Conditions later on.

OnDamage Condition
As noted elsewhere, the exploding objects have the nice OnDamage Conditions that we can use to have interactions that don't require the limited Switches and using the X button. I noticed that the barrels, power cores, some shield walls, and vehicles have OnDamage Conditions. The shield walls don't seem to work.

The barrels and power cores work well, but I think some can't take enough damage, since I'd like to pull off being able to activate things in a more hidden manner. I did set up the basic barrels and cores to Despawn & Respawn (using scripts) whenever they take any damage, so if you don't hit them with something strong enough, they don't get destroyed. I had some set up so they could take damage from assault rifles without triggering OnDamage, but would with the magnum. Either way, they'd Despawn/Respawn and wouldn't blow up unless you hit them harder with a melee or something. The one power core strong enough to take a melee was funny about script respawning. (maybe since it has a base that doesn't explode so it isn't quite destroyed in the same sense as objects that completely explode? Same with wall shields? Those objects regenerate their parts or something?)

I think vehicles might work the best since they can take plenty of damage. You could hide something that only occurs if you hit a vehicle really hard, like from a high-up ground pound.

Game Mode Labels
I noticed that Game Mode Labels can keep objects from spawning at the beginning of some types of matches. I haven't tested if they can be spawned using scripts when they're excluded from a match, but maybe that can be useful? Is there any other way to keep objects from spawning at the start?

Changing Colors on Switches
I've used the Interaction Condition to change the third color of switch stations to sort of show that they're turning on or off. Kind of annoying, but at least it provides some feedback to players.

Forge Mode vs Matches
Based on the posts from earlier in this thread, it looks like we can distinguish between Forge mode and Match mode in some ways. Like using Object Despawn properties to set objects in motion only during matches. It would be fantastic to keep a list of properties, conditions and actions that only work in Match mode (or could any only work in Forge mode?). Since there aren't distinct "edit" and "test" modes in Forge, we need all the help we can get there. And it doesn't hurt to let people know about things that won't seem to work if they only test in Forge.

The OnTimer Conditions definitely start in Forge mode. What about OnMatch, OnRound, or other Conditions? It'd be great to get a really detailed list of all Properties, Conditions and Actions, including timing information and in what modes they work in.

Note: objects don't seem to Despawn (when property is set) after Respawning in the first round, but will in subsequent rounds.

 

Good info dump there!

The Shield Wall's "On Damage" condition is indeed broken - it's annoying, because I was hoping to use that as a way of making invincible shields.

I kept meaning to look into that Power: Toggle Multi Condition and always forgot. I kinda assumed it just wouldn't work lol. So it looks like it triggers whenever a channel is turned either On or Off. Interesting...

Did you test that optimised version of yours? I didn't go with that approach because I kinda assumed that turning a Power Channel On immediately after turning it Off would cause some quirky behaviour, due to the Order Execution of Scripts under the hood - I know it used to cause problems in MCC. What I'm getting at is that if you, say, had a wall set to move when the Power channel is Off, but you also have a Script set to turn the channel back On the moment it's turned Off, then if the Script that turns the channel back On executes before the Script that's meant to move the wall, then the wall will never move. Like I said, this used to happen with Timers back in MCC. So (admittedly without testing) I assumed we'd get the same issue in H5.


This is the more robust version of my Round Timer Script - the basic approach being to separate out the logic that works out whether it's Round 1 or Round 2+ to be independent from the Timers (Scripts 3 and 4) and then have the Timers use that Round info (Scripts 5 and 6):

Script 1: 8 seconds into the start of every round, a message is sent to Charlie.
Condition (OnDestroyedDespawn)
Action [MessageSend:Charlie]

Script 2: 16 seconds into the match, a message is sent to Bravo.
Condition (OnTimer:InitialDelay=16:RepeatTimer=0)
Action [MessageSend:Bravo]

Script 3: Turns On the Alpha channel at the beginning of a round.
Condition (OnRoundStart)
Action [PowerSet:Alpha:On]

Script 4: Have the Alpha channel Off at the start of the game. The "OnRoundStart" Condition will actually trigger before the "OnMatchStart" Condition, so that basically means that the Alpha channel will only stay On from the beginning of the 2nd round onwards.
Condition (OnMatchStart)
Action [PowerSet:Alpha:Off]

Script 5: When the 16 second Timer activates (Message:Bravo), and only during the 1st round (Alpha Off), a message is sent to Alpha.
Condition (OnMulti:Minimum=2) (OnPower:Alpha:Off) (OnMessage:Bravo)
Action [MessageSend:Alpha]

Script 6: When the 8 second Despawn Timer activates (Message:Charlie), and only after the beginning of the 2nd round (Alpha On), a message is sent to Alpha.
Condition (OnMulti:Minimum=2) (OnPower:Alpha:On) (OnMessage:Charlie)
Action [MessageSend:Alpha]

Summary Info:
- Objects used: 1 (The Invisible Blocker)
- Scripts Created: 6
- Message Channels Used: 3 (Alpha, Bravo, and Charlie)
- Power Channels Used: 1 (Alpha)


To actually prove that my robust version works of course, you'd want to use much higher delays for your timers. But this version basically means that it no longer matters if your rounds end before your Timers go off. Handy if you want to do some kind of "Sudden Death" type deal towards the end of a round, if the game goes on that long (more likely to be useful for Mini Games).

 

Ah, crud! Right, I'll go with the curly brackets. Kinda like handling javascript events? element.onclick = function(event) {Action}. I think it would also really help (me!) if we got lists of Object Properties, Script Conditions, and Script Actions that were very thorough and included things like:

• General summary - but better than the half sentence Forge gives us!
• Some kind of standard format and naming convention. I prefer spelling out names to convenient shorthand so that it's easy to understand when I'm trying to learn, but I'll follow what everyone else goes with. I like it when things say the same things as what you'd find on screen, but don't mind trimming some text as long as it's completely clear. OnDestroyed/Despawn is kind of a pain when OnDestroyed seems like it wouldn't be confusing. Saying "On" and "Off" around both "On Power" Conditions and "Power Set" Actions kind of burns my brain out, so I like when the words get dumped together... like German mammoth words. I wish Amazon listings used those, especially for something like a USB2TypeBFemale to USB2Micro converter! So many hours wasted... heheh
• List of objects it applies to, which ones it works for
• Work in Forge mode?
• Timing - Beginning of match, for each round, when multiple objects listen for Channel Broadcasts, works/begins after object spawn? (various scenarios), etc
• Reliability in different modes or situations, AVOID! warnings, etc
• Good, reliable uses for this item

Again, crud! I need to test much of what I wrote. I did some testing, but not enough. I should edit those prior posts and put question marks everywhere. I didn't test the "optimized"(? heheh) script I posted or the OnMulti:OnPower:Channel:Toggle condition. Wish my head would stay clear long enough to really hammer out these things, but I should be considered unreliable unless I remember to put something like "TESTED AND REALLY WORKING!" I'm used to messing up like that so no worries if anyone bites my head off for jumping the gun or generally being an idiot who hasn't actually worked things thru yet.

I've looked around a bit without success, but are there any threads that list the Do's and Don'ts (gotchas and pro tips) for Halo 5 Forging? Is there a way to keep a list of the more important tips at the top of posts in threads or in these forums? I get lost too easily these days and have a hell of a time digging thru threads to get up to speed on things. My brain also refuses to think of the words and phrases that other people would use when searching for specific info, so searching can be excruciatingly slow.

 

Looks like there are a lot of scripting pros in here so this will probably be the best place to ask this question that I feel will be easy for the pros to answer.

I'm in the middle of making a very large Battle Royal map. I'd like to force players to make their way towards the middle of the map over time. The simplest thing I can think of is having huge pieces enclosing the entire map and have them slowly move towards the center of the map over the time span of the match.

Is it possible to continuously move a piece with scripting at a very slow pace? Could someone point me in the right direction on how to get a script like this started? I see tutorials on how to press a button and move a piece but how would I make a piece slowly and continuously move in one direction for like 10 minutes?

 

Wouldn't it be easiest to use a timer function with the blocks moving 1 space after every second or so?

 

Ooo is that really all it would take? I'm very new to scripting and I guess I don't realize how easy some things are. I've seen a lot of people script pieces to move a few feet with a press of a button but haven't seen any pieces that continuously move in one direction for a long time.

 

In my new minigame, Rainbow Sniping, I wanted to have as many unique scripting events as possible to despawn individual objects. The most that I could come up with was 52, 2 for each channel. Event 1 = Alpha Message, Event 2 = Alpha Power On, Event 3 = Bravo Message, and so on. 52 blocks that need to despawn are waiting for these 52 unique and independent conditions. Can anyone think of how to have more? Must work in a multiple round setting. It kind of sucks that we have Alpha-Zulu as channels instead of 0-63...

 

Yes (based on your gametype design), with a caveat...

So basically, instead of just doing a single message channel Condition and Action, combine unique combinations of two message channels together, like so:

1. Barrel triggers Message Channels Alpha and Bravo. Platform uses Multi Condition listening for both Alpha and Bravo.
2. Barrel triggers Message Channels Alpha and Charlie. Platform uses Multi Condition listening for both Alpha and Charlie.
   
3. Barrel triggers Message Channels Alpha and Delta. Platform uses Multi Condition listening for both Alpha and Delta.
   
4. Barrel triggers Message Channels Bravo and Charlie. Platform uses Multi Condition listening for both Bravo and Charlie.
   
5. Barrel triggers Message Channels Bravo and Delta. Platform uses Multi Condition listening for both Bravo and Delta.
   
6. Barrel triggers Message Channels Charlie and Delta. Platform uses Multi Condition listening for both Charlie and Delta.

As you can see, using only Message channels Alpha, Bravo, Charlie, and Delta; instead of only getting 4 unique combinations out of that, I got 6. This grows as you use more and more of the channels. #Factorial Combinations yo! (stay in school, kids). So, using all 26 channels, that would be ... 325 combinations. Yep, I think you're good...

The caveat is that if two barrels explode at exactly the same time, their net combination of channels can trigger platforms they're not supposed to. For instance, if barrels 1 and 2 exploded at the exact same time, they would cause platforms 1 and 2 to disappear (naturally) but also platform 4 (whoops!). I got this behaviour when I used a grenade to blow up two barrels at the same time, but if I used an AR such that 2 consecutive bullets blew up two barrels, then it didn't give me this behaviour. This makes me think that they have to literally blow up at the exact same moment, so in practice you might be fine, but I figured I'd give you suitable warning!

Oh, and do NOT also do this same trick with the Power Channels. I can't be bothered going into the explanations of why right now, just don't lol (ok ok, I'll give you a teeny tiny explanation why - Power Channels and Message Channels are partially sorta kinda shared when used in Multi conditions. There, now leave me alone!). Simply use the Power Channels in the same way that you've already been doing.

 

What about using 3 Power Channels to set up 8 digital combinations (000,001,010,011,100,101,110,111) and then broadcast a Message on another Channel to say Despawn? Each object would listen for the Despawn broadcast Message and then check for its own combination on those 3 Power Channels. The Multi Condition would require all 4 Conditions, which means you can set the Power Channels first and then fire the Despawn Message when it's ready... just don't use 4 Power Conditions since they'll be checked each time any ONE Channel is changed.

So if we set Power Channels Alpha, Bravo & Charlie and then Broadcast a Message on Delta, we can have 8 objects listen for a Despawn Message on Delta:

Object Delta:000 uses
OnMulti:Minimum:4 (OnPower:Alpha:Off) (OnPower:Bravo:Off) (OnPower:Charlie:Off) (OnMessage: Delta)
Action{Despawn}
Object Delta:001 uses
OnMulti:Minimum:4 (OnPower:Alpha:Off) (OnPower:Bravo:Off) (OnPower:Charlie:On) (OnMessage: Delta)
Action{Despawn}
Object Delta:010 uses
OnMulti:Minimum:4 (OnPower:Alpha:Off) (OnPower:Bravo:On) (OnPower:Charlie:Off) (OnMessage: Delta)
Action{Despawn}

... each object's digital number has three digits in the form of Alpha-Bravo-Charlie (0-0-0, 0-0-1... etc)... or maybe ABC = 010 is the way to show it.

You can then set up any object to set the 3 Power Channels and THEN send the Despawn Message in the last script (I don't think a time delay is needed based on what cookies4you said earlier about the order of Actions).

A Barrel that Despawns object Delta:110 would use these scripts:
Condition(OnDamage:Below:1)
Action{PowerSet:Alpha:On} 1XX
Condition(OnDamage:Below:1)
Action{PowerSet:Bravo:On} X1X
Condition(OnDamage:Below:1)
Action{PowerSet:Charlie:Off} XX0
Condition(OnDamage:Below:1)
Action{MessageSend: Delta} <MessageSend goes last!>

It's possible to reuse Power Channels in different unique combinations.

The problem here is that this takes 4 scripts to set the Power Channels and then send the Message. I guess you'd run out of scripts before running out of combinations. If you know the objects will despawn in a specific order, then you can use less scripts by only changing one or two of the Power Channels at a time.
000>001>011>111>101>100>110>010
Hmmmm. I think if you can guarantee that four Power Channels will only be used for this despawning scheme and they will occur in an exact order, then you might be able to rig up 16 objects to the four Power Channels and only have one Action{PowerSet} per object. Just expand the 000>001>011>111>101>100>110>010 sequence to four bits (0000>0001>...) and make sure they fire off in the correct order. Guess that doesn't qualify as unique and independent conditions though. I'll have to test this one anyways.

It might be best to stick with buddhacrane's technique of using combinations of two Messages to save scripts since there are plenty of combinations there to "yo!" about. If they give us Multi-Action scripts later on, then this'll be good stuff.

 

Yeah, this is what I've been hinting at for a while. The multi condition's Message will also trigger whenever a Power Channel sharing the same channel is altered (I can't remember off of the top of my head whether it's whenever the power state is toggled, or only when it's turned on).

So, in your example, when switch 2 is activated, and the brain Toggles B, that toggling of B also counts towards brain 1's Message B multi condition, and because your switch 2 also sent a message on A, that means that the overall brain 1 conditions are met, giving you the behaviour that you saw.

This is why I said in my previous post to avoid the Power Channels when using a setup like this, lol.

So yeah, in a multi condition, its Message condition isn't only triggered by receiving a message on that channel, but also by changes to Power state on that same channel. Bug or intended feature? Who knows!