RAZBAM_ELMO

Alright, I have moved this back as there is some clarification here as I misunderstood the team and they were able to clarify it. I was under the impression that all the graphical errors were due in part to the external model. Not so. The Gun pod is a 3D model attached to a 3D model ( woooah man your trippin me out), therefore its position can be changed and has been addressed internally. The avionics bay issue was resolved back in early December. The weapons sitting high however is lua based and a separate report has been added for that and will be changed. The future development still is true for the external features of the harrier such as the canopy fram and vents as well as not mentioned is the engine inlet being an incorrect shape. However this will take development time which is currently needed elsewhere but willl be addressed later. This is my screw up and I apologize. For everyones sanity and to keep this thread clean, I will be locking this thread and this thread ONLY. Just incase someone tries to pull the ol' you said youd never censor". True I did say that, however in this circumstance it is for the better to make sure the thread doesn't get overridden and stuff buried. So again I apologize for that and I will keep this updated as things are fixed.

Well besides the snarkyness there bucko, I dont think that a Harrier should reach M1.6, my question was why would you. Thats all I was asking. How was someone think gosh this is really fast for a Harrier....and then keep going lol. Its a very odd instance because in its normal flight parameters, our SME and the pilots in their squadron who have flown our Harrier say that its better than the sims they have.

Did you by chance only have the lights set to DIM and not birght? Just cause I flew on GAW the other night in full darkness no moon light and even at dim the lights were quite bright

I've been told that down the road there are some minor graphical changes coming which will require a whole rework of the 3D model to correct some discrepancies and skins. Marking AS INTENDED for now but should this persist in the next model iteration then we will re-evaluate. Moving to RESOLVED

Should be fixed from previous OB patch. Marking as RESOLVED and moving to RESOLVED. Further lighting enhancements will continue . ED has changed the logic from a linear calculation to a curve which threw that curveball our way.

So I'm going to move this to the main Mirage subforum and see if this can be confirmed and grow some traction. From what I know, DCS doesn't use active radio communications like SRS for example and therefore the indicator with the radio call coming in would be impossible as we dont have an argument for that. It would onlu work if we tied it the the UHF/ VuHF button that would be player controlled. FWIW we are just as limited as to what we can display with the radios as we are with the IFF.

With an extra sensor, it is difficult as syncro can cause somethings to appear where others are not. This is a DCS wide issue. What matters is that should the player have D2M installed it works., which it does. Marking AS INTENDED and moving to RESOLVED

Marking as RESOVED and moving to RESOLVED

Understand bug has been resolved but when INS is off, heading tape should still be present showing magnetic.

Marking as RESOLVED and moving to RESOLVED

Tracking.

Bump, tracking.

Bump, tracking.

Ok so I've merged the Fuel amount bug on the ground and the refueling bug after dropped tanks bugs together as it appears that they are inter connected. So to preface, how the fuel amount works right now is automatic. In the real jet, on the fuel panel, the left fuel display shows internal fuel, the right display shows internal PLUS external. The aircraft does not know the quantity but only knows when the external tanks are empty, it predicts the amount of fuel left by using the fuel flow to the engine. ( similar to the MiG-21 where the fuel usage is predicted and not actual. Normally, in the real jet, you would have to manually set the added external fuel load to the jet onto the fuel display. For ease of use we have implemented an automatic feature which takes that out of the equation for the end user. HOWEVER, for instance if you move on rearming, the rearming window has told the mirage that it will take X amount of external fuel before the tanks have been loaded ( as per the automatic feature). When it comes to refueling ( ideally you would never ever dump your fuel tanks IRL but this is a DCS ism habit players should break.) the Tanker sees what the maximum fuel load should be according to the automatic feature and attempts to give you that amount of fuel even if you have jettisoned your tanks. So there's a two for one and why those issues are occurring. There is not an easy fix for this as the entire fuel logic would have to be re-written and at that point it would most likely not be worth the dev cost to do so. If we were to do it, we could potentially change it to a manual system in which case if you were to re-fuel with tanks, you would have to manually calculate the amount of fuel you are adding and input it manually. For the time being, I will mark this AS INTENDED as any future implementation of the manual setting would be subject to whether the input outweighs the output. Perhaps when and if we do another M2K model we will take this into account and carry it over to the 2K C.

K, ive had this explained in detail and let me check to see if I have this right. We enter in X ft into the ft display. That value is converted to meters but displays in the ft display. That coverted value from ft to meters is then read as feet and converted to meters again which is displayed in the meters display. For eg. We enter in say 1000ft which gives us a converted meters value of 305. Then if we convert 305 ft it gives us 93 meters which is displayed in the meters display. The bug only affects the display, the sytem reads the original value of 1000ft correctly.

Weapon limitations adjusted in previous patch. No longer able to mix loadouts. Marking as RESOLVED and moving to RESOLVED

As it stands, it is difficult to say whether te radar can even lock on a jamming target, and further, if given an estimated range, if it can perform a burn through on a jamming target. I will present this to the SME and see if he can clarify.

Marking AS INTENDED and moving to RESOLVED

Some file types recently encrypted by ED. Our current library is correct. Marking AS INTENDED and moving to RESOLVED

Known graphical issue with current ED shaders on other modules as well. Marking AS INTENDED and moving to RESOLVED

Bump, confirmed closer speed is negative in PID whereas it is positive in PIC

Behavior of the CCRP cue is AS INTEDED. Moving to RESOLVED

All lights were adjusted after latest OB patch. ED switched from a linear to a curved solution for lighting. Marking as RESOLVED and moving to RESOLVED

Conferring with SME. However we might not know exactly what the CM consumption is or be allowed to have the correct value added due to ECM amd CM systems still being CLASSIFED. Will report back.

Are we ensuring that there is no drift occuring? Also, the DCS engine likes to round coordinates even in other modules so while you might input correct positions they may be rounded. If that is the case then this may be a totally separate issue entirely.