(WIP) FLARE - Deployable Equipment - weigh in on development!

you can move them (blockers) around the map, but they block bullets as they move. So, the trick is having it spawn somewhere outside of playable space and move them to the deployed location in an inconspicuous way. Meaning, as it moves to your desired location, it cannot interfere with gameplay , not just most of the time, but ever. Getting tihs idea to that kind of integrity is what will be hard, not proto-typing it, per se.

I may create a new thread for this so we can compile thoughts there...

 

ATTENTION: Please respond, anyone interested in this item!

I am considering a change based on the only real piece of feedback other than "owww! my eyes hurt!" which was that players may be discouraged from picking up and using the item if it blinds themselves. That is valid, and is why I originally posted a poll asking for input on that! It was 7-0 in support of blinding the player who deploys it as well. That is why it was scripted the way.

Alas, the Flare took a lot of R&D and is not as far as I can tell, being used in any way by anyone. So, I would prefer to get this to a point where people want to use it on either custom variants of dev maps, and hopefully, some of your own original Forge maps.

My proposed change is as follows: Change behavior of secondary blinding effect, which is a chasing smaller orb that attempts to disrupt the aiming abilities of anyone tagged by it, so that it no longer tags and chasees the deploying player. That player would still see the bigger, generalized blinding effect within that room, but would not remain blinded when looking away from the flare. This would give him/her some advantage over those who have been blinded and continue to be harassed by it.

I am considering allowing that deploying player to still be tagged/blinded by secondary effect if they eventually wander back into the tagging radius, (cuz it would be their fault at that point)

Do you think this change is a good idea?

(see video for demonstration of this "secondary" blinding effect)

 

sorry to spam, but here is an important note about this scripting scheme, which if I get the keywords all into the post, will hopefully help other scripters to accomplish similar tasks in their setups.

SELECTING UNIQUE PLAYERS (Targetting them, labelling them)

Depending on your use-case, this may not work as a plug-n-play player selection mechanism. But, it probably means you could alter your scheme so that it can incorporate this mechanism.

I have this posted in this Flare thread because it uses this technique for selecting which individual player gets assigned each secondary blinding orb. There are four orbs that will follow four unique players. The trick was always how to assign them on a elimination basis so that no two ever try to chase the same player, and no player (up to the fourth) could ever be tagged by the zone but not get assigned a chasing orb.

The first attempt at this technically worked, but was less elegant and more resource intensive. See video clip. This (old) technique was to do similar to what other scripters have done, which is to have each player pass through a zone that labels them. The light/orbs would first spawn in a sequential order, 1-4. Between each spawn would be enough time for the prior orb to travel to the nearest tagged player, use its own boundary to tag them with a label that claims it as being chased by any orb, excluding those with that label already, and assigns them the label belonging to the specific orb which was assigned. The process of elimination created a perfect assignment scheme, but it shows a small delay in the chase, and uses a LOT more script brains and objects than were eventually needed.

This problem originates from the fact that 343i has not given us a target list query/select option called "Nearest exclude". We only have "include". But there is a better way...

One day, while talking to myself in my head (something I do regularly to review recent happenings), I imagined that one of the great scripters for Halo 5 asked me to explain and justify why I had so many script brains and so many moving pieces involved in the Flare's construction. I talked it through with this other (self), and realized that I had made a logical omission! I am a database guy at heart (professionally, anyways) and the whole "Select first" option did not initially seem to be a good approach. But, after considering I had in the above not-so-good method, already established a sequential way of assigning labels, that I could combine that with the "Select first" option and completely avoid first forcing each orb to touch the player to tag them. It can all be done remotely via selection criteria!!!! (visualize lightbulbs flashing and bells dinging)


Here's how you should do it: (Video demo of it working)
(I can write out scripts later, but this is for advanced scripters, so just read the explanation and let me know if something doesn't make sense as written)

In short, use "Select first" in combination of any other criteria already needed to classify those who should be targetted. If it is all players, it is more simple in terms of criteria.

You need to assign a label to each player. You will probably need 1 script for each player targetted/label attached. Each should run in a sequence so that they are not running at the same time, and so that they have time to do their task before the next one begins. You can simply place no wait time on the first script, and add .10 wait time to each consecutive script. #2 waits .10, #3 waits .20, and so on.

Selection criteria: Each of the above sequential scripts needs to assign a different label, perhaps two, to each player. In this case, User Alpha is the generic label identifying that it has been assigned a specific label as well.

Group = Whatever criteria you are already using to identify people who need tagging. User "Players" if everyone in the game needs to be tagged.

First script would use target selection criteria of (Group) Add, Select First = 1. This causes the game to select whichever one it sorts first in its list, based on however the game does that. The script would then have an action item of tagging the targets with a label (User Alpha) and a second one tagging them with a label that specifically marks them as an individual (User Barvo)

Second script begins after 1st is complete, and uses selection criteria of (Group Add, Select First = 1, Label Exclude User Alpha. it doesn't matter which of the next targets in the group get selected, so long as they are not already selected. Action of this script assigns the generic Alpha label and the next in your sequence, Charlie.

We now have two users uniquely labelled, one with Barvo, and one with Charlie. You can repeat this process for as many labels as you need to assign.

This can be done at round start, and can also be redone every time the player count in the match changes, or some other event occurs.

Good luck!!

(EDIT to add that you may at times need to use "Exclude Dead" in your criteria, depending on what you are doing)

 

Well, Halo 3's did continue to blind those who were withiin range of the flare, even after looking away. Only those close enough... others simply glimpsing the flare and not close, did not get blinded momentarily after looking away...

EDIT: Additionally, if secondary effect did not exist, someone could look slightly to the side of the general flare effect (primary) they can easily avoid it. It would create zero meta for the game.

Considering this aspect of the development is what took about 90% of its time, I would be hard-pressed to remove it.

Thanks for the input though,