Giskvoosk

I'm aware of the anecdote however i cant verify if its merely software/connectivity compatibility or a hardware compatibility expanded to the rail. I suspect its the former. It could make less sense if Dassault developed a different rail for Spanish when the indigenous magic rail, which is mounted on wing tip almost exclusively in French service, is already compatible with sidewinders. After all, its the CE version that we have in game, a correct sidewinder rail would be more appropriate in this case. J is included relatively recently in the game, around March or April this year. Its teeny tiny a bit short of 3m, meets the open source info. P has been modelled ~2.78 which IRL should be 3m also...? But it depends on the rocket/propellent types im not sure how it varies.

It's a normal map error and here's a quick fix: adding the following 2 lines to the customized cockpit will address the issue

↑as the title suggests Several noticeable parts suffer jaggies such as in gear wells, gear structs, speed brake interiors, vanilla type ejection seat. affected parts highlighted in magenta: affected parts/objects, channels, and names of the respective texture files: Recommend checking other textures in case there's oversight in somewhere less noticeable as well.

I'm more concerned that the sidewinder rail doesn't seem to have been modelled at all. I did a quick image search on the internet, sidewinder and magic doesn't seem to share the same launch rail. I've yet been able to identify the exact types but they do have dissimilar geometry at least. The one on our in game model resembles magic rail more than the sidewinder's rail: Magic rails: Magic rail on left wing tip, sidewinder rail right for acmi pod or something alik Sidewinder rail:

More or less, it's offered in low vis scheme though. Name and default nation restriction is as shown to the right null

I'm not intended to be rude. It's not some angry rant from a "new DCS user", relatively newly registered as for this account yes however not so new into the game. I just want to point out its not "just dark", the texturing is objectively substandard and I already gave my reasoning, briefly but nonetheless. Detailed reasoning as follows: Metallic channel: In practice you should only assign metallic property to exposed metal parts: here for example the seat buckle, worn out painted parts, or some glass materials. Instead metal value is assigned to most parts of cockpit, including fabrics. And its not like Dassault was painting the cockpit in metallic paint for aesthetic reasons. And how the stitches on the fabric radar scope hood are metal? It completely blows my mind, metaphorically not figuratively. How it should be handled if you may ask? ED's work as example: The common approach is, DO NOT arbitrarily assign metal values to objects. And to be honest, nothing else post-LOMAC has been as-confusing as what's presented in this Mirage F1 here. Deficiency in details: For example the screws on sidewall. The screws are textures rather than 3d mesh, which is completely understandable as to save polygons (which is not the case i'll later explain). First of all, as common approach you model the screws in high poly mesh then later bake into lower ones. Here the devs were taking a short cut by texturing the screws directly, which is okay as long as it could be detailed enough (not so here). The key part being, just see how distorted they are, the projection is completely wrong. Once again they took a shortcut by painting directly from UV. It's amazing such an error in conspicuous area rolled into public release instead of being debugged earlier in the development. rivets on inconspicuous parts as well Poorly baked AO maps AO maps directly effect your shading, the blacker they are in grayscale, the darker it will be rendered, shadow-wise. Again using ED's work as standard. How it should be baked: How should not do: To the point im suspecting dev's were using curvature maps by mistake for the AO maps. ill-optimised 3d mesh The screw at the top of your trim hat: 400+ triangles You may also want to check other switches that have semi sphere, couple hundred tris each. Things should be optimized to improved performance are simply not done. These mistakes are easily avoidable, and some are rookie-level even. @Rudel_chw take my opinions above with a grain of salt. In terms of art quality, the mirage is off the standard. I'm not being condescending or over-dramatic here, overall this is easily THE worst since 2016 even including the MiG-21's at its release.

That is what would happen when you assign semi-metallic texture to most part of the cockpit including painted parts, which aren't supposed to be handled like this. A sign of lacking fundamental understanding of texturing from the devs. The combination of base color in black and metallic esque is what makes it dark. Furthermore the fact that AO maps aren't well baked either, only worsens the situation.

there's a indexing error in livery's script: there's not such file as miragef1tank_CT_F in the skin-specific folder, instead its in the texture pool. change the false i highlight below to true will fix the problem

The current extractor is not compatible with the latest iteration of .edm But you can always extract the necessary info for creating skin by reading the file with notepad/notepad++ or something alike

Well, because i was busy working on mine. Good luck with your project!

create one folder named default under Mirage-F1CE in the Liveries in your dcs profile folder put all updated textures in it and a corresponding description.lua updated: basic file structure as shown below, and the lua script i use in mine pick the lines to your liking description.lua

Yeah if only we have the aircraft specific chart. Unfortunately there's none fuel economy related charts in the -1 flight manual that can be found online (for free). Both cases i maxed out at S.L.

You are right its an engine-only spec. All things considered, how would compared the economy in practical use to the benchmark stats, higher or lower? I'd imagine if pressure loss is taken into account and lower thrust output is the result, the fuel flow derived from the specfuelcon should be lower(?) Unless the given specific fuel consumption neither does not reflect the status when engines are "on the wing".

Both full Mil and full A/B in the game, test condition being: standard day, jet spawned airborne, full internal fuel and no external pylon/loadout, whole flight under 1k ASL To drain the whole internal fuel load, it takes 1,745 seconds in Mil or 659 seconds in full A/B Deduced from the stats provided in Mission Editor, the internal fuel being 7,399 lb, the fuel consumption clocked 15,264 pph in Mil and 40,419 pph in full A/B However according to info from public domain, it should be 10,728 pph at Mil vs. 31,105 pph at A/B (presumably full power). That's nearly 150% and 130% of what's supposed to be. Ours even has 300~500 lb less thrust than the spec below, it should clock tiny bit less than this, negligible but still.

Either way i guess it wont be long before we can find out

that will make a better alternative although this part wasn't mentioned in Spud's latest video. Will have to rewind Redkite's tutorial once more before the release.

Seriously, please make the removal of radar glare shield a client option, rather than a mission maker's option.

As the title suggests, AIM-9 series P variants in particular are mounted approx. 12~13 centimeter forward in the game compared to real life counterparts. For P variants the quick fix would be adjusting mounting point 0.12m backward with attach_point_position Likewise for B variant its rocket nozzle is to align with the rail mounted formation light.

You are correct Flappie. Tested on one with 4x blu109 the 2k lb penetrator, again failed to knock down these buggers. Secondary attack might be improper wording from me. Here I was referring to using the explosion action offered by ME, rather than with aerial weaponry. Could be of a different mechanism; also not sure what unit of measurement does the volume variable use. Edit: Went again with the blu109 jdam, basically you'd have to land on wreckage's bullseye to have a slim chance to kill it. Killable but ridiculously buggy still.

As of now there're two issues with Tank 2 and Tank 3 under the Warehouses category of the static objects a) a disconnection between 1)what's represented visually 2)the log event and the actual destruction registration b) secondary attack is required no matter what absurd amount of explosive is used in the first run. The object seems to have 2 lives Test 1, Engaged with 65k/mk84/gbu24, all appear as dead visually and in the log, however still intact on f10 view Test 2, Set of with explosion action at the highest allowed value of 10000, and message to all action is set to be triggered once the tank is dead. Tested with all units under Warehouses category same symptom, appeared on log but no registration Test 3, 2 explosion each value set to 250, survived first and manage to register in second one. Destruction Test_2.miz Destruction Test_3.miz Please take a look into the issues, thanks!

The application of such capability was a direct result of 1987 some teenager piercing through soviet's air defense in a c172. The field mod was only received by those with boarder patrol role as a stop gap measure to intercept low altitude slow GA aircraft, a niche application rather than a general self defense capability by design for this airframe in cold war timeline. I'm content that for now it's not available in daily rotating missions. All missions on the server are of hypothetical scenario i know, but i'd still argue it needs justification case by case in those handful presence. For example in Mariana helicopter event i think for sure it's a nice-to-have; missions featuring gen 4 i'd say 50/50; in Arab-Israeli campaign i'd say no. Imagine Syrian operating Mi-24s that were supposed to be patrolling border in either Czechia or DDR, it is just weird.

No problem. Likewise thanks for the response

The muzzle noise on the HMG technical trucks doesn't offset in azimuth correctly as the turrets turn around. Tested with the vehicle engine off to eliminate interference: The following units suffer the same bug, note that other vehicles equipped with Caliber .50 such as Cobra and Hummer don't have similar symptoms.

Not exactly. In an ideal situation where both sides scramble jets from respective homebases soon as the bombers are on the scope, MiG-21 will manage to merge with the targets (coalt or above at M1.2+) prior than F-5 to just line up with bombers, by about half a minute or so. Clash will be inbetween bomber waypoint 2 and 3. That was what more or less happened last night, only the timing difference was greater, and was outnumbered by x3. Visual representation as follows, A 5-minute buffer should be bare minimum so as to send in escort flight. A reasonable 15 min buffer should allow scattered fighters over the map to RTB roadbase/homebase and proceed to BARCAP position. True! Especially with F1 it's been in 2 weeks™ status for a long while. I wish the arrival of two new airframes could spice up the missions. IKEA 24-7