Moonshine

Yeah especially fuel leaks from small arms should fix themselves due to self sealing fuel tanks but currently you lose fuel as quick as if half your plane was shot away under you. Rather frustrating in AG scenarios

It should automatically but didnt for me at times. Using the updater.exe always did it for me

I have the feeling they were not primarily made to be self lased, whats the point of letting it glide for miles when you still have to get within laser range of your own laser. Might as well drop it late then. would need to test a buddy lasing scenario (or with a JTAC) to see how it behaves edit: did some quick research online, have to correct my statement of its use case. made specifically for low level use, should not be affected by early lasing. Was an interesting read: https://www.globalsecurity.org/military/systems/munitions/gbu-24.htm

Go to the core installation folder -> bin -> and instead of launching the DCS.exe run the updater.exe, should then download the latest patch

Hm, maybe hot start does not have it already entered in DED, but if you choose Airstart, it should be already in.

Kneeboard is simulating the ground crew setting the code on the bombs. Pod needs to be fully running (right hardpoint power on), make sure thats the case. Maybe check if you have it equipped in the first place

To change the laser code on the kneeboard you need to have your jet cold (basically do it before you even start your startup-procedure) If you want a different code for a hot start jet, you might change it in the mission editor or as stated in the post below, shut down the engine. For the DED Page you need to be airborne to make changes to the Laser page. Codes in the DED page can not be changed on the ground

sounds like it might be related to the observations made in this bug report:

so, tried in SP and could not get it to wobble that much. multiple possible reasons for this: - AI doesnt defend hard enough and uses significantly less Chaff than players seem to do. maybe it would need to be tested in a LAN MP environment against something thats better than AI - Netcode might be a factor, however, if its Dsync, i cant explain the speed loss of the missile (as my tacview was taken from the server and not the locally saved one) However, as you can see in the track and the tacview of my SP test against Ace AI (i did hope they defend "best"), the amraam simply cant hit a target that just does a split-s or similar maneuvers, highest G load on the missile was 8.5G and radar lock was held throughout. (1st missile). i have no idea how a missile that can pull a lot more G than that does not pull enough to actually intercept the target. Tacview-20220610-193219-DCS.zip.acmi Aim-120.trk

indeed. the question is not the functionality as you will explain to us in the white paper, more the performance of said functionality.

In the final stage of flight, the Amraam enters an unnatural wobble, causing it to lose lots of speed and adds to the probability of a miss. sadly only a tacview, the track is way too large from a MP server. however i was spectating these m issiles (f6 camera) and it looked exactly like the tacview shows, especially the first one. if you are watching the tacview, focus on the red Aim 120s, the first one already in the air. Amraam_wobble.zip.acmi

thanks for the quick reply! is it normal that the ambiguous symbology is overlayed over the red one as shown towards the end of my track? focus on the altitude numbers for example

So i did test the FCR Symbology "fix" as mentioned in todays patch. Mission Scenario: Friendly AWACS present 2 Groups of Bandits Now upon locking a clearly as hostile identified aircraft the symbology changes to yellow instead of filled out red with the "Bug" Circle around it. shouldnt it appear as Hostile with the bug circle around it? also it does look like the yellow symbology is overlayed over the red one, you can see that as i change the DTT priority target. Track attached FCR_Symbology..trk

Yup it’s ridiculous. by now i hope ED has enough tracks and videos provided by a lot of people showcasing this issue and hope for a rather quick fix to this.

looks like you describe what has been reported over multiple bug reports already, most notably this one:

LADD stands for Low Altitude Drogue Delivery; an air bombing mode designed for the delivery of retarded activation, airburst weapons. - not implemented yet. the options to the CNTL page were added in the update prior to the one yesterday. i think there is a video form Wags about it too that briefly explains the use of it.

true as well. but even zulu time isnt correct after a cold start WITH GPS, see my tracks earlier in this post.

yeah, only referring to DCS as i know how it should be sorry for the misunderstanding

Still does not explain why the clock wont set itself to actual GPS time with GPS turned on and it showing up as GPS on the time page

that is true, however, with the GPS turned on and the MMC turned on, time should automatically sync to GPS time with no input needed from the pilot cant publish the source here, but NL did not react to the DM i sent him yet. (probably too much in his inbox)

Any news on this?

Syria is Zulu +3, that matches your description of 15.00 instead of 18.00. times are not wrong on hotstarts. and thats just the viper using Zulu time instead of local but thats correct as is. However, if GPS time would actually be working and syncing, it would probably be like the hornet or hog. or at the very least show the correct Zulu time in sync

Yeah but take into account that the DED displays Zulu time and not local. So you have to calculate timezone deviation. Which after a cold start depending on how quick you are will be a difference in time of a couple seconds, maybe minutes if you take into account the difference between Zulu and local. the hour will be different, yet the minutes and seconds should be the same. on the marianas map Zulu to local is about +12h, so instead of 18.00 your plane shows 06.00. but after a finished cold start, mission time might be 18.05 and you jet will be at 06.02z or something. and thats the issue Added track to demonstrate In hot starts the time is synced as you get instant power on the jet when you start the mission. not so during cold start. you lose those seconds until the engine is running or ground power is connected, until then the watch does not tick and will not sync at all despite GPS turned on. also the mission date is in 2016, so GPS is available F-16_GPS-Time_not_sync_3.trk

found some things in some documents, sent a dm to @NineLine as i do not know if i can publicly post this here.

Even then, cold start with gps as time source will not synchronize the times as of now, without de-selecting gps time beforehand and thats the subject matter