dutchie_031

Hiya! For my project https://paddles.contact I've been experimenting with ways to more accurately detect the wire that's caught. Locally `getDrawArgumentValue` works perfectly, however when on a dedicated server it never returns what wire is caught. This makes some sense, however, other drawValues are returned (eg. doors, landing gear, tail hook, etc.), so the assumption that it's because there's no rendering on the server seems wrong. So it's somewhat hard to assume what is and what isn't returned. So I thought to create a post here and see if I could get a response and maybe it's a bug that can (somewhat) easily be fixed! So would the wire state be retrievable? Currently the argument values that are working in the model viewer and locally are: Nimits: 141, 142, 143, 144 Forrestal & Kuznetsov : 400, 401, 402, 403 How to replicate: Use "getDrawArgumentValue(400)" for example and see the difference in return in single player vs dedicated server when the 1 wire is caught. I've tracked over 50 000 landings and have a lot of servers that are using it, so would absolutely love for the wire to be detected as my ML models only go so far and an absolute value would be way better! Kinds regards, Dutchie

An absolutely awesome event that was well worth all the effort! (To be edited later: Will insert the link to the RedFlag Script as it's open sourced and will be released officially once cleaned up and adjusted for general use as well as improved with the feedback provided.)

Hiya! When building multiplayer missions having runway strikes being done and available always adds quite a thrill. However, when it succeeds it's hard to continue to adapt the balancing. Currently runways are only repaired after 60 minutes (hardcoded) as far as I can see. What would be awesome if would for example be something like: ---repair the given runway for operations ---@param runwayName string @the name of the runway, as also specified in Airbase:getRunways() function Airbase:repairRunway(runwayName) end ---OPTIONALLY ---sets whether or not DCS will automatically repair runways after 60 minutes ---@param autoRepair boolean @true or false function Airbase:setAutoRepair(autoRepair) end The idea is that in bigger dynamic missions it would be awesome to balance the runway repairs ourselves. (eg. faster when the resources/personnel at the base are higher and slower when certain resources are lower). The second function would be to disable automatic repairs. This would be in line with the logic of airbase captures, where you can also enable/disable the automatic capture and then force the capturing yourself. PS. Removing the craters itself doesn't repair the runway it seems via world.removeJunk() as AI doesn't want to take off even when the runway is pristine after that. PPS. To all those having the itch commenting underneath here that it wouldn't be realistic. Please just don't. This would just add options, and options are what us mission makers can use.

@Roughmaster Hiya! Love these. Are these the ones that have heen teased through most trailers for Kola and now the 2025 and beyond video? Any updates. As a Dutchie I'd absolutely love some representation of the EU vipers in the game

Hmm yeah, I reacted mostly to the Per Unit F10 command Not to the message only per se. I read the title in that context and read the rest just as such haha I kinda would like units to have F10 commands that are specifically linked to that unit (without them having to be in seperate groups)

@BIGNEWY Hi BN, Sorry for tagging as you're tagged very often. Just saw this post and no response from the ED team, so thought it would be sad if it was missed I think the mission making community would be very grateful if this would be looked at. Basically the work around now is having 1 client per group, but that has a lot of downsides as well. And with the new missionmaking options focusing on easy group reusability (comms, loadouts, waypoints) it would make mission making a lot easier. It would also make it possible to make more engaging multiplayer missions. Tankers, ATC etc. already are specific to the user initiating. It would be nice to extend that option to the F10 (other) menu. Both in the API layer and mission editor. Kind regards, Dutchie

Bump?

Bump @BIGNEWY Any idea on this? I had a similar issue in making a mission recently. We do have the "Unlimited Fuel" now. It would be nice also having "Unlimited Ammo" as a similar command. On top of that as a very next level nice to have would be to have certain pylons unlimited while other wouldn't. It's quite a niche, but it would add some options for mission making, especially when making missions for training environments. If not per pylon, it would be nice to have a "Unlimited AAM" and "Unlimited Weapons" distinction. Unlimited for AA missiles to simulate captive missiles that still get "launched" for the PK calculations. (immortal players) Have it all working in scripts now, PK miss/hit etc. Only thing that's missing now is a flag for unlimited weapons. From top to bottom of fine graining. Any would do for me personally. Group -> Unit -> MissileType -> Pylon Ps. Happy Holidays all

Hi, Bump. Facing the same issue. Curious if you ever got a fix @Yukari Especially the script part.

Hi, just wanted to draw your attention to the following. If this post is a duplicate of an earlier reported issue, please mark it as duplicate and add the duplicate link. I'm an admin at a community server and we run 8 instances over multiple servers. Our users are reporting higher pings and way more timeout kicks while they should be in a zone which is fine. What some users have also reported: It seems ping spikes are not corrected as quickly as needed and a ping spike (which in essence isn't something "wrong" or weird) is only coming back down very slowly even though the connection established itself fully again and the reported ping should snap back down to the "actual ping". Obviously it's very hard to debug the network on our end, but there might have been some changes in 2.9 that cause the behavior as described. Thanks!

Was actually curious what the state of investigation and answer was of the actual question from OP. Just curious if that part is also being looked at or on the list to be looked at The Knife edge was only mentioned, but not the main part of the actual initial post imo. But I have the feeling this post is now titled and deemed only knife edge related while it's not.

Hi Joe! Learned nothing yet! Have you got it to work with any other modules? Or is it a not only the F-16 that's failing? Sadly...

Hi there! I've been searching through the roadmap and other notes and forums, but could not find any plans of using the HSD for markpoint creation, From others I hear this should be possible, so I just thought I posted something here. Sorry if I'm double posting, if so, please just let me know. Kind regards, Dutchie

Hi guys, I don't know where to post this question, but I'll just start here I'm trying to export info from LoGetTWSInfo() export function yet it keeps being Nill. LoIsSensorExportAllowed() // returns true in my case (it's single player anyways) There is other functions that get Sensory data that work. So I'm curious why this one isn't. I've been testing with the F-16. Anyone got some pointers?