nighteyes2017

I have this exact problem. Havent seen the mission work at all yet. Flew the mission 3 times now, and after lead tells me to flow to steerpoint 3, nothing further happens anymore. Tried to hang on steerpoint 3, tried to join in lead, (thought that maybe that would trigger something). nothing happens.

reopened in mission editor bugs. This one can be removed.

as far as i know. not all maverick types are able to handle auto handoff. which means putting the TGP on auto, doesn't work if the maverick cannot handle that setting. Also, don't expect to get a complete lock at say, 15nm away. Completed handoff only works when you are close enough for the maverick to lock on. The TGP can lock targets from much further away.

It seems that when using a missile in zone condition with a quad-point zone, always triggers the condition even when the missile is not in the zone itself. Circle zones seem to work fine. I've setup these 2 test files: The trigger logic detects if a missile is in the zone between the Mig and the patriot. If so it activates an action for the patriot to shut down, and thus explode the missile. Then, after 4 seconds, another command is given to start the patriot up again. both triggers give a message so you can see when the trigger fires. When using a circular zone this works just fine When using a quad point zone, the patriot missile explodes as soon as it leaves the launcher When starting the mission, fast forward time 1min 45secs. That's when the patriot starts firing. mission files and track files atached. Missile in zone quadpoint bug test.miz Missile in zone Circle bug test.miz missiles in zone quad.trk missiles in zone circle.trk

This would not only help in WW2 scenarios. Just now designing a mission and i'm running into this problem as well. It would help a LOT if the bomb in zone actually triggers when the bomb detonates .

saw this post just after i started a new topic about this. I do not like the new airflow sound either. its over the top, and the sound loop is really obvious once you hear it. The pitch change gives the loop away and it becomes really annoying. Its not an improvement, lets go back to what it was please.

yes, i experienced this as well. Flying a case 3 carrier approach. trimming to the correct AOA is suddenly very hard. It is suddenly very sensitive.

track file uploaded target heading magnetic.trk

track file uploaded. missing slant range.trk

In the lower left corner, the lower line gives you heading and ground distance. However the given heading does not match with the heading tape. It seems one uses magnetic heading, and the other uses true heading. I dont know if this is as intended but i cant imagine pilots having to do the math here using the magnetic variance for the map, since caucasus is exactly the 6 degree difference shown in the pics. https://gyazo.com/c29daf33f1954b7e32a6ca3152836720 https://gyazo.com/2caed0e915b5e8fd95c66218c3aa064e

In CCRP mode, that slant range, which was located above the timer in the lower right corner, has gone missing. Anyone seen where it went? there is now an empty line there.

Is it just me or have the F18's displays suddenly become a lot less bright? Yes the switch on the right is on day setting, en the knobs above are on day as well. contrast and brightness only make the display dim further down.

there is actually, a much easier way to steer on the ground with a twist joystick: find the increase and decrease brakes controls in de controls list and bind them to something. now in the game, increase the brakes just a little. (look at the brake needles in the bottom left) Now watch what happens when you use the twist on your joystick: one side of the brakes actually gets momentary released, allowing you to steer normally using the rudder, without having to tap the brakes all the time. It will take a little more power to get moving, since the brakes are continuously a little on , but this works way better than having to tap the brakes all the time. don't actually use the normal brakes key when you do this though, because it will reset your brake amount to zero again, and you will have to increase the brakes again. unless off course, you need to actually stop, or are about to takeoff. i even set my brakes up just before touchdown during a landing. not to hard off course, or you will tip over. This will give you immediate control on touchdown with a twist joystick.

Ok, so i've done some further testing. I put waypoint 2 further away in the 36 kts version. They stop the same distance away. So not halfway, but the same distance as the first time. So yeah, definitely something to do with stopping too early because they think they need the distance to stop. However they did not actually think they got to the waypoint itself. I added a command to waypoint 2, to see if it gets executed when they stop. It didnt. No matter wich command i added to steerpoint 2 (switch, fire at point) gets executed. So apart from them stopping too early, they dont actually seem to think they got to the waypoint. So the moment they start braking, is not the moment at wich they look at the commandlist for that waypoint.

Braking distance. now there's an idea. That could be it. Dont have time to test that today however. So if that is the case, then different units, would stop short of the actual steerpoint based on their speed and needed stopping distance. As a workaround, i could place 2 steerpoints at the same spot and see what that does. will test it tonight. that would still classify as a bug to me though

Well thanks for the extensive testing. I appreciate the help. I know there are different ways to get them to do what you want to. I understand how to use the triggers, so no need to explain that. The way i had set them up is NOT how i would normally do this, and my point is not about that. Its just a quick and dirty setup to show the problem here. It is NOT, about how to set them up. As i said, i am getting different results with the 36 kts mission from the first post. You say both missions hold short at waypoint 1. that is not, how i set it up. I have setup up a second timed trigger that activates after 2.5 minutes. (again, not how i normally do this, its just a way to demonstrate the problem). So both missions should end up at waypoint 2, and not waypoint 1. the 11 kts does this just fine. The 36 kts does not (at least, not in my case). i recorded what happens here. this is a video of what happens in the 36kts mission from the first post. I time accelerated it. watch the timer in the upper right corner. 1) after 10 seconds. the command is given to waypoint 1. They go there and wait (as the should because the hold is still active. yes i know) 2) after 2.5 minutes, the second command is given to waypoint 2. You can see them heading for it, but halfway there, they just stop. and this is the problem. again, its not about how to get them there. I can think of 3 way to do the same setup. But they should not stop halfway, even with this setup. the ONLY difference with the 11 kts version is the speed i set for the group, and in the 11 kts version they get to waypoint 2 just fine. So why does a difference in speed cause them to stop halfway?

did you try both missions? because i get different results on both missions. the 11 kts works, the 36 kts does not. the bradleys stop halfway to the second waypoint.

If you read my post carefully, i already concluded that the hold task should have a stop condition. I get it. But that still does NOT explain why they stop halfway to a waypoint.

Ran into some trouble in my mission to get units to stop and move using triggers. So i setup some test missions to see whats going on. Setup: set a group of 4 bradleys with a hold command on the spawn point, and prepared a triggered action 'move to waypoint 1', and a second triggered action to move them to waypoint 2. After that, i setup a trigger after 10 seconds, to trigger the action to waypoint 1, to set them on their way, and a second trigger after 2.5 minutes to send them to waypoint 2. Result: they start moving to the steerpoint 1 after 10 seconds, and at the steerpoint they stop again. (no hold command is present at that waypoint) after 2.5 minutes, the second action is triggered, and they start moving to steerpoint 2, but they never get there. they stop somewhere halfway there, move like confused ants, and then stop. Somehow, the hold command screws up any subsequent move commands if it is not cancelled. My expectation would be that a 'move to waypoint' command, would auto cancel any hold command given. As you can see, they do actually ignore the hold command and move to the waypoint and then stop again. Now this would be fine except for the second waypoint, wich gave a different result, and makes the group end up at a seemingly random position. The only way i am able to achieve the result i want, is to introduce stop conditions to the hold command using flags, and give hold commands at each steerpoints with different stop flags. Not exactly elegant is it? I dont know if this new 'buggy' behaviour, or by design, but imho any movement command should auto cancel the hold command until a new hold is encountered by the group. now here's the kicker: If i plan all this with the default speed of the bradley (11kts), the group actually makes is to the steerpoint i send them to (either 1 or 2) . However if i set a max speed for the waypoints (36 kts), i get the weird behaviour of them stopping halfway. What is going on here? Hold command 11kts.miz Hold command 36kts.miz

Hi guys, check the last post in this thread. It seems to fix the problem. From what i can see, it seems 2 filesnames were changed in the 2.7 update.

i have the same problem. I did download the huey to try it out. However when i go to my steam account details and look for the license, it isnt there. There is no license mentioned for dcs having to do with the free trial. How do i uninstall the module?

another bump, still not working in multiplayer

Yep, i'm having the same difficulty as OP here. My system is about the same except i have an intel 9900K and an 2080TI RTX. I did nothing to change the settings and experiencing sudden heavy stuttering and lots of ghosting. Using fpsVR i noticed the CPU frametime is now way up. lots of red and orange spiking. (GPU frametime around 9ms). Another thing i noticed is that reprojection mode doesnt seem to work anymore. FPS will no longer locks to 45 even with overhead FPS available. We did have an update from steamWMR, maybe it has something to do with it? Setting Motion Vector mode works partially, but setting reprojection to auto or off doesn't make any difference anymore. Thanks fpsVR otherwise i wouldnt have noticed it.

I have the same problem here. Even when i start a new mission in the mission editor and save it, everything is fine. When i use the 'prepare mission' option (ctr-m), a config folder gets created wich also contains a copy of my snapviews.lua file from the savedgames/config/views folder. This gets shared over multiplayer and screws up the views from my clients that join the mission. Is this caused by a setting somewhere? is it a bug?

What you could do is make the targets that they are not supposed to attack invisible. This wil not actually make them invisible off course, but it will make the AI not see that target and so not attack it.