Jump to content
Panta

Conditional routes and foe's IDs

Recommended Posts

I am making a scenario where a tank force will head for one of three predefined sectors if enemy AFVs are identified in one of them. The order is to engage the route IF more than 2 enemy AFVs are known to be in the sector.

During the test, the silly bastards head for one sector where there are not enemy AFVs, but boxy M113 instead. AFAIK, AFVs are only the tanks and the M113s are APCs or PCs. Any possibility of wrong target identification, or is it something else? :confused:

Cheers,

Panta

Share this post


Link to post
Share on other sites

You can find out with the Mission Debugger. :)

Create several overlapping regions, and in the middle you put an M113. Then define conditions like

"more than zero AFVs in region 1"

"more than zero MBTs in region 2"

"more than zero PCs in region 3"

"more than zero trucks in region 5"

"more than zero ... in region ..."

Then check which of the conditions is true in the Mission Debugger while you test run the scenario. :)

Share this post


Link to post
Share on other sites

Mission debugger? That's great, I hadn't noticed! But how do I read the series of dots in the conditions' indicator? :eek2:

Share this post


Link to post
Share on other sites

And for your logic issue:

AFVs are anything armored, inclusive of both MBT and PC in the game logic. AFV is a way of weeding out non-armored vehicles like trucks or civilian vehicles.

So M113 are both AFV and PC.

Share this post


Link to post
Share on other sites

Thus 'Tanks' is just that (MBTs). My confusion arises when the voice of a crew member warns 'Tanks!' when only an APC is in sight, perhaps. BTW, there is no mention to MBTs in SBP whatsoever.

Share this post


Link to post
Share on other sites
But how do I read the series of dots in the conditions' indicator? :eek2:

Not quite sure what you mean, but maybe

will give you an idea.

Share this post


Link to post
Share on other sites

Ssnake: I think Panta is referring to the debugger. There are a series of boxes that appear next to the conditions and events. How do we read this tank braille? :)

Clearly the check box next to an event is a true condition. What about the check with the boxes to the right? (see Event "Plan 1" in the test image)

SS_21_14_09.jpg.39d47dc751ad4489cec6df96

SS_21_14_09.jpg.39d47dc751ad4489cec6df96

Share this post


Link to post
Share on other sites

I would assume those are the individual logic statements within the condition/event. There is a maximum of 7 individual statements which would gel with the 7 tick boxes.

Share this post


Link to post
Share on other sites

So:

"Tick" means statement is "True".

"Cross" means statement is "False".

"Square" means statement is not being used?

So in the picture there is only one statement and it was "True" or satisfied?

Share this post


Link to post
Share on other sites
Ssnake: I think Panta is referring to the debugger. There are a series of boxes that appear next to the conditions and events. How do we read this tank braille? :)

Clearly the check box next to an event is a true condition. What about the check with the boxes to the right? (see Event "Plan 1" in the test image)

AFAIK (I will correct this if I am mistaken), Plan 1 has five parts to its logic, basically it uses every OR/AND slot available to it. The box means that logic is present but has not been met/is not yet true, and the check means it is true. In regards to Plan 1, the first part of five is true (the check to the right), as is the event itself (the check to the left), therefore I assume the five parts to plan 1's logic are OR conditions since only one is true, and the event itself is true. Only the scenario designer would know that though, and he would have to cross reference the boxes to know what it means. As I said, I could be mistaken, but this is from memory.

The mission debugger is something we would like to put in the SBwiki, but there hasn't been time yet... :frown:

Share this post


Link to post
Share on other sites

Actually, in the example, the event "Plan 1" has just one logic part: "If trigger 1 is set."

I think the assessment that the boxes are "not checked" logic events seems to make sense. So for each of the "plan" events in the example, there is just one logic part. Until the condition is tested/met, no boxes appear to the right. When trigger 1 was set, the information at right indicates which part of the logic statement was evaluated as true. Since there was only one option, it shows as one check and 6 "not evaluated" boxes.

Share this post


Link to post
Share on other sites
Actually, in the example, the event "Plan 1" has just one logic part: "If trigger 1 is set."

I think the assessment that the boxes are "not checked" logic events seems to make sense. So for each of the "plan" events in the example, there is just one logic part. Until the condition is tested/met, no boxes appear to the right. When trigger 1 was set, the information at right indicates which part of the logic statement was evaluated as true. Since there was only one option, it shows as one check and 6 "not evaluated" boxes.

Ah yes, that makes sense. It seems I was remembering it wrong then. :shocked:

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...