Ignition

Excellent, but there are issues! Me and my friend (pilot and WSO) had a LOT of desync when using MN. Each cockpit had the same waypoint pointing to different locations in each cockpit. We made lots of MN updates but this was always the case. It never got synched. The mission was in 1990, we did a full INS alignment, cold start. When the WSO moved the TGP I could see where he's waypoint was pointing, the same when I moved the TGP, he could se where mine was looking and it was very far away, like 0.5+ nm. The same waypoint was not in the same place for each cockpit. If you're flying let the WSO make the update. Cue the tgp to waypoint, move the TGP (only move) and in the other cockpit the TGP display will switch from where he's looking to where your waypoint is. Sorry I don't have a track. If we can we make one from each cockpit. "please document them using a video from both seats." Yes better I will try.

I guess M1 and M2 aren't used after FENCE in because they aren't encrypted? Maybe changing the master to low instead of normal?

It made me laugh, in a good sense

It's not. Well when you push the update both cockpits update but in different positions. MN and INS are not synchronized. Both cockpits have their own drift.

It's possible right now.

I just remember the TSD has a bug were it doesn't show correctly the waypoints and the background, you need to change the zoom/range on the screen for it to update.

Maybe you or the WSO changed the PPKS from EGI to MN or INS. INS and MN are not synched in multiplayer multicrew. This makes impossible to do missions without GPS. Also INS MN updates aren't synch either.

Really!? I didn't know about this, thanks.

No mention to new static objects, it says ground units but it doesn't specify statics. Why ED is so reluctant towards the STATIC objects? 90% of the DCS objects are 30 years old and it limits the possibility for missions to want the map offers, we do much more combat missions in DCS than any other real pilot could possibly do and the lack of targets is very noticeable.

Although some random details of light brightness resembling wear is nice, is it possible to have brighter console lights? Also the master modes are very dim. I'm sure it's difficult to see in the real plane at night but I'm sure It's harder to see on a monitor.

I don't have a track but I had this issue playing multiplayer multicrew. My WSO tried to transfer the target point, XFR SEQ PT got boxed forever and smart weapons page got stuck. Tried changing armament page but it didn't solve the issue. We had to respawn. Also the smart weapons page gets desynched when dropping jdams for the WSO, the bombs still appear in the smart weapons page until all the bombs get dropped. If we have time we will try to reproduce with a track.

I believe it's just a coincidence. Imagine the consequence if the VV goes beyond the HUD and the pilot believes he's in the correct AoA just because it's still flashing with 30 units. The flashing in fact it's a warning that the VV may not be trusted and not because it's the correct AoA.

The VV flashes when it's on the limit of the HUD and beyond. It shouldn't be used as a reference for AoA.

In the F-15E it's still very green, there are some things that are missing and/or working incorrectly, but it is in a very nice starting point since it has been out from a few months now. I hope after so many many years of development of the F-18C ED finally add a proper INS simulation to this aircraft.

I did another test, this time with a .miz I've made. Full alignment with the correct coordinates. The helicopter was the waypoint. With EGI With INS This time the altitude didn't change, just the LAT/LONG It has an error but is precise. Should it be on top of the helicopter or this error is common? The screenshots were taken in less than a minute after the update was done.

Yes, sorry. I will do more tests to see what was the problem. It may be related to a .miz thing. The aircraft wasn't in the correct position when aligned with SH. The next time I did a full INS alignment (changing the alignment with the correct coordinates) and the precision was way better, it still had 80-100ft error but it was almost on point. TGP after ins fix TGP where it should be

I see, it's more a problem of the pilot than a lack of datalink You can build a lot of SA with TEWS, AWACS, Radar a wingman and common sense. But if you only fly on PVP airquake arenas with 40 aircrafts all of the same coalition and go alone like a cowboy, I can understand why you're not training that SA. I don't know, that doesn't sound a like representation of real BVR to me.

There's a problem with the altitude when using MN or INS. The waypoints are always looking below the terrain, I did some tests in the Caucasus map and it ranged between 250ft and 640ft When changing to EGI it gets fixed. I did PVU updates to both MN or INS in each test before updating, did a radar update (PB 17 on radar was correct and altitude was also correct in waypoint), the waypoint gets updated but it's looking below the terrain. In the last test the waypoint was at 16ft. Looking with the TGP to the correct place of the waypoint, it said 644ft (which was way above the real 16ft). Changing manually the waypoint to 644ft did point to the right direction. Switching to EGI, now the waypoint was way above the ground, changing manually to 16ft did point to the right direction.

Datalink will not change change the aircraft in BVR so much. I don't understand why so many people say this. Datalink is useful for situational awareness, it will not change the F-15E on an intercept aircraft. It's not a bad BVR plane but it's not the best. I see many people flying on PVP server arenas who want datalink, but the SIT page on the F-15E is much more than a display to see the enemy. You can evaluate and make many things through JTIDS.

If the bombs are set to AUTO, you will only be able to drop them when "In Zone". In DIRECT you can drop them when "In Range".

thanks!

I tested isTargetDetected, it doesn't return distance. detected is the same as getDetectedTargets. Useless functions right now.

I tested it and it's still not working. isTargetDetected doesn't return distance. getDetectedTargets does return distance but once it detects the target once, it will never stop detecting it until the target is destroyed.

Yes I thought about that. If that's the way it's supposed to work it would be really useful to have an option to reset it and force a check from 0. As it is right now its only useful for the first time it sees the target. I'm going to couple this with isTargetDetected and see what happens. I guess it will check the table generated by getDetectedTargets and it will not be very useful.

I have this executing every second on a trigger: local SAM = "Ground-1-1" local maxRange = 160000 local controller_unit = Unit.getController(Unit.getByName(SAM)) --sam local tDetectedTargets = controller_unit:getDetectedTargets(Controller.Detection.RADAR) trigger.action.outText("#tDetectedTargets: " .. tostring(#tDetectedTargets), 15) if #tDetectedTargets > 0 then trigger.action.outText("Mayor a 0", 15) for objetivo = 1, #tDetectedTargets do local objName = Object.getName(tDetectedTargets[objetivo].object) trigger.action.outText("objName: " .. tostring(objName), 15) if Unit.getByName(objName) then local target = Unit.getByName(objName) local coal = Unit.getByName(objName):getCoalition() if coal == 2 then local distancia = Distancia(Unit.getByName(SAM), target) trigger.action.outText("Distancia: " .. tostring(distancia), 15) if distancia < maxRange then a = 1 else a = 0 end end end end else trigger.action.outText("No detecta NADA", 15) end The problem is when it detects a target and the target goes beyond detection range, it still keep detecting it forever. If the target gets destroyed getDetectedTargets, it gets fixed and it doesn't keep detecting it.