Set Value Modifier MCU and Counter MCU Logic

[Sketch]

I've been messing with the Set Value and Counters to see what I can do with them. I'm sure others have already learned about them, as seen here, here, and here. I went over the documentation from the devs in this post. Specifically item number 36, and I know the devs have also updated timers to function the same way as modifying Counters based on this update. Anyway, I've provided a picture tutorial for others. Let me know if it make sense, and if you have questions.

 

 

 

Here is the mission I used to test the Set Value Modifier MCU. As always, feel free to reverse engineer it.

Testing Modifying Counters.zip

Edited January 6, 2021 by Sketch
Clarity

[JG7_X-Man]

@Sketch I am a tad slow, but smart enough to know this adds huge value to mission making. Can you give a real (...ok ok virtual) world example on how one could use this in the ME?

[No_85_Gramps]

This, and along with all the other ME articles, makes my head ache...in a good way. At my age they say mental exercise is important, and working with the ME will definitely give the brain a workout!

[Sketch]

5 hours ago, JG7_X-Man said:

@Sketch I am a tad slow, but smart enough to know this adds huge value to mission making. Can you give a real (...ok ok virtual) world example on how one could use this in the ME?

In this example, I've created a dynamic front line that changes depending on what objectives get destroyed. When an objective gets destroyed, I give that objective to the team that destroyed it, and move the front line accordingly. When the objective gets flipped to the other team, I'm resetting the onKilled counter so that it'll always needs the correct amount of kills to be destroyed. I can only do this with the set modifier MCU.

 

 

 

[JG7_X-Man]

@Sketch Thank you for that clear explanation. This will be a great addition for automated dynamic campaigns creation.

[AcidBath]

One other super useful feature is that applying a Modifer:Set Value MCU with Data[0] = -1, Param Index = 0 to a timer that is running will stop and reset it as if it was never given a trigger.  Using Deactivate only pauses a timer that is running.

 

For missions I make for our squad, I use a Modifier:Add Value MCU with Data[0] = n, Param Index = 1 to a counter to increment its limit.  The value n is for the number of object's to be added to the limit, one such use is for keeping track of the count of AC dynamically spawned.  As these objects are damaged, killed, whatever fate is desired, the counter is incremented.  The counter triggers when all such objects have met the fate being tracked.  Note that for this to work, at some point in the mission some sort of 'begin fate tracking event' needs to increment the counter once (or conversely, decrement the counter's limit via Add Value -1,1).

Edited January 29, 2021 by AcidBath
updated for clarity

[Sketch]

[JGr2/J34b_Matthias]

Quote

One other super useful feature is that applying a Modifer:Set Value MCU with Data[0] = -1, Param Index = 0 to a timer that is running will stop and reset it as if it was never given a trigger.  Using Deactivate only pauses a timer that is running.

 

Absolute gold.  This can potentially save so much time and effort spent making timer breakers to kill logic pulses in the middle of complex repetative logic.

Edited January 11, 2021 by J5_Matthias

[Hanu]

Thanks Sketch and AcidBath for the input:

 

Could you Acidbath open your logic about keeping count of AI's and how to use it a bit more as it sounds very much something I try to achieve?

Here is what I was thinking just two nights ago when I was trying to get some sleep, but ended up planning some way to keep count of AI instances in mission... ☺️ Let's say you have already a working randomized logic in your mission to populate AI planes and tanks. You want to keep the mission as populated as possible, but watch out you are not overloading the server.

a) each AI instance trigger Add Value when they spawn: For example 1 = fighters, 2=IL-2's, Bf-110's, Stukas and 4=Bombers (depending how many crew members are in each plane). Same with tanks.
b) You have a "server limit" counter to send a pulse which disables the spawns (for example value of 50)
c) OnPlaneDestroyed/(OnDestroyed for tanks) you trigger to substract equivalent number from that value with Add Value negative number (I guess negative values work too?)

So far so good, but any idea how to send a new pulse to reactivate spawns when "Server limit" counter drops below 50 and still keep a count of AI instances?

But two major problems: I just cannot get a nice way to send that reactivate pulse while keeping the count. Perhaps by creating "reactivate counter" that activates when spawns deactivate. Something like value of 10, which would set the "server limit" back to 40 and reactivates spawns, but I'd see that the value will go to inconsistent state as hops are sometimes different than 1. But also I guess that the after firing the counters once, they will not fire any more unless ticking "reset" on those, which will spoil the calculation completely.

 

SAS_Skylla released (most excellent) logic gates couple of years ago and the work on query principle. I could use the boolean gate these to query the situation when OnPlaneDestroyed event triggers.

https://www.sas1946.com/main/index.php/topic,58745.0.html

Could you think this sort of a scenario to be possible by using these counters and add values? Just wondering if someone has already implemented this kind of logic, or do you have something even better (Acidbath?) Beauty of this idea would be to have a nice active and stable playground with lot of AI stuff, which you could easily to scale according your server performance with "server limit" value.

[JG4_Deciman]

7 hours ago, Hanu said:

Thanks Sketch and AcidBath for the input:

 

a) each AI instance trigger Add Value when they spawn: For example 1 = fighters, 2=IL-2's, Bf-110's, Stukas and 4=Bombers (depending how many crew members are in each plane). Same with tanks.

b) You have a "server limit" counter to send a pulse which disables the spawns (for example value of 50)
c) OnPlaneDestroyed/(OnDestroyed for tanks) you trigger to substract equivalent number from that value with Add Value negative number (I guess negative values work too?)

So far so good, but any idea how to send a new pulse to reactivate spawns when "Server limit" counter drops below 50 and still keep a count of AI instances?

 

 

Leave the 'main counter logic' running and counting all time

Enable/disable the spawners by server load limitation.

 

Every unit spawned increases the counter

Every unit despawned/killed decreases the counter

Spawning new items will be suspended when server load is too high (so no more upcountings triggered by spawned units)

Killing/despawning will reduce the counter, and when spawning is available again the will spawn

if the main counter has triggered that (maybe some ping-pong-timers to keep the requested spawning alive and permanently retry)

 

Deci

[Hanu]

30 minutes ago, JG4_Deciman said:

 

Leave the 'main counter logic' running and counting all time

Enable/disable the spawners by server load limitation.

 

Every unit spawned increases the counter

Every unit despawned/killed decreases the counter

Spawning new items will be suspended when server load is too high (so no more upcountings triggered by spawned units)

Killing/despawning will reduce the counter, and when spawning is available again the will spawn

if the main counter has triggered that (maybe some ping-pong-timers to keep the requested spawning alive and permanently retry)

 

Deci

 

Are you implying that counter triggers and sends the pulse when traversing to either direction over the threshold value? But the Counter trigger does not work that way; reducing the counter below the trigger value won't send anything. Or how did you meant to trigger those spawns back to life?

 

[JG4_Deciman]

keep requested spawn alive

 

Deci

[AcidBath]

I have to admit that I'm a noob when it comes the ME, just learned it in the last few weeks.  But I'm also a LabView programmer, which is a graphical Data Flow programming language very similar to using the ME.

 

Situation:  disable spawning AI when a server player counter limit (say 50) is triggered, and when it goes back down below the limit enable AI spawning.

 

This can be done by using another counter for tracking server overflow and an associated Modifier:AddValue MCU (Data[0]=1, Param Index=1), both which are disabled when not in use.  When the server player counter triggers at its limit (50) enable the overflow counter and its AddValue.  Now each succeeding server players' spawn event, which should be connected to the AddValue,  increments the overflows counter's limit.  Each server players' "On Finished" event, which in the standard manner should be connected to the overflow counter, increments the overflow counter.  The overflow counter will trigger when the server player count drops below its counter's limit (49).  On that trigger, disable the overflow counter and its AddValue, reset its limit to 1 (counter should be set to reset on trigger), along with doing whatever else is needed.  Note that this overflow tracking mechanism is not coupled to the server limit value, but is only triggered by it, i.e. any limit value will work fine with zero changes to the overflow counter mechanism.  Also, the server player counter's operation is independent of the overflow counter.  A counter's current count can be decremented by using AddValue with -1, 0; counting backwards into its limit will not trigger it, but a counter will trigger if its current count goes negative (observed by testing this behavior).

 

One thing I do with "inventory counters" is use them in "for loops" (a traditional programming construct) that iterate up to the counter's limit, where each iteration triggers a timer output that is connected to something relevant do to, like spawn one or more enemy objects whose number of instances is determined by that counter's limit.  I use this to load level mission enemy AI to the number of players in the mission.  Using inventory counters and for loops in this manner allows the spawning of the mission's players to be cleanly decoupled from the spawning of enemy AI.  Here's an example of a For Loop controlled by an inventory counter.  In this case, the Stuka flights counter resets when it triggers, allowing for the For Loop to be run again when desired.

 

Edited January 18, 2021 by AcidBath
added example picture, typo fix on add value

[IckyATLAS]

On 1/7/2021 at 11:44 PM, AcidBath said:

One other super useful feature is that applying a Modifer:Set Value MCU with Data[0] = -1, Param Index = 0 to a timer that is running will stop and reset it as if it was never given a trigger.  Using Deactivate only pauses a timer that is running.

 

For missions I make for our squad, I use a Modifier:Add Value MCU with Data[0] = n, Param Index = 1 to a counter to increment its limit.  The value n is for the number of object's to be added to the limit, one such use is for keeping track of the count of AC dynamically spawned.  As these objects are damaged, killed, whatever fate is desired, the counter is incremented.  The counter triggers when all such objects have met the fate being tracked.  Note that for this to work, at some point in the mission some sort of 'begin fate tracking event' needs to increment the counter once (or conversely, decrement the counter's limit via Add Value -1,1).

 

Not only this is gold, but now I can do some "logic programming" that could simply not be done before. This is true when you have to use the same logic multiple times with changing situation. This means going through the logic graph many times but with different outcome. That timer reset is really what was missing. The more of us experiment with the editor and the more we will discover about it. Who knows what there is yet to discover.

The problem of this incremental way of doing things is that you can often review what you did before and see that you can redo it in a much simpler way.

It is a kind of continuous never ending redesign and reworking.

I think if we did not have Jim's manual as a starting cornerstone many would have simply never gone into this rabbit hole. I speak for myself here but maybe it is also true for some others.

 

Edited January 31, 2021 by IckyATLAS

[AcidBath]

The Modifier features have been around for a few years.  I just was stubborn enough to dredge deeply enough to find them:

 

Quote

For mission designers we added a way to control Timer and Counter values dynamically. To do this, there are two new logical objects Modifier: Add Val and Modifier: Set Val. We plan to widely use them to alter various triggers in the future, but at the moment they can be used for:
- modifying a Timer trigger value. A modifier can set, add or substract the time value in a timer by using the 0 index of the controllable value and 1-st field of the value vector. When set to a negative value, the time counter is reset and the timer stops until the next input. For example, this can be used to reset and stop a timer in a mission, delaying some events tied to it.
- modifying a Counter trigger value and threshold (initiall set in a mission). To alter a Counter value, use the 0 index of the controllable value or alter Counter threshold using the 1-st index. For example, a certain mission event like a premature elimination of some targets can lower the threshold of a Counter to make sure the others are eliminated at the moment the player arrives to the waypoint.

 

When I started build missions a few months ago, the counter MCU functionality seemed way too limited.  This is what eventually led me to the above.

[AcidBath]

Just a coda to add on this topic.  I've found that it's generally asking for problems if you tie more than one input to a modifier:Add Value if any can occur less that 20 ms apart.  Though it is far less tidy, replicating the Add Value for each of those common inputs will prevent teeth gnashing later.

Edited February 17, 2021 by AcidBath

[JG4_Deciman]

Maybe somebody has already tried and known how to do that...

 

Using 'Modifier Set' for changing a behaviour....

 

MCU_CMD_Behaviour
{
...

  Filter = 16;
  Vulnerable = 1;
  Engageable = 1;
  LimitAmmo = 1;
  RepairFriendlies = 0;
  RehealFriendlies = 1;
  RearmFriendlies = 0;
  RefuelFriendlies = 0;
  AILevel = 2;
  Country = 101;
  FloatParam = 0;
}

 

Filter '16'  means altering country only

In case I want change the country set by the 'Behaviour'

- as the 'Param Index' starts with '0' (should mean 'Filter' ???)

- as 'Country is the 10th parameter

 

will a 'ParamIndex 9'

with 'Data[0]' set to '201'

change the country for the 'Behaviour' ???

 

And will using 'ParamIndex 8' change the AILevel provided in Data[0]

in case the filter is matching (should be 8 in that case)???

 

Deci

 

 

Edited October 12, 2021 by JG4_Deciman