vsTerminus

People like rurounijones have a greater impact on the community than I think anyone realizes. He and others like him are creating and enhancing game functionality to make things better for the community, but they can't do that if you don't enable them. Opening up more of the game to the scripting interface will do wonders for the community. I know it's hard to go back and create APIs for existing functionality, but it makes a ton of sense to create them for features that are new and in progress. Build APIs as you build the feature and let us create cool things for the community. I support this request fully.

Yea, this is absolutely correct. If Mi-8 Multicrew cannot be implemented in a way that allows solo players to still swap seats online then I would not want it at all; It would effectively kill my ability to use this helicopter in a multiplayer scenario without a human crew. For example, a typical mission in the Mi-8 for me looks something like this: Startup - Middle seat Nav Prep - Right Seat Takeoff - Left Seat Transit - Right Seat Any combat - Left seat Landing - Left Seat Shutdown - Middle Seat I move around a lot. I make use of having two course select knobs to keep track of different things. If you lock a pilot into the left seat here are some things they will struggle with (Some of them are straight up inaccessible from the left seat): - Tuning the radio nav - Powering on and tuning the R-282 VHF Radio (Often used for Interflight online) - Powering on and tuning the Jadro-1A Radio - Powering on and configuring countermeasures - Using the NS-430 in the dash - Reaching the electrical panels, external lights, doppler brightness, and other switches used during startup - Reading the exterior air temp thermometer - Startup becomes a real pain in the butt - Navigate with the DISS-15 Doppler - Read realtime drift angles - Read and configure the fuel gauge Even with bindings, not being able to see the R-828, Jadro-1A, or CMS panels makes them unusable. Pilots in 2D might be able to zoom in and "make the best of it", but in VR it will be that much harder to read anything because of low resolution. A solo pilot cannot navigate or defend themselves properly, they cannot plan their flight, they cannot communicate properly. If locked into the right side you'd struggle with - Using weapons without a gunsight (Kind of important) - Navigating with the ARK-UD - Knowing your collective pitch in degrees - Using signal flares I'm sure I'm forgetting things on both sides even. Almost nothing in that cockpit is duplicated. Ultimately there is a reason this helicopter has a crew of three, and that makes it a perfect candidate for multicrew! But it also means that we cannot sacrifice the ability to hop seats at any time when flying alone. So please, ED, when it comes time to work on this, find a solution that works for solo pilots playing online too.

Yep, you got it. Wish I had known this when I did my trim tutorial. Center Mode and Rudder Trim don't play nice together. Glad you figured it out!

That's my big concern as well. I switch seats a lot in MP and if I lose that ability it will really kill my enthusiasm to fly it online. They have to find a solution where solo pilots can swap seats in MP for this to work.

That would be wonderful. I do have plans to re-do some of these videos and I will include things I have learned since I originally recorded them. If you want to just post here for everyone to read that seems like the quickest way to get the info.out there, and gives me an easy way to find it all. Thank you!

You guys have it figured out, but more or less to summarize, - The slip ball will tell you when you are coordinated, but it does not account for the drift caused by your tail rotor. It cannot detect it. - If you want to fly coordinated and straight you need to fly a few degrees right of your intended heading to counteract the drift. - If you want to fly straight and don't need to be coordinated your slip ball will rest on the line right of center. Now if you flip over to the pilot navigator's side, - The doppler drift gauge will show you the difference in your heading (the direction you are pointed) and your track (the direction you are moving). - "Kick the needle" with your pedals until it is centered and cancel any bank it induces with cyclic roll. - Centering that needle will put you out of coordinated flight, but you'll be flying a true heading. - If you stay coordinated and leave the needle left of center, the number it reads is how many degrees to the right you should adjust your heading to compensate. Which is better? Which do real world pilots do typically? I don't honestly know. I assume they probably fly coordinated for comfort / economy reasons and just adjust their headings, but I'm not a real world pilot so I can only guess.

I'd be interested in doing a cold start video with the more realistic checklist once it's complete. Less of a tutorial and more of an "in case you're interested..." kind of thing. With full credits to everyone in this thread of course.

I certainly plan to create tutorials for the Hind, but it will take time. It also depends on the state of the manual for the module since that tends to be my primary source for information. I'm glad the Hip tutorials are helping!

Of my 1000+ hours in DCS I think the majority of that has been in sandbox missions either alone or with friends. They are immensely valuable to me as a learning tool and as a low pressure socialization venue. More recently I have been trying to make sandbox missions better; Make them less cumbersome to build, and more convenient to fly. Because of limitations with the mission editor I've turned to lua scripting, and now I'm running into limitations of the scripting environment as well. Here is a list of a few problems I'm encountering, and the API expansion(s) which would help me - and others - to build better missions for everyone in the community to enjoy: Note: I'm pretty sure these are all things which have been requested before by others, but I want to lend my voice to the cause and my own personal examples of why these things are so greatly needed. 1. No way to determine which Unit invoked a Radio Menu command There are two ways this could be addressed. I think we need both: The first is to provide a way to add radio menus/commands to a single unit, not just an entire group missionCommands.addSubMenuForUnit missionCommands.addCommandForUnit missionCommands.removeItemForUnit The second is to provide an event for when radio menu commands are called. S_EVENT_RADIO_COMMAND This way we could add radio menus globally when appropriate and then simply key on the event to know when they were called and who they were called by. Why is this important? I made something cool: I wrote the functions that enable a player on my sandbox maps to spawn a tanker directly in front of them which matches their heading and extends out for 100nm in that direction. This cuts down dramatically on time spent just trying to rejoin with the tanker, and makes it easier than ever to practice the actual act of AAR. Any time, any place. No more having to place a dozen tankers on the map so one will always be nearby. The downside? Because I can only add this command to a Group I have no way to know which unit in the group wanted the tanker unless I limit group sizes to one client per group. This has implications, such as not being able to put Hornets in a group together so they can take advantage of datalink stuff, and greatly increasing the time it takes to place all of my client spawns, since I can't just configure one plane and then up the group size. I have to copy/paste and rename and fix all the waypoints. 2. No way to determine what a player is locking/targeting So in my missions players can now dynamically spawn pretty much anything they want, wherever they want. When the unit spawns it will announce everything you need to know about it, such as radio freq, TACAN channel, ILS channel, and so on. But the thing about tankers and boats is that they tend to be alive a lot longer than that message is around. Sure, I can also put that information in the Briefing (Which I do), but one of the features I want to build next is the ability to spawn multiple boats or tankers of the same type and have my scripting auto-increment the radio frequency, TACAN, and ILS channels they are using. I can report that when the unit spawns, but then there is no way for the player to get it again later on when they inevitably forget. We need Unit.getSPI() -- returns a table {point = vec3, object = object} of whatever the radar, TGP, or current Sensor of Interest is focused on (Obviously this should work for anything that can designate a target, not just for the A-10. Everything that lands on a boat or can AAR right now has a radar at the bare minimum, which should be compatible with this function.) This way we could, say, re-send the tanker or boat's information to the player if they lock it up on radar or designate it on the TGP or whatever. However, that brings us to another set of functions we need: trigger.action.outTextToUnit() trigger.action.outSoundToUnit() So that we can send the message and any sounds to the unit directly, not to the entire group (who probably don't care). 3. No way to rearm a plane or access the current state of its pylons We don't typically run "Unlimited Ammo" because it has some undesirable side effects, notably things like not all weapons work correctly with it, and not being able to ever shed that weight without using the admiral's doorbell (emergency stores jettison). It's a no-compromise all-or-nothing setting that doesn't give us the granularity we desire for practicing. We need Unit.getPylons() -- Returns table of pylons {wepName, wepNum, clsid} Unit.setPylons() -- Reconfigure the Unit's pylons based on a given pylon table Unit.addAmmo() -- Adds ammo to a unit Unit.removeAmmo() -- removes amunition from a unit Unit.setAmmo() -- sets the units ammo to given values Unit.getInitialAmmo() -- returns a table of the initial ammo for the unit. Unit.rearmNow() --- forces the unit to rearm Unit.stopRearm() -- force stops the rearming process, because in CA you can do it, we should be able to force it for the player. Unit.getRearmTime() -- returns when a unit will be rearmed. If currently rearming returns when it would be rearmed, if not rearming how long it would take if started now. These should work basically any time, including while in the air. It would give us the ability to do things like rearm the plane using a Radio Menu command or define a "Rearm Zone" in the map and rearm the plane whenever it flies to this location. Not only would that be useful for sandbox maps, but for recreations of Ace Combat missions which I know there is an audience for in DCS. These would also allow for a more immersive rearming experience in single player missions and campaigns where you could rearm mid-mission without needing the player to manually use the Rearm and Refuel window. Speaking of which, being able to disable that would be cool. Unit.disableRearm() Unit.enableRearm() These would toggle the Ground Crew's willingness to rearm a plane which requests it via the Alt + ' window. Immersion! 4. No way to control the weather If you could look at my sandbox mission changelog from the last couple years you would see a lot of "changed the weather" as the only thing in each "version". Sometimes we want to practice with clear skies and no wind, other times in terrible crosswinds or with blanketing cloud cover and a low ceiling. etc. It kind of sucks that we have to quit the mission and edit it in order to do that - especially now that we can watch videos of people just changing the weather any time from a menu in FS2020. Give us the API commands to control the weather and we'll bring that to DCS too. atmosphere.setWeather() -- sets static weather atmosphere.getWeather() -- gets static weather atmosphere.getDynWeather() -- gets current position of weather fronts atmosphere.addDynWeather() -- adds a weather front at a given point and values whatever they are atmoshphere.removeDynWeather() -- removes a weather front. atmosphere.setTime() -- sets the mission time to a given date and time. (Must decouple the time with triggers, if a AI flight spawns 1 hour after mission start make it relative to mission start and not the world time that would be modified here) This would be huge not just for sandbox missions but for campaigns and other SP missions as well, allowing the mission creator to have dynamic but predictable weather. For example, clear skies at the start of the mission which slowly degrade until you end up doing a case III back to the boat at the end, or a rough launch which turns into a calm evening after the main objective is cleared. This would add so much to mission immersion. For MP servers too, this would allow better approximations of realtime weather, where they could poll weather from multiple stations in the region and update them multiple times throughout the mission's runtime. Right now we are kinda stuck with one set of static weather until the mission reloads and can pick new weather. 5. Very limited control over AI shared knowledge and behavior This one's a bit more complicated, and even though I don't have a specific list of functions we need here (because I've not personally tried to tackle this yet as many others have already tried), we need more control over how the AI behave, and how they inform their decisions. The biggest example I can think of here is an Integrated Air Defense System (IADS) Right now my sandbox mission lets users plop down different groups of air defense systems (S-300, SA-6, SA-8, etc etc etc) but they all just have the default behavior of "FIRE EVERYTHING!" at max range. It would be really, really cool if we could use the existing dynamic spawn engine I wrote to create an actual functioning intelligent SAM network where we could then simulate different configurations and practice suppressing or penetrating them without needing to build multiple missions to do it. Other examples would be things like - Smarter tanker behavior, allowing scripting to (easily) redirect them to a new waypoint or to intelligently rejoin with a plane that has requested fuel. - More control over weapons engagement behavior than just "FIRE EVERYTHING AT MAX RANGE" and "Don't defend yourself ever!" It would be great if carriers could defend themselves without also feeling the need to lob missiles at something 250nm away. Eg, being able to set maximum engagement ranges, or prioritized target lists. 6. No way to dynamically add Client spawns This could be a Mission Editor feature too, but right now the one thing I have to go through and hand place in my sandbox missions is Client Spawns. Everything else I can do with trigger zones, markpoints, and lua scripting. The implication is I have to go configure and place spawns for nearly every plane in the game, with duplicates so we can all fly the same thing, and repeat for multiple airfields so we can spawn all over the map. It takes forever and I hate it. It would be amazing if I could dynamically add Client groups to the mission as well, either to specific airfields or to a trigger zone (ideally to both). This way I could define all my spawns as Lua tables one time and simply load them into any blank mission. We would need - The ability to get a list of available parking at any airfield - The ability to dynamically add a Client group to the mission and link it to a parking stall And I would really love to have the ability to spawn any unit "On Ground" as the helicopters and Harrier can do. This would allow us to work around the current parking stall limitations, which make it very difficult to fit all of our spawns into any one airfield (really limiting our choices) even when there is physically plenty of space. Bonus: No way to access the Warehouse right now Alright these are a little bit less focused on sandbox missions and a little more on dynamic missions, but very typically the former trends towards the latter as complexity increases. We need Warehouse class Warehouse.getInventory() -- returns a list of all objects in the warehouse Warehouse.addLink() --- links one warehouse to another with set properties Warehouse.removeLink() --- removes warehouse from linakge Warehouse.setLinkProperty() -- modifies warehouse link properties. Warehouse.addItem() --- Adds object to a warehouse in X quantity Warehouse.removeItem() -- removes X of item type from warehouse Warehouse.setItem() -- sets item type to have X number available. Warehouse.getByName() Warehouse.getObject() -- returns unit, static, or airbase object Conclusion These are all barriers I have run into while trying to build a better Sandbox Map experience for myself, my friends, and for the DCS community at large. All I am asking for here is the tools I need to build better content. That doesn't just benefit me, it benefits everyone. Sandbox maps are quite popular because of the steep learning curve in DCS. We could build better ones than we do today if we just had the support from ED on the scripting side. Give us the power to make cool things and we will. Thanks. (PS, feel free to check out my DCS-Sandbox repo on github -- https://github.com/vsterminus/dcs-sandbox -- You'll see for yourself if you look through the code how much trouble it is to make all this stuff work, but also how cool it can be when it does.)

So when the Hind comes out I plan to work on a tutorial series for it much like I have been doing for the Hip. So to that end, here are some of the things I am going to be attempting to demonstrate that I hope will be present in the flight model. (Don't get me wrong, I'm not making any assumptions that this stuff will or won't be modeled, just being thorough.) Torque Effect Ground Effect Weathercocking Translating Tendency (and Inherent Sideslip) Dissymmetry of Lift Transverse Flow Effective Translational Lift Flapping Dragging Retreating Blade Stall (and by extension, Phase Lag) Vortex Ring State Loss of Tail Rotor Effectiveness In addition to those general concepts, some related flight model tests I would want to be able to demonstrate include: Needle Splitting Hard collective pulls Quickstop Maneuvers Autorotations Throttling down on the ground [*]Different trim modes (All three present in the Hip) [*]Changes in inputs and behavior with AutoPilot on and off [*]Single engine performance [*]Impacts of systems like PZU and Anti-Icing which reduce engine power [*]Impacts of IR Suppressors (I assume it has the option like the Mi-8 does?) [*]Impacts of any engine performance options in the cockpit, eg the Hip's ECLs, Emergency Power Mode, and so on. Nothing mind blowing or earth shattering here I think. The vast majority of this stuff is present and demonstrable in the Mi-8 (LTE being the one I think none of our helicopters have right now), so I have no reason to doubt that the Hind won't be comparable, especially given the similarities between the two birds.

Thank you for the ability to remove the pylons via Rearm & Refuel, but there are a few bugs which make this feature feel incomplete. Here is what I am able to demonstrate: Part A: When starting the mission with pylons/hardpoints on the helicopter When removing the pylons they come off along with Station 3, leaving the remaining weapons to float in mid-air as they are removed After removing the pylons, rearming with weapons will attach the pylons when Station 3 is rearmed, but they disappear again when Station 4 is rearmed and stay off / invisible indefinitely. This leaves all weapons just floating in midair permanently. Like the pylons, the gunsight also reappears with Station 3 and then disappears again with Station 4, leaving you in an armed Mi-8 with no gunsight. It is worth noting before I continue that the ground crew can and will allow you to mount door gunners even after you have removed the pylons. This is expected behavior. This will be important in a minute. Part B: When starting the mission without pylons/hardpoints on the helicopter Attempting to rearm stations won't show any icons until all six slots have been filled The ground crew will refuse to mount the pylons The ground crew will refuse to mount door gunners, even though they were fine with it in Part 1 after the pylons were removed. Expected behavior here is that if the crew can remove the pylons they should also be able to mount them, regardless of how the helicopter was configured in the mission editor. Expected behavior is also that the ground crew should always allow you to mount door gunners without pylons. (As a bonus feature request, I would love to see the ground crew also be able to mount/remove the IR Suppressors, Additional Armor, and Cargo Halfdoors via the F8 Radio Menu in addition to the current Mission Editor options) Attached are two track files, one for Part A, one for Part B. I have also made a video demonstrating these bugs, which you can find here: Mi-8 Pylons - Part A.trk Mi-8 Pylons - Part B.trk

I agree with Xoho, in large part because having rearm and refuel tied to a FARP object is not all that intuitive. The FARP just provides a flat surface for landing where one might not otherwise exist. Rearming and Refueling makes more sense, in my opinion at least, to be tied entirely to ammo and fuel trucks which could be deployed basically anywhere. Now... if you insist on tying refueling to the FARP object itself, could we get one of these and have it count as a FARP?

I have been working on a deep dive tutorial series for the Mi-8 that aims to show you not only how to fly it, but to give you a broader understanding of helicopter flight concepts and a deeper look into the various systems along the way. By the time the series is done I hope to have covered everything the Hip has to offer, and I hope you will feel more confident as a virtual Hip pilot. Or Individual Tutorials: Series is ongoing and there will be more to come. With all of these videos, if you know something I don't please share in the comments section so others can benefit from your knowledge too. Linked in every video description you will find the following: These are some mods that I am using in the videos which you may want to install for yourselves: Mi-8 Black English Cockpit by Devrim Unofficial RoughMet Patch Ace Combat Erusean 3rd RGR Livery These are my primary sources of information, I suggest keeping a copy of each on your hard drive for reference: Chuck's Guide Belsimtek Official Flight Manual Thanks for watching!

So I was having serious problems with phantom button presses that only seemed to be getting worse as I played. I took your suggestion and plugged in the X-55 with my Rock Band powered USB Hub and the problem disappeared instantly. 45 minutes now with not a single phantom button press. Thank you!!