Pikey

Hi folks, I'm wondering if it's just me, out of all the displays in the JF-17 cockpit, and especially when looking at the fantastic visual filters added to the Targetting pod, there is something that really itches my teeth about the way the radar scope, and to an extent, the MFD's like the HSD in general "look and feel" that is detracting from a fantastic module overall. It's like the graphics are pure and unedited. They don't react to light or global illumination, they appear as if they are a direct image floating in the air, a bit, there is no glow or luminescence about them, they move a little too crisply and it doesn't feel in VR like I am looking at a display at some distance, more that I'm seeing an overlay of graphics via a helmet sight projection. It's very hard to describe and obviously I am talkign about my subjective experience, solely in VR. I could do comparison shots with "other modules" to demonstrate that feeling that the display is coming from behind some layer of glass or plastic, with, but I think folks either see it and it bothers them or they don't care and that's fine. But it bothers me because it detracts and sticks out from the feeling of much of the rest of the excellent art in the cockpit. Anyone feeling this or am I just affected by my own virus?! :)

Hi ED, I was drooling over your new models and textures for the latest additions, they are world class and you need to tell the folks responsible what a great job they did. If we think back to 1.2 days and those sprite infantry and some of the low quality ancient models from years gone by, we might say that the one thing ED have consistently upped their game on year on year are these new units. In fact, your team have pulled away and are leaving the rest of the game behind. I realise this area is of high cost and effort and almost no return, so seeing the "love" in these items makes their value so much higher and my appreciation so much more. I sat last night and watched the Ju88 torpedo run under fire and I felt all sorts of warm and fuzzy (desperately aching for a torpedo bomber one day). Please don't let the incredible art be wasted with a poor AI engine and damage modelling, you would let the artists down in their success. I've always maintained that DCS makes a fantastic film, or a fantastic aircraft sim, but the game, is a bit behind. ;) Keep rocking you guys!

So, I took time to respond to this as I found it interesting and whilst I agree that LDT is extremely helpful I wanted to add a different point of view that I've seen. This is also about balancing different requirements and objectives from the many different ways people view DCS mission creation. It's not about trying to correct and force my opinions over your valid experiences, though, it's about highlighting one of the key pitfalls that is so easily overlooked when one starts to gain more knowledge and experience. So please take the excited tone as passionate intellectual conversation on how others might view LDT rather than an obnoxious disagreement on your success! :) :) I believe this is the same position from which Sven setup the entry to MOOSE, that people want to go deep, learn how to write Lua eventually, or contribute to code updates and generally go into writing their own scripts from scratch. And I think it misses the larger audience and the people that need more help. A huge amount of people that i listened to, when coming to MOOSE, wanted to use it for very basic respawning, not learn Lua or even fully learn MOOSE. It's a critical failing of the introduction to scripting that they have to jump through so many hoops that are not absolutely required for what they need. In fact (I can't find it now) the GH landing page had three paths: Moose for Contributors, Moose for Developers and Moose for Users, each with a setup path. No one seems to read that and I can't find it so that has to be why! For some reason, people skipped that and went straight into setting up a development environment when they want to do something very basic, usually via the YT channel since that's the most popular medium for instruction. I think what I'm trying to achieve here is championing the dumbasses like myself. If I can do it, anyone can, sort of thing. It's the feeling that, when you meet MOOSE, you assumes everyone is a developer, they know more than you, they went to University and studied computing languages for three years and know all this already. But actually, Moose is for the common man, and that includes... you and you and you. I've seen folks plodding for hours through the LDT setups, getting hung up on LDT errors and getting frustrated and I ask them, "What are you trying to achieve" and many of them have said, 'I am following the videos', and after the 3rd 'why', they say, "I don't know, I just want to respawn a tank". And my heart just sinks. Isn't the primary focus of MOOSE about simplification? Enabling people that haven't a clue about scripting, to bypass the option of using confusing Lua and the SSE, and writing out tables by hand to get a simple few lines of copy and paste? SPAWN:New('tank'):Spawn() Copy and pasting examples is MOOSE's biggest strength, with the mission repsitory, I think anyway. Moose is being consumed by people with less and less care for doing anything complex or time consuming, I'm not saying people are becoming more stupid or trying less than last year, I'm saying that the success of MOOSE has brought people who wouldnt normally have ever thought of trying it, are not developers and not investing the time or effort or bringing any experience, and that success should be anticipated and catered for, because I love that MOOSE reached this far. This is where the majority of newcomers fall over, they look at some of these videos, and after 45minutes they just say, 'screw this, all I want to do is respawn the tanker'! If they actually got over that hurdle, saw some cool spawns, loaded RAT or whatever with minimum effort, they'd be inclined to keep going and maybe invest in setting up LDT properly because they were in positive balance of effort:reward. Or, they can choose not to, because, that's OK too! I'm not saying exclude LDT from your life, don't set it up, or it is worthless, far from it. What I'm saying is that a lot of the times, people don't know they don't need it for what they want to achieve. From my point of view, I didnt set out to learn how to write scripts in Lua, that part came whilst I wasn't watching. What I wanted to do was use MOOSE to make better missions. All it took was the bare minimum and reading through the Spawn docs a few times and trying each thing out and seeing what it did (and dynamic loading, but that is another story). I think Sven failed to anticipate that, from his almighty altitude of knowledge, of how little people give a damn about all that and the majority (that's an assumption) want "take-away scripting". Maybe it's my age or maybe my personal experience or maybe it's my professional Customer Service skills kicking in, or maybe it's because I loved serving beer when I was young, I dunno, I just think the ball was dropped badly from the outset and years later we are reeling from missed opportunites to get more people consuming Moose-burger fast food, and understand that many people just wanted simple, OKplzKthnxBai! :) Side point, NPP does Lua syntax ok enough for your early hello world stuff, I use it for reading scripts all the time, but even LDT with no config does syntax well with error checking, and I write on it but without intellisense. Thats a 5 min install. Asking myself after two years as an amateur hack in Lua: "What tools do I need, which ones save me the most time?" 1. A log parser (because you cannot guess errors and you have to help yourself correct mistakes as near to realtime as possible) 2. Dynamic loading of scripts (largest time saver ever, no miz restart) 3. Syntax checking (saves general typos which are saving reloads, but see above) 4. Good workflow, bookmarks, reading the docs, knowing where things are (everyone wants knowledge and experiences injected directly these days) 5. Intellisense (formatting, syntax, arguments, basically inline documentation rather than offline documentation) Some time back, when I didn't know where things were, 4 and 5 were reversed, but I couldnt give up my accumulated knowledge for Intellisense, because relying on LDT appears to be a risky proposition with the way it seems to work. I don't use any of it's advanced features, it's bloated, breaks, not user-friendly and the cause of many cries for help. But more importantly, most importantly, it's way in excess of what is needed for someone to write a few lines right at the start. Sure, go ahead once you wrote a few things and had some success, but let's leave the specific pain of LDT out of the general uptake of Moose/scripting Lua right at the start, because that's the meet and greet no one wants. If people want to progress beyond "Hello World" or SPAWN:New('tank'):Spawn() and then on to either become "handy with Lua" or "Handy with MOOSE", the door is then open and they can put more into the 'effort basket' to get more back. I just think the logical order for learning is to firstly have that instant gratification buzz, the quick win with dopamine shot, and then have the choice to dive deeper and do more. People don't know any better when they come along to be honest, they just follow videos because Sven said so. The simple thing is; many fall right at the start, I've watched the rants, felt the pain and this was always my last ditch advice as they turned their backs. LDT config is the second most painful support issue after the link to static moose.lua being hidden behind the out of date live branch. Of course, people have different use cases. The ones looking for more, often have the experience to skip ahead and ask the right questions. "Normal" folks that want some basic few lines should not be given the LDT nightmare, and I feel quite strongly about that! :) Having said that, I've only provided anecdotal experiences. We don't have an "Exit poll" for Moose or DCS scripting. We won't hear from many of the people that gave up fast again, I think we missed an opportunity, if not to create more scripters for DCS, just to reduce their pain and anguish a bit. (side note, what am I doing about that? Mainly picking up the pieces, cheering folks on, taking as many basic questions as my patience will allow, and every three months asking the same questions on how to refine the mission demos and make the entry point easier and meeting with silence, because let's face it, unravelling Sven's work is as hard as putting it together, it's kind of institutionalised to such an extent that a normal human just thinks, 'screw this, the world will gain more by just daily maintenance than rewriting the book'.) Hope that made sense, if you can see something in this and have any good ideas, there's always time to talk about it on Discord :)

That's fairly recent^^ But it doesn't mean anything, I can invent a few stories like, didnt/forgot to pay their web hosting bill, took a job on the terrain team at ED, formed a new company, sold it, took it down to stop all the annoying speculation. :D

Don't forget Iran began decentralising their airforce and like any airforce can forward deploy and move them around as required, with a bit of setup time. The same things goes in terms of destroying it on the ground, doesn't take too much imagination to envisage a lot of dummy hangars, dispersed remote parking and storage. They would fight in their SAM engagement ranges, which, are also dispersible, and not always from fixed sites, for example, the one that took out the US drone came from a location not marked by the famous SAM overlay for Google Earth, a lot of SAM mobility and deception would exist, as any idiot would do when faced against a serious threat with long range GPS missiles. If they had a chance, they could sit back and not expend everything, rather keep the hidden threat meaningful enough to deter silly deep strikes and just use the depth of their country to provide enough shielding around Tehran/Natanz. I'm not sure the long game would work out, but it would be a painfully protracted and expensive campaign through lots of layers which would attempt to work in concert. The size of the country is massive and the scope for pop up SAM's would be a very risky one for conventional airstrike to deal with. It would boil down to a game of who can throw more burning bundles of cash at each other.

Ah you need to subscribe to the videos "Can I stick my Harrier on this" The last one was particularly interesting, normal people don't consider a 80 upward slope a landing platform, but Mike Dickson's imagination is unrestricted in this regard!

This is the ultimate 'together' thing, teach ourselves to script together is quite a thing. I came from... ermm, a bit of Autoit scripting and batch files at work, lol. Like most hard to achieve things, it's takes a lot of effort. I spend less than 1% of my time helping the forum and mostly on Discord when it comes to MOOSE, I don't think forums really work as it's so iterative and interactive learning scripting. With Discord people engage in realtime. We haven't encouraged it, but in the last year, we've had a huge surge in general scripting and mission design queries. It's far from optimal but it beats forum threads that go on for weeks. :D

A bit late to this, but my advice would be not to use LDT if you are starting out and ignore all the LDT setup videos that FlightControl insisted "Developer-contributors" should have. Just download the dev moose.lua from the static link that i'm forever linking to people and use Notepad++ to make a script, go download sample missions and bookmark the docs and read them. That is it, anything else for a beginner is going to be a big turnoff. And I sympathise with people finding starting to script frustrating! It nearly made me commit some violence on inanimate objects! I think the issue with starting out is that Flight Control had a view of creating a team of people that were all of his standard of ability, so they could support growing Moose and creating other classes. It happened but to less of an extent than he hoped. I think to date there's only been 23/24 people with commits to moose.lua and realistically only Frank is making cool shit (and still making it, watch this space) The problem folks get is they land on moose and there doesn't seem to be a consistent single entry point. If it were me, I'd enforce an entry point as a single web page to moose with a number of very important single FAQ's, the required links for basic learning and some pointers. It's just too complex the way FC tried to get people into Moose as fully fledged devs. Anyone with prior experience will already be asking the right advanced questions, anyone with no prior experience is left stranded. I still remember what it was like and I argued like hell with Sven over it, but he just produced more videos or blamed Githubs inflexibility or other things. So I sympathise. But.... Moose is 100% alive and kicking and still growing. It's so ingrained in my workflow I have cold sweats imagining a world without it. And, we are super record breaking fast at fixing core issues. During the 2.5.6 Airfield bug from ED we were done in a few hours after ED released it, with a workaround, and reverted that whilst adding in the new airfields to Normandy when fixed, and so fast in fact Frank was telling me to just leave it until ED fixed it, but I pointed out, that we were faster and more agile than ED and we could indeed soften the effects of those ID changes. So if anyone else here wants to say this project is in anyway "words to the effect" of "dead" they can enjoy a large amount of "nope" from me, it's functioning awesomely, it's got way less bugs than DCS and the imperfections it does have are often caused by DCS bugs and workarounds in any respect. We have newcomers to scripting every day to Discord and the amount of people who now have access to scripting for DCS across the community have so greatly increased in the last few years, it's quite astonishing to see so many people cut their teeth on writing code and perhaps enlightening themselves with something challenging, that it warms my heart to think that not everyone in the world is selfish or stupid and there are so many tenacious people out there who want to excel themselves. But I'm sorry if you find starting out frustrating. It's not easy. Putting scripting into the hands of everyone came with a lot of pain. Especially copy and paste genius' that unravel when you ask them where the DCS log is. That, is the side effect frpm this success and I'm begining to avoid the low quality questions now that are solved with a little bit of effort or reading one's logs.

Overtime is quite an old fashioned concept, it's going away now in the private sector, gone are the days when my contract had overtime clauses, now they just have "work reasonably as required". At least that's the UK posture, other countries like Germany don't mess with people as much and their unions are stronger. However suggesting the forums are making developers slave away, which was the tone I got from the OP, isn't correct. This is down to ED's leadership team and whether they think it's justified and it is quite unusual, software across the world is in a constant state of slipped timelines. I'm kindda surprised the word was mentioned. It might not be a literal translation, and it might apply to one day, one person or a figure of speech. I'm still dealing with a feature that we promised more than a year ago to a customer and the business changed so much it looks like it will be dropped completely and we'll lose that customer (and the product makes a lot of money). Honestly there is nothing unusual going on, if anything I think a developer would absolutely love to have overtime, if that is really on the table, I know I would.

It's a long time ago but I always saw F-16 and A-10's doing this anyway, but they move on, looking around. I wonder if it might be a better idea to have this done by a seperate flight, as the players wingman is restricted in AI more, but a group leader of another is not. You can achieve all this in scripting though, but I guess that is not your ask.

Ooh good question. No. The stock type i havent seen how its divided up in the allowed tonnage.and it has been a ling time since i did those tests.

This post made so much sense after so much confusion. Thanks for the pictures. I had no idea what was happening.

Ka50 should handle some 23mm also, which is quite a lot more than 7.62mm. What you are really seeing is the basic damage model, so things like optics or tires or other small vulnerable parts are not registering hits. The current damage model is and has been for many years a basic health points system of which the warhead value deducts points from. Same issue as ARM missiles not damaging antennae dishes and ship damage modelling.

Broken physics, desync issues shouldnt be in the sim, full stop. I've not bought super carrier DLC until I see the base games physics on the carrier behaving to a satisfactory degree and that it is stable enough for some basic low client count multiplayer. That's not an unreasonable condition, I'm not spelling out doom, or suggesting ED are completely unable, in the current physics engine, to do a reasonable simulation of an aircraft on a moving deck, I'm only speaking for myself when i say there's no chance I'll buy a DLC about a carrier whilst the current sim's carrier physics has so many issues. I enthusiastically engaged in squadron activities in MP on the carrier and most of them ended in fireballs, deck and spawn collisions, Tomcat's slipping over the side, either sticky non bouncing deck or overly weird leaping off the deck. That was last year. I know a bunch of people who are also looking at this with skepticism. Great visuals notwithstanding, it's lipstick on a bulldog until the fundamentals work. I genuinely fear for a massive backlash on this one. Time to bury this physics engine ED.

I think its expected or similar. As in what is due.Bear in mind theres still lots of gui errors to show the contents but a combination of clicking around can refresh the list.

Who are these people you are quoting? Does anyone want to put their names down to this? Because if it's public domain then ED can change it, but if it's just non attributable, it might as well be me saying it. As is, at least the CNATRA docs teach a 20nm head on shot, and my personal finding in DCS is that you really need 17nm before it will catch someone executing a reasonable crank at 20k ft asl. The reason I ask for the links is that I've not found the documentary evidence of the range, yet everyone keeps quoting gospel and I'm wondering what I am not reading and where I am not reading it from.

I've seen loads of people get more from their CPU upgrades, but really it always comes down to what combination, where the bottleneck is and what type of mission you are running. I've seen frametime go red for CPU in one module and GPU frametime go red in another in the same mission but different modules. This isn't a simple question at all and I'd still pick the CPU first as it involves the board, busses, RAM and other places that can bottleneck first. You can solve GPU stress by turning down graphics, but you cannot solve CPU frametime easily.

I think this is a fairly recent bug as I've seen it too, this should most likely be under the DCSW 2 bugs section in AI, it's goign to be super hard to reproduce on demand.

ikr this is hilarious. The concept that people develop for DCS multiplayer is funny. I heard the Spitfire is getting the Meteor first, so it could perform better in multiplayer.

Hahah :) I like how you thought there was more chance of getting coordinate of scenery from DCS than a laser on a coordinate! We must have disappointed you greatly in the past! Not even the scenery id's are reliable in DCS, I have found duplicates and seen one explosion blow up something a mile away. Perhaps let us know what you are trying to achieve, you probably already have the coordinate, just disregard the scenery

To turn an airbase blue after killing all the red in it, make it blue to begin with and that will just happen. Airbases revert to what they were set as in the ME when empty. coalition.getAirbases(2) -- the "2" is for blue. 1 is for red. You can't change the name of a function and expect it to do what's inside differently.:) As for the function execution, functions only accept the arguments they specify. In my case it's one argument, and it's a string and it's an airbase. So you need to go back to the working example and call them one at a time. I do love your spirit though, being unafraid to try things. Just remember to keep looking at a log tailer and learning from all the "nopes" that Lua gives you, things will click, slowly at first, then with increasing speed. It might be the point now to read through the first four chapters of the Lua manual online now.

There's a few changes to aircraft altitude and the behaviour change has actually caused odd issues in their performance. Firstly; the above mentioned climb/descent Secondly, AGL now has a hard limited altitude that I never noticed before and might affect certain missions Now the real things I see affected. AI when set to AGL can really become messed up. What I have seen is - Pegged high AoA - Ignores tasking and heads in an unusual direction with no regard - Combat operations (engaging) messed up or delayed shots So there's loads of un documented change and people are having various problems that are more subtle than usual issues.

I have to admit, I've not tested the FC3 birds in neutral dogfighting setups, it's been many years since they were the only thing going. I don't there's much dogfighting in MP, it tends to be BVR or ambush, which you might call a dogfight, but not many people would choose to dogfight on an equal footing, and neither should they, it's quite risky. Realistically meeting a flanker with a light loadout and the equal same for a Eagle lightly loaded and fuelled in DCS mp is quite uncommon unless its staged. Exploiting strengths and weaknesses, the ambush would suit the Sukois. If you are seeing a lot of Su27 dogfighting Eagles, which server is that on?

Same. The basic premise is great. I would like to see something more generic so that different communities could make use of it. For example a lot of virtual squadrons want to collate user timing data and have to create a lot of server work to catch things like basic flight hours. The medals and everything are nice for immersion of single player activity and storyline, but hoenstly, just the flight hours logged, weapons used should be such a basic thing and I'd like to see ED catch all that and share a large database of flight details, avialable with an API to import to local DB's. Still very good on your work.

I'm sitting somewhere in the middle here. I understand "backwards compatible" and "no integration required" but we get these discussions come up time and time again. There is a ticket open for the Mig-21 with the picture of a Cuban BiS with R-73's, the F-5 sidewinders, the Ka-50 igla story, Iranian F-14 changes and so on. Honestly I believe this is more about limiting the software product to a fixed deliverable than it's IRL possibility more than half the time. Else why would you see Ka-50's BlackShark III, as a paid module? I can only see this as a software restriction and a budget constraint, and not as a real practical limitation, the excuses about "was it in existence in 1998 on block XYZ version Blah?" don't really wash, and neither do the choices the modules are made with about what systems the aircraft registration had at the date time IN THE PAST. But monetry, project and practical limits, yes, these make sense to me from a software side. For example, we can't expect our X labeled module from 2019 to have future updates of weaponry from 2021, that's not a supportable situation. What you get is what they set out to do and if it didnt include laser riding rockets, then it's tough shit tbh. I'm sure you can ask and fund the addition yourselves, but what you bought from a module does in fact have an end of development sunset, as sad as that might be. DCS is an open development continual improvement platform. DCS modules are not. If you get additions to what they set out to do, you are... lucky, or there is money involved.