Pikey

Did anything ever come of either a Greek or Turkish F-104 skin? I didn't find anything and was hoping to create some 1975 action on the Syria map.

This is our yearly mission statement and achievement wrap-up post. This continues in the theme of: Discord developments As of December, there are over 2160 Discord Community members. This is up y-o-y from 2021 by 600 contributors. Over 400 participants contribute 5 or more separate messages. From 2020 we can count double growth. The top ten list of Discord contributors is here taken by the MEE bot: One of our two main developers, AppleEvangelist, is almost single-handedly propping up other contributions to the Discord, to show that your questions are answered by a developer (as long as they are answerable and on topic). We are all very grateful for the time he and everyone else that contributes give up of their free time to help. Frank had a clean out of the Intro section and updates the #FAQ and we now have a dedicated Moose Discord bot that parses logs and offers advice when it sees log parses. GitHub statistics Master branch commits 2015-2022 (green) File size December 2022 - 8.7MB File size June 2020 - 5.9MB Over 4600 commits, 46 releases, to master branch from 33 people Yearly over 1MB of growth in code. 1MB = over 1 million characters a year! Thats a lot of fingers on keyboards! MOOSE is a community project, the code is open source and we very much appreciate all participation. We have participants in many ways, by committing code or documentation updates, by responding to people's questions in Discord and online, by providing feedback and suggestions and even just asking questions to stimulate interest. MOOSE was originally created by Sven (Flightcontrol) in 2015 and is now over 7 years old and we can see from above that maintenance of it continues regularly. For interest, Flightcontrol ceased development at the beginning of 2019, FunkyFranky began developing on MOOSE in 2018 and AppleEvangelist began in 2021. We welcome any new developers, no matter how small the contribution. The above statistics are relevant to the main branch. There are two main branches, Main and Develop and the primary difference right now is that the Ops AUFTRAG hierarchy classes are only available in Develop (more on that later). This slightly distorts figures as the commit rate to Develop can be higher due to the extra classes. These are the commits for this year: As you can see, if MOOSE is dead, it's going to need a stake through the heart at the very least. Class developments 2022 was an excellent year for innovation! New classes, additions and fixes: Ops.FlightControl. This class provides Audio Air Traffic Control just like AIRBOSS class, to land installations. We've iterated on basic sound files to utilise @Ciribob's excellent Text-To-Speech and deliver audio messaging via SRS direct to your ears. https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/OPS.FlightControl.html Ops.Playertask. This class supersedes previous Task classes by providing a framework for players to have a task system give them things to do in a mission based on automatic discovery or manual provision on any single unit or group of units and including scenery. This amazing class also uses our modern, localisable, Text-To-Speech system from Google. https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Ops.PlayerTask.html Ops.AWACS. This class can guide and direct both AI and player clients together, in multiplayer, to intercept trespassing enemy planes in defined friendly airspace using Google TTS over SRS for the messaging delivery. We use NATO brevity as much as is possible within the remits of simulating a Human controller (anchoring is nigh impossible and simplifications to process are required). This would typically replace crude text to screen for BRAA and attempt to provide realistic engagement using human like voices for targetting allocation with a number of reality and era options. Whilst it won't exceed a human attempting to provide a AIC job, it better than any other scripting solution out there and represents a world-class solution not seen in any other simulation to date. Ops.PlayerRecce. Inspired by Gazelle helo scripts used on MP servers, the Recce class simulates optical detection by the Player which is otherwise impossible to script (because a computer doesn't know what you can see). The class features a number of hooks that can be used to link to other scripting actions - passing the target, for instance to AI for prosecution. Ops development. We are now at the end of the second year of Ops development. The Ops classes comprise of the AI Tasking system of "Auftrag", a three tier hierarchy of land, sea and air controlling classes. Over the top are two classes, COMMMANDER for direct execution to a subordinate class, and CHIEF. CHIEF represents the automation of spawning and attacking by an AI commander. These classes have been actively developed and refined since 2020 and represent MOOSE 3.0 in the evolution. SSE API additions (ToUnit) MOOSE will incorporate most API functions if they work and are useful. Additions from time to time are made by Eagle Dynamics. Fixes/enhancements: A great deal of work has gone into reducing on-screen messaging and migrating to Google Wavenet voices via Ciribobs TTS executable in the SRS installation. The future of DCS scripting is communicating via radio, not via imaginary writing on your canopy. L10N: We have begun innovating localised options for language in our code since we have embraced TTS. MOOSE Usage in DCS Missions Moose is used by 4YA and Enigma servers and many more, representing many of the large MP servers or 30% of the top ten populated individually named servers. This is quite an achievment given the Administrators are often already technically adept. Offline, MOOSE is used by @deadlyfishes very popular Through The Inferno (TTI) representing over 82,000 downloads and most of the top ten downloads. A vast number of administrators discuss MOOSE every week in Discord across the world, even in heavily firewalled countries like China. It is fair to say that MOOSE has had a huge impact on DCS whether realised by the individual consumer, or not. Legacy classes and supportability statement 865 closed tickets, 19 open Since many of the MOOSE classes were written by FlightControl it is fair to say that after he ended his contribution in 2019, we were left with a large support deficit that was not feasible to sustain as a hobby. Frank created the OPS classes as a result and we have concentrated development on fresh ideas, because sustaining someone else's hobby is hard enough at a code level. Here is the current list of "class health". Use the documentation to understand the class names (develop is used here) https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/index.html All Tasking classes - Deprecated (known issues) Superseded by Ops.PlayerTask All AI - Deprecated (known issues) and superseded by Ops.Auftrag and related Ops.Chief, Ops.Target combinations. No parity with the originals. All Cargo classes - Superseded by Ops.OpsTransport Functional classes (the mixed bag) Functional.Detection was superseded by Ops.Intel - Intel is simpler and has groupings and decay but not threat. It also hooks. Functional.MissileTrainer was superseded by Functional.Fox several years ago Functional.Escort was superseded by Ops.Auftrag (and appropriate task) Functional.ZoneCaptureCoalition superseded by Ops.OpsZone Functional.PseudoATC - Developer has indicated that using Ops.FlightControl is prefered Functional.Suppression - working, best effort support Functional.Movement - Deprecated, does not work, do not use Functional. ATC_Ground - limited repairs being made - best effort support All Ops classes have an active developer owning them. Wrapper, UTILS, Core are always supported Sound is supported with a nod to more effort going towards converting sounds to Google Text To Speech as static sounds are less scalable. Supportability definitions Deprecated - The guidance is to no longer use this class due to one or more known issues. (We never remove classes from Moose) Superseded - There is an equivalent class that is performing functions that are the same or close enough in design. "Best Effort" - The owner of the code is no longer supporting this and any volunteer dev is probably going to spend limited time Troubleshooting. Supported - The developer is active and answering questions. There are no guarantees or Service Level Agreements on what constitutes "supported". You may check the MOOSE Discord class channel and the history of discussion for a better idea. Future MOOSE continues to grow, evolve and innovate. MOOSE and it's community thrive based on the principle that a free community has no barriers. We are agile, useful and relevant to DCS World with a huge majority of DCS customers using MOOSE without even knowing. If you want to help, please use the code and talk about it here: https://discord.gg/gj68fm969S FAQ MOOSE has two main branches (master and develop). master: https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/ develop: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/ Download MOOSE (save as a file.lua): Release version: https://github.com/FlightControl-Master/MOOSE/releases Master branch: https://github.com/FlightControl-Master/MOOSE_INCLUDE/tree/master Develop branch: https://github.com/FlightControl-Master/MOOSE_INCLUDE/tree/develop As the documentation of MOOSE is created via luadocs on-the-fly from the respective Moose.lua, every class that is in the docs is also in the Moose.lua. User Guide A good place to start is the MOOSE User GUIDE: https://github.com/FlightControl-Master/MOOSE_GUIDES Youtube Even though a bit outdated, FlightControls YT channel contains a lot of useful information on MOOSE https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg/featured Especially the MOOSE for Dummies series is a good way to get your scripting juices flowing https://www.youtube.com/watch?v=ZqvdUFhKX4o DCS Scripting Environment All scripts including Moose eventually use the DCS API or Simulator Scripting Engine (SSE) to interact with DCS: https://wiki.hoggitworld.com/view/Simulator_Scripting_Engine_Documentation DCS Version Info: https://updates.digitalcombatsimulator.com/ LUA Resources - Learning LUA YouTube videos : https://www.youtube.com/playlist?list=PLxgtJR7f0RBKGid7F2dfv7qc-xWwSee2O - Programming In LUA (First Edition): https://www.lua.org/pil/contents.html - The Implementation Of LUA 5: http://www.lua.org/doc/jucs05.pdf "The best things in life are free"

I don't disagree AI could be better, however, it's irrefutable that you'll get closer to what you need by concentrating on solutions that are actually available to you. Waiting for wishlists is something i do not advocate, i'm still waiting a decade later, for dynamically created player spawning. Let me help your decision-making and solution. Things are not as simple as "When AI are in recovery stop players spawning, lock up cats and allow them to dictate players play times" Why would enforcing wait times for a cat work better than disallowing spawning hot on a catapult? Both restrict what a player can do for their own convenience. You either allow players to do what they want and work around that or you accept you have the forces of chaos in play and you can only limit the risks. AI waves off, that was implemented but it doesn't acknowledge players in the pattern. If you care about those things, implement AIRBOSS mod and ask players to follow its instructions as it will seperate AI and player. It doesn't mean they will, of course. If you want to advocate an AI change where they remain in pattern as your wishlist, then, whilst we would prefer to have AI crash into the sea, all it takes is for a player to sit on the deck twice in a row doing cold starts and a typical fuel load for AI would be expended and they would ditch in the sea. Which means AI are somewhat useless when Players are wanting to have their cake and at the same time, eat it. Your real issue is players not doing what you want, rather than AI who are predictable enough. The thing I inferred is that the start time of the player cannot be hard set for your scenario. Which follows it's a server that you can enter immediately and have unrestricted take off at any time regardless of what AI are doing. I'm wondering if you even set the wind for the takeoff because if you have a carrier that is always into the wind, its not 24/7. Which also raises other questions on the use case that render the potential solutions as 'out of scope'. Things you can change that can help - Limiting cat starts for players will always stop a crash from an aircraft on finals seems to be the most obvious solution - There is a network block switch to stop a slot being used called slot blocker. It would require heavily edited to be adapted to only get half of your requirement. It cannot stop the dynamic cat allocation, you cannot infer planes departing, you would have to create an incredibly complex layout of moving trigger zones to check in order to deny a player entering a cat and chances are, it will just block people from doing what they want anyway. Arguably pointless because you want hot starts on the cat so time is of the essence. - implement AIRBOSS scripting mod which will alleviate some of the organization for landing, create recovery windows with the wind which it sounds like you dont have, and provide insights to AI in the pattern via the comms it does. - Plan recovery windows to coincide with carrier movements and AI flight cycles in your mission (doesn't work with 24/7 servers and perhaps your use case) - Leave AI off the player carrier or drop them entirely (moving AI to another carrier is often done but players will still screw up your decks because ... reasons) - Spawning AI with proximity checks for other planes (there's no API for planes recovering as a query, you cannot tell from the mission environment, only their proximity) - Implement a scripting solution for recovery windows on demand (helps with the wind and carrier placement) - Delay the non-cat hot starts by putting no fuel weapons on which makes players be a little more careful as they have enforced waiting - Having a human coordinate the deck whilst players are involved - (this is done in some squadrons, over the top of ATC) Things you cannot change easily - How AI is coded - How players in a game will behave - What additional scripted control is available Take your pick and good luck!

You are right! I was wrong, I was thinking of take off from runway (ground based) which exhibits that behaviour as a server. That doesn't make any difference to your issue though because YOU are setting that configuration (start from runway/start from parking). I would not expect the issue is as simple as you state though, I've seen all sorts of results when blocking cats and my hunch is (feel free to test) that if you sit on Cats one and two, and start a slot that is set to start from Cat1, it might put it on cat3. The reason for that is that cats are dynamically assigned and the ME scrapped being able to spawn direct to any cat way back during early access. I don't think there is any scenario you want players spawning directly to catapults. Variations of this topic occur weekly - You must observe the AI for recovery options, they WILL force a deck open wether you think players should be clear to spawn in or not. The issue is not really about cats at all but the fact that the ATC will always allow planes to recover if they are AI or player. At worst they get wavedoff (if you are lucky).

It cannot be managed with any scripting engine. But the only reasons those locations could ever be picked would not be in the normal design of the spawn, typically with no other deck parts blocked, in MP you spawn on the 6 pack. If these are occupied or in use, there's a system of spots that doesn't cover spawning directly onto a cat. In fact, spawning to cat is the same as runway start and not deliberately done in multiplayer, only accessible in single player. Having said that, you see it happen if something jammed up.

Hi Dolfo, DTC and similar has been talked about as being in medium term development for some time, there's no news on it, ED haven't forgotten but no one knows how far they have made it. One day, i am sure, it's been a very popular wishlist item.

Still solving problems for people in November by removing this junk. Now I can give you actual numbers based on a fix I did for someone logging a bug in the ED Discord. Before: Customer complains about over 30ms CPU frametime, DCS is terrible, ED don't care, 2.8 is bad, yadah yadah. Title of post: "VR unusable" After removing exports: CPU frametime down to 14ms. Happy customer, ED, we are sorry for blaming you. It's literally the difference between green and red frametimes. In VR this is about half of your FPS. HALF. Trouble is, if people don't know what exports are doing and how they work, then people will just blame the sim again. The only export I will put my trust in is Ciribobs SRS. As much as I love Tacview, it scales atrociously with large MP missions. Use servers where the Tacview acmi file can be downloaded afterward. As for other products, you choose, pretty lights or a working simulation.

It's quite a weird use case for sure. `This is needed for DSMC mod, to detect if the user launching DCS have access to the options menù or not. ` The fact that it was a requirement to be run before the mission executes in the plugin environment seems to me only be asking if the UI "could have" supported the options dialog boxes, not whether it was a server at mission runtime. If my logic is flawed we can rethink, there is always more to these questions!

Check for a folder that does not exist in the dedicated installation! You cannot, prior to a mission launch, use any line that asks if it is a server, those are mission and net environments. There's nothing in _G about that https://stackoverflow.com/questions/1340230/check-if-directory-exists-in-lua

Your points were already made. I've also added a constructive way to alert people there is something afoot. This stuff is NOT new.

I thought it was a lovely gesture of fun and goodwill from the team. It was very easy to tell it was deliberately done, perhaps the skeletons and the pumpkins could go on the front screen to help those that are only logging in after a while and not picking up on the date. Well executed, funny, thank you, and shows the caring side of the team. Please make sure you get them with the Reindeer, Tie Fighters on April fools and other such occasional nonsense.

Once you can send things the rest is DCS scripting and not to do with the DIscord webhook exe or how to make a webhook. So you should look for help with your scripts in the scripting section to find out what you did. Troubleshooting scripts very much requires people to read their dcs.log and look for errors.

Damn, I need this in my life!

I never saw a mirror that could be made from this that wasn't part of DCS, there's no options I see in openXR tools, how did you do it?

Although I ran OpenXR and it worked straightaway this morning, so it doesn't mean the reinstall didnt work, I haven't reproduced the issue again yet.

Thanks, had a look and there's one entry and the file exists and paths seem correct. But wondering if Data value should be 1 and not 0 for this DWORD? null

In the south atlantic map there are massive several degree swings on location, pretty much impossible without lots of effort to find it, so the posts relevance stands. SHouldnt have to have a script for it.

no, something else is wrong. It doesn't work automatically most times, i have to restart my PC.

Does anyone know why OpenXR tools for WMR most of the time launches looking like this for me: Usually I launch WMR, launch DCS and DCS never loads, just hangs. Then I open that tool and it looks like this. ALl I ever could do was reboot which usually fixes it until the next time and I got sick of this today and tried uninstalling and it still behaves like this and its not useable without huge delays an dfaffing around on my PC, which defeats what was good about the solution. What should I do? null

Just in case anyone arrives at this post asking the same thing - no you cannot edit the moment to moment AI decision making specifying the com-plex parts of viosual detection, the movement of the plane outside of general waypoints, the manner of the movement outside of general tactics set as Task "options". These things are held in DCS programme files that are not editable, in encoded C language. Things you can edit - Tasks, as per design, either by the Mission Editor or scripting, to issue moment to moment tasking options or generalised behaviour. Example - tell a plane to land. It conducts its own routine, the closest you can do is tell it when and where, the rest is not editable. Sensors, weapons, unit core behaviour by type in the editable lua files AI is naturally cognizant of the player and other AI and the amount of ways it interacts when it detects and detection itself has been tweaked over the recent years, most notably in the WW2 units, with new routines that tell AI to try to escape sometimes or make it not aware of rear blind approaches. The progress on this is slow. It's well understood it is very important. The next generation of BFM routines and code is coming at some point according to ED official news.

Wow thanks so much, truly excellent additions to DCS! Thank you for your gift!

Asking again

No tracks, no sources, no defects.

Wow thanks so much, I thought I was going mad, I spent ages since it used to be in the profile but now, I am happy to irradiate my eyes less again!!

Thought i'd share a demo of what we can do with moving battle lines.