Jump to content

Pikey

ED Beta Testers
  • Posts

    5687
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Pikey

  1. Yes, easy to explain. The map is based on a time period of specifically two weeks before Paris fell, 'August to mid August' based on the ALG's that are present. The PDF you provided shows that there isn't a Luftwaffe airfield on the map that is applicable. What good is the Luftwaffe approach system on Evreux when the RAF are using it that month? Its the age old issue of when the map is based on. And, regardless of if customer A wants this time or customer B wants that time, not everyone can be satisfied by the point in time the developers sets. If you put down beacons on the map the AFN-2 on two thirds of the DCS module Luftwaffe planes that were never there in the first place would not be able to use it anyway because the airfields are being dismantled and abandoned. Hence having the ability to ignore these constraints is optimal. I'd rather have the ability to ignore the constraints of the map than live with the map that has no beacons. Historical accuracy cannot be used as an argument for having Lorenz, its an argument for not having them on the Post invasion Normandy map. SO I think you'll find we are in agreement about wanting something that wasn't there but the route to getting that is not via Ugra.
  2. So its an ils in game but we cant put ils down with the me. I think we need to get back to ed.
  3. For the German birds I have had no luck with the navigation needles on anywhere except caucasus, I believe this is an ED problem. For landing system radios and Lorenz I actually don't think there is any implementation in game, I've been waiting. The beacons.lua of Cacuasus should provide the answer, it may be moddable witha few lines of text, not IC compliant though.
  4. I looked for data on broadcasting stations and the location of beacons and radio stations and I found there was not that much information, so I preferred to make my own. If you find anything its easy enough to create a template for mission editors with a very alive radio for Mosquito back seat fun, however I think the time of the war was quite restrictive on navigation beacons pointing to airfields.
  5. Can confirm after testing this and hearing of it that I got 5/5 crashes with "Always on". DIsabled is fine. To be fair, Auto (Default) was not crashing (or doing what it said) but another user said it crashed on Auto so I would advise setting it off for now. This is kindda important and hidden.
  6. Thank you for these answers! Yes, very helpful. So typically I head to OpenXR tools for WMR and reduce the number there first to save the pixels being pushed which is the largest FPS gain, then make up the image quality in game with the upscaling toolkit. First one starts making the image jaggy, second blurs a bit? Is this roughly it for the layperson? Please correct me if I misunderstood! Cheers!
  7. Hi, I am trying to understand the methods to tune VR scaling (everything works already) using OXR and HP Reverb 1. I need some help with some basics, specifically the interaction between: OpenXR Tools for Windows Mixed Reality | Customised render scale (as per screenshot) OpenXR Toolkit | Upscaling/Sharpening NIS | Size (as per screenshot) QUESTIONS 1. Is the render scale on OpenXR Tools for WMR applied before the OpenXR NIS upscaling? 2. Which direction of render scale does what effect? I read on Reddit that 100% is auto adjusted based on GPU RAM but is this 100% of the GPU memory adjusted figure? i.e. is 100% the same resolution for everyone? 3. In VR headset the NIS upscaling "Size" setting requires the user to increase the number to reduce the screen resolution to improve the performance. Is this AFTER the Customised render scale or does it Overwrite that scale or something else? 4. I see NIS, FSR, CAS. CAS has no resolution size. What helps me pick one, what should be better for DCS? I can't really tell easily in game as I have to restart between and it seems no different. 5. Is the DCS VR setting, is Pixel Density applied after or before any of these and does any figure other than '1.0' help? 6. How will any of this be affected by Nvidia DLSS 2? Applied before, after, in the middle somewhere or not at all? 7. When either tool says to Restart VR to take effect, does this mean you need to close WM Portal mirror screen? I'm sorry for these questions, good answers will help choose which slider to set before another and save hours of testing
  8. nullThe OP asked about the core game files, without conflating module and game files, which are seperate for good reasons Note that I never said 'lazy'. Don't put words in my mouth. I said 'didn't look'. Let's look then: https://www.digitalcombatsimulator.com/en/support/faq/ It's the fifth question. https://www.digitalcombatsimulator.com/en/downloads/documentation/ Beautiful tiled wall of module documentation ready for selection. From Google, its got the answer right there, it's even got a video with 5400 views. I maintain, this is not looking for the documentation. So the last thing to wrap up is why negativity was attracted to this post. Let's see, someone writes a sarcastic topic title: Why is DCS documentation so darned SPECTACULAR?nullnull Where not once but several times they state they can write a better manual than ED, proclaiming that if it were not a fail and was more prominent then they would be able to find out how to use a Windows dialogue box to save their campaign. Yes, the question was, where does it need to be saved. And the answer is that it is completely irrelevant. So we gotta go to the forums to be sarcastic because that's how adults behave, instead of simply asking the question "Does it matter where I save my campaign file?" without all the sarcasm and ranting. And folks wonder why, after years of seeing this behaviour (and the repeat quesitons) why we cannot hold people accountable to acting like adults and thus being treated like adults. It's simply a matter of how you ask attracts the answer in the format you asked it. That's why this happens and it shouldn't be a mystery!
  9. Not to the same screen (anymore), but some displays can be exported to other screens and you can use multimonitor https://wiki.hoggitworld.com/view/Exporting_MFCD_Displays for exports too. There was some software that allowed some resizable export windows but I don't think it is developed anymore.
  10. Yes Rudel most likely has it. If you have two networks separated by two different routers they are naturally unaware of each other, Networking isn't plug and play, each router is creating an internal network and its going to require some configuring that goes way beyond a forum post that includes how you configure your wiring, default gateways, subnet masks and DHCP. Luckily there are videos on the topic so you should find what you need. Good luck.
  11. The Campaign editor works on a linear "did you achieve the set goals or not" basis. Yes>proceed to mission 2, No> refly. It's what all the DLC is based on, so you could review those or some of the existing campaigns that come with modules to see some ideas. To 'get the most out of the mission builder' you would generally not use the campaign builder and would use Lua scripting using the Simulator Scripting Engine which might be out of scope for you, I can't tell, but its not a mainstream activity. There are some off the shelf scripts that have very little configuration that can extend your play. You might like to try a bit more like DSMC and leave your PC on to keep coming back, or servers. But for the vanilla ME the depth is not in the campaign builder, but in the extensibility of the scripting.
  12. So this is a thread about not finding the manual that changed to why the products manual aren't in the same place as the purchased modules and eventually ending up in some casual moaning about how much they are advertised to the surface. The part that irks me is when folks don't look and make the assumptions based on what they could see without looking first, then backtrack to find anything else to moan at to cover the fact they were in error and should not depart from that path with a simple "Ignore me, i found it, thanks for your help". Having written manuals, and being a techical writer with access to the analytics that show who reads them, I know exactly where the problem is. So when people say that ED needs a good <expletive> manual, I disagree. With evidence.
  13. Watching the love going into this project is so heartwarming. The lanc was my favourite bomber as a kid, no idea why.
  14. I'd check the logs for compiling textures. If you just got this map then ran it this could be attributed. NTTR is normally one of the most performant maps in DCS. Read the dcs.log.
  15. I did ask the Moose Community Discord, there was minimal and duplicating feedback, so no follow-ups here. Your average DCS pilot won't understand much of why adding more detailed terrain API's help them, right up until they ask why all the artillery is pointing into a tall building. Turns out that was true of the people that consume Moose in general. What had me absolutely baffled was not trying to use the 2200 folks on Moose Discord to get more visibility on this request. So much effort is still being siloed in the community amongst its time zones, languages, Discord servers and individuals. FWIW if any of the items turn up this year all communities would be delighted without reservation. You are welcome to use MOOSE Discord to announce project milestones or new technologies, we recently integrated a MOOSE voice class to optionally utilise gRPC as its cloud voice output, last year we ventured into a socket class, cloud speech and a couple of bots to see if MOOSE can break out of the mission environment so it more relevant for things that can interconnect to be mentioned than ever before.
  16. So for context I did in fact do searches of areas going back to Nevada map and literally every fence and rubbish bin would report a bomb hit. I dont think anyone wants that, it made using this harder. I prefer the objects weren't returned. But above all, I really think consistency is the most important when we deal with code that can make DCS customers go wow. I'd rather know it was consistent and a goal of map development, than either of the possibilities.
  17. Seems OK for me using the 5 lines of scripting. something else going on. beacons.miz
  18. I think this is a common thought shared by many. I don't think there's much comfort in this direction since the initial ww2 assets were funded by the failed 3rd party project many years back and there's another quote from Nick way back on the cost to create these assets being quite high. In this way i think DCS is a bit of a victim of it's own quality, i'd like a lot more AI planes and ships at the cost of some of that quality but it seems they want to model every nut and bolt these days.
  19. Thats a display driver crash and partial recovery and you will see it in your System Event Viewer. This might be a driver issue, I think a while back there was some talk on a certain Nvidia driver version being bad and people rewinding version. Try the most obvious like updating that. Elsewise read out the event view system errors at the time it happens and it will give you enough to chase through to conclusion. GL.
  20. Sounds like my old one when the cable went. If you hear the ding dong like a USB connect its the headset intermittently connecting. I'd humbly suggest you began troubleshooting on the headset without DCS, get it setup correctly first with the accompanying WMR software.
  21. 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.
  22. 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"
  23. 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!
×
×
  • Create New...