Zyll

EDIT: I ran textures.ps1 following slightly modified version of your instructions above, and it created the folder structure but no files. opened pwsh (Powershell 7) as admin, ran "Set-ExecutionPolicy Unrestricted" closed this window, and opened a new pwsh window and navigated to d:\DCS texture convert (where my texconv.exe and the ps1 files are located ran ./textures.ps1 and let it find my DCS folder It created the Mod folder, has all Bazar, CoreMods and Mods folders with subfolders under them, but no files It created the Temp working folder too which is empty Total time was a few seconds. I don't suppose I need any other files do I? Does the "Set-ExecutionPolicy Unrestricted" apply to all future windows of pwsh until I restart the PC? --- EDIT2: oh wait a sec, let me roll back all of Taz' optimized packages on my DCS installation first... --- EDIT3: nope, didn't make a difference re-running the script after reverting Taz' packages Admittedly my ability to read PowerShell script is rudimentary. So this iterates through the entire dcs install and finds all loose and zipped textures to create a converted version in a mods folder, nice. Does it have any special handling for certain files deemed not to convert, like the canopy glass that Taz mentioned he omits? I'm going to do further testing of this today and will give my feedback. Zyll @ TAW

Amazing, I'll have to give this a try. I noticed you aren't processing files in coremods folder, where Taz did in the original post. Is there a reason? Zyll @ TAW

How many dynamic spawns can be filled on the Super carrier and Tarawa? At FOBs it seems you have at most the number of pads, but carriers would behave differently I hope. Otherwise we need to continue to use traditional spawns. Hard to test the theory without several folks, so thought I'd ask here in case anyone has already tried. Zyll @ TAW

Not sure I see the problem, but if I understand correctly, you can fix your issue by inverting the Y axis and leaving the X axis as-is. Go into Control Options - Axes and Axis Tune. Zyll @ TAW

In a mission, take an airbase and allow dynamic spawns create a dynamic spawn template (I tested all helos I own) and assign it to some aircraft in the Resource Manager A/C list fly the mission and spawn into one of these aircraft view the F10 map You will notice that the flight plan does not display in F10. Aircraft do indeed have the flight plan (easily seen in the TSD of the Apache for example).

Yeah agreed, unlike a player, George won't happily over torque the bird to 120% to keep in an out of ground effect hover. Check your PERF page to see if you are setting George up to fail ;) Zyll @ TAW

Just like basically every other helicopter in the game, we need to be able to have different trimmer modes because we can have un-sprung pedals and centering joystick, or vice versa.

The DCS API getCategory function returns 0 as the unit category when joining a helo from a dynamic slot. But 0=airplane, a helo should return 1. This impacts any scripts and APIs (e.g. Moose and Mist) that attempt to identify and act upon helo spawns. Regular spawns work as always, its the dynamic slot spawns which are broken specifically.

Oh and of course I wouldn't stress enough that a good IDE is key to maximizing your effectiveness (and enjoyment) while coding in any programming language. I use Eclipse LDT because of the strong intellisense support, but there are other options out there. Zyll @ TAW

Honestly, you don't need to go deep into learning the nuance of Lua to be effective. Expertly traversing tables (hint: everything in Lua is pretty much a table) and then getting familiar with an API (I personally transitioned over from Mist and DCS vanilla to Moose) will net you the biggest bang for your buck. It's enjoyable and rewarding, if you are into this kind of thing. Join us in the Moose discord if you go down this direction. https://discord.com/invite/8mu8cZV9Gh Zyll @ TAW

Internal Aux Fuel tank 100 gal for Apache is: {1,3,43,1700}

Hmm, did the waypoints for that randomly placed spawn work? They didn't for me, so I assumed the whole template was non functional Zyll @ TAW

echoing earlier comments about being able to define a more generic dynamic spawn template (airframe-agnostic), but also could we somehow NOT use up a parking spot with these templates? Certain airfields have very few slots to begin with, and filling them with invisible templates hinders their usefulness. Perhaps allowing an air start within proximity of the airfield to serve as a dynamic spawn template is an option.

interested in how you generated that list of gunpods and equipment? The Apache FCR is missing, and I'd like to be able to determine the codes for other equipment as they arise.

I uncommented out these two lines from AH-64D_BLK_II.lua and analyzed the output from Export.log: function ExportScript.ProcessIkarusDCSConfigLowImportance(mainPanelDevice) --ExportScript.DeviceMetaTableLogDump(mainPanelDevice) -- comment this to prevent log flooding --ExportScript.ListIndicationLogDump(mainPanelDevice) -- comment this to prevent log flooding

is anyone having any issues with their ExportScripts after patch 2.9.6? My script for the Apache which was setting indicator statuses in my Stream Deck for the Apache stopped working and I am trying to troubleshoot where the issue lies. EDIT: turns out the Apache got a new list_indication() somewhere up high in the list, which pushed all the others down one, breaking the CountermeasureReadouts() func as well as my own custom stuff. I had to increment the list_indication(24) to list_indication(25) in the aforementioned function, then stuff started to work again.

Necroing this thread. Apparently with the 2.9.6 patch, my mouse with a polling rate of 1000 reports per second was the cause of my terrible sporatic frametimes. Moving the mouse and monitoring performance made it very obvious this was the sole reason for my performance dip with this patch. If I hadn't experienced this issue years ago, I might have never known to look at the mouse polling rate again. This has to be fixed, there's no excuse to re-introduce a bug like this years later. EDIT: in case it wasn't clear, this was fixed a long time ago and the bug has resurfaced with the latest patch.

Thanks for sharing. I'm following this thread in the hopes that a more elegant solution is available as well. Zyll @ TAW

I love the comment about visiting the mole people lol. Zyll @ TAW

Hey JetCat, I don't suppose you are able to remove these in your excellent clean Apache cockpit mod? [emoji120] Zyll @ TAW

Lol thanks guys for confirming. Zyll @ TAW

Obviously a very minor thing, but a little peeve for me anyways. Since I've had the Apache, I've always wondered about these scratches, either they represent green paint under the black paint of the cockpit panels (and are intentional), or I'm missing a very minor texture somewhere. Just wondering if anyone else has seen this? null

Let me play with that a bit. I want to still see errors and informational messages that help mission makers troubleshoot their scripts, I just don't want to see all the other stuff that is being obsessively logged. Thx Gater. Zyll @ TAW

turns out I could have just made my life a whole lot easier with this simple line in a mission script (assuming sanitization is turned off): lfs.writedir() I can determine the server with this since the path will be specific to the folder under Saved Games that it was installed. alternatively this worked just fine too: dofile(lfs.writedir() .. "Config\\serverSettings.lua") grab any server setting from this file

If you launch a mission (no scripts) in single player, you will not notice any logged events in dcs.log, unless you explicitly request them via scripting. That's good. However, if on your local game you launch the same mission as a multiplayer server, or you put the mission (no scripting) on a dedicated server, then your logs fill with messages like these: 2024-05-31 15:57:28.565 INFO Scripting (Main): event:type=mission start,event_id=1,t=0,linked_event_id=0,ta=28800, 2024-05-31 15:57:28.565 INFO Scripting (Main): event:linked_event_id=0,t=0,event_id=2,type=took control, 2024-05-31 15:58:14.783 INFO Scripting (Main): event:type=engine startup,initiatorPilotName=TAW_Zyll,place=Kobuleti,t=42.808,placeDisplayName=Kobuleti,initiator_unit_type=UH-1H,initiator_object_id=16777729,linked_event_id=0,event_id=8,initiator_coalition=2,initiator_ws_type1=1,initiatorMissionID=2, 2024-05-31 15:58:14.792 INFO Scripting (Main): event:initiator_unit_type=UH-1H,type=under control,initiator_object_id=16777729,targetMissionID=2,target=Rotary-1-2,t=42.808,initiatorPilotName=TAW_Zyll,initiator_coalition=2, take a Huey door gunner firing into a group, and you can imagine the logs just get filled with unnecessary messages, which can hinder performance. If there is a server configuration to remove these event logs, I'd love to know it. If anyone is not seeing these messages running as a server (local install or dedicated), I'd like to compare notes. Can something like the above be used to REDUCE the amount of logging? What I don't want to do is eliminate mission makers' ability to actually log events to troubleshoot their scripts, but I don't want events to fill the logs when I didn't ask for them thanks,