Jump to content
SYN_Haashashin

The Groups Sharing Corner

Recommended Posts

S!

 

Try changing the command formation timer to 2 seconds and the waypoint timer to 4 seconds.  That way the command formation comes first and the waypoint is triggered after the command formation.

Share this post


Link to post
Share on other sites

All he has to do is change the Timer START 2sec 'advanced settings' to 2sec. It was set at 2min and 30sec. 😐

Share this post


Link to post
Share on other sites

Dog1... attached is a modified version of your mission and vehicle convoy.

 

I corrected the START mcu and added several more waypoints for the column to follow. :salute:

------------------------------------------------

mission convoy check.zip

Edited by Thad

Share this post


Link to post
Share on other sites

the amazing train ride

though they both start going in the same direction , eventually one will turn and go in the opposite . question about journey ending , the train stops where the last WP is set with its area  circle ? must the circle cover the track the train is passing over to stop ? i need to place stations and things so i need to plan the routes for the scenarios . too bad we cannot plan single missions with objectives and points .   

 

Edited by SYN_Haashashin
Swasticas

Share this post


Link to post
Share on other sites

Sheesh... one helps a mission builder get his trains moving and what happens? A train demolition derby.  😀

Share this post


Link to post
Share on other sites

Train route:

i want to extend the route of the trains to certain points , stations etc , do i follow the same concept of the road convoy and place WP's ? do they stop in the circle of the last WP ? is there any time adjustments ?

Intersections :

When i reach an intersection the trains are derailing , how do i guide them to go one way or the other ?  

Blocks :

Do we place these to stop the train at the end of the route .

Edited by dog1

Share this post


Link to post
Share on other sites
On ‎9‎/‎15‎/‎2015 at 1:14 PM, Sim said:

 

Noticed this too.. unfortunately it appears to be by design (apparently an AI performance optimization). Shame, hopefully those issues will be revisited in the future by the devs.

IL2 was created as combat flight simulator. The ground topography was never created for ground combat and the AI isn't set up 'yet' for tactical use of terrain. A new map for Tank Crew in the works. The AI line of sight implementation better be good along with blocking terrain.

2 hours ago, dog1 said:

Train route:

i want to extend the route of the trains to certain points , stations etc , do i follow the same concept of the road convoy and place WP's ? do they stop in the circle of the last WP ? is there any time adjustments ?

Intersections :

When i reach an intersection the trains are derailing , how do i guide them to go one way or the other ?  

Blocks :

Do we place these to stop the train at the end of the route .

Make A Train Follow A Route

 

Starts on Page 70 of the Mission Editor

Share this post


Link to post
Share on other sites

Salutations,

 

After several hours of trying to get the train routing to work from the ME, I gave up. It wouldn't even load into the game. 

 

I started experimenting. Much frustration ensued. The files attached were the results.

 

Synopsys: A Russian train departs a station.. stops at a intermediate railway station for 30 seconds...  then moves on to the final station. One can take the mission from there to add more stops if desired. Nothing fancy but it works. 

 

There are three cameras included. One loacated at each station. Access via the [F12] key.

 

The player starts in a T-34. :salute:

 

Brought my above missions elements together into a Russian Train Route Group for mission builders.

 

Of course it can be modified to meet ones needs or desires.

 

 

SP Train Route Demo.zip

RussianTrainRouteGroup.zip

Edited by Thad
Removed Needless MCUs
  • Upvote 1

Share this post


Link to post
Share on other sites
46 minutes ago, Thad said:

...

Synopsys: A Russian train departs a station.. stops at a intermediate railway station for 30 seconds...  then moves on to the final station. One can take the mission from there to add more stops if desired. Nothing fancy but it works. 

...

 

SP Train Route Demo.zip

 

Brought my above missions elements together into a Russian Train Route Group for mission builders.

...

RusTrainRoutGroup.zip

 

You don't need the formation command MCUs. The train will move once a waypoint is triggered.

 

The demo mission from the manual will work if you run the "Resave all missions in folder" menu item on the folder containing the mission.

Edited by JimTM

Share this post


Link to post
Share on other sites

You are correct. I deleted the formation mcu and things ran perfectly without them. Less is more. Thanks. I will update my files.

Share this post


Link to post
Share on other sites

hello

i want to download the AAA spawn set from the first page but link broken , can someone help pls .

Share this post


Link to post
Share on other sites

Salutations,

 

I have several versions I could post but Page 15 in the Mission Building Guide shows one step by step how to create a Soviet AAA Battery. You can learn to do them yourself and you might learn and understand some basics of mission building during the process.

Share this post


Link to post
Share on other sites

Thad 

i've already read that , i want to download this AAA group which spawns and reappears . Its from page one of the thread , updated if necessary since it was developed at the onset of the sim .TKS

Share this post


Link to post
Share on other sites

Updated version of my enemy proximity groups that works with version 3.008 of the game:

  • WhileEnemyCloseCZ: Continuously check if an enemy enters a zone, triggers WakeUp when that happens. Then triggers Sleep when there is no enemy left in the zone, with a delay of up to one minute. Meant to be used with units that do not move, such as AA guns
  • WhileEnemyClose: Continuously check if an enemy enters a zone, triggers WakeUp when that happens. Then triggers Sleep when there is no enemy within the vicinity of a unit (to be object linked with the proximity trigger in the group). Meant to be used with mobile units, such as AI fighter patrols.
  • The variants with suffix Alt monitor enemy entrance non-continuously, to save CPU. You probably don't need that, this is only really useful if you generate missions programmatically, potentially generating several hundreds of these groups.

Proximity.zip

  • Thanks 2
  • Upvote 1

Share this post


Link to post
Share on other sites

Could you elaborate this a bit?

I can't get behind the logic of any of these at all.

For instance, what's the "Random Delay" Timer good for, now that it's not connected to anything?

What's the difference between "StartMonitoring/StopMonitoring" and "Activate/Deactivate"?

How to use this thing at all?

 

:drinks:

Mike

Share this post


Link to post
Share on other sites

The random delay is used in the Alt variants. These "pulse" monitoring, instead of doing it continuously. The initial random delay is there so that not all instances of the group pulse simultaneously. It is meant to be modified by a mission-generating script. In order to have all my implementations expose the same API to my code, all have the random delay, even though not all use it. So short story is that you should ignore it.

 

Same thing with the activate/deactivate nodes: ignore them. They were once used to handle corner cases in virtual convoys, i.e. convoys that appear when a plane flies nearby. For most uses, triggering StartMonitoring once at mission start should be enough.

 

The general principle of all these implementations is that the top part detects when a plane comes in. When that happens it triggers WakeUp and deactivates itself and activates the bottom part, which detects when there is no longer an plane nearby (i.e. the plane left, was shut down, player disconnected...), in which case it triggers Sleep, deactivate itself and activates the top part again.

 

The bottom part is the tricky one: There is no direct way to check if there is no plane in a zone.

Instead, we start a timer and start a check zone/proximity, and activate the detection MCU. If it finds a plane, it resets the timer, and trigger logic to reactivate itself in 30s.

If the timer expires, it means there are no planes in the zone.

Edited by coconut
  • Thanks 2

Share this post


Link to post
Share on other sites

Thanks for the explanation coconut!

Following your report here...

...and the corresponding confirmation from my side, I've put together a "quick & dirty" replacement group for those who need to use counters as gateway in the described manner (i.e. use them to apply an arbitrary delay to a "gateway" built using a counter with threshold "1").

Counter-as-Gateway.png

 

The usage should be self explaining, you have an input and output ("IN" and "OUT") like you did with your counter, and you have two inputs "Activate" and "Deactivate" in order to activate/deactivate this replacement group.
You can find the group attached to this post, or alternatively here: https://www.sas1946.com/main/index.php/topic,60165.0.html

 

:drinks:

Mike

Counter as Gateway.zip

  • Thanks 1

Share this post


Link to post
Share on other sites
On 2/28/2015 at 4:42 AM, No.501_MikiBzh said:

Here is a small one :

 

Random result. Each equals. One right at the end.

 

https://dl.dropboxus...ITOR/RANDOM.zip

 

Sans%2520titre.jpg

S! All

 

I was thinking about this and the odds of an event happening.   You have four possible outcomes. Each of the timers is set to represent a chance of activating. The last one is set to 100% to make sure that some event does occur. If you have four possibilities then each should be 25% ?  In the example above the first is 25% and the next is 33% followed by 50%.

 

I understand that that it looks like the first timer is one 1 out of 4 and the second timer looks like 1 out of 3 but should that really be the percentage they are set to?

 

So the real odds of the first event are 1 in 4, The odds in the second event are 1 in 3, The odds of the third are 1 in 2 and the final event is 1 in 1. It looks like the first event is getting less priority . Priority goes up on event 2 and 3.

 

So if the first 3 are all set to 25% then they are all 1 in 4 and even though the last one is still 100%.  it should happen just 1 in 4. 

 

Does this make any sense at all or am I just failing math class?

 

Share this post


Link to post
Share on other sites

Airfield runway fire as a self-starting group. Remember to set group as working, then place the effects on the ground or they may be floating:

 

https://www.dropbox.com/s/igdloi3m76ybdqf/Airfield-runway-fire-as-group.zip?dl=0

 

Airfield warning FX as a group. Needs to be wired to a Mission Begin translator, not self-starting. Detects enemy planes within a certain radius then starts airfield siren and fires a warning flare. When enemy planes are beyond a longer radius, stops siren and fires a green flare. I suggest using quite a small radius for the warning FX and a longer one for 'safe' FX. Here I think I'm using 4km and 6.5km. Possible extensions could include firing flares at two locations on a large airfield, or only firing with a random percentage of confidence.

 

https://www.dropbox.com/s/nh4ujurr3jn5qij/Airfield-warning-FX.zip?dl=0

 

Radar zone with high/low detection. Needs to be wired to Mission Begin or other "on" message. When a plane flies into the zone, this group will attempt to both detect the plane and notify "high" or "low". Uses spheres for detection, so planes may be undetected or mistakenly detected high or low. If you are editing this, do not randomly change the detection sphere sizes, visualize first before changing. I've tested this and it works decently enough for covering most of a map square.

 

https://www.dropbox.com/s/1hwz98fu5wdds9q/Allied-radar-zone-high-low.zip?dl=0

 

Axis radar station to accompany radar detection zones. Needs to be wired to Mission Begin. OUT on destroyed radar station should be wired to a deactivate for all the radar zones, switching off radar reporting when the station is destroyed.

 

https://www.dropbox.com/s/yjm38mzc91ly06e/Axis-radar-station-v4.zip?dl=0

 

Axis "front line flak" position. A collection of flak, AA and dugouts with detection zone, activation, "under attack" messaging and eventual destruction. Needs to be wired to Mission Begin for the defence zone to be active.

 

https://www.dropbox.com/s/oj2j4q9g4b411hc/Axis-flak-position-v2.zip?dl=0

Edited by Alonzo
  • Like 1
  • Thanks 3

Share this post


Link to post
Share on other sites
On 2/3/2019 at 11:43 AM, JG1_Butzzell said:

S! All

 

I was thinking about this and the odds of an event happening.   You have four possible outcomes. Each of the timers is set to represent a chance of activating. The last one is set to 100% to make sure that some event does occur. If you have four possibilities then each should be 25% ?  In the example above the first is 25% and the next is 33% followed by 50%.

I understand that that it looks like the first timer is one 1 out of 4 and the second timer looks like 1 out of 3 but should that really be the percentage they are set to?

So the real odds of the first event are 1 in 4, The odds in the second event are 1 in 3, The odds of the third are 1 in 2 and the final event is 1 in 1. It looks like the first event is getting less priority . Priority goes up on event 2 and 3.

So if the first 3 are all set to 25% then they are all 1 in 4 and even though the last one is still 100%.  it should happen just 1 in 4. 

Does this make any sense at all or am I just failing math class?

 

 

 

The way they are set up is correct if you want each of them to have the same probability. That is because the timers dont trigger at once but in a sequence and each timer is discarded if it's not triggered.

If you set all three as 25% then they don't actually have equal probabilities and that gives the last one higher chances of being triggered.

  • Like 1

Share this post


Link to post
Share on other sites

Butz, think it through.

If number one doesn’t fire and you have 3 remaining, are the chances still 1 in 4? :)

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
13 hours ago, Gambit21 said:

Butz, think it through.

If number one doesn’t fire and you have 3 remaining, are the chances still 1 in 4? :)

 

 

S!

 

Yes. 

 

It is not an intuitive process.  The odds do not change because number one does not fire. 

 

I have 4 coins and I want to get one head. The odds are 50% , 50% , 50%, 50%. Just because the first one is not successful it does not change the odds on the next.

 

 

 

The 25, 33, 50, 100 deals with deductive reasoning. I have four boxes. There is guaranteed to be a gold coin in one of them. I open the first box and I have a 1 in 4 chance of finding the coin.No coin.  I open the second box and I have a 1 in 3 chance of finding the coin. No coin. I open the third box and I have a 1 in 2 chance. No coin. I do not need to open the fourth. I know the coin is in there.

 

 

That is the problem. It is not about how many choices are left. It is about the odds of each choice being selected. Since they are fired sequentially, option 1 has only a 25% chance of happening. Option 2 has a 33% chance and option 3 has a 50% chance. Is that fair to option 1.  The 100% for option 4 is irrelevant. The other options have all had their chance and failed.

 

If you wanted 8 possible outcomes would you do 12%, 14%, 17%, 20% , 25%, 33%, 50%, 100% ? Would you ever see option 1?

 

If you want to be truly fair you could make all 4 choices 25% and put in a fifth timer. If one of the first 4 options is activated it deactivates timer 5 as well. If nothing is activated then timer 5 is target locked to the initial timer and it cycles until something is activated.

 

 

Edited by JG1_Butzzell

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, JG1_Butzzell said:

...

 

It is not an intuitive process.  The odds do not change because number one does not fire. 

        In the case of the random selector, the timer odds have to be changed by the designer to insure that one of the remaining timers fires.
        If all the timer odds are set the same, there's a chance that none of the timers will fire.

...

 

If you wanted 8 possible outcomes would you do 12%, 14%, 17%, 20% , 25%, 33%, 50%, 100% ? Would you ever see option 1?

        Yes, those are the values you must set for the timers (internal) to ensure that each output (external) has an equal chance of occurring.
        You would see option 1 12% of the time. If the timers for options 1 to 7 did not fire, you would see option 8 100% of the time.

...

 

 

 

Edited by JimTM
  • Upvote 1

Share this post


Link to post
Share on other sites
Posted (edited)
17 hours ago, JimTM said:

It is not an intuitive process.  The odds do not change because number one does not fire. 

        In the case of the random selector, the timer odds have to be changed by the designer to insure that one of the remaining timers fires.
        If all the timer odds are set the same, there's a chance that none of the timers will fire.

Yes, that is why the last one is set to 100%.  In my example of the other three set to 25% the last one is still only one 1/4 because the first three timers have failed.

Quote

...

 

If you wanted 8 possible outcomes would you do 12%, 14%, 17%, 20% , 25%, 33%, 50%, 100% ? Would you ever see option 1?

        Yes, those are the values you must set for the timers (internal) to ensure that each output (external) has an equal chance of occurring.
        You would see option 1 12% of the time. If the timers for options 1 to 7 did not fire, you would see option 8 100% of the time.

 

Yes, that is the problem. The first choice has the lowest possibility of being activated. Those values give an increasing chance to the following choice. They do not give an equal chance to each option.  It is not about how many choices are left. It is about the possibility of each choice being chosen. You want a 25% of the time for option 1.  A 25% of the time for option 2. A 25% of the time for option 3 and a 25% of the time for option 4. Option 4 is set to 100 % just so something is chosen

...

 

Traditional set up with first 3 output set to 25% and last at 100% and a cyclic where each option is 25% and the 100% restarts the system

 

 

tr.jpg

fr.jpg

Edited by JG1_Butzzell

Share this post


Link to post
Share on other sites
Posted (edited)
47 minutes ago, JG1_Butzzell said:

 

...

Yes, that is the problem. The first choice has the lowest possibility of being activated. Those values give an increasing chance to the following choice. They do not give an equal chance to each option.  It is not about how many choices are left. It is about the possibility of each choice being chosen. You want a 25% of the time for option 1.  A 25% of the time for option 2. A 25% of the time for option 3 and a 25% of the time for option 4. Option 4 is set to 100 % just so something is chosen

...

 

You're looking at the probability of the random timers firing (set in the timer) when you should be looking at the probability of the output timers firing (set by the design of the logic as a whole). At every step, each output has an equal chance of firing, and taken as a whole, that works out to 25% for each output (for four random timers and four outputs). All this is assuming you wanted an equal chance for each output; you can also calculate random timer settings for unequal chances of output (as demonstrated starting on the last paragraph on pg. 294 of the editor manual).

 

Perhaps someone experienced in probability can confirm or refute my belief and explain the math.

 

Cheers!

Edited by JimTM
  • Upvote 1

Share this post


Link to post
Share on other sites
5 hours ago, JimTM said:

 

You're looking at the probability of the random timers firing (set in the timer) when you should be looking at the probability of the output timers firing

 

 

Exactly

Share this post


Link to post
Share on other sites
Posted (edited)

S! And thank you.

 

 

"You're looking at the probability of the random timers firing (set in the timer) when you should be looking at the probability of the output timers firing (set by the design of the logic as a whole). At every step, each output has an equal chance of firing, and taken as a whole, that works out to 25% for each output (for four random timers and four outputs). All this is assuming you wanted an equal chance for each output"

 

If the output timers all have an equal chance of firing why are the random timers at different percentages? The random timers determine if the output timer is fired or not. That is the purpose of the random timer. If you have 4 output and you want an equal chance for all of them then why give the first 25% and the next a 33% and the third a 50%. Looks like the first choice is getting the short end of the stick.

 

This is the text:

 

"Here is a formula that you can use to calculate the probability to set in each random timer:
TPx=OPx/(OPx+...+OPn)×100
where
TPx is the probability to specify in the current "Random" timer trigger to obtain the desired probability (OPx) of triggering the related output.
OPx is the probability that you want for the current output to be triggered.
OPx,...,OPn are the probabilities that you want for all of the outputs associated with the
"Random" timers that have yet to fire.
For example, say you want a three-way random switch where the probability of output 1, 2,
and 3 are 75%, 20%, and 5%, respectively. Here are the calculations for each random timer
setting:    (these percentages are random selected by the author to demonstrate the formula and meant not to be equal.)
TP1= 75/(75+20+5)×100=75
TP2= 20/(20+5)×100=80
TP 3=5/5×100=100"

 

If you change the last number from 5 to 60 you get

TP1= 75/(75+20+60)×100=48
TP2= 20/(20+60)×100=25
TP 3=60/60×100=100  

 

So a 4 way switch with each at 25% with all equal would be

 

TP1= 25/(25+25+25+25)x100=25

TP2= 25/(25+25+25)x100 = 33

TP3=25(25+25)x100= 50

TP4=25/25x100= 100   look familiar

 

or

 

TP1 = 75/(75+75+75+75)x100= 25

TP2 = 75/(75+75+75)x100= 33

TP3 = 75/(75+75)x100= 50

TP3 = 75/x100= 100     gosh what is up here? 

 

TP1= X/(X+X+X+X)x100= 25

etc.

 

This formula has  nothing to do with the probability of a timer going off but with the number of choices. it subtracts a choice at each step and recalculates the percentage. We are back to the example of the box with the gold coin.

 

This is why I long ago asked for a true random number generator

 

Random number ( enter random number here)  ex: 3

On 1  ( enter target link)

On 2  ( enter target link)

On 3  ( enter target link)

 

 

"Perhaps someone experienced in probability can confirm or refute my belief and explain the math."

+ 1

Same here, I could just be spouting crap from the inside of a box in boat sitting upside down in the lobby of some downtown hotel.

Edited by JG1_Butzzell

Share this post


Link to post
Share on other sites
Posted (edited)
38 minutes ago, JG1_Butzzell said:

...

If the output timers all have an equal chance of firing why are the random timers at different percentages? The random timers determine if the output timer is fired or not. That is the purpose of the random timer. If you have 4 output and you want an equal chance for all of them then why give the first 25% and the next a 33% and the third a 50%. Looks like the first choice is getting the short end of the stick.

        Note that the random timers are triggered at different times. As each random timer is triggered, it either triggers its associated output timer (and closes the remaining outputs) or it does not fire and is now out of the probability game. The next timer now has an equal chance of firing, but that chance is based on the number of timers remaining to fire.

 

38 minutes ago, JG1_Butzzell said:

This is the text:

 

"Here is a formula that you can use to calculate the probability to set in each random timer:
TPx=OPx/(OPx+...+OPn)×100
where
TPx is the probability to specify in the current "Random" timer trigger to obtain the desired probability (OPx) of triggering the related output.
OPx is the probability that you want for the current output to be triggered.    <--- the OP values for all of the outputs must add up to 100%
OPx,...,OPn are the probabilities that you want for all of the outputs associated with the
"Random" timers that have yet to fire.
For example, say you want a three-way random switch where the probability of output 1, 2,
and 3 are 75%, 20%, and 5%, respectively. Here are the calculations for each random timer
setting:    (these percentages are random selected by the author to demonstrate the formula and meant not to be equal.)
TP1= 75/(75+20+5)×100=75
TP2= 20/(20+5)×100=80
TP 3=5/5×100=100"

 

If you change the last number from 5 to 60 you get   <--- If you change the last number (OP3) to 60, you must change the other OP values so that the sum stays within 100%

TP1= 75/(75+20+60)×100=48
TP2= 20/(20+60)×100=25
TP 3=60/60×100=100  

...

 

I've added some notes in red above. I hope they make the calculation clearer. I should add a note to the formula indicating that the OP values must add up to 100%.

 

S!

Edited by JimTM

Share this post


Link to post
Share on other sites
1 hour ago, JimTM said:

  Note that the random timers are triggered at different times. As each random timer is triggered, it either triggers its associated output timer (and closes the remaining outputs) or it does not fire and is now out of the probability game. The next timer now has an equal chance of firing, but that chance is based on the number of timers remaining to fire.

 

 

Yes, Each random timer is set to go off at a different time. That makes each timer a unique event. It is not one out of three or one out of four. It occurs as one out of one. It either goes of or not. It relates to the rest of the random timers in that if it does go off then any timers set to activate at a later time are deactivated.

 

Again the probability of it going off is what is important not the number of timers left.

 

Set to 25, 33, 50,100

The problem is when you look at it in increasing order it tracks in an expected progression. The progression is based on the choices left not the probability of that choice being selected. That is why I reduced the timers from numbers to X. It shows the progression is based on choices left not the choice itself.

 

 

1 hour ago, JimTM said:


OPx,...,OPn are the probabilities that you want for all of the outputs associated with the
"Random" timers that have yet to fire.

 

Yes  that is where the problem occurs. People assume that because there are only 3 choices left that it must be one out of three. The random timer is a unique event and does not know or care what other timers are set to.

 

I think the best way is actually a branching A or B set of choices. If A is chosen then it goes to the choice between 1 or 2. If B is chosen then it goes to the choice between 3 or 4.  All choices are then a 50/50 possibility with 4 possible outputs.

random.jpg

Share this post


Link to post
Share on other sites
42 minutes ago, JG1_Butzzell said:

Yes, Each random timer is set to go off at a different time. That makes each timer a unique event. It is not one out of three or one out of four. It occurs as one out of one. It either goes of or not. It relates to the rest of the random timers in that if it does go off then any timers set to activate at a later time are deactivated.

        Yes, it is a unique event, but (for the case of equally probable outputs) the probability of that event is set by the designer to give one of the subsequent
        timers an equal chance to fire. At every step, the probability of the next timer is set so as to give the remaining timers an equal chance of firing.
        E.g., 

        1. After 0 ms, timer 1 (one of four remaining) has a 25% chance of firing (so there is a 75% chance that one of the three remaining timers will fire instead).

 

        2. After 50 ms, if timer 1 doesn't fire, the second timer (one of three remaining) has a 33% chance of firing (so there is a 66% chance that one of the
            two remaining timers will fire instead).

 

        3. After 100 ms, if timer 2 doesn't fire, the third timer (one of two remaining) has a 50% chance of firing (so there is a 50% chance that the remaining
            timer will fire instead).

 

        4. After 150 ms, if timer 3 doesn't fire, the forth timer (the only one remaining) has a 100% chance of firing.

...

 

I think the best way is actually a branching A or B set of choices. If A is chosen then it goes to the choice between 1 or 2. If B is chosen then it goes to the choice between 3 or 4.  All choices are then a 50/50 possibility with 4 possible outputs.

        Assuming that your 50% timer occurs before your 100% timer, I think your design would work as expected.

 

 

I don't have the math background to really do an effective job at explaining my point of view. Guess we'll have to wait for a probability guru to chime in.

 

S!

 

 

Share this post


Link to post
Share on other sites

This is a logic block for scoring a map based on "kill 3 objectives to win" but where, if time runs out, the side with the most objectives destroyed should win. If they're equal on points, it's a stalemate. This is for use on a multiplayer server; we're currently implementing this (with bugs, hopefully fixed!) on Combat Box.

 

How to use:

  • Edit every CONFIG counter MCU and change to the number of points required to win, or to notify one side has almost won. In the example file it's 3 points to win, 2 points to "nearly win." Note that Red and Blue need all three CONFIG counters set to something sensible, and two are duplicates of each other.
  • Wire up the IN blocks to events where one side destroys/completes an objective. This should be a full objective, not just a kill of a building (usually). On Combat Box, an objective is a large target such as an industrial complex.
  • Wire up the OUT blocks to take notice of the events. For example if one side wins outright, you should probably show a subtitle announcing the win, set that side's primary objective complete, and end the mission. 

Alonzo-mission-win-logic-0.1-ungrouped.zip

Share this post


Link to post
Share on other sites

On random timers:

 

I have never liked the approach most take.  If I want any one of 6 convoys to spawn, Then I will send a trigger to 6 timers, all set to 1% probability.  If any one of those 6 triggers goes off, then it will shut down the other triggers.  If none of the triggers go off, in 200ms it will try again, and keep repeating till one of the 1% timers triggers.  

 

There is always the chance of what I call "bounce", where 2 timers might go off, and the deactivate is not quick enough so 2 events occur, but in the 3 some odd years I have been using an 18 output random timer, don't believe I have seen it happen.  

 

This is an 18 output random generator.  The subtitles in there are just for testing.  The timers on the left (first trigger timer, second trigger timer etc) are for how much time before the sequence starts, and then how much time  in between the previous output is trigger before it selects the next output.  The output 1-18 on the right is what gets linked to whatever is going to happen when that timer went off.  If there are only 8 events that might happen, in the "trigger all random timers" (middle of the group),  I would delete random 9 thru 18 in the target window for the timer

 

Consider it great for a mission builder, as although it is impossible for them not to know what is going to happen, at least they don't know when in the mission it will happen.

 

 

18 output random.rar

Share this post


Link to post
Share on other sites

Check any of the WOL missions. All of their airfields have siren logic.

Share this post


Link to post
Share on other sites
1 hour ago, =FEW=Kampfbiber said:

Anyone done a siren FX group yet? activates when enemy planes are overhead and deactivates if gone?

 

Allied version attached. Wire up to the "Enable Airfield FX" timer MCU. Group contains two trucks that will fire a red flare when enemies come nearby and green flares when enemies clear. Second flare is 8 second delay 70% chance to fire. Siren with start/stop also included. To create Axis version, update check zones to find Allies not Axis, and change truck model to be a German truck.

 

 

Allied-Airfield-warning-FX-Alonzo.zip

  • Like 1

Share this post


Link to post
Share on other sites
On 5/10/2019 at 6:00 PM, Alonzo said:

 

Allied version attached. Wire up to the "Enable Airfield FX" timer MCU. Group contains two trucks that will fire a red flare when enemies come nearby and green flares when enemies clear. Second flare is 8 second delay 70% chance to fire. Siren with start/stop also included. To create Axis version, update check zones to find Allies not Axis, and change truck model to be a German truck.

 

 

Allied-Airfield-warning-FX-Alonzo.zip 2.65 kB · 2 downloads

 

Thanks mate!

Share this post


Link to post
Share on other sites
On 2/25/2015 at 2:07 PM, SYN_Haashashin said:

 

20/03:

          - Runway lights and beacons, lifted from a campaign mission by No601_Swallow. Post: 36 https://app.box.com/...y5eg0opfhbd5dqa

 

I can't open the "Runway light and beacons" group within the mission builder, "Error reading group file" message pops up and it won't open! Can you double check if it's still working.

Any help appreciated!

 

Share this post


Link to post
Share on other sites

Try resetting the group by using the resave group option in the mission editor.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...