virgo47

An hour into the sale, millions of people saw the video and... shop is still oblivious about it. Shouldn't it be all ready when someone presses the red button?

End of (Summer Sale) or (End of Summer) Sale? Any sale is welcome, of course! I've had a birthday recently, so it comes in handy for a late present.

I was trying to perform the Level 8 training mission (AA-TWS), but it took quite a long time before both targets were "large boxes" (track targets). At that moment I changed them to system targets (TMS up) and bugged one of them (TMS up again). However, it was already a bit late so it seems, as they headed to my right. At this moment, the mission is unpaused, but when I wanted to turn towards them, something that was NOT mentioned in the mission (unexpected autopilot) kept rolling me back left. If I left the plane as is the missile (AIM-120) never reached the maximum launch range and the locked plane dropped out of lock. Was the mission designed with different radar/range parameters or am I doing something wrong - most of the time I'm in the active pause anyway. Lesson 13 - Air-Air TWS and TNDL Use.miz_12092024_22-43.trk EDIT: As a side note, for training missions, I'd not hide the enemy units, it is very frustrating to lose it and not be able to use F10 to understand at least what is happening. This applies to all F16 training missions I encountered so far.

I found this thread after searching for "fuel pressure zero". Because that's what I saw on the multiplayer server in one of UH-1H. I'm not sure what it showed at the start, but there was no other warning, I didn't crash the helo, so I have no idea why the gauge didn't work (or stopped working, not sure). Perhaps also a random issue. I wanted to reproduce it, but could not - and didn't take any track from the first flight.

Rudel's observations are definitely more in-depth, I had no other type of groups in my mission, only my client planes/helos and static units. They may be waaaay down in the priority list to consider as the "first" unit to look upon. But all the other hassle I mentioned, that was definitely based on that groupId (based mostly on the order the units were added into the mission). It would be cool if we could simply say "focus on this unit/object before I select any client".

I was also annoyed by this, having client-only missions that first viewed Anapa aerodrome in a completely different part of the map. From my experiments it seems to be FIRST added unit that is not a client. So recently I started to add some static object first. Be it a cow or some kind of static airplane. It always shows that one first. Reordering doesn't seem possible, so you can try to copy some units (but this may break some parts of the mission). Sometimes, if I don't like the static object in the initial view, I use it in such a way that I move it to where I want it and change it to another object I actually want. But you can do this only for the same category of objects (e.g. static object can't be changed to non-static-model airplane).

Besides this (also found this during the trial), I'm also confused about this: I guess it's wrong? (My previous experiences often proved my assumptions wrong, hence the question mark.)

You have to hover over the other columns, not over the left one - see: And with this info, you can try to use this answer to a similar question of mine by our champion Rudel_chw: Hope this helps and works for F-16 as well. Is it straightforward or practical? Not really. But that's what we have.

A dramatic turn of events here: ISP looked at the problem again, after I asked if they expected I'd talk to Deutsche Telekom or colt.net directly (which was a rhetorical question, of course), and voila, after a week they announced the problem was 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!

While a few bugs are fixed here and there, for me it's an abandonware - I just hope not forever. I despise some cheap bugs most actually, I don't care about the damage model, but that controls named "xy toggle" don't work as toggle? Was there any QA? Or did it brake soon after and they left it there as many other bugs for years after? Yak-52 embodies all the cheap bugs in many other modules that are 99% easy to fix... yet left there. Other than that... it's a sweet prop trainer, would be a great module for those who like these. I do. But the quality is terrible.

I landed in the fourth training mission (VFR landing), got to the end of the RWY and turned right as instructed, but then got confused where to go. Everything was full of other stuff, so I got to the only free spot, but the mission didn't progress - I tried to press Space, to be sure, no help. How was this meant? jf-17-training-cornered.trk

This would make running the server much easier as Windows is not only more costly but also has a bigger performance overhead and is generally less controllable than a Linux server.

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