pcoud

Hi, although this thread has been tagged as "solved", may I ask if the above statement from Q3ark ("I don’t think you can disable the new dynamic reflections"), has been confirmed by ED ? I always had canopy reflections set to none in the F18\special tab, and never had them in game, but I have got them now and cannot disable them (though I'd like to). I think (but not 100% sure) that this is since last update.

Many thx @hsth, there was just no such file in my DCS\Config so far

Hi @Flappie, currently going through your list: Disable track recordings by adding this line to your autoexc.cfg: disable_write_track = true but can't find any autoexc.cfg anywhere ? Thx

What do you mean by "it doesn't work" ? The code "don't care what it is doing here..." is not executing ? You are testing Group.getByName(u). Group.getByName(u) will return the object group IF this group actually exists, or (I think, but to be confirmed) nil if it doesn't. Are you sure the group exist when the check is made ? It may be that your code is run before you click on "fly" and therefore executes before you, as a human player, have actually spawned (happened to me numerous times)

I just found this more than 4 years old post on the topic of SAM rearm logic and time. I am very interested in that subject at the moment, and have a few additional questions: 1) Does anyone know if what @Grimesexplained here above is still up to date ? (maybe @Grimes ? ) 2) DCS manual states (p316): "Upon exhausting all their ammunition, ground units, such as air defense systems, missile defense systems, self-propelled guns, infantry fighting vehicles and tanks, may all have their ammunition stores be replenished using supply vehicles." After some testing, it doesn't look like "Upon exhausting all their ammunition" is correct. For example, I made a test with one SA-11 launcher (4 missiles), made it fire 2 of its missiles (so, 2 were left), waited for some time and could watch it replenish to 3 then 4. So, is it "Upon exhausting all their ammunition" or "As soon as they are no longer at ammo max" ? 3) Is there any way (through scripting) to know WHEN a launcher is starting its rearm process ? Thx

Yes they are (i would actually like an option giving one waypoint only, in the area where the targets are, so that you have at least to make the effort to find and designate the targets with your ATFLIR, but as it is now, you have precise waypoints on each and every target of your strike).

Got it, thanks for your help !

Many thanks. Actually, I now don't understand why you say an aspect of it is bugged (?). You said that getTarget wasn't returning anything (for a harm in PB mode). Now you say "Weapon.getTarget never changes once it does start acquiring a target". I don't get that last statement: what should be the correct behaviour? And why would getTarget change once it acquired a target? Also: I am not sure I understand: what exactly did you get to occur with the HARM in PB in F-18?

Hi @Grimes, @NineLine, I am sorry, I just noticed your replies. @Grimes: 1- My mistake, I am using the assert(bla bla) when I'm testing, I forgot to join the actual script when I sent the tracks. 2- You are absolutely right. I have made additionnal tests and I confirm what you said: the event.shot is triggered by a harm in PB mode. You also made me understand why I did not see it before. It is because the event.shot was only triggered when a certain target was shot at (I am using the Moose event handlers and subscription system and I had something like: EW_radars:HandleEvent (EVENTS.Shot) function EW_radars:OnEventShot (EventData) etc.. But EW_radars being a target and a harm fired in PB mode not "generating" a target, the event was not captured by this handler. I have made a "generic" handler (not through an object subscription, but capturing ALL events, as you said), and it works. 3- I think it makes sense that getTarget does not work in that case. A harm fired in PB mode does not have a target, it is fired towards coordinates where the target is roughly supposed to be, then search for its actual target in flight. My apologies to NineLine for the fake bug. My thanks to Grimes: I think I would have had a hard time figuring this out without your insight.

See attached tracks. I am running a short script that detects fired missiles at an ennemy EWR and shuts down said EWR. Detection is based on the event_shot event. Track1: I fire my HARM in TOO mode: a message appears proving detection and EWR going dark Track2: I fire my HARM in PB mode: nothing happens. Shortly after I fire another HARM in TOO: it is detected (message appears) 100% reproduceable. HARMs fired in SP mode are also detected. Only those fired in PB do not trigger the event_shot event. pb no event shot1.trk pb no event shot2.trk

Many thanks @Grimes If that works, that'd be an easy countermeasure, I'll test it tonight. In the meantime I'll forward all this to the Liberation GitHub dev team.

Thanks for the answer @Grimes. I hadn't checked the mission file, and what you are pointing out explains what I'm seeing. But then, the question remains: where does this 123Mhz come from? The mission lines you copied hereabove are from the Wallaby group, but in the mission editor, for both units of the Wallaby group here is what you see: Comm 1 channel 1 is 119 Mhz, so how does it become 123Mhz once in the mission file ? (maybe a bug when Liberation generates the file?) Also, I am sorry to ask again, but do you know what checking or unchecking the "RADIO" checkbox in the ME does ? (can't find an answer)

We're a group of friends playing in multiplayer on the stable version and exclusively flying the Hornet. In the Hornet, as soon as you switch the battery switch to "on" (cold start), your comm1 channel1 radio is active. So we've taken this habit, everytime we fly: we jump in our aircraft (cold), we switch battery "on", and immediately perform the radio checks within our own package (we use comm1 / chnl1 as our intra flight frequency), and awaits our leader's orders. But lately we are having issues. In the attached mission are 4 client packages (if you want to quickly find them, check "planes", country: France in the ME's unit list) -Truman BARCAP (3 aircrafts): within the mission editor, you can see that it's comm1 channel1 frequency is set to be 120Mhz -FROG SEAD (2 aircrafts): 118 Mhz -PIKE STRIKE: 123 Mhz -WALLABY: 119 MhZ But once in the plane, most of these comm1/chnl1 frequencies don't match what was set in the editor. The frequency is not even the same within the same group (ie the leader's frequency and its wingman's are different). It's very reproduceable (at least for me). Open the mission in the ME, check by yourself the assigned frequencies to the 4 client packages, then launch the mission, either from within the ME or not, choose a slot and note what's the comm1/chnl1 frequency (if you have SRS up and running, the test will be very quick: as soon as you switch battery ON you'll see the comm1/chnl1 frequency on the SRS overlay. Ifyou don't have SRS you'll have at least to start the right engine to check the value of comm1/chnl1). Do that for all clients aircrafts and see all inconsistencies. IMPORTANT NOTE: the attached .miz was generated by Liberation, so maybe the issue lies there (I have filed a bug report on the Liberation GitHub), but I am still a bit surprised that what is in the actual plane does not match what was in the ME (?) Also, investigating on the above, I realized I had no clue what the herebelow "RADIO" checkbox was for ? What is the purpose of checking or unchecking this checkbox? Thx ! radio_test.miz

What is the purpose of checking or unchecking the "RADIO" checkbox in the airplane group panel? Thx

@Goliathus I fly the F/A18C in Liberation and had the exact same issue and frustration as you. It's just plain impossible (for me) to fight those 31s. The only (not very honourable) way for me to solve the issue was to create a custom "Russia light" faction where I simply removed the mig31s At least, the fun is back...