Jump to content

Mission Editor MOD


Blindspot

Recommended Posts

Also I find it's a good idea to track rule dependencies. (->nomedeplume :thumbup:). I think about to implement this a bit more "space saving". Would this be ok?

 

Not sure if you're asking me me specifically, but if so, yes that's fine. My original idea was to colourise the rules list, so e.g. you select an action "set flag 5" and any trigger that has a condition or action referencing that flag is highlighted in the triggers list. But I don't know if the GUI widgets allow that. Besides, I normally edit at 1680x1050 so I have plenty of space. :D

 

A custom grouping is basically just something exclusive to the editor and all it does is it ties those 4 unique groups together and acts as if they were 1. Whenever the custom group is added into a trigger it automatically inputs every unit from those 4 groups into the trigger.

 

This sounds like a very good idea. My main concern with rules like "any blue ground unit in zone" is that there's likely to be a lot of ground units in the mission, but only a small number which can conceivably enter the zone because most are stationary or in a different part of the map. So it would consume CPU time to check every single unit when most of them can't possibly be in the zone, anyway.

 

You could also provide a few built-in 'custom groups', e.g. All BLUE fighters, All BLUE ground units, All client aircraft, etc. So rather than having new conditions, you'd be overloading the group handling to allow them to seamlessly coexist with the custom groups. Probably much harder to do though, but I think it would make for a nicer user experience.

Link to comment
Share on other sites

  • Replies 150
  • Created
  • Last Reply

Top Posters In This Topic

Is it possible to add more and/or condition boxes? Or perhaps just have a 3rd box that acts as an "and" for both items? I like to use flags to act as a lock with certain actions so that they evaluate specifically when I need them to be evaluated. With the current setup its not the optimal setup.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

Is it possible to add more and/or condition boxes? Or perhaps just have a 3rd box that acts as an "and" for both items? I like to use flags to act as a lock with certain actions so that they evaluate specifically when I need them to be evaluated. With the current setup its not the optimal setup.

Please give me an example.

Я только понимаю Вокзал.

Link to comment
Share on other sites

Please give me an example.

 

I had one in mind when I wrote that post, but having thought about it some more I've found a workaround for the logic needed.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

new 1.7 version with and and or option or is it or and and, :thumbup:

will be much easier working with trigger zones now

greatly reducing the amount of repeated entries

even for my low tech mission building attempts, thankyou.

Link to comment
Share on other sites

Say whaaaa...??? Thanks for the reply but geeeez. Any place in the GUI manual explains this clearly? Thanks again. Sorry, but totally confused.

 

It's a pretty simple concept. A 'Flag' in the mission editor is just a boolean variable, i.e. it is either TRUE or FALSE. All flags start out set to false. They are referenced by number, which is purely arbitrary, i.e. Flag number 1 has no special meaning compared to Flag 2 or Flag 3 etc. Or put another way, the meaning of a particular flag is entirely determined by the person who makes the mission. The number of flags you can reference in a mission is essentially unlimited.

 

Within a trigger, you can use the SET FLAG action to set a particular flag to TRUE, and the CLEAR FLAG action to set it back to FALSE.

 

Then you can reference the state of the flag using the "Flag is true" and "Flag is false" conditions. You also have the very useful "Time since flag" condition which will only be considered true if the specified flag has been true (i.e. set) for at least the specified amount of time, which allows you to implement timed events.

 

This is all explained in the GUI manual. Start reading from the CONDITIONS heading on page 65.

 

What's somewhat missing from the manual is practical applications for flags in a mission. Essentially, flags are the best way of keeping track of the state of the mission. For simple scenarios, just using a check if a unit is dead or alive may be sufficient. But often you want to remember things like "has the player flown through a particular zone?" You can't just use "unit in zone" for this, since that's only true while the unit is actually inside the zone. But you can use a "unit in zone" trigger to set a flag, and now if you want to know if the player has flown through that spot, it's trivial to check in a condition.

 

It's often best to learn by doing, so here's a fun exercise if you feel like it: create a mission where the player has to fly within a certain distance (e.g. 100m) of another aircraft for a certain amount of time (e.g. 30 seconds). For this, you'll need to understand the "Unit in moving zone" and "Unit outside moving zone" conditions, the "Set flag" action, and the "Time since flag" condition. You'll probably also want a way to notify the player when they've achieved their goal, so the "Message" action is probably helpful as well.

 

For extra credit, also consider the player's altitude in relation to the other plane.

  • Like 1
Link to comment
Share on other sites

Blindspot, are there any plans to integrate nomdeplumes patch into a future version of your mod?

 

That way one would only have to check for updates of one file.

 

Btw.: Great work man!!!!

[sIGPIC][/sIGPIC]

Asus ROG STRIX Z390-F Gaming, Intel Core i7 9700k , 32gb Corsair DDR4-3200

Asus RTX 2070 super, Samsung 970 EVO Plus M2, Win10 64bit, Acer XZ321QU (WQHD)

TM HOTAS Warthog, SAITEK Rudder Pedals, TIR 5

Link to comment
Share on other sites

Another idea. Auto Generate Target Zones for group.

 

Located within the targeting tab for a group. User specifies Begin and End waypoints and target zone radius. User clicks "generate" and target zones are automatically placed in the center of each waypoint within the range.

 

Basically its useful for placing lots and lots of aircraft AI. I've found it better to put AI fighters on CAP with several waypoints and a limited flight time than to just give them waypoints, a massive zone to defend, and a begin/end loop flight path.

 

It would really cut down on the time to create AI CAP and even CAS missions.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

Since 1.0.2 you don't need target zones anymore. The aircrafts attacking ground targets automatically.

Link to comment
Share on other sites

It is more for air to air combat, specifically CAP flights. Giving them a limited target area prevents them from going full burners straight at a target that is more than 100km away or anywhere they damn well please. It offers a level of control over their behavior. It might have gotten changed/broken in FC2 though, but the last time I tested it thats how it worked.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

Awesome mod this one is. I bet dollars to donuts the mod's features will be in the DCS release.

 

2 ideas for consideration:

 

1) A radomization trigger so you don't have to manually setup one yourself, to alleviate the work it takes to manually create one as detailed here:

http://forums.eagle.ru/showthread.php?t=57454

 

...or instead of a trigger just include an option right in the object's properties screen to enter a percentage of randomness.

 

2) Also include an option right in a object's properties to set a time delay before spawning.

 

 

Both these would make things faster if you don't need the extra corelations a trigger gives.

 

Cheers


Edited by Crunch
Link to comment
Share on other sites

Maybe, yes. But I hope they will extend the runtime by creating more flexible trigger conditions.

 

1) The discussion you reffered to concerns runtime features not the editor. You can easily create the wanted effect using triggers and it's not sooo time consuming to insert some of them.

 

2) This feature is already there - twice - also without any mod. ("Time hold" for objects, rule "Time more" for triggers)

Я только понимаю Вокзал.

Link to comment
Share on other sites

As you described that's basically an "and... and.... and... or". we can essentially get the same results by putting the "and...and...and" into its own trigger setting a flag, while putting the "ors" into their own trigger, setting another flag.

 

Once both flags are true the code executes. Obviously there is the downside that they might now always occur at the same time. So you'd need triggers to clear either of em if they are no longer true.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

Subtriggers - "else" logic in action lists

 

Here's some more experimenting. It's a bit rough, and while the implementation does give some flexibility it's probably a bit hard to understand. It also has one annoying usability bug which renders it very unreliable at the moment.

 

The basic idea is to make it easier to do "one and only one action". For example, let's say you want to explode one and only one of a number of zones. You can do this with a complex series of flags, but it's very cumbersome.

 

My idea then, is to allow a triggers' actions to perform if/else logic. However making a fully flexible conditional evaluation thing in the actions list is a pretty big task, so I've done something easier to implement. Unfortunately, it's not easier to explain. So here's a few screenshots which will hopefully explain it.

 

subtrigger_small.png

 

This shows a subtrigger I created. It's just like any other trigger, and therefore not very interesting. The only difference is, as mentioned before, the game won't actually ever evaluate/run this on its own.

 

 

 

 

action_small.png

 

This shows a trigger using the new "SUBTRIGGER" action. At first glance, this would appear to be running all five "explode" subtriggers any time flag 1 is false. However, the SUBTRIGGER action is deceptively tricky.

 

The SUBTRIGGER actually implies an "if ... else" structure into the actions list. Essentially, if the condition in its subtrigger is true, then none of the following actions are executed. The only actions run are those specified in the subtrigger's actions list.

 

So in the above screenshot, if the condition for "Explode #001" evaluates as true, then its action will be run. If it evaluates as false, then the next action ("SUBTRIGGER(Explode #002)") is checked. If that one's condition is true, then the following actions are skipped. If it's false, then the next one is checked, and so on.

 

The following sequence of actions (as shown in the screenshot):

 

  • set flag 1
  • subtrigger (Explode #001)
  • subtrigger (Explode #002)
  • subtrigger (Explode #003)
  • subtrigger (Explode #004)
  • subtrigger (Explode #005)

generates code like this:

 

action: set flag 1
if (conditions of trigger 'Explode #001' eval as TRUE)
{
  run actions of trigger 'Explode #001'
}
else if (conditions of trigger 'Explode #002' eval as TRUE)
{
  run actions of trigger 'Explode #002'
}
...
else if (conditions of trigger 'Explode #005' eval as TRUE)
{
  run actions of trigger 'Explode #005'
}

What happens if you have a SUBTRIGGER action followed by some other kind of action? In that case, the following action(s) become part of the "else" clause. A modified sequence of actions like this:

 

  • subtrigger (Explode #001)
  • subtrigger (Explode #002)
  • set flag 1
  • subtrigger (Explode #003)
  • subtrigger (Explode #004)
  • subtrigger (Explode #005)

generate code like this:

 

if (conditions of trigger 'Explode #001' eval as TRUE)
{
  run actions of trigger 'Explode #001'
}
else if (conditions of trigger 'Explode #002' eval as TRUE)
{
  run actions of trigger 'Explode #002'
}
else
{
  action: set flag 1

  if (conditions of trigger 'Explode #003' eval as TRUE)
  {
    run actions of trigger 'Explode #003'
  }
  else if (conditions of trigger 'Explode #004' eval as TRUE)
  {
    run actions of trigger 'Explode #004'
  }
  else if (conditions of trigger 'Explode #005' eval as TRUE)
  {
    run actions of trigger 'Explode #005'
  }
}

 

ModMan package is available in this post.

 

Edit: both bugs fixed.

 

I've also attaches a simple example mission (which the screenshots are from), which just has an explosion going off every 3 seconds.

 

No doubt there's a better way to solve the problem I'm trying to solve, but I thought this might be interesting for discussion purposes.

 

Note: this patch is experimental and not widely accepted, so probably will never be incorporated in Blindspot's mod. Relying on it too heavily might not be a good idea.

TestSubTrigger.miz


Edited by nomdeplume
Minor bug
Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...