Jump to content

Check_Zone MCU does not behave correctly.


IckyATLAS
 Share

Recommended Posts

IckyATLAS

If you set the altitude of the ICON of the Check_Zone MCU set as a cylinder, this would mean that the base of the cylinder should stand at that altitude and go upwards without limit. In this way you can fly under that base without being detected.

But at the moment this does not work properly and and whatever the altitude of the ICON the cylinder starts on the ground and then goes vertically up without limits.

If the MCU Check_Zone is set as a Sphere the behavior is correct then the altitude of the ICON corresponds to the altitude of the Sphere.

So the Cylinder case should be corrected. Thanks.

Link to comment
Share on other sites

coconut

Nah, not a bug. Checking for altitude would be useful, but I don’t think it should be baked into the cylinder case. 

  • Thanks 1
Link to comment
Share on other sites

Jaegermeister

Actually, if the cylinder CZ behaved like the sphere, a cylinder with an altitude of 1000 meters and a zone of 1000 meters would have the base at ground level and a diameter of 2000 meters. I tested this yesterday and flew about 4000 meters above a checkzone set up this way. It did trigger the checkzone. 

 

I think it's always been this way, and I don't believe there is anything wrong with it. If you want to have a limited altitude, you can use the sphere.

Link to comment
Share on other sites

AEthelraedUnraed
8 hours ago, coconut said:

Nah, not a bug. Checking for altitude would be useful, but I don’t think it should be baked into the cylinder case. 

On the contrary, I think a minimum altitude on the cylinder Check Zone would be a neat solution to detect altitude. That way you could easily create zones where you should stay under a certain altitude, e.g. on the upcoming Normandy map stay below 100m over the Channel in order to avoid radar detection. One Check Zone MCU with altitude 100m and you're done.

 

You're right that it's not a bug though, it's just a missing feature.

Link to comment
Share on other sites

IckyATLAS

The gods of the forum have been very quick to kick this post out of the bug zone.

Let's check if it is a bug or not. The Y axis of the Check Zone is not greyed. I mean you can set up the altitude.

Why give us this possibility if it was not for a given functionality that is indeed missing.

 

So here is the real bug: the Y axis should be grayed and we should not be able to input a value.👍

 

 

Link to comment
Share on other sites

AEthelraedUnraed
20 minutes ago, IckyATLAS said:

The gods of the forum have been very quick to kick this post out of the bug zone.

Let's check if it is a bug or not. The Y axis of the Check Zone is not greyed. I mean you can set up the altitude.

Why give us this possibility if it was not for a given functionality that is indeed missing.

 

So here is the real bug: the Y axis should be grayed and we should not be able to input a value.👍

If you set an altitude, the MCU will show up in the 3D view of the Mission Editor at that specific altitude. Therefore it has a function. Not a very useful function, true, but still it's a function and therefore it's not a bug.

 

You're asking for some additional functionality, on which I agree with you, but the Mods were right to move this post out of the bugs section.

Link to comment
Share on other sites

coconut

Bug or missing feature, call it what you want, but fixing/adding the feature must not affect existing missions. Because of this constraint, a bug that’s been present long enough really isn’t a bug. It’s now a feature. 

Link to comment
Share on other sites

  • 4 weeks later...
chanklaus

I had my own problems with the checkzone, and I couldn't solve it yet.

 

I modeled this little scenario: two bombers attacking an airport, two fighter planes defending it. An attack area command makes the fighters counter the attacking bombers, set to 1 hour, but as soon as the bombers leave a checkzone the attack area is deactivated and the fighters return to base and land.

 

For the development I made the planes of both sides "immortal", so that I could properly observe the progress of the scenario, with the change of the waypoint markers and so. This worked completely fine, and I enlarged the scenario, with multiple aircraft on both side, and now they could be shot down.

 

But the upscaled version did not work. First time I thought it is due to bombers which belly-landed within the checkzone and - as I thought - might for the algorithm still be an "enemy within the check zone". So I assumed that the "height", so the Y axis value, determines the lower rim of the detection cylinder. I assumed I could solve the problem of belly-landed bombers by lifting the height to 200m, so well above the 140 meters of the surface. I thought anything on the ground - whether landed or wrecked - would be off the check zone.

 

But it didn't work. In one case there weren't even wrecks left in the checkzone, any still flying bomber had left it.

The Trigger CheckZone (out) still didn't fire.

Any idea why? Any guess what I did wrong?

Link to comment
Share on other sites

What exactly do you want happening event wise?

 

It sounds like, as I understand it (because it reads as frustrated ramblings), that you want:

  • Bombers to attack an airport
  • When bombers enter the airport area (via an entering checkzone), enemy fighters are called to assist and will arrive within 1 hour after bombers arrive. I assume there's some sort of Subtitle MCUs letting the player know that the enemy fighters are X time away from arriving on scene.
  • Fighters arrive at the 1 hour mark after bombers enter the entering checkzone (1 hour to attack a target seems like a very long time before QRF arrives, but I digress, it's your mission.)
  • If bombers are destroyed, fighters do not come
  • If bombers escape (via an exiting checkzone) before the 1 hour mark, fighters do not come

 

Is this correct? Where does the player come into play?

Link to comment
Share on other sites

chanklaus

No, sorry, I guess I expressed myself wrong.

Offline mission, not multiplayer.

 

Sovjet bombers attacking German airport, from which German fighters start to intercept the bombers. When the bombers have left the scene the fighters return to base and land.

Program-wise I use a Trigger Attack Area to make the German planes defend the airport. Whether it is triggered soon after mission start, or rather triggered through the advancing bombers with a checkzone trigger is actually irrelevant for my problem. The trigger is defined with a lifetime, after which it automatically is inactivated - that's, though, what I understand from the manual. If I choose the time too short it might be that my defending planes loose interest, even if there are still bomber or strafer around. If I choose it long the planes will circle around, until the clock is run down, and only then take the next step. Or I have to deactivate it, which I tried by a Trigger Check Zone firing when all planes of the Sovjet side have left the check zone. The Trigger Attack Area is deactivated, for the German fighter planes the next waypoint and soon after the Command Land is called.

 

I will finally fly the mission, but for me it is fun enough to construct the mission, tinkering until it's working and then watch the mission in autopilot mode.

Link to comment
Share on other sites

Alright I think I understand.

 

You want:

  • Soviet bombers to attack a German airfield
  • When they enter the airfield's area, German fighters are spawned and are set to intercept the Soviet Bombers
  • If the bombers remain in the airfield area, the German fighters will attack the bombers
  • If the bombers leave the airfield area, the fighters will stop attacking and chasing the bombers and return to continue defending the airfield for any other threats
  • After a certain amount of time, the fighters will return to base

 

Is this right?

Link to comment
Share on other sites

AEthelraedUnraed
2 hours ago, Sketch said:

What exactly do you want happening event wise?

 

It sounds like, as I understand it (because it reads as frustrated ramblings), that you want:

  • Bombers to attack an airport
  • When bombers enter the airport area (via an entering checkzone), enemy fighters are called to assist and will arrive within 1 hour after bombers arrive. I assume there's some sort of Subtitle MCUs letting the player know that the enemy fighters are X time away from arriving on scene.
  • Fighters arrive at the 1 hour mark after bombers enter the entering checkzone (1 hour to attack a target seems like a very long time before QRF arrives, but I digress, it's your mission.)
  • If bombers are destroyed, fighters do not come
  • If bombers escape (via an exiting checkzone) before the 1 hour mark, fighters do not come

 

Is this correct? Where does the player come into play?

To me it's clear what he's trying to do ;)

 

He's got a few bombers attacking an airfield, probably with an Attack Ground MCU (although he doesn't explicitly say so). When these bombers enter a Check Zone MCU, an Attack Target MCU is triggered for a couple of fighters (it's this MCU that has the 1 hour limit, so that the fighters don't stop attacking by themselves). When the bombers leave a Check Zone MCU, the fighters are made to return to base.

 

3 hours ago, chanklaus said:

But the upscaled version did not work. First time I thought it is due to bombers which belly-landed within the checkzone and - as I thought - might for the algorithm still be an "enemy within the check zone". So I assumed that the "height", so the Y axis value, determines the lower rim of the detection cylinder. I assumed I could solve the problem of belly-landed bombers by lifting the height to 200m, so well above the 140 meters of the surface. I thought anything on the ground - whether landed or wrecked - would be off the check zone.

It doesn't work that way, the Y axis value doesn't matter at all. If the "Delete after death" checkbox is checked for those aircraft, the MCU should trigger.

 

3 hours ago, chanklaus said:

Any idea why? Any guess what I did wrong?

My guess is you didn't trigger the second Check Zone MCU properly. Although I can't tell for sure without taking a look at the mission itself. Can you post the mission, or at least show a screenshot?

Edited by AEthelraedUnraed
Link to comment
Share on other sites

I'm asking so that I can build the mission and show how I've done it. 

  • Upvote 1
Link to comment
Share on other sites

Just a guess but if there are parachutes from the shot down bomber in the air, maybe these count as planes? Then the check zone "further" won't trigger until they have all despawned.

 

EDIT:

I just tested the parachute hypothesis, and it doesn't hold. Parachutes don't affect check zones.

I also tested the "delete after death" hypothesis. Inflicting complete damage to a plane without the delete after death flag triggers the check zone when the plane crashes into the ground. Maybe softer crashes lead to different results.

Edited by coconut
Link to comment
Share on other sites

chanklaus

I am pretty sure that belly-landed aircraft for the algorithm are still "active": I have seen flak shooting at a nearby belly-landed plane, and even if you click "delete after death" they remain in the game - because, I suppose, they are not "dead".

Link to comment
Share on other sites

chanklaus
Quote

He's got a few bombers attacking an airfield, probably with an Attack Ground MCU (although he doesn't explicitly say so). When these bombers enter a Check Zone MCU, an Attack Target MCU is triggered for a couple of fighters (it's this MCU that has the 1 hour limit, so that the fighters don't stop attacking by themselves). When the bombers leave a Check Zone MCU, the fighters are made to return to base.

Yep, AEthelraedUnraed, that's exactly what I have in mind. The  Attack Target MCU for the fighters is already triggered "on plane started", but that shouldn't make a difference. Many thanks that you would look into my missions; it really puzzles me that I can't find out what's wrong.

 

I attach my missions as two files, AlarmStart_Devel.txt, and AlarmStart_UpScale.txt. Rename them into *.Mission files; that format is not legal as attachment.

 

The AlarmStart_Devel mission has 2 attacking Pe-2 and 4 defending Fw-190, all invulnerable to assure one can watch the mission progress. This one works properly.

The AlarmStart_UpScale contains 5 defending Fw-190 and 15 attacking bombers. Here I made just the "player plane" invulnerable, to ensure it is possible to see the mission's progress. I double checked, both contain the same structure, the same succession of MCUs with the same properties.

At least I couldn't detect any differences.

 

But it doesn't work the way it should...

 

For both missions I triggered "Translator Subtitles" from the CheckZones, that way it is easy to follow when the CheckZones are firing. Because the texts for the "Subtitle" MCUs aren't stored in the mission files you'll have to add them in the "Mission Editor" if you want to use them.

 

In both scenarios you will still find a structure with a "FoeIn" CheckZone, which are relics of an early stage of mission development, in which I triggered the "Attack Target" (air) MCU for the fighter protection by this CheckZone. That, however, shouldn't make any other difference than that the "Attack target" is created a bit earlier. I left the MCU in because I can't see that it disturbs mission progress, and I can still use it to monitor the mission (...through development).

 

I am new at modeling BoX missions; any constructive criticism is highly appreciated.

 

chanklaus

AlarmStart_UpScale.txt AlarmStart_Devel.txt

Edited by chanklaus
Link to comment
Share on other sites

AEthelraedUnraed

@chanklaus I had a look at your mission, and I noticed a few things:

 

1 - deactivate the CheckZone In (id:25) MCU on triggering your CheckZone Out (id:30) MCU. That way, the mission won't reset when a bomber for whatever reason returns to the airfield.
2 - you don't need the 1 Waypoint (id:46) MCU if you want the fighters to attack the bombers right after takeoff. Just link to the AttackArea Cover (id:38) MCU right away.
3 - on your CheckZone Out (id:30) MCU, you link to a Deactivate MCU that then deactivates the AttackArea MCU, while at the same time linking to a waypoint with the priority set to Medium. This is not the proper way to do it. Instead, you should target link the CheckZone Out (id:30) MCU to a Force Complete MCU object-linked to the player, and to a Timer MCU with the time set to 1s or so. This timer then links to the waypoint. Because you know there aren't going to be some nasty surprises with enemy fighter aircraft, I'd set the waypoint priority to High. This forces player flight to focus on the waypoint and not engage any enemies (even when attacked, so you should be careful with setting waypoints to High. Also disables rear gunners for bombers).

 

Point 3 is likely where it goes wrong. I'm not sure deactivating an AttackArea MCU even works, and even if it does, the Timer Foe Out (id:32) MCU links to both the Deactivate MCU and the new Waypoint at the same time. This way, the new waypoint can actually be assigned *before* the Deactivate MCU triggers and nothing will happen.

If you want to give new orders to the player (or AI for that matter), always use the system I described above: first a Force Complete MCU object-linked to the player to cancel the current orders, then after a small delay (1s is enough), link to the new orders.

 

11 hours ago, chanklaus said:

I am new at modeling BoX missions; any constructive criticism is highly appreciated.

You actually use a nice layout and grouping, much more consistent than I do :P. It seems you're learning fast! Anyhow, if you have any other problems or questions, just let us know.

 

Also, I'm sure you already know it, but there's an excellent Mission Editor manual by JimTM. I'm a relatively experienced mission editor, yet I always have it opened for reference. You can find it here:

Also, if you want to do a little more advanced level editing and do things such as create your own villages, roads and airports, or change those that already exist, please check out my Surface Editing Manual that I just released (a little extra advertising never hurts :P)

 

Edited by AEthelraedUnraed
  • Upvote 2
Link to comment
Share on other sites

chanklaus

Many thanks for the pointers you gave me, AEthelraedUnraed, they definitively improve my MCU network.
Unfortunately they didn't solve the problem.

 

I made a bit of experimenting with the code. As I already mentioned the development version that I made works fine: two Russian Pe-2 bombers, attacking a German airport from which two pairs of German Bf-109 start to protect the airport. For all planes vulnerability is switched off - this way in the progression of the mission can be observed properly.

 

I extended this MCU network to 6 Bf-109 and 15 Pe-2 - and it failed to work properly. The obvious difference between the two versions of the same situation is the number of planes involved and the fact that in the "Devel" version all planes were "immortal", whereas in the larger final version they were vulneralble.

 

So I turned all of the planes on both sides to "not vulnerable". Obviously there was fierce fighting between the AI planes, and obviously none of them was shot down. Through SubTitle translators I could prove that the CheckZone trigger checking for the approach of the bombers was firing properly, and as well the CheckZone checking for their leaving. The deactivation of the AttackArea command worked properly and the planes returned to base as intended. This seems to prove that the general MCU logic was fine.

 

I made one of the Pe-2 vulnerable, and just one, for a test. This one plane was shot down within the circle of the CheckZone - and the CheckZone checking for the leaving of the bombers did NOT fire! Now, if a plane is shot down in the game, there are situations in which the plane explodes on impact, the debris being visible for some more time and then vanish. In other situations a wreckage of the aircraft lies around permanently and seems to be still "active" for the algorithm, because the labels are still visible, and I've seen flak still shooting at those wrecks.

 

Now, if such an "active" wreck would still remain in the CheckZome I wouldn't be surprised to see that it is not firing. But it seems to me that even those planes having their last position in the CheckZone - because that's where they were shot down and exploded - but which aren't visible any more, are counted and thus make the CheckZone not fire properly.

 

I hoped that the YPOS property of the CheckZone might help, assuming that it marks the lower rim of the detection cylinder, which then rises up "to the stars". That would be a handy property, offering the possibility to stay undetected by flying low. And it would help here, because crashed aircraft could be left out simply by lifting the bottom of the detection cylinder a bit above surface level. I tried with my "Devel" scenario, setting the YPOS to ground level, to 900 meters, 9000 meters - and 0 meters, sea level, so well below the surface, but found no difference. It seems to me that the YPOS does not mark a special property of the CheckZome.

 

Is it just my impression that the CheckZone reacts that sensible on plane crashes, or has anybody else made my experiences with its behaviour? Or is it the complexity of the MCU network, that sometimes sprouts surprising and unwanted side effects?

Link to comment
Share on other sites

AEthelraedUnraed
11 hours ago, chanklaus said:

I made one of the Pe-2 vulnerable, and just one, for a test. This one plane was shot down within the circle of the CheckZone - and the CheckZone checking for the leaving of the bombers did NOT fire!

This is the only change you made? And "Delete on death" is checked? In that case, I think you can file a bug report.

 

That said, your chosen solution to trigger when the fighters should RTB is not what I would personally do. I would simply make another waypoint for the bomber formation at the location where you want your fighters to return. Then trigger the fighter RTB when the bombers reach this waypoint. I tend to only use CheckZone MCUs (or Proximity MCUs for that matter) when I'm not exactly sure where an aircraft may be at the time. For instance, when they're doing a normal ground attack routine where they fly all around the area for a couple of minutes. For formation bombing, this is not a problem so the easiest way is to just use a waypoint.

 

You're right that the Ypos of the CheckZone MCU is currently not used. IMHO, it would be a neat way to detect the altitude of an aircraft; for now the only way to do that is by using the CheckZone MCU as a sphere.

Link to comment
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
 Share

×
×
  • Create New...