Pikey

The one dude doing it spent some time revisiting Normandy. He did another 6 airbases, some custom models of key features, a shore rework, lightings changes and extended the roadwork and towns quite a lot. People probably dont know how much work it takes to create ED maps. It's not like the models are generated automatically, they are placed manually. The custom models, like the Pegasus bridge, mont St Michel are made in 3DS and done all themself. There isn't too many shared assests as this was the first WW2 map, so all the houses and buildings and objects were done manually. What I'm saying is that the update to Normandy probably took at least a few months. I saw some map work being done by a third party, this stuff takes a really really really long time and is painstaking. Since the dev doesnt ever say anything anyway, he hasn't broken any promises and there shoudlnt be any expectations of dates for Syria, you can be really close and months away from what I've seen.

I liked the detail in this post and it gave me a good insight into the development issues. Something to note is that the objects and multiplayer are always difficult to resolve, so much added burden to synchronicity on the MP game. It's a bit strange that some folks haven't been as welcoming, I would have thought a very clear remaining show stopper list would have been exactly what people had wanted, to ease their minds. Turns out you simply cannot say enough to please everyone.

Harrier mission type might be of interest since it shorter range, interdictions, CAS, beach-head support of Marines or "anywhere in the world" carrier based force projection. STOL means you can have a broader set of simulated missions. Unfortunately the FARP is not well done in DCS but with a light load is broad enough to take off from if the wind is going right and you haven't overloaded it. The stopgap conversion of the old sidewinder stock to the AGM-122 ARM is interesting for short range radar based SAM and radar guided AAA. And a 9M makes any interceptors have to think twice about a head on shot if they haven't picked you up BVR. The Night aspect is fun and interesting. It's got a good view from the pit and it has unique features with some development still to go, but mostly done. It's good in DCS for simulating a small group to play with since there wouldnt be more than half a dozen, maybe 7 on a ship, so it can make for some cozy gameplay, in mostly permissive environments. The Viper has to operate for fixed bases, but it's massively popular in forces across the world, so ubiquitous, if you fancy simulating perhaps Oman block 50's for example. Vipers are everywhere. Makes a good opfor jet, adversary, and has a broad role. Over the Harrier, especially of interest are DataLink, Harm Targetting system, JSOW for air to ground, with a lot of speed. The ground radar will eventually have moving target pickups, SEA mode for sea recce and of course air to air, and the BVR AIM-120, which is a big thing if you ever want to fight in a non permissive environment. It will eventually have a lot more so it gives people time to learn the jet as it's developed, but this has disadvantages too, like having to relearn. It will have a dedicated SEAD role with the HTS available, but can handle CAP and Interception, strike and even a deep interdiction with some planning. I can't really comment on the air to ground before ED finish the module, it does have a slightly thinner armament available than the Hornet, like lack of sea mines, Harpoons, but if you ever want to pick up air to air, you would want this over the Harrier, at least to fight your way in somewhere. I find the MFD far easier to read in VR on the Harrier, but the canopy for the Viper is something else, having no bow frame which is an oddly significant thing in simulations. However, the Harrier has the second best visibility of all modules with a very high seat and good look down abaility. Also the developer of the Viper is ED, that might factor in a choice. As a personal aside, I've always never decided to choose what to have, only what to fly, they are both great, with more to come, but I am partial to the Harrier role, being carrier and farp capable gives the longevity of scenarios you can try out a lot more variety.

Previously you could load scripting at mission start and whilst a lot of it would initialise, at least Event handlers wouldnt fire until the mission began to run. Now, with specific relation to birth events and single player, you can initiate an event handler for the player birth and it is picked up immediatley. The point of this advantage is in this scenario: For those that create player created menus and test or play in single player (that includes administrators and writers of multiplayer servers) you can now avoid the dreaded, "Press Escape twice to start" to get menus for players. You do this by having the relevant event handler and menu call script in a trigger from MISSION START. Some people already did this, but didnt understand why the script didnt completely run and they had to still press escape twice in order to get player menus generated. Others, specifically server admins often started their scripts in strict order because of reasons of order and initialisation so they wont have seen this change. TLDR; put your scripts into mission start and you will now have player menus built first time, rather than having to swap slots or do the Esc twice trick. Super handy, great change/fix by ED.

Honestly @jasonbirder you would be happy you missed the first 2.5.6 release. if it werent for several iterations now, ED would only be making OB into Stable, which they've taken valid criticism on in the past, however by fixing a LOT of stuff, stable will now benefit. DLC is massively different, they set super low requirements for complexity for support reasons. I was going to get into 3rd party DLC it but when I found out that you couldnt use custom scripting to any big degree, it became unattractive for me. And now you can see, there is some impact but not quite so much impact to DLC as multiplayer, servers and deeper scripting on top of DCS. OB took it full in the face on this round. It took down servers. Yet people still welcome the opportunity to be in it. Given that, and people fighting for the right to be involved (according to the terrible popularity of my post suggesting we could ban OB from multiplayer), having stable branch supporters wanting to enter this mess earlier strikes me as the exact opposite of the entire point of all the last weeks of pain OB has been through. Aside from that... you don't simply revert parts of code in certain areas and take them and selectively pile them into stable as you go. Sadly (and wouldnt it be great!) you cannot seperate most code in isolation and apply it to stable. I can't explain that to you easily, and some of the explanation involves on ED's coding methodology and the application itself, and the code itself. Not to forget the COO called it "spaghetti code" in her own words, and that is a hard legacy of the many years of development.

Frank has removed the airbase ID issue workaround from the DEV branch and we tested and all spawns last night on all airfields on all maps. Happy to report that SpawnAtAirbase() which is heavily used in Dispatcher, RAT and so on is now confusion free. My advice for Moose users is that 2.5.6 current is much safer for scripting from a moose and airbase perspective and you should now use 2.5.6 with the latest DEV version of Moose and have no issues on airbases. That is IF you want to use OB. You certainly don't have to, but that is also looking much better (and it is also imperfect of course with many known issues) With all complex things, there is no such thing as a perfect world so any issues with current DEV moose, please report on Discord or GitHub. Hopefully we can move back to getting the DEV to stable now as originally planned. List of scripting and server issues that bother me personally (FWIW) Statics, specifically FARPS and Oiligs do not like being handled in SET_STATIC and having certain methods run on them like GetID() which is used in other functions like filters etc. Because Farps are so special (being airbases too) I would recommend people do not try to access them with broad tools like SET's and ensure they and oilrigs are not used as they will eventually error your script. I'm not sure of the status of implementations of the new EH's. I think I like the concept of the kill event that was introduced as a smarter way of counting death, which would be difficult for people catching planes and scoring, because events dont work the same for human and AI wrt planes. Will look at this in the coming weeks. AI_A2A_Dispatcher has long had some inbuilt stupidity with engaging. This is a problem in code but not an error. It's more to do with when it releases AI to engage and has changed during it's lifetime. The net effect is that BVR is often pretty rubbish with AI. This is a sad side effect of there being no way to stop an AI engaging short of turning off its ROE. Doing this on ED's AI makes them both dumb and reliant on where you placed the CAP. Always create long distances between CAP stations and engagement points like borders. Some people have had good effect with older version of moose for this. Other than that, we just need to release a main branch :) New airbases and taxiways are in for the Normandy map, airbases are fixed.

Want. I love torpedo runs in sims, It gets my brain fired up with maths puzzles.

there is potential for them to become full units but it seems unfinished in the core game

If the DCS patchnotes actually said what they changed in DCS, then the folks that don't understand would see why it's so slow to get to stable and why we get pushed into "OB as live". There is so much under the hood maintenance and change in DCS core that just never comes to light. We see just a fraction of the effects, feel such a fraction of the bugs and are prvy to such a small amount of the total drama that goes on. It takes some experience and a leap of faith to imagine the scale of it all, so it does bug me, that people moan about delays to the supercarrier or whatever module whilst being oblivious to it all.

OK I've tested airbases including the NTTR airport switchups with the moose versions prior to before we had to emmergency hotfix. Here is the advice for MOOSE users: If you were affected on NTTR by airplanes spawning is odd places on DCS World 2.5.6, you can now revert to a moose version released prior to that and everything will be fine. I tested on December 19th moose and all NTTR (and I expect other airports hit less hard) work fine for "SpawnAtAirbase()) Specifically Las Vegas, TTR, Creech, Pahute Mesa would spawn incorrectly because the workaround of guessing patterns didnt work. There's probably others on different maps, this is just an example. However, with the hotfix applied, moose dev version will spawn incorrectly for some airbases and this can affect Dispatchers, RAT and GetId andGetCategory() functions at a deeper level. If you never had any airbase issues because of Franks emmergency hotfix (count yoursleves lucky) then you can wait and expect a moose update to revert the ugly workarounds with the ID's being wrong. There may still be issues with GetCategory() and other Airbase functions, and if you had these, you can also revert to an earlier moose and everything will be fine. For those folks that didnt notice anything, there was a massive panic, a global pandemic, your shops don't have toilet roll and stuff happened, but it will all be ok soon!

Initial findings on DCS version today is that Airbase ID's look healthy. Which now means we are back to Reversing partial workarounds Moving onto publish a Release candidate This is only spot checks, drones are busy testing as we speak. I'll post up any Moose progress. I'm trying to be optimistic about this, but I'd hate to speak too early.

Don't ask us, ask your logs. Where is your error?

a few things I noticed in the last 20mins missing from the change logs: Statics renaming themselves to "Ammo" constantly - FIXED Airbase ID numbers returning incorrectly - FIXED All my initial tests ran well. I think Player ID's may also be fixed now. This only leaves the DCS: Cow so far. Why don't ED celebrate their successes more? It's not trivial to fix stuff.

This is very narrow minded Yoda1875. You assume that we can't find out, that it's hidden and that for some reason it's a coca-cola secret. No one wants or is asking for the compiled C code, we want to know the areas that have been changed so we can be more effective in our testing back to ED. Being focused to faster find and report issues in YOUR product. It's not a secret what they give us, it's the product itself. We get it, we use it and we find the issues plain as day. It's not unreasonable to simply say that "we refactored statics in the global mission environment to report to the namespaces of airbases better". It doesnt say what the code is, we don't need either the exact code they changed or the compiled code, just the areas they meddled with so we can check them, so that Open Beta is actually tested properly. Because it sure as hell isn't tested properly before it arrives, and the proof of that is in history. Any Lua changes are open code anyway. What ED currently do, is throw us a black box mystery every week and let fall over, then we troubleshoot why, duplicate our seperate efforts, report it multiple times it back, bury the forum and real issues in noise and mess, plunge moderators into frenzies, which costs us ALL time that could be avoided by having a reasonable data led approach. Remember we give them problems, they demand data like tracks and steps to reproduce? Well THEY give us problems too and we get none of the same courtesy back: Nick Grey, 1 month ago: Symbiotic does not mean equal, fair, intelligent or optimised. We have a completely one sided approach where ED do not discuss the majority of changes with us, yet we are completely open and detailed about what we find, in the SAME FORUMS. But the burden is on individuals working on their own without any clue as to what is coming. I'm asking we be efficient about this process, not for more QA. There is nothing wrong with being efficient and not wasting people's time. Might I remind everyone: ED are not just asking for our help, they need our help in testing They have one of the most complex sims/applications out there with a large codebase They currently provide one of the shortest and abbreviated change lists of any game developer in the public eye They opted for the open development model to all our benefit They frequently never mention new complete features, fixes or known issues, despite mentioning 'some' (got see the unofficial post for hidden features) We don't need a list that says "Cow in, textured, Cow texture broke, Cow now removed" more something like Refactoring X feature, added placeholder paratrooper event, added kill events, changed event ID's, changed airbase ID's. Their customer base is actually a few pegs up the evolutionary tree, folks capable of recalling multiple complex processes, talking whilst listening to two conversations and operating a simulation jet with reasonable accuracy simulataneously There are bundles of developers writing code, creating content, textures, models for their game Nothing I asked for was unreasonable, impossible, never been done before, or breaches a covenant. Everything I asked for benefits everyone, even if the average next Starfighter pilot couldnt care a less what even a static is or why airbase ID's are relevant, this is the start of where things get fixed and the speed with which it is done so that servers and missions and future missions and modules and content is better, faster.

It adds value because you can look up the lunar, solar patterns online and set the time and date and you get what you should get. The alternative is guessing and being confused. Which isn't fun. I'm sure it should have been corrected some time back, but better late than never.

Will the next patch notes accurately list all the things/areas the ED team fixed and changed? We had many discussions on this over the years and we still find that the patch notes are not covering most of the changes that affect gameplay/use. It was said somewhere that ED would try to be more verbose, yet we see massive changes in 2.5.6 and very little of them were mentioned. It would help us find issues faster, rather than accidentally, which leads to frustration, especially when ed say they need us to feedback on OB yet the feedback loop is cut in two places, receipt of outgoing information and limited to a single word in return of information "REPORTED". Plus, the amounts of times ED fix things without saying anything is insanely high. It would help the PR machine, surely?

Commit is pre timeline and broader acceptance of the entire tactical picture, often from a point of being on station immediately at the time of the call and entering the timeline. Target is a directive to take ownership of a specific group. Targetted is a broadcast to let everyone know you have ownership of the group. In actual differences it seems a bit silly but the commit is further out and indeed implies IDcrits need to be fullfilled as said earlier. In DCS I've committed and targetted in one and where there isn't much non squadron gameplay that is related to pre commit handling, its far simpler to use target and targetted to avoid confusion.

There's only one way to practically improve. Get a human of better knowledge and skill, get Tacview installed and learn it and fight him. You can read all you want, but you will only learn how to read and not apply the lesson. Application of theory is where the make or break happens. I love how folks ramble off links to Shaw's or P-1289 and that's their only advice. Personally I think P-1289 is far better as an instruction set with specific guided training that goes in logical order: i.e. snapshot drills come BEFORE rolling scissors and the Perch only makes sense once you understand the concept of the bubble (but ilustrates it beautifully). It's had years of maturity over Shaw's, doesn't ramble and introduces the training you require to DO, to improve the skills. The truth is, the AI in DCS is not flying within the laws of physics. The sooner you give up on calling that a training aid, the better. They will lead you into vertical fights you cannot compete with, whilst being complete dumbasses with repetivive routines that can be cheesed and then once you learn how to cheese AI, what is the actual point? 1 on 1 the head on neutral merge, the AI is gameplan high in the same direction. You can actually practice a non cheesed method of anticipating that and I've beaten a Su-27 in 180 degrees by a whopping 90 degrees just by anticipating the exact place I know the AI will go. Give me a player and I have no idea. And he uses the same physics that the module has. It's not only fair, you get to practice faster, learn more, get feedback during, and post fight, and have a laugh engaging with someone human. And FWIW I've read it all, written it into training for players and I'm terrible in my skill, spatial understanding and reading my own and the bandits relative energy states. I spend my energy like a 1990's hedge fund millionaire spends on hookers and coke. But I know what I know.

Funny fact: In multiplayer you mostly find cold starts, despite the larger group of time-bound players who want a quick game perhaps wishing it weren't so. Whether one considers it a waste of time to start an aircraft yourself is entirely subjective, you either want to or you don't, it's your time after all. But there are a few reasons for knowing how to, even if you choose not to. From an immersion point of view, it's quite odd that we might consider cold and dark to be required, since in many countries and types the aircraft is started for you, at least my tech friend started Jags for his pilots, I suppose it varies. Sometimes you need a cold start to quickly configure a jet for somethng specific. Case in point are scrambles. You configure it to be all on ground power and aligned and configured with engines off, which is the most likely configuration for a pilot in the services as far as I know. Other reasons revolve around doing the configuration yourself so that you are sure the plane is setup the way you meant it to be. Finally you might not be given a choice not to, depending on the mission configuration. Knowing the aircraft to start it seems like a pretty normal thing for a study sim, but for those that like driving like they stole it (but someone else started if for them) then, it would be a shame to rule out cold start servers, which are the majority that I have seen. I got the feeling the OP was an offline player since you can't always choose your startup type online, it is up to someone else. There is a place for everything in a sim, choosing is its strength. Air starts and hot starts allow you to practice a set piece, or combat, or a specific weapon or whatever and I'm grateful for that ability, and do use it. However, something set's me uneasy with starting the sim for an immersive mission from hot, even if it might be closer to a realistic receipt of a plane than cold and dark. I find that i am unable to explain that very well. We surely cannot get another startup config, like "engines off", so cold, for me at least, is the closest.

Well they haven't responded in over 5 years to the multitude of posts on the silly collision model and angle of their farps caused by... the crappy terrain engine. So unless you know someone at ED you can come sit on the bench with the rest of us and we can bemoan the world without fixed wing airbases.

Yes, I agree also. A strong point of DCS is it's FM's. Flying without instruments cuts everything down to comparitive FM's. DCS still needs to catch up on weather. However, it's also strong in what made A-10C famous, so, there's no real argument for having one or the other, except integration of multiple modules in multiplayer. On that point, it is definitely ahead of anything. The first time you do CAS with real players or buddy lase or team up with multple flights over datalink, you see what DCS really has.

The takeaway is his passion and how lucky we are that we have leaders in positions that they love aviation, it's their life, because without that, this would be a difficult ship to steer, being that it's not where your skilled entrepreneurs are gravitating to in order to make money!

You will get the top half with the Syria map with a Israel-Syria-Lebanon area. For the bottom half, despite the interest in Egypt borders i think skipping south to West Yemen is what I suggest as it also contains a major US base in Djibouti and bases shared by other nations and has a massive melting pot of nationalities in a combat arena. Unfortunately most of the combat hotspots are broken up and will never be able to be put together.

You've identified your own personal taste all the way through your post without acceptance that not everyone plays in the same manner. For example, I haven't "played" Single player since 2015. I don't own any DLC campaigns and will never buy one because I do not like the format or the experience of flying alone. I use the training material once, i find it frustratingly slow and hate the entire "press space bar to continue" voice. I prefer learning with others in a group and asking questions and then showing someone else. When I need a process I'll check out a coupe of videos, scribble some notes and then try it out myself. But none of this means that I or you are not part of the same group of customers, we just have different ways of enjoying the product and different views on what the "CORE" of the game actually is. I see the CORE as a very low level item, key features that might have absolutely no relation to a single player, like for instance, single players probably have no idea that clouds in multiplayer are not synchronised. To me, however, this is absolutely core. Apart from the other examples I gave in my post on the differences there are lots of examples where you cannot say things like Multiplayer is a "tack-on". I had assumed you meant it had received little development, when in actual fact it seems like you don't think it has validity for the majority in terms of precedence. That's a very limited way of looking at things and I cannot in any way support your view on this.

The important part is both your client, mission and server settings enforcement of "Realistic comms". The mission will override player settings if you set it to. This causes confusion. Thereafter, if you want service from AWACS/tankers and they are the right unit type, set the frequency you want them on and if realistic comms are set, you need that, elsewise you wont. When you create an AWACS or tanker it will already have the inbuilt AI Task for it to perform that function. More important is that you want to give awacs and tankers a Perform Orbit task at a certain waypoint. If you want a racetrack, you set it to start the racetrack before the next waypoint and it will loop between the two. [EDIT] the awacs and tanker menu items are built dynamically depending on if there are any available awacs or tankers. They wont show for example, if it's not taken off yet.