okopanja

I hope you do not mind I sort of went out of the topic. I have not flown the Ka-50 in 2.9 that much recently, so I will also try to replicate the problem.

@PawlaczGMDFrom what I gathered so far and found in internet. Ka-50 at least 2 major versions of cockpit one without ABRIS and one with ABRIS. Additional sub-variants are possible including different SHKVAL screen (e.g. green vs brown). The main system navigation/attack system is called Rubikon K-041 and interacts with pretty much everything. The navigation part of the system in particular is called PNK-800 Radian and consist of several devices including INU. When entering coordinates through PVI-800 you are actually entering them into PNK-800 and Rubikon. Rubikon utilizes SHKVAL to perform the Fixpoint-based update. It can be assumed that Rubikon predates integration of the ABRIS, and that ABRIS was added later, as relatively simply upgrade (it caused the cockpit layout change). There are indications that the ABRIS was actually a product of Swedish company that specializes in civilian navigation. In addition you will notice the Garmin antenna on the 3D model of Black shark. So far the following information from Rubikon is displayed into ABRIS: navigation points fix points targets points azimuth and distance to the SHKVAL view point (this is sadly not accurate, but more later...) You will notice that in mission editor these values are exactly spot on with ABRIS equivalents of these points. This is because mission editor on load loads them into Rubikon with absolute precision. If this is the case the targets will be spot on when you slew the shkval to target points and ready to fire. Now following applies only to manual entry: PVI-800 allows you the entry in (D)DD MM.m format which will introduce relatively large error for latitude. This is roughly +-92,5m. You can calculate this yourself when you know that 1 degree of latitude has certain number of meters (I used one of the online values, and did not check how much it is actually in DCS ). The error of the longitude depends actually on the latitude (parallels are not equally sized) is typically lower than latitude errors. You can not expect to slew the Shkval to the target and immediately lock. In addition the Rubikon seems to be unaware of the altitude of target/navigation/fix points. Instead it, in DCS it will assume that point is at see level. As a consequence: - target points will be usable only at up to 100m altitude - SHKVAL indication in ABRIS will have usable indication of distance up to 100m altitude - in all other altitudes targets points from Rubikon and SHKVAL indication in ABRIS will be almost useless I did interact with ED developer and pointed out that: 1. targeting system that works only next to the see level is illogical, and that Rubikon must have some knowledge on e.g. target point altitude. He did propose that maybe they can assume the target altitude based on helicopter altitude above see. I proposed the algorithm based on the laser range finder of SHKVAL (basically starting with his proposal augmented with iteration along the azimuth until the coordinates roughly match). Still no feedback if they are going to do anything, but I gather they were busy with DLSS and damn spotting dots. 2. manual contains written text and pictures that indicate that PNK-800 has information on altitude of waypoints. I argued that there must be a way to enter those values in PVI-800. It should be noted that there is even a flag in ADI that shows direction of deviation of altitude compared to current waypoint). This flag actually works if you started with preloaded coordinates. So far I got the answer that manual contains errors. At the end I attached the PNG and SVG diagram of devices generated from ED's own code with graphviz. Once you download the SVG to your local storage, open it with web browser. SVG contains additional tooltip annotations. ka-50.svg

I do believe that this will not happen. Personally I believe that each developer should have the freedom to choose the conditions for development and distribution of their work. I also do not thing there is a point to keep pressing this subject.

So zoom should be eliminated?

I gather we have to wait for ED''s equivalent of May 9th parade since this is how Soviets did it.

the instructions do not work anymore on JF-17?

No you would connect immediately without waiting for the livery download. During that time you have drawback of using default livery, but afterwards it would be replaced the same way it get's loaded and replaced whenever any player changes the livery(this is how DCS works already now). As for 10-20GB: yes you can reserve even space, or simply let it fill in and if there is not enough space the game deletes the livery that was not recently used (Least Recently Used).

Why not installing liveries on demand? You login to the server, and your client figures out you do not have the livery for one player? DCS displays you low-visibility livery from default set, while in background downloads the correct livery, stores it in your local livery cache. You would be able to define the size of a cache. E.g. 10-20GB, and the non-used liveries would be deleted based on LRU (least recently used) principle. Benefits: you consume less disk space on clients you get to see all liveries "no cheating" (you ensure the least visible used be default before download & load completes) Drawbacks: ED needs to work to implement this. Either way if they aim for world coverage, streaming of maps is something that will surely be on their roadmap. ED gets larger traffic bill for their infrastructure (people keep downloading from them) your livery is not immediately available on first encounter. Some small amount of resources get consumed on client to download and load.

Making the other players aircraft easier to see in a way they don’t suspect? That’s a cheat/exploit in any other CFS game. Further explanation shouldn’t be necessary. Please see what I wrote later than initial comment.

Another approach would be to determine if there are common textures used in multiple liveries? Now, we all know that graphic designers do not care how many megabytes the livery will take, but they tend to be Mega-pixel-click friendly for everything to look better, and as consequence spend around 0 time thinking if this has impact on disk space or game performance. One could argue we could have several approaches, e.g.: 1. de-duplication of existing liveries, which might save perhaps 30% of disk space. This is essentially some intelligence applied to present strategy, Would need to be enforced by ED, and all liveries are still show to everyone. 2. ED defines mandatory livery pack, if the person wants he/she can download additional packages, either as bundles or specific aircraft. If the livery is not locally found, use the default low visibility from mandatory pack 3. ED defines mandatory livery pack, if user wants to use something extra he downloads additional packs, the viewing user when encountering the user using fancy non-mandatory livery is displayed the default low visibility livery, while in background without affecting performance too much the livery get downloaded and stored in local cache based on LRU algorithm to ensure that disk space is not overused.

Why would that be cheating? Simple map to module default. Each and every new module adds more and more irrelevant garbage by adding more and more liveries that ever were.

Note: this is not about AI, this is about multiplayer. As far as I know, this affects all aircrafts. Not just Viper/Flanker.

I did not expect yet the fix, but I tested just in case: still the same behavior with 2.9.1.48111

Issue is still not really fixed, just mitigated. ED needs to obtain separate certificate for https://dcs.world or disable the SSL interface on that SNI. @silverdevil at this moment http://dcs.world redirects to https://www.digitalcombatsimulator.com/ which is OK-ish Notice http vs https. In general the site has very decent A grade at https://www.ssllabs.com/ssltest/analyze.html?d=digitalcombatsimulator.com (this page if not cached will take 1-2 minutes to generate), but not the A+. However, noticeable is the usage of weaker TLSv2 (TLSv3 would be better) and encryption algorithms (they need to disable some):

Altitude is reset to 0 now. Thank you very much for the rapid fix, but I also found out that it is not 100% fully reset in case of hemispheres. E.g. on Caucasus (N and E hemisphere): 1. Enter the coordinates and intentionally set wrong hemisphere for that map, e.g. W and S instead. 2. Clear the waypoint 3. Enter coordinates for that waypoint again, they will default to W/S. I would expect it to be E/N In contrast untouched waypoint will have E/N by default, so therefore the re-entered waypoint should behave the same way as pristine waypoint. One question that remains it the following: Which hemispheres will be default in e.g. Caucasus, Nevada? Would that be E/N for Caucasus, or W/N for Nevada (since customer may be in a different hemisphere)? Or it will always be E/N (since both Pakistan and China are there)?

I would say this issue is fixed. However, it remains to be see if the new entry of geo coordinates should be: - N/E as default - N/S W/E depending on what the map default is. (Someone flying the same hemisphere would prefer preconfigured airplane to default based on where the country is). Not sure how this was solved in other modules and real aircrafts.

Interesting, e.g. I personally wanted to switch my VKB profile on airframe change, except for now that software does not allow it yet. (trying to get them to listen and provide at least command line tool).

I would write 3rd function with the real logic and call it from onShowBriefing/onPlayerChangeSlot. onSimulationResume gets triggered in other situations as well. E.g. pause/resume Also, check how it works in: -SP - MP on your own PC - dedicated server (with paused and unpaused mission) If it is not a secret: what are you trying to do?

There is no documentation, but it's there in ED's code. I faced the same issue and resolved it with onSimulationResume, but that was before I found out onShowBriefing. I will probably switch to the later, since it appears to be more reliable.

You can use: onShowBriefing() It will be shown when the user has already selected the aircraft and advanced. Briefing is shown at that moment

2 more locations: C:\Users\XXXX\AppData\Local\DCS.openbeta C:\Users\XXXX\AppData\Local\Temp\DCS.openbeta

1. Not really a problem when you gain access to documentation and you know where to look for and you happen to poses the electronic base 2 gens more advanced than opponent. https://en.wikipedia.org/wiki/Adolf_Tolkachev 2. Su-27SK manual explicitly states inability to relock. Apparently the missile is primed before actual launch through main radar's side lobs. If this is true, on relock it is not possible to synchronize missile anymore. 3. You can use TWS2 mode with Mig-29С but, upon launch the target it will switch to something akin to the DTT with addition of triggering the RWR warnings. I asked this some time ago and did not get straight answer, but perhaps another case of point 1? 4. Comparing the radar equation results between host radar and missile seeker on one side and active missile radar on other side would probably show the advantage of second variant (not to mention the benefits of having more freedom to stay out of range, or network-centric tactics). Also note that limitation of R-27ER range, does not come from the engine, but rather from the same power generator as used on R-27R, which limits operation to a maximum of 60 seconds. It should be noticed that certain slides on radar operation of dubious quality circulate around. The translations into English largely amount to techno gibberish. Also note that we are talking about early 80s tech vs late 90s up to 2006-2008 on the other side. E.g. during this long period 10+ generations of CPUs did proliferate. We are talking about having limited resources of e.g. F-15C/Flanker radar computers able to display only simple shapes on HUD/MFD compared to modern stuff (15-17 years compared to nowadays).

https://wiki.hoggitworld.com/view/DCS_hook_onPlayerChangeSlot

The main problem is that when you join 2 metal materials, the join is never perfect. The resistance will some somewhat higher, but worst is the forming of so called parasitic capacitance. These can interfere with the signal. Even worse when you do it with 2 different materials. And btw: soldiering is not quite bendable. Do it properly or you will suffer from inexplicable connection losses.

Ethernet cables are not re-soldered, ever. Even if you succeed you will not end up with cable of high speeds. Ethernet cables are pressed together with special tool. If you need a longer cross over cable, either buy one finished or buy connectors, cable and something like this: https://www.amazon.de/LogiLink-WZ0012-Netzwerk-Werkzeug-Tasche/dp/B003Y3S0U2/ref=sr_1_4?keywords=lan+kabel+zange&qid=1699783293&sr=8-4 Here: