virgo47

I've just tried the third training mission - Navigation - and discovered this situation: Was this the intention? My experience is that many Caucasus runway recommendations in various provided missions are wrong recently, so I can only assume this is another case of it. Sometimes the slight wind in the right direction helps, but the problem may be caused by 0 wind as it seems to affect some Caucasus (and perhaps not only) ATCs. So either the mission needs to be fixed, or the whole ATC default runway problem needs to be escalated. I doubt Caucasus ATC is fixed anytime soon, so perhaps the mission fix is the easier one. EDIT: This seems to be the opposite problem, reportedly, the runway with small non-zero wind was fine long time ago and is wrong now. Not sure how this is related, but Caucausus ATCs are defintely funny:

EDIT: tl;dr: Try killing the other dcs.exe process. If that doesn't help, try waiting for a few minutes. Aaargh... I though I'll not need to return to this thread. However, just killing dcs.exe did not help me this evening (tried a couple of times). Restart didn't help either. I didn't do anything wrong, yet I can't play the game! Why isn't the launcher process finishing? What is it doing? It's not just a matter of waiting, it's been taking minutes already! Please, any tester or ED stuff, what can be the reason for this? Before the launcher I hadn't had this problem... although I didn't suffer from it before the most recent 2024-08-09 update. Can this be in any way related to my other woes - suffering from the routing through colt.net? I'm probably seeing things at this moment, but I just want to start the game, nothing else. ... Not really an edit, just writing the post for some time "helped". After MORE minutes the game started. So... I guess, try killing dcs.exe to try again, I'm not sure about restart, but other than thet - just wait for few more minutes to start the game? I'm asking about the network problems, because I don't know what else can seemingly randomly cause this delay in start. It's not 100% repeatable, even after the latest patch the game sometimes starts just fine. But ED guys, you programmed the launcher and its interaction with the game, you know what may cause this. I have no clue, really. For me the "black box" just started to behave worse.

Thanks for the painting. The problem is the collision detection/interaction, the dive of the tail into the ground was pretty obvious. Of course, I often clip the tail rotor because I suck in piloting the chopper, but the tail skid is of no use as it is now. If you're lighter on your cyclic and ahead of the aircraft you may not have the problem. We often practice taxi and "elephant walk" and if I don't see soon enough that I need to slow down, I clip the tail rotor with a few knots speed. I'm not sure how realistic that is, but it is strange that the tail rotor is clipped and the boom and skid is untouched, to say the least.

This is only partially helpful because not all touches are equal. UH-1H and L-39 are just a few modules with long-term bugs, L-39 got a new obvious bug introduced in 2.9. Those are long term stable modules which simply still have many bugs. I don't expect all of them being fixed, I'm a SW developer, so I know how things are. But having little to no hope majority of them will - and we're talking about well documented bugs, some of them known for years - is kinda sad. Are the modules broken? No, definitely not. But they are full of control inconsistencies, missing or broken animations, etc. So the statictics in the Boolean terms (touched/untouched) is right, but doesn't paint the whole picture. Perhaps the module got some love in 2024 when it's not on the list anymore, but oftentimes not enough love by a wide margin.

I've just started the second training mission for the first time and very soon I got to the step where brake pressure is checked. However, these are my results - completely other way around for PARK and full brake. With the switch in PARK: And when pressing the toe brakes: Also, 1306 is not >= 1450 PSI, if it was meant for the parking brake. EDIT: Attaching the track file. jf-17-brake-pressure-bug.trk

It's probably with colt.net, really. But the result for me is the same. Anyway, for more than two years I thought ED's main site kinda sucks and only after starting this thread and - in doing that - falling down the rabbit hole, I realized the problem is somewhere else. It's a bit of a slap on my face, as I often try to check stuff before jumping to conclusions - yet I often jump to conclusions anyway. Somehow, before I start to write about the problem somewhere/anywhere, I don't get it. Oftentimes, I get it before I finish the post and send it. Oftentimes not. Stupid me, I could have tried traceroute and other stuff before starting this drama. But perhaps someone with a similar problem finds it before they do the same. Let's move on... Thanks guys.

I contacted my ISP (Slovak Telekom) and now they responded that the problem is outside their network and they can't affect the routing. So their mother company Deutsche Telekom AG routes the packets to colt.net - which seems to be the problematic hop - and they don't care that a significant % of the traffic through there is wasted. So I can try some VPN or ... contact Deutsche Telekom AG directly, or ask colt.net to "just work"... I thought big players could do better with WAN routing and would find an alternative to a route like this. I was wrong, as I often am. Anyway, apologies to ED and their site - obviously, it works better than it seems from here. EDIT 2024-08-20: ISP looked at the problem again, after I asked if they expect I'll talk to Deutsche Telekom or colt.net directly (which was a rhetorical question, of course), and voila, after a week they announced the problem is fixed. And indeed, while colt.net is still in the route, it does not throw away my packets and my favourite ED page works more reliably now!

Yeah, I've heard about shutdown being "less shutdown" then restart, was shocked by the info and turned it off somehow. There is a checkbox "Turn on fast startup (recommended)" for that which is ON by default, I set it off. So that should do it. But good you mentioned it, because that can drive users nuts why some things are not fully restarted after shutdown!

I've started to experience this after the latest patch ... gosh, I wish the launcher showed the version just like DCS main screen does! The Hook updated, you know. I've not started DCS before since last restart (yes, I completely shutdown and restart my computer), so I guess this is somehow Launcher related? I exited from the error, found dcs.exe in Task Manager/Details, stopped it, tried again and started the game just fine. The version is MT preview 2.9.7.58923

Thanks @silverdevil, interesting info. If I get to more specific info I'll add it here. For now, it seems it gets all wrong somewhere around Zurich which you're lucky to avoid somehow.

I assumed forums and www.digitalcombatsimulator.com are different servers, or even multiple servers on the backend. The funny thing is that I have no problem with forums, this is snappy server and always works fine. The main DCS site and everything related (e.g. shop) is hit and miss. Sometimes it times out, rarely it appears fast. Most of the time it's just slow. Slower around patch times, I totally understand that. Timeouts are annoying because they are not always obvious, e.g. when I change shop filter the site just does not respond ever (does not show the "show" link, buttons stay disabled, etc.). The ways of the internet are mysterious and it may be ISP problem as well, but it is very selective then. I have virtually no problem with other sites I regularly visit. I made some ping tests - the first one is google.com, the other one is digitalcombatsimulator.com: > ping -n 100 google.com ... Ping statistics for 142.251.36.78: Packets: Sent = 100, Received = 100, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 6ms, Maximum = 9ms, Average = 7ms > ping -n 100 digitalcombatsimulator.com ... Ping statistics for 93.115.211.146: Packets: Sent = 100, Received = 64, Lost = 36 (36% loss), Approximate round trip times in milli-seconds: Minimum = 14ms, Maximum = 15ms, Average = 14ms The ping time isn't bad - but 36% ping lost is crazy. I actually didn't expect such a loss when starting this post. The clue may be in the traceroute result: Tracing route to digitalcombatsimulator.com [93.115.211.146] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms sagemcom [192.168.1.1] 2 2 ms 2 ms 2 ms st-static-bckb-198.213-81-232.telecom.sk [213.81.232.198] 3 3 ms 3 ms 8 ms 10.69.253.125 4 4 ms 4 ms 4 ms 80.156.161.128 5 4 ms 4 ms 4 ms 62.159.61.127 6 * 24 ms 24 ms ae2.7.ear1.zur2.neo.colt.net [171.75.8.1] 7 25 ms 25 ms 25 ms GREEN.CH-AG.ear1.Zurich3.Level3.net [213.242.82.42] 8 * 14 ms 15 ms 146.228.55.4 9 44 ms 29 ms 28 ms 109-106-19-250.static.xelon.ch [109.106.19.250] 10 * 14 ms 14 ms www.digitalcombatsimulator.com [93.115.211.146] Tracing route to google.com [142.251.36.142] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms sagemcom [192.168.1.1] 2 2 ms 2 ms 2 ms st-static-bckb-198.213-81-232.telecom.sk [213.81.232.198] 3 57 ms 8 ms 7 ms 89-24-28-19.customers.tmcz.cz [89.24.28.19] 4 7 ms 7 ms 8 ms 192.178.98.175 5 7 ms 7 ms 7 ms 142.251.224.127 6 7 ms 8 ms 7 ms prg03s12-in-f14.1e100.net [142.251.36.142] It is clear that Google is routed differently on the third hop already, but that doesn't need to be the problem. For DCS, it seems to go through some Swiss nodes, 6th of them introducing some packet loss, which only continues on hops 8 and 10. Of course, if the problem is only on my end and page is snappy (or at least not slow) for everyone else, then I accept it and live with it.

EDIT: Not a site problem, probably a routing one. Original post: I experience very slow site www.digitalcombatsimulator.com. Forum is fine, it's probably the fastest thing around DCS. But the main site, shop, filtering there - it's not a second or a few seconds. It's regularly ten seconds or more. I know we have to wait - and you know we probably will wait. But please, make it faster somehow. I can only assume this is also what causes random 500 errors (not the long term ones) or infinite "radar" waiting thing in the Game Files section of the Launcher - or perhaps occasional never ending server load? I don't know, I can only guess. It is quite frustrating. Please, try to make something with your infrastructure, because it is not easy to figure out what is not working - sometimes it's a bug, then it's an unresponsive infrastructure and when it all combines it makes things unnecessarily frustrating.

Hi @xoomigo, there is some progress. I can see more lines with NS430 in the output now - see the attached log. It seems it knows about it now + the initial state is communicated. However, when I rotated a knob (encoder type) on NS430 no events were sent. l39-ns430-try-2.log

I'm attaching complete logs from starting the command, then loading the mission and pausing it after a few seconds. Both Supercarrier and NS430 only appear in the initial list of found modules, nothing after that (search "cvn" for Supercarrier actions, none found). For L-39 with NS430, I also toggled the NS430 popup before the pause to ensure it worked - no reaction in the log for that. coins-l39-ns430.log coins-supercarrier-case1.log

Just a side note: 1 m/s = 3.6 km/h, not the other way around. 100 km/h is 27.777... m/s

This seems to be a general problem with PAPI lights on Caucasus and perhaps on other maps too... Batumi ditto. It shouldn't be hard to fix (if it is, then something is seriously wrong), but it's like this for a long long time.

I've never tried it before, so I don't know whether this ever worked. I tried it now, I got negative/no connection info for NS430 and no actions worked. I checked with dcs-coins.exe -v and nothing was going on for NS430 when I moved some of the knobs in-game. While setting up the test, I was surprised by the offer of actions for MENU button. It's a simple button and I don't know what this means: This may be a deeper DCS-BIOS problem, I don't know. @xoomigo have you tried NS430? I've got only the basic level without the 3D models for some plane, but I believe that should make no difference.

I appreciate the positivity, but that is still an overstatement. When you have a crayfish, you still don't have a fish, just a substitute for it. It's a matter of perspective, for me it is a big upgrade from TWCS, but some things are gone. Not details really, quite useful things. I've been using STECS for over 10 months now and I'm happy overall, kinda like a marrige. In good and bad, we're in this together.

I tested the training #4 Landing - Difficult (IFR) and I was immediately surprised I have to fly so far away. I believe, previously the RWY 10 was used for landing - which is the shorter way. This is corroborated by the voiceover that mentions markers (available only for RWY 10) and wind from south to north and banking right - which would indicate the approach from the west. But now the mission leads me around as the Return point is for the RWY 28. The funny thing is that the instructions about the left rudder and right bank still apply because it seems someone found the problem and reversed the wind (which still means some of the voiceover is incorrect). But this still makes this training mission unnecessarily long/boring - or frustrating when it needs to be repeated. (It feels easier now than in 2022 though, but I believe it's reasonable difficulty.)

FC got some love, Su-25(T) brakes did not. I know it's not officially a bug, but it kinda is, really.

I wanted to search for some aircraft on the server: However, given our aircraft use various prefixes, it doesn't help me, because I can't search for "hot" to find "UH-1H hot". But it's nice the search is case insensitive - it would really be insensitive to make it case-sensitive for obvious reasons - this was actually my first guess because I didn't expect that "contains" semantic is not used by default. Minor problem also occurred when I wanted to delete the last remaining letter (the first one), it felt very laggy at that moment. I don't know why, because otherwise, the search looks pretty snappy to me (which is a good thing). EDIT: I know about the Availability dropdown, perhaps "hot" was not the best example, but the essence stays the same.

I use opentrack which also has a shortcut disabling the tracking - however, this does not reenable mouse movement nor all those View * (slow) bindings which still stay inert. Not to mention that if I want to have it on the HOTAS the button is taken by opentrack software completely, while in DCS I could utilize its powerful modifiers.

Works on my end and it's even in Saved Games, so that's a progress, I guess.

Just a bit of an update - it's done differently with 2.9.6 now:

Great there is a way - and actually, this is a better way, because finally this is a Saved Games setup, not messing with the installation stuff. Of course, *.lua suffix would be more handy for syntax highlighting in editors. But thanks for the info!