Halo 5 Scripting Infodump

This is an important observation for scripters:

This is nice work, guys. I need to get off my butt and create a scripting test map to share and help people with this stuff. If only I wasn't so darn unreliable!

I did test the basics of how the Power Channels work, and discovered that when the values are changed (toggled or set explicitly to the other value) the action is basically Broadcast in the same way Messages are. No Broadcast occurs if the Power is set to its current value.

Based on your testing, I'd guess that the {PowerSet} and {MessageSend} Actions use a similar Broadcast mechanism that the (OnPower) and (OnMessage) Conditions are able to distinguish between, but the (Multi) Condition doesn't at some point.

---------- PURE GUESSWORK ----------
I'm also guessing that

• the Channel/Broadcast mechanism uses a queue or stack structure for keeping track of Actions that send Messages or trigger Power changes at the same time.
• Conditions are all processed first and then the Actions execute.
• There's likely a counter for each Multi Condition to test against its Minimum property.

The catch is that if any of the Actions subsequently send additional Broadcasts, then the Conditions have to be retested and, if the same queue/stack and set of counters are used and the original calculations aren't isolated from newer ones, the the Minimum counters might be incremented again and only two Conditions can test true three or more times.

I'd like to check out the code they used to handle this. I think for it to work how the intention seems then:

• Multi Conditions must properly distinguish Message from Power toggle
• Counters shouldn't be used to compare against Minimum... The code should recount how many Conditions evaluate to true each time.

Or maybe buddhacrane was onto something with it only triggering a Message-like Broadcast for one Power state transition (off to on?). That way Brain script 1 would test true three times on every other button press.
----- END GUESSWORK, STUPIDITY CONTINUES -----

It might be fun (aka "fun") to create some pseudo code orJavaScript (or something easily shared) to see if we can come up with a Channel Broadcast system that works like we think it should. I'm gonna assume that you're all in your right minds and don't want to do anything of the sort.

 

Mmmm, nope. It would go from combining 26 items in groups of 2 (only the messages) to combining 52 items in groups of 2 (messages + power channels). Which would be ... 1540 combinations. Link to formula

It doesn't actually matter though because the 325 combinations you can currently get with Messages alone is already more than the Scripting budget allows (you'll hit your 512 Scripting budget before you reach your 325 combinations), so it's a moot point.

 

Thanks for creating this thread! I'll be watching it.

 

You crazy scripting guys figure out the best way to imulate (spellcheck?) weapon drop spawns yet?

 

I've been working on making a digital sequence mechanism (or counter) that can increment at any time (not based on times), but I think there's a simpler way that I need to test.

Anyways, as part of the testing, I finally verified that you can toggle a power channel back on/off in response to it being set and both events will fire as long as the 2nd Condition is caused by the Action of the 1st Condition (and that the 2nd Condition wasn't also met by the events that set off the 1st).

The timing/order seems to work in batches of scripts whose conditions are met at the same time. All those scripts become a collection whose actions are all done in a group. For a single object, I think the Actions fire in order like cookies4you described. I haven't tested of there's any order of scripts for different objects.

Once all the Actions are done, it's possible for a new group of scripts to be immediately activated.

In this example, because script 3 isn't active when script 1 triggers, script 1 can turn Alpha off which script 3 won't turn until the next round of script Conditions are met. That will, however, happen immediately along with any other scripts that were triggered by the last collection of Actions.

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]

I think I had one Multi: Power: Toggle Condition achieve an infinite loop, but I need to double check what that was.

I think I also saw that the update hasn't fixed the bug where the Multi Condition message still triggers from changes to that channel's power. For now I'm simply avoiding using Messages in Multi and using Power: Toggle instead.

 

So I'm wanting to make an item giggle. I want it to move back and forth only about half an inch. (I'm trying to re create the flood movements, the bubbles or eggs that's are on the walls of flood areas). I am able to get it to move about the distance I want it to. My problem is that while I'm watching it, it slowly moves in one direction too far. So I have it giggling back and forth back it won't stay in its current place. If I leave it as is, but the time the match is over the item would be out of the map. Any ideas?

 

I think using the {Position/RotationReset} Action to keep returning it to it's spawn point should keep it anchored to a large extent. Resetting almost seems like a requirement for script movement and rotation when you want an object to stay put.

Oh wait, if your object is jiggling and traveling around the map simultaneously then that won't work. (I really wish Forge let us separately control the spawn location and the spawned object! That would make this Forge so much cleaner, I think). Possible solutions for this case:

• If you can use Phased physics, that might help it avoid collisions that alter its path.
• You can also try to change which object is the parent.
  • Try an object that's less likely to collide with surrounding stuff
  • An object with more mass so that collisions have less impact
  • Try adding an invisible object that floats above so that it doesn't collide with objects in its own group and then make that the parent.

 

More dumping!

Detecting Forge Mode Using Match Type Property
Not sure if this is useful, but what the heck. I had a barrel that would trigger the OnTimer, OnMatchStart and OnRoundStart Conditions at the start of both Forge and a custom slayer game, but it would only trigger OnSpawn in Forge. Scripts still seem to work for objects that are excluded for a game type... they just won't spawn if you tell them to. (So basically, Spawn & Despawn Conditions won't work).

Set an object's Match Type property to exclude some game modes (I tested with all 4 exclude types listed). Then you use its Spawn Condition to turn a Power Channel on that indicates that you're in Forge mode:

Script 1: (OnSpawn) {PowerSet:Foxtrot:On}
Note that you can't test Foxtrot at the very start of a match or Forge (OnTimer:Time=0, OnMatchStart, OnRoundStart, etc) since all those Conditions plus the (OnSpawn) Condition will fire at the same time and Foxtrot won't be set until the first batch of Actions occur. You can test (OnTimer:Time=0.1) or another event triggered by the first batch if you need to test as early as possible:
Script 2: (OnMatchStart) {PowerSet:Alpha:On}
Script 3: OnMulti:Minimum=2 (OnPower:Foxtrot:Off) (OnPower:Alpha:On) {some action!}

Weld a Switch
I don't know if early on I just tricked myself into thinking that we can't add switches to groups and still be able to use the (OnInteraction) Condition, but I added a switch that already had (OnInteraction) scripts to a welded group and it continued to function.

Using Object Despawn & Respawn Timers
These seem to have significantly more reliable timing when they're placed far away from where any Spartans will be. The game doesn't like to Despawn things right in front of a player. And it's a little afraid to spawn objects when a player is in the area. Sometimes in matchmaking it really likes to spawn me closer to the enemy team than my team. Jerk game.

 

Looks like we can script objects and then group them or even weld them and they'll maintain individual scripts. I tried it with one scripted cylinder and more unscripted objects all welded and phased and only the cylinder moved. So I guess we can have welded groups with parts that move in independent directions.

I thought that welded groups that had scripts added after only had one of each script, but it adds the script for each object, which seems like a waste.

 

I noticed when working on my moving platform that I had 40 something scripts & I was thinking "Theres no friggi way" but that makes sense now.

 

I need to check out your stuff! Is it ok if I look at your maps? Which one has the Sentinel? Is there a better place than this thread (and YouTube) to get up to speed with scripting or do we need to set up something like that? I was thinking that collective Forge scripting documentation would work better in a public Google doc or some Halo wiki entries than forum entries where they get lost down the feed. Where would you guys set up public documentation?

 

Quick question and I'm unsure whether or not it's as simple as it sounds but it doesn't seem to be working for me and I'm quite new to this, I want a pelican to fly past the screen on match start. I have my camera set up, with my pelican having one script (if that's correct) on match start: offset 250, however it doesn't seem to be working. It moves past my screen however I'm sure if I test it again and start the custom game up, the pelican starts from point b instead of point a which it should do every game ?

 

So it's supposed to move from point A to point B in front of the camera before players spawn? But out it starts at point B? The Pelican's original location might get changed to point B if you leave it there when you save your map, especially if it gets edited in some way after it moves. If you don't save the map after it moves, it should still be at point A.

You can add another script to it like (OnMessage: alpha) {Position Reset}) to move it back before you save.

You can also avoid moving the Pelican while you're in Forge. Add an object that doesn't spawn in matchmaking (by setting one of its Game Mode properties to an exclude value) and have it turn on a power channel (say bravo) to let your scripts know it's Forge mode (not matchmaking). Only let the Pelican Offset script work if it's not Forge mode, that is if that power channel isn't on. You have to delay that script by any account of time to let the Forge mode channel be toggled first.
(OnTimer: Initial Delay=0.1: Repeat=0) {Power Set: Charlie: On}
Multi: Minimum=2 (On Power: Bravo: On) (On Power: Charlie: On) {Offset Pelican}

 

You can do like Warholicdid with the drop pods & have the pelican stationary & have the cinematic camera just fly by the pelican really fast. You can put smoke in the back of the pelican & play around with wind speed & direction to make it look very believable. He did.

 

Ooh that sounds much better than what I said!

 

It would be cool to have it fly over the map in the cinema & even during game but as buggy as scripting is right now this is a much better looking solution.