Mission Editor MOD

[HiJack]

@HiJack: You mean the "eye candy", rendering a "OR" symbol into each list entry? Or what do you mean?

 

No. I mean a condition where UNIT1 OR UNIT2 OR UNIT3 OR UNIT4 OR UNIT5 ................. (keep on adding units with OR) will trigger the ACTION.

[Blindspot]

Aha. So just use the mod like shown in your screenshot. It's exactly what it does already.

[HiJack]

OK! Didn't test that :P Will do

[nomdeplume]

@Nomdeplume: Please tell me, what do you want to do?

 

What do you mean?

[Blindspot]

I believe, I did not understand what you want the triggers to do because to trigger "one and only one action" only one flag and no SubTrigger is needed.

[nomdeplume]

Edit: short version is, I wanted if-then-else functionality. But if-then-elseif was just as easy to do.

 

I was initially thinking of the case that you want some randomness in the mission. This might be random location of a target (i.e. you want to activate exactly one of a number of groups), or similar. So, safest way is to make some random flags:

 

MISSION START - Random 20% - set flag 1

MISSION START - Random 20% - set flag 2

MISSION START - Random 20% - set flag 3

 

but now somewhere between 0 and 3 of these flags are set. But you want only one, so you add a bunch of 'once' triggers:

 

ONCE - No flag set? - set flag 1

ONCE - Flags 1 and 2 are set? - clear flag 2

ONCE - Flags 1 and 3 set set? - clear flag 1

ONCE - Flags 2 and 3 are set? - clear flag 3

 

Hopefully that all works as expected - you now know for sure only one of those flags are set. (But pity to you if you want 4 or 5 or more mutually-exclusive random flags.)

 

Now you can make the three triggers to wait for the right time to activate your group, but with the different flags so as to activate the correct group.

 

ONCE - unit X killed and flag 1 set - activate SAM 1

ONCE - unit X killed and flag 2 set - activate SAM 2

ONCE - unit X killed and flag 3 set - activate SAM 3

 

This is all very messy, and you have lots of extra triggers sitting around being checked by the game that will never be true (e.g. those 'flag 1 and 2 set?' triggers).

 

And of course, if you want lots of random things - you either end up with just a 'set' of random possibilities because they all use the same flags, or you have to duplicate this over and over.

 

Or - you try to confine the randomness to the actual moment. But then you still have lots of triggers being continually checked by the game, which will never ever be true.

 

To me all the solutions to this issue just seem very messy; and while checking if a boolean is true or not is a very fast operation, I still don't like having masses of triggers being run once a second for the entire duration of a mission.

 

So - move some of that logic into the 'action' part. One trigger to decide when it's time to activate the group, and then decide which group to activate then. No overlap, no tricks needed to stop the other versions of the activation trigger from running once the winner is selected, no stale triggers being continually checked for no reason.

 

Basically - a way to say "these conditions are fulfilled, now do either this or this or this ...". And that's it. The "subtrigger" thing was just a way of getting all the power of the existing conditions "for free".

 

So, that earlier bunch of conditions to set flag 1, 2, or 3, can be simplified as:

 

SUBTRIGGER - random 33% - set flag 1

SUBTRIGGER - random 50% - set flag 2

SUBTRIGGER - random 100% - set flag 3

MISSION START - random 100% - subtrigger 1; subtrigger 2; subtrigger 3

 

And this scales linearly if you want to have a set of 4 or 10 flags.

 

Only thing I'd like to improve (aside from the mentioned bugs) is to make it a bit more understandable. Not sure how to best represent it.

Edited September 7, 2010 by nomdeplume
Hopefully better explanation

[nomdeplume]

And it seems like, when I tested it, it's possible for both of these to be executed:

 

ONCE - flag 1 is set and random(20%)? - clear flag 1; activate group 1

ONCE - flag 1 is set and random(20%)? - clear flag 1; activate group 2

 

Actually I don't think I did test this. If I recall, I think I was testing using 'mission start' triggers to make sure only one of the set of flags was set; and I concluded that relying on them being executed in any particular order was a bit risky.

 

So with further pondering, perhaps my original goal is more useful: and that was to have a nice easy way of setting up groups of random flags which would be mutually exclusive. Current way is rather cumbersome, especially if you want to have more than 3 or 4 since the number of combination checks you need to do grows exponentially.

 

I still think this 'run another trigger on demand' thing is useful and more elegant than the other ways of solving the 'do one of these, but only one of these' methods.

[Blindspot]

In your case, an action "RANDOMLY SET ONE FLAG BETWEEN (1, 5)" would be more helpful, because step-by-step evaluation of different RANDOMs will never be fair. You will always need to have a static default action as a fall back, in case every RANDOM call is "false".

 

As a work aroud I would suggest the following: If you want to have one of a number of 5 flags to be set, giving each of them a individual chance of 20%, do this:

 

1) Create a new MISSION START trigger

1.a) Select trigger logic button "(A) OR (B)"

1.b) Insert rules "RANDOM(20%)" and "FLAG IS FALSE(x)" into list A

1.c) Insert action of your choice (set a flag or activate a group...)

1.d) Insert action SET FLAG (x)

 

2) Hit the trigger clone button

2.a) Change the action to be performed

2.b) ..repeat 2) 3 more times

 

3) Create a new MISSION START trigger

3.a) Insert rule FLAG IS FALSE(x)

3.b) Insert default action of your choice

 

If you activate the SAM groups directly, all is done only once during mission start.

Edited September 7, 2010 by Blindspot

[Case]

You will always need to have a static default action as a fall back, in case every RANDOM call is "false".

Exactly!

 

This means that if you have 5 flags to randomly choose from, and you want each flag to have the same probability of getting set, 20%, then you can determine the probability for each random flag.

 

The argument works like this. For the first flag there is a 20% chance of it being set, so you use RANDOM(20) here. If it is not set, then the second flag should have a 25% change of getting set, as there are only four options left, so RANDOM(25). If that still isn't set then the third should have RANDOM(33), and similarly, the fourth should have RANDOM(50), as it must decide between flag 4 and flag 5. If that still isn't set, then the last test should test for RANDOM(100), as it is the only option left.

 

So in trigger code, this looks:

MISSION START(Choose 1/5 #1) // RANDOM(20) // SET FLAG(1)

MISSION START(Choose 1/5 #2) // RANDOM(25) && FLAG IS FALSE (1) // SET FLAG(2)

MISSION START(Choose 1/5 #3) // RANDOM(33) && FLAG IS FALSE (2) // SET FLAG(3)

MISSION START(Choose 1/5 #4) // RANDOM(50) && FLAG IS FALSE (3) // SET FLAG(4)

MISSION START(Choose 1/5 #5) // RANDOM(100) && FLAG IS FALSE (4) // SET FLAG(5)

[Blindspot]

Case, you are right.

Why simple, when you can make it complicated. (clumsy translated from German) :doh:

[Grimes]

Im starting to like this setup to randomly choose from options.

 

Mission start, or some other condition > Set Flag 1

 

Random 10% && Flag 1 is true > Clear Flag 1, Activate Group 1

Random 10% && Flag 1 is true > Clear Flag 1, Activate Group 2

Random 10% && Flag 1 is true > Clear Flag 1, Activate Group 3

Random 10% && Flag 1 is true > Clear Flag 1, Activate Group 4

 

If you want it to execute more than once or to give extra stored data on what you spawned the triggers need to look like...

 

Random 10% && Flag 1 is true && Flag 5 is False > Clear Flag 1, Set Flag 5, Activate Group 1

Random 10% && Flag 1 is true && Flag 6 is False > Clear Flag 1, Set Flag 6, Activate Group 2

 

It will always pick one option rather quickly, and with the 2nd set I put in there you can recheck the list easily to spawn whatever is left.

[Case]

Why simple, when you can make it complicated. (clumsy translated from German) :doh:

Don't worry Blindspot, I made the same mistake myself earlier. Only when I took the time to think about it did it dawn on me this was the way to do it. I even wrote a small C program to test it myself and it works great.

 

So for N flags to set with 1/N probabilty, use the following probabilities:

1: 1/N

2: 1/(N-1)

3: 1/(N-2)

4: ..

5: ..

N-1: 1/2

N: 1

[nomdeplume]

So in trigger code, this looks:

MISSION START(Choose 1/5 #1) // RANDOM(20) // SET FLAG(1)

MISSION START(Choose 1/5 #2) // RANDOM(25) && FLAG IS FALSE (1) // SET FLAG(2)

MISSION START(Choose 1/5 #3) // RANDOM(33) && FLAG IS FALSE (2) // SET FLAG(3)

MISSION START(Choose 1/5 #4) // RANDOM(50) && FLAG IS FALSE (3) // SET FLAG(4)

MISSION START(Choose 1/5 #5) // RANDOM(100) && FLAG IS FALSE (4) // SET FLAG(5)

 

This fails the 'one and only one' test. If Flag 1 is set, there is nothing stopping flag 3, 4, or 5 from being set. You have to check every prior flag (i.e. the last option has to check flags 1-4 are false) or you need to use an additional gatekeeper flag (easier).

 

The other problem I have with this method is that it relies on the triggers being run in a certain order. I haven't seen anywhere that the editor guarantees triggers will be written out in a certain order, or that the game will run them in a particular order. What happens if in a future version of the engine they make the scripting system multi-threaded so more than one trigger can be executed simultaneously?

 

Basically: I don't like relying on happenstance in order for core functionality to work.

 

Grime's method is what I used myself*, but I hate having triggers all over the place that can never be true. I know the imposed load is minimal, but I still don't see any reason for it.

 

* - nowadays with an additional 'time since flag' in the 'or' condition so I can put an upper bound on how long it'll take to pick something.

 

Anyway, flags + groups were just one example. There's lots of other things where random (or non-random) variation is nice, and although there's nothing you can't do with a bunch of flags and a horde of triggers, I do value elegance (though you wouldn't know it to read my code :D).

 

Consider: mission status report at particular time (check various conditions, units alive/dead, etc. and send a single radio report), activating one of a few WP markers near the target area but not always at the exact same spot, simulating artillery firing illumination shells over an area, ...

 

All can (and have) been done using flags, but they're also all done faster, more simply, and more efficiently using 'subtriggers'.

[Blindspot]

Just combine Case's probability handling with my post, that is how it was meant. Currently triggers, rules and actions ARE run in the order they appear within the lists.

I think to add IF-THEN-ELSE blocks for most users adds a lot of confusion too, especially when built into "dialogs" and "forms". Also the "workload" you have as a user to create triggers and rules will not be less. Maybe it would be better to make an expert mode, where experienced users can write down their LUA script directly.

[nomdeplume]

Yep no worries, obviously it's not of interest to anyone but me. I'll stop trying to convince y'all.

 

Is anyone else as anal as me about naming units consistently? I always just use "group name/unit number" as the unit name (e.g. "RU Ground 01/04" for the 4th unit in the group RU Ground 01) but it's a bit tiresome entering the names. Last night I thought, why the hell am I doing this? Surely the computer could? So I've started on a "unit name template" field under the group name.

 

At the moment I've implemented enough to suit my needs, which is to say, if I put in the name template field the string "g/n" then all units in that group are named according to my standard scheme.

 

I also have "t" which includes the entire unit 'type' string; I'm planning to use 1-5 for the 1st, 2nd, 3rd (etc) word in the type string (probably 1 will be most the useful, i.e. AAA, MBT, INF, etc.) and 0-6 for the last, second last, etc. word (might be useful in some circumstances).

 

Also thinking of adding 'a' which will show be replaced with AAA, SAM or nothing, depending on the type of unit.

 

So -> is anyone else anal about naming schemes, and if so, is your scheme something a computer could do automatically for you, and if so, what is your scheme?

[Grimes]

So basically you want an "or" trigger built into the actions column to choose one of those actions at random?

 

That would simplify things immensely. You brought up the illumination flares, I've got that exact same setup in my next mission. At least 20 triggers are needed to: activate the random flares (12 flare options), pick 1, pick another 20 seconds later, cycle through every 90 seconds or so until flares are "out", clear flags, begin launch cycle, and deactivation of flares when it either becomes light outside, all enemy units are dead, or all friendly units are dead and no player aircraft is in the area.

 

I honestly don't know what the effect triggers may have on a mission. Whether a bunch of "dormant" triggers that are left to never execute because they weren't randomly chosen will eventually lag the game, I don't know. I'm quite sure a single trigger with 400 conditions in it won't effect the game the same as AI spawning.

 

 

An automatic namer would be great. Even something that just made each unit in the group the groups name with an added a ".1" ".2" at the end.

 

My naming convention is rather erratic and I don't always stick to it.

 

B_GND_DFS_01

 

They are on blue, they are ground units, defending and are group 01. I tend to put what they do as part of their name. Especially if they are critical to the score of a mission.

 

AI aircraft are generally R_AI_ASph_01.1

 

If it had a preset list of stuff to name off of... that wouldn't be so bad. I'd prefer it to be based off the group name though.

[Blindspot]

The random thing should be no problem. Would be a kind of "DO_ONE_OF" extention to the action list box, what means it would not affect the rules. So one could create a trigger, that if all rules evaluate to "true", would randomly pick one of the actions and execute it. For your example this would be like that:

 

MISSION START -> IF (nothing) -> PICK ONE(SET FLAG(1), SET FLAG(2), SET FLAG(3), ...

[nomdeplume]

Unit name templates

 

Unit name template thing for ground vehicles is attached. I've just zipped up the one file, so make a backup of the me_vehicle.lua in FC2\BlackShark\Modules and replace it with the one from the zip.

 

The updated dialog looks like this, with the new "UN TMPL" field and checkbox:

 

 

By default the field is blank, and units will be named in the normal fashion.

 

If you enter stuff into this field, it'll be interpreted as a template to use to generate the unit name for all units in this group. There are two modes here, a 'preview' mode and an 'applied' mode. When you first enter something into the unit name template field, you'll be in preview mode. The UI will show the generated name prefixed by an = sign. If you close the vehicle group dialog and re-open it, the change won't have been applied. You can use the 'unit number' thing to cycle through the units to see what names have been used.

 

If you're happy with the generated names, click on the tickbox to apply it. This will rename every unit in the group, and any new units you add to the group will be named according to your template.

 

If you make changes to the template field after you've applied it, you'll go back to 'preview' mode. So you can experiment and easily through away changes.

 

All that said - the template is very simple and you'll only be using a few characters anyway, so being able to preview probably isn't all that helpful.

 

Template characters are:

 

• g - the name of the group
  
• n - unit number, 0-padded if more than 9 units in the group
  
• t - full unit type string (AAA Vulcan M163)
  
• 1 - first word from unit type string (AAA)
  
• 2 - second word from unit type string (Vulcan)
  
• ...
  
• 5 - fifth word from unit type string (often blank)
  
• 0 - last word from unit type string (M163)
  
• 9 - second last word from unit type string (Vulcan)
  
• ...
  
• 6 - fifth last word from unit type string (often blank)
  
• a - if first word is AAA or SAM, then show that, else blank (good if you want to call attention to air defence units in a group)
  
• ' or " - prevent above characters from being special
  

So by way of example:

 

An automatic namer would be great. Even something that just made each unit in the group the groups name with an added a ".1" ".2" at the end.

 

g.n

will generate that naming scheme.

 

g.n a

will generate the same naming scheme, except any air-defence units will have an "AAA" or "SAM" appended to the end.

 

g 'type'=t

will generate names like "My Group type=AAA Vulcan M163" - the quotes around 'type' prevent the 't' from being expanded into the unit type.

 

Name collisions are handled in the same way as normal - by appending #001 etc. to the name.

 

Leading and trailing whitespace is stripped, so putting "g/n a" won't result in non-AD units having a space after their name.

 

Multiple sequential spaces within a name are also reduced to a single space, so a type of "g a n" won't place two spaces within a name if the unit isn't an AD unit.

 

Edit: I've incorporated this into v1.7.3 of my info list patch thing, available from this post for those that prefer ModMan packages.

me_vehicle.zip

Edited September 12, 2010 by nomdeplume

[nomdeplume]

Very quiet 'round here!

 

I've been using the subtriggers thing more and more and although I'm convinced there's a better way to implement/explain it, I'm also convinced it's quite useful.

 

v1.7.4 of my patch fixes the remaining issues with tracking subtrigger usage when the triggers list is added to, removed from, or reordered. It also adds a 'triggers' button for easily locating triggers which invoke the subtriggers. Available from this post.

[Anastasiuss]

@nomdeplume that is a nice mod. I will test this a soon as possible.

I spend most time with marking the single unities of cloned groups.

Edited September 19, 2010 by Anastasiuss

[Case]

Apparently your work is received well by ED Blindspot! The DCS:Hog mission editor has quite a few of the features you implemeted in DCS:BS and FC2.0!

 

Very well done!

[Blindspot]

I hope so! Thank you Case!

We will see if there is anything left to do in the future... :)

[104th_Crunch]

I see no copy unit function but there are other good improvements like the trigger sorting and the or function. Lots of new triggers as well.

[Moa]

Yes. I hope copy unit gets added in, it is a pain to create missions without it (noticed this morning when serving up test multiplayer mission on stallturn).

[Grimes]

if they dont add it in officially I'm sure this mod can be easily adapted to the new editor functions. Would be nice if it was part of the final product though. Sadly I've yet to pick up the pre-order to work my magic with the new editor.