Conditional routes and foe's IDs

[Panta]

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

[Ssnake]

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.

[Panta]

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

[DrDevice]

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.

[Panta]

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.

[Ssnake]

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.

[DrDevice]

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)

[DarkAngel]

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.

[Gibsonm]

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?

[DarkAngel]

square i would think is not used or not evaluated yet.

[Volcano]

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:

[DrDevice]

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.

[Volcano]

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: