rogorogo

well.. that would be quite far beyond beyond the scope and confies of what I was pointing out - but intriguing nonetheless. So while I simply stated "you should not be able to close the door with seals inflated without something breaking.. and vice versa to a lesser gradient" - your suggestion of course would be something to wish for - but with how the product provide is and what methodology and practices it applies (or not) going forward. This is as likely to happen as world peace. Too much would have to change, and the prerequisites or rather backlogs are too mountainous for it too happen. Nonetheless a few thoughts: ABC (NATO, PfP, non-alligned) or NBC (US) would likely be confined to BC. There is a reason the Nuke is not modelled with DCS AI and not with the Mig-21 and while there may have been well less in thought and more in engine confines behind the notion back then this accidentally was a very sensible choice (as with most things DCS, what is +++ is purely accidental without prior cognition) If either BC topics were to be implemented as placeable AO zones or deployable munitions (resulting in zones by player agency) this would require attention to PvA or PvP topics at least, something the product provider has not only failed to do and abysmally failed in (on levels far beyond and far more fundamental thant most product consumers would think and/or understand) but actively dismissed for how long now.. 15 years? employment of any related mechanic would indeed be very interesting - but the question remains if the player/flightsimmer cooperation and interaction would be there, moreso since what servers there are are run by community members.. and most of them, especially the most "populated" ones and their runners (and population) are.... well.. let us leave it at that.. technically the prerequiste would be so introduce industry standards in many aspects instead of proprietary, first core only, permanently clientside waypointed assets - background dormancy, multi-core, authoritative services would be required to make this actually work - imho ofc but still... But in the end, sure this would be interesting. Very interesting. This is - supposed to be - a simulator after all, right, Right?

next orbat for REDfor - weaponize a ZIL-4104... Also.. as someone who was there in the AO, 10 clicks north, and we were outnumbered.. 4:1? - this is MVP status forever, your callsign from now on should be "THATsplash 1-1" And while of course we normally try to not kamikaze on things (which in A2G does not work anyway) - despite me not so lately getting rammed by a lot of things that then also disconnect or not... this one is not only valid and within the scope but also shows the potential of CA assets and that ground assets are not a shooting gallery when under human control, enriching the experience and making cognitive involvment necessary for the rotary loop.

I think I may have failed to eradicate ambiguity for what the report is about, despite trying to be extensive for the sake of clarity. When the seals are inflated before or after opening both the door and the canopy they expand beyond the targeted size. And even if they did not closing the door and the canopy would either mechanically not be possible at all or result in damage to the seals at the least. This currently is not the case - and applies to mechanics, not situational needs. Again, I was just typing about mechanics and physics for that contributing part of "hermetization" as it is currently represented (or not) in the module and may be bugged (or not), planned (or not), not yet implemented - not hermetization (which it is not btw, it is slight overpressure.. nothing else..) and the contributing systems themselves.

The very same collection of assets in the very same area under the very same circumstances will render correctly standing or moving just 150m away from each other. This has been paid attention to for over a year, yet no corelation has emerged in subjective and chaotic (statistical sense) observation and sampling. It seems to arbitrarily and randomly happen with any asset placed in some areas - which is especially disturbing when those assets are basically parked in the middle of an open plain, no a Wadi, divet, gulp, valley, vegetation or placed directly on a road. This blocks reproduction on a downsized track but also points to a more systemic bug that has nothing to do with the assets, the map module (per se but it still applies to PG solely by occurence in observation thus far). The terrain features and the mesh surface category the asset stand on or traverse over seems to not cause the issue. Attached are two exemplary tracks with non-engineered exemplary bug occurence as per DCS open beta 2.7.9.18080, comments provided. track "tank_convoys" map grid CS50, position , throughout the entire track when player asset (Shaitan-Arba) approaches the two tank convoys at different angels and different vectors. Notice how the eastern convoy will render late at point blank (when SR SAMs would long have been in range fe), despite both convoys being on a road surface, throughout the entire track - while the western convoys renders normally, as expected in the same area on the same surface in the same asset composition and same asset state https://drive.google.com/file/d/1ouiVgAR3IkzyW9snRnhPaqa74jwTA_E1/view?usp=sharing track "AAA_groups" map grid DR 79, NE, position , throughout the entire track track when player asset (Shaitan-Arba) approaches the aa groups at different angels and different vectors. Both groups or one of the groups and later placed assets in the open plain render late or point blank, while other assets further away render as expected. Placed assets on the eastern side of the AO (BLUE FARP EAST area) map show the same bug randomly on the high NE plains througout the track, while the entir lower east plains (FARP urban area) with the same surface show normal behaviour https://drive.google.com/file/d/1osJYb-IBYW54tSxCtYuc3r3kyLSrgadG/view?usp=sharing The current even more intense unreliablity of trackfiles as a means of reproduction (system divergences in reproduction of events) has to be taken into account. What can be observed to HAVE NO CORRELATION (beyond the exemplary tracks provided): terrain features (plains, valleys, wadis, slopes, urban, country) terrain surface (grassed, humid, dry, rock, sand, concrete, road, urban, shrubs, palms, vegetation) asset (type, faction, composition, state, category) movement state (parked, movement speed) LOS altitude (low, medium high) - IMPORTANT, initially thought that LOW-ALT, rotary sandmowing was correlating but this is NOT the case! client settings (checked with other reliable players on diverging systems in instance) player module and category (fixed wing, rotary, CA ground asset!!!, checked with other reliable players on diverging systems in instance) fps, RAM, GPU capabilities, CPU timer dynamic weather static weather weatjer conditions set (static) or scope (dyanamic) This bug is systemic but also puzzling as it may be narrowed down to some sort of trigger combination for the bug - but this is beyond what can be expected from a player/product consumer. What can be observed: assets are NOT sunken into the ground assets "pop-render" appear assets have proper behaviour (fe engage with main guns, coax, ballistic aa, launch SR, MR, LR SAMs, trigger movement if AI is set to do so) munitions launched from vanished assets can also be invisible, launch transistions might or might not appear As this is a combat simulator product the bug itself is severe nonetheless, especially for assets and eras where LOS, VFR, visual canning are dictating the engagement envelope for A2G. Exemplary tracks provided, engineered trigger track not possible, dxdiag irrelevant as bug occurrence is on low-average-median-high-highend systems at all settings noticeable with both Nvidia and AMD chipsets, both Intel and and AMD CPUs.

The Mi-24 inflates the door seals after the cockpit door (Pilot Commander Cockpit) and the canopy (Pilot Operator Cockpit) are closed to aid with rudimentary ABC (well BC actually) protection of the assault helicopter crew. Depending on the operator the label might be placed differently but the process is always to open the pressure valve by turning the corresponding valve knob (which literally is the valve) counter-clockwise top open, and clockwise to close. A status light is also available (Doors sealed/hermetization) - although that is slightly miselading (how global in military logic.. we should take that as a hint to unite as a species and find someone else to throw sticks 'n stones at each other with) .. as the cabin is never hermetized (see below). When the seals are inflated, they press against the door, and while opening it is still possible (for very good reasons) but not advizable (seal damage) and reserved to emergency procedure context , closing the door and canopy is not or not without inevitably either doing damage to the door/canopy or more likely the rubber seals (which by then would be oversized and overstretched due to the lack of a surface to press against. But in the module the seal inflation and hermetization state (which also includes the air condition running the cabin at slight overpressure - the cabin in not pressurized but run at light overpressure like fe IFVs an MBTs do) seem to make no difference. One can close the door / canopy with seals inflated. The cabin overpressure can be safely ignored as it makes no difference to door and canopy procedures. One can also open/close the door canopy with seals inflated repeatedly without any damage state or malfunction in the pressure line, seals, door, canopy. This does not apply to the passenger compartment door/hatch iirc, As we as consumers cannot tell what the planned endstate is, this might or might not need attention (low priority, bottom end of the PM tools, lists, open office calc files). I cannot tell if there is a boolean state-chain planned, or any further audio-engineering, Petrovic lines, anything.. but at the moment, this seems like insular animations and state-sounds with no crossreference or logic-chain/statecheck requisites. Again, this is an absolutely minor issue in this state but and issue is an issue, thus an attempt was made to feed this into the... "bug tracker". No trackfile needed, permanent issues, applies to SP and MP, reproducable on all systems and settings.

This a bug report for a specific module as noted with this module. In the absence of a standard bug reporting tool most products in this industry and this segment of the industry and even 3rd party providers within this very franchise with the most meager of resources mangage to offer this bug report was placed in the correct place as defined by the module provider in question. If there were similar issues with other modules of the same or different asset-categorization the corresponding reports could be cross-referenced in front-office or merged in backoffice. The same goes if there were fundamental or foundation level bugs for the underlying suite. Unfortunately this is not the case - to the contrary the product provider has even actively dismissed more systemic reports up to re-enacting events normally found in an Ian M. Banks novel and quite aggressively decreed beyond any ambiguity to only report strictly within the scope of a module and limited to whatever is on-the-nose. How... confusing. Or maybe quod erat demonstrandum in expectuu sine qua non est casu exemplii pars pro toto.

It is Eagle Dynamics's world - we are just here to get whiplash from smh... (yes, I know.. this still needs work.. but every bonmot has to start somwhere.. right.. RIGHT? )

@Alpenwolf & @rossmum - can confirm, "Into the Desert", RED MilBase, for Shaitan-Arbas no AAMs, no ATGMSs, but UB Dumbfire Rocket Pods (HE, AP only, not HEAT,AP) in limited numbers. Probably nothing more serious than a typo or a warehouse issue.

because it is... that the complete lack of global standardization not only on cohesive design outlines in the franchise and the information and whitebox starvation of 3rd party module providers in general and on an arbitrary and preferential, everchanging approach in particular exists does not change the assertion of the fact. It just contributes to the general assymetry, or chaos, or coherence fissures, or lack of cohesion in the co-viability of suitable assets in the AO, you can call it whatever you want. Also the reflections themselves actually are highly settings and situationally dependent - so that alone mitigates them actually when taking the reality of how most of the product users "play" this "game" into account. So just do not bother, at some point this will be suitably fixed by the module provider (they always do, despite their meager ressources, despite the challenges they have to overcome) at least on a module inside-out level. And btw. reflections happen, always.. in all assets of all generations to this day IRL, and this one as well, anyone trying to ex-post fakevalidate anything else is someone with preferences or a narrative or an agenda at worst, or just a lack of familiarity with the topic or bereft of understanding the wider systemic impacts at best (and we shall assume the best and give the benefit of the doubt).

When landed on a random terrain surface or a terrain pad area, grass will clip through the airframe in both cockpits (the rear passenger compartemt has no position and only a blurry inner render model, so no assumption can be made for this compartment). While I do not know if this is intended or not, the grass does react to rotary module in some way (movement, proximity trigger of a "dust blowout"), so this should be paid attention to by collision or other means (down the line, low priority as purely cosmetic). random example (Caucasus terrain), pilot-cmdr cockpit with cyclic and seat hidden for better visibility of the clip-through: no trackfile needed, as reproducable with any grass surface and occurrence is permanent, for any systems (unless grass removed via DCS settings)

well.. then the usual full list: go to control and check if keybinds are still there (DCS patches like to wipe some here and there) check in controls if keybinds still work and rebind them to the same keys or different ones if they do no (DCS patches like to do that here and there) and in general be conscious that jets of this generation are often flown in neutral time by using the alt-hold or SAU APs (AP on, wait until the plane retrimmed itself, AP off - all in level flight) instead of the actual trim

The black flicker still happens even with "just headtracking", no matter if DCS is running windowed, windowed fullscreen or fullscreen. There seems to be some bugtrigger identifyable as well as a rather clear bug behaviour: The bug seems to be altitude related (happens mostly at the when the map seemlingly state-switches into its last ground-LOD) The bug always occurs on "the left eye" (no matter if in VR or screen headtracking), the size of the black flicker may vary from a square to half a screen to (almost) full screen, but it has always its source on the "left side" Turning the view vector "to the right" (turning head right) makes the flicker disappear while zeroing the view vector (looking forward) makes it reappear, turning "to the left" (turning head left) intensifies the flicker going to higher altitude (into a different LOD state of the map) seems to make the flicker disappear completely the flicker seems to appear if there are more scenery buildings present in the view cone and of a certain generation,. Example, bug less likely in/over Caucasus cities, higher occurence in/over Persian Gulf cities but not/less likely/lower occurence in/over Syria cities (Marianas not enough flighttime to be able to indicate any possible corelation) As the Mi-24 module is the latest module operating at these low altitudes and has a far more contemporary standard than fe the Gazelle, Hip, Huey the bug might not actually be completely module-insular but maybe expose an issue in a different part of the DCS product. Thus debugging effort might want to look into the combination Hind/PG (occurence not related to high polygon Dubai buildings but random cities with low polgyoncount buildings) as a trigger scenario to create logs. There is also imo nothing that could be done "playerside" to "fix" anything - refering to the OP of this thread or solutions that do minmize occurence in perception like this one:

please extrapolate - how exactly "does not work" manifest?

that might not have made it into the update, screenshot from yesterday:

welcome to the wonderfull world of acronyms and especially confusing everchanging official DCS acronyms. As stated before: FM - Flight Model, general industry term encompassing the code concept of a title how to represent "flight" (player asset, AI, NPC, environmental) in the product GFM - General Flight Model, DCS specific term that is supposed to mean "a general and global ruleset all flight assets operate in"... while intriguing.. also as likely as world peace additional things you should be aware of SFM - Standard Flight Model, discontinued (or so they say, whoever "they" are), comes from Lock On: Modern Air Combat and represents an older way of doing flight modeling on PC flight sims. Its data driven and has scripted elements to it. For example, in the older versions of aircraft using the SFM you could perform a ‘cobra maneuver’ by button press. AFM - Advanced Flight Model, should actually read "Arcade", originally gestated for FC3 assets, still present in one last FC asset (F-15C). Officially once described as going with a more physics based model simulating actual forces on aircraft surfaces to achieve a realistic feeling of flight. Fewer or no scripted elements are a part of this flight model. Hydraulics and fuel system modeling comprise a AFM+ setup. PFM - Professional Flight Model, more fidelic, proper physics-adherent. Gestated for full fidelity modules, later also applied to almost all old FC3 modules (save for the F-15C). Feels better, is better but unfortunately and contrary to popular belief is NOT standardized at all, not even within a module provider. This can and does cause unforseen issues with tiresome regularity. Finally started down the road of a few years ago and has been slowly, arbitrarily and non-cohesively been updating aircraft to support this level of detail. Realistic simulation of nearly all elements of aircraft including its construction (such as the individual elements of a landing gear system, its hydraulics, etc.), flight surfaces, wind tunnel testing, and other data are all fed into the system, née grid components, inheritance and interdependece in meshes, grids, textures, action maps, bleed and overbleed states. I’m sure I’m not doing the complexity of this justice but nonetheless its a very high level of detail - if only if only it and many other things were actually standardized franchise-wide. EFM - External Flight Model, whatever modding does to a base asset when used to create a mod representing an entirely different asset. No one actually knows what it is supposed to mean but everyone and his/her grandparents have started to use that label. It may be intended to mean something entirely different but no one knows, no one will dare ask and frankly few dare care anymore because that is what autism-level paying customer interaction by a product provider results in. If your head by now has not gone booooom - welcome to DCS, enjoy your everlasting and neverending journey in discovery of wonders. It is Eagle Dynamics' world, we just go ever so slightly bonkers in it...

While I am in no position to raise my voice there are nonetheless some things coming to mind I would like to submit for additional consideration. As recently stated the serverrunners and admins stress that real life comes first and the Cold War Server is a hobby - an extremely healthy and for the fidelic topic almost solely suitable motivation. Nonetheless from my outside point of view the seeming lack of a structured, ansynchronous colaboration space (fe asana.com ) to apply time and energy when available and being able to track items in a structured fashions seems to have caused additional nuisance (or simply waste of precious free time and energy) detracting from bringing things forward or simply maintenance. Same goes for the humurous mirror of core Eagle in there being no structured channel to submit issues. Now if there was an official discord to be gestated (social media, oh dear..., and before giving away UCIDs, there is a discord script where players can add a randomly discord-generated unique ID to add on their profile page that then fully automated greenlights them for rights and adds roles an even ensure their local discord name matches up with their profile moniker [in the absence of the ingame moniker being part of their profile information]) for whatever reason, maybe this could also solve these issues. A "Troubleshooting" channel could be added and I know of a discord script that automatically generates a ticket-thread in the channel (by type command like fe "-new" or "-create" or "-ticket", with the channel still being available for normal exchanges), only visible to the submitting ID and the "admins" (or roles/persons chose) unless set otherwise for reasons of wider information submission fe. These threads can then be used to track both issues submitted and simply generated internally, with the threads being able to be added to and eventually closed when the issue is resolved or the time found to implement whatever their topic was. It would also encourage submissions as they are no longer subject to opinionation while structuring them in a rigid thus workable upcom channeling. This imho would solve the issue of asynced time, timezones and energy as well as availability while also solving the issue to mentally keep track or look up issues and to-dos in an unstructured fashion in multiple sources or this forum thread. The automation would not only raise the level of collaboration and reduce chaotic (in the technical terminology) maintenance allocation imo but free up time and energy that could be focused on the actual core tasks. As for discord itself the "threat" of further erosion to proper coms (in-game "voice chat", SRS - which btw might or might not be able to cross-integrate btw) for a "gamified" discord-voicing is naturally something that would also need carefull consideration. But again - I am in no position to raise (well, type actually) my voice (well, thoughts actually).. but reading this while just glancing for general news in eventuality had this spring to my mind.

after having paid attention to this before and especially after patch open.beta.2.7.9.18080 I would like to affirm this bug. As so often this imho is a cumulative bug without a singular source issue. While the module's DM is both WIP in rapid prototyping (and nothin beyond in practices) and in a very noticeable assyemtry some damage states might be in mispercpetion. That IFV have a hardcoded sniper AI always locking on the pilot is well known - but as there is no shattered perspex (well.. it is not perspex but I forgot what the material is actually called) inner or outer render model, no cockpit sparks or panel damage states, no pilot injury and death animation or overlay filters (while there is a simple red overlay filter if the pilot gets crushed/inured in a rollover) and the player is also allowed to keep looking around and notice cursor map state changes, just without interaction - this once again shows a baseline systemic bug that has not been adressed for many years and will not be for many more. But when a single rifle-caliber impact "plink" (rifle-caliber, as in infantry) result in either loss of both turbines complete loss of electrics (even when apu is started) pilot death (with the added flavour of see above) there is definitely a mesh/hitbox/surface glitch and/or anything from a typo to a wrong action.result chain present. For the latter another indication is that even a slight loss of power on one of the two turbines (with both turbine rpm, engine pressue and collective rpm very much still in the cruise threshold, and comfortably in its centroid) inevitably leads to an ever so slow descent and crash or at some pitch a sudden state.change into an uncontrolled RBS nose-up followed by an inevitable (and correct!) VRS crash. External views can be disregarded, there is no finished indication for anything - but then seemingly the same applies to instrument indication for most damage events. And - as stated above - the still complete absence of injury state indication for the player/pilot itself. So even variants of the bugged state by - for example - single cannon (20-30mm) by IFVs or ballistic AAA cannot be paid attention to - as still is the case with most missile (A2A, G2A, AAM, Manpad, SAM) impacts. For "sticks" the module mostly just evaporates. It does not blow up, it just evaporates in midair. And alternatively you crash while not actually showing any physical damage on the airframe (exception: collision meshes and damage states for main rotor blades, main rotor only, the tailrotor just goes missing and or the tail just breaks off). Not the end of the world, will surely ably change at some point - but should be taken notice of and maybe attempted to stay in more cohesive or at least coherent coresponding overall progress state. And while of course the argument "butbubbut it's early access... it's open beta...." could be brought forward (and will be done so as the usual pretense and cop-out) - no, that is not an excuse. That the product provider has made an open-beta TESTBED the de-facto release tree while the actual release tree has ZERO release schedule paired with early-access states that span years is a fallacy in itself and deserves being admonished. And before the usual Ian Banks excession event happens - in eventu conditionalis this will be pointed out wherever possible - act like adults (you know who you are), your actions define tonality, you create the echo you deserve as it will mirror your message outline (in median and centroid, the unsuitable outliers will always exist and should be disregarded if baseline cognition is present).

well, @rossmum, tradeoffs, a conscious choice of more munitions (pew pew) or have an asset that can be deployed in the AO - would not detriment to further layer gameplay loops (not that it would change anything for me, I tend to find something that evaporates me anyway, even if I fly a detour akin to sightseeing far away from the AO ). Also simply a question of numbers - the Mi-8s are not that plentifull in the skies to not be tasked with heavier loads the entire time.. and at least when I participated the two airframes tried to work together.. and an extra infantry-squad (that is either a jtac or at least has a single Igla in it) would have often helped a lot. I can't see that many headaches the Shaitan-Arba is causing... teamwork aka the spontaneous self-organization of chaotic system - while pleasant and suprisingly intense here and there - overall is not that nuanced that the usual swarm of Tigers would not be vectored on any Crocodile and Hip by someone in a CA JTac slot, or someone hopping into a Tiger from a JTac slot (something which in the end only Eagle could adress, like the ominiscient team-table, like the ominiscient role-table - and all of it is as likely to happen as is World Peace). It is also not really about "paratroopers" - the Hind is an assault helicopter - it in fact did (in its early iterations) more often than popculture has us all believe deploy squads in an AO via an LZ-drop (although technically the infantry deployed belonged to paratrooper regiments most of the time - red tape, literally in this case). So by that alone there is another tradeoff. And again - the Hips I encounter are overburdened all the time and some of them even raised the very issue on SRS (before all of us inevitably blew up midair ) In the end there is no right and wrong answer, no good and bad anything. It is a choice of the admins and the serverrunner, and either decision taken or not taken will be suitable in the overall picture. It is just something I - on my personal cellular level - keep noticing as missing. Especially since with the upcoming Apache (which is a D!) we will have another chopper flying around that will be made era-suitable (A++) by loadout, while still flying around with is post-era avionics, optics, system upgrades (like the AJS made AJ via pylon restrictions, which btw take the pylon wiring issue of the AJ/AJS not into account, not that I get to fail in my smoerebröd, as numbers do not really permit it, so I shall stay even more inept in it than in other modules...). But again, it is up to the admins that have to balance and take the overall picture into consideration, including the Tigers' wrong RWR array, the Fishbeds' overperforming radar (that underperforms for others due to once again core Eagle issues, not 3rd party module issues), the weird missile issues with the very same type performing differently with different modules, aso aso aso, all of it. A humongous task in which server-runners and admins are pretty much left abandoned by the product provider anyway. But the compartment is there, it may even receive proper inner render modeling at some time (the outer render already shows the benches fe), it was used, so why not use it (since the server is in the correct era on top), limited to a period correct, fidelic and suitable "haul"?

Well... as there were primary weapons missing, completely missing (no ATGMS, no AAMs, no gungpods, only S8 rockets), for everyone and from the beginning it may be that they do not work in this mission for some reason not matter on which faction side (aka on the red side not either, unless it is a warehouse count bug or a typo). If the admins (aka @Alpenwolfand @rossmum) find time for any additional tests and debugs (real life comes first!) - please could you also adjust the Petrovich-crosshair (aka the minimized one without the superfluous and unnecessary boxes clogging visibility). That was an extreme improvement where it was already implemented via serverside setting. And an unrelated question - is it too early to ask for the MI-24 to be allowed to carry and deploy infantry and/or a jtac-infantry squad?

can confirm @Alpenwolf & @rossmum swedish deluvery - RED FARP Shpora has no ATMGs, no AAMs, no pods. This seems very much not intentional but a bug. Hinds can't do anything on this mission until fixed, we tried several times to do something with mi8 deployed assets.. but between that, the sniper aI, how frag dmg is (not) modelled, the wip DM and the frankly bizare DM of FC3 assets and the myriad of other issues on ED would have influence over... it really is a little beyond impossible

since it may not have come to attention:

oh, well.. then I am sure many of us cannot wait You are literally a lifesaver for our eardrums in the loudest of times! Thank you for the fidelic mod and v3.0 in advance

Is the DL link updated and correct? - the files in the download and the readme are still the ones for the core tree reading "2.0". ( I read the instructions in the first post but maybe you should rename the user file or upload them under a different filename and URL to avoid confusion and to get rid of the "2.0" in the URL and filename)

Well.. I am aware of that (no naahhh ) - but luckily I - personally - only use IC-passing mods and only the bare necessity.. I have not opened my JSME in ages (maybe I even uninstalled it). It was just interest if anything noticeable might have changed to encourage a complete move to the profile folder structure for anyone doing anything. And while - of course - the use of JSME is advizable (especially for those dynamically switching between stable and o-b-- rumor has it that rare species is still not extinct... ), not everyone has to use it. Some might also be just overwhelmed by it. But that is always the case. So caveats should always be mentioned. Moreso since one day Eagle might, might finally introduce franchise wide standards and practices. At which point modding (which will never not be necessary for a multitude of reasons and/or preferences) might need to find a uniform, unified and universally accepted consensus. But - all that is as likely as world peace, thus we should be thankfull to those investing time into modding and not overthink it. Happy new Year fellow digital pilots - might the cloudrender be favourable upon your systems!

Thank you - that is what I suspected - but you clarified that beyond ambiguity. So again, thank you - you explained it very well! It is wise to try keep those mods undispersed and in one location, even it means having to re-install them after some patches -> aka in the core folder structure then. Lua seems to always cause more problems than it solves. And again thank you for the quick reply.