okopanja

That is logical, since most airplanes have radars pointing into direction of flying. Although I assume it would also be able to pick up sidelobes as well as rear lobes if the aspect change occurs when missile is already very near. Anyone who can help with accurate translation?

I do not recall being able to use this missile effectively since at least 1 year. Al the time on multi-threading. My understanding is the ED needs to fix this since 3rd parties do not control weapons anymore. I do not recall being able to use this missile effectively since at least 1 year. Al the time on multi-threading. My understanding is the ED needs to fix this since 3rd parties do not control weapons anymore.

1. I think bandwidth is not an issue, but rather latency and low packet loss 2. I think that USB can be tunneled through IP in some cases, would be interesting to hear that part too.

misread...

You can not sell the DCS as a service due to the current licensing, at least not without ED approving. At best you can seel the DCS-ready service-setup with user installing the software and bringing own licenses.

I gather any cloud service would go bankrupt if offering GPUs to DCS players. I wonder if this would be a viable business model for ED? DCS-in-the-Cloud

You have multiple display adapters, try explicitly using NVidia. E.g. laptops often have integrated + nvidia, and I recall that first time I installed DCS, I ended up with horror performance until it turned out DCS used the integrated adapter. Forcing the Nvidia in control panel solved my issue back then. Not sure if you have there Nvidia control panel... it's interesting to note that parsec acts as display adapter, this is probably to enable it to capture the image and encode before it streams to your client. IMHO: your idea as attractive (would be interesting to hear at some point about your cost calculation), why buy the super-expensive PC, when you can rent one. I really think you need a ED developer to comment on this.

Strictly speaking this is only if you aim to use it maximal distance against non maneuverable target. However more realistic use case it to utilize it on closer targets and leverage it's huge NEZ to kill the opponent which actively attempts to escape at far greater distances.

Why?

I will try this, but if it is true, I would consider this as a bug.

I think in order to exchange DTC with ground crew you need to open the cockpit, but if it works for you ok...

4 and 5 for cold jet would be part of regular startup sequence. For hot jet you need them to bring the route in. I had empty nav mode on spawn, really had to do it like this.

I did try ED way: Entered route before slot selection Picked option to make it a route for the next slotting Selected slot and spawned Opened cockpit Requested DTC update Inserted DTC In left MFD, selected ALL, and then transferred Nav points were visible.

Thanks

I was absent from DCS for a month, but I believe there are multiple possible answers to your question. 1. if you ask for addition made by ED that allows you to create route points for the next aircraft you want to slot into. I did try this briefly with FC3 where it works. I may try it later in the evening with JF-17. 2. The vanilla F10 approach with markpoints should still work with some minor adjustments compared to before 3. I also wrote a mod that can enter the waypoints:

In addition to using sealing cooling pad make sure your fans run at 100% when DCS is running. You may repaste the cpu/gpu, but this can be risky. If you used your laptop with DCS for 2 years, your paste is effectivily a stone by now.

Nice, kind of annoying the nobody did enforce the naming consistancy.

DL is a separate mode, in this mode ypu can recalculate the local angle needed for slewing from known information. We are talking here about target points that should provide meana to slew shkval and allow single pilot to do slight manual changes to targets observed. For this mode we are missing either absolute/relative height to calculate correct angle. If you have an declassified document or even idea how this worked IRL it would be interesting to hear.

You do not need much space to reach Mach 2 within 7-8 minutes with flanker, you just need to do circular climb and be careful with the stick not too pull lots of Gs. Would be interesting to see Mig-25/31 with their huge engines at the same task. Yes, you will spend a lot of fuel, but it is easily doable.

thanks for this screenshot, I was wondering about different early cockpit layouts I found while digging for more information. So if no ABRIS could be used, how did the slewing to general area of target work from Rubikon? BTW, this is the ADI instrument I have located: https://www.ebay.co.uk/itm/355311818311 https://i.ebayimg.com/images/g/1ksAAOSwQYhlhghf/s-l1600.webp

Yes, at the moment these are indeed speculations with 3 already state options and maybe one more if we use the laser assisted algorithm (as we know laster is getting used when obtaining corrections from known fix point). While these might be a speculation I am merely trying to help solve the mystery of non working features in Rubikon. Still it appears that ABRIS was very well equipped to integrate either with aviation standard or non standard equipment. E.g. the following screenshot comes from IRL manual and it indicates not only A/D and D/A konvertors, but also ARINC-429, which is de-facto a standard in civilian aviation, allowing different kinds of messages to be transmitted over the shared line. In comparison our BS3 has the following with minor glitch (digital 5-6 overlap with each other), but clearly indicates the active lines 1-5 and non-active 1-4 analog. In the real manual the following is stated for the ABRIS: "В зависимости от конфигурации пилотажно-навигационного оборудования, изделие Абрис может взаимодействовать с приборами, размещенными в составе бортового комплекса по различным интерфейсам: аналоговому стыку с использованием ЦАП и АЦП, стыку ARINC-429 (ГОСТ 18977-79) или стыку RS-232 (ГОСТ 18145-81). Все реализованные стыки дуплексные – позволяют изделию Абрис принимать и передавать стандартизованные сигналы." "Depending on the configuration of the flight navigation equipment, the product The outline can interact with instruments located as part of the on-board complex via various interfaces: analog interface using DAC and ADC, ARINC-429 interface (GOST 18977-79) or RS-232 interface (GOST 18145-81). All implemented joints are duplex - they allow the Abris product to accept and transmit standardized signals." Clearly ABRIS could both send and receive information either analog or digital.

@Pack Rat @Hobel and @Chizh I was able to reproduce the manipulating of slewing of the SHKVAL to approx altitude just like @Hobeldid in the same version: 2.8.1.34667.2 IMHO: ability to slew in general area of pre-planned target was probably one of the most important features of Rubikon. Another one would be ability to designate the point at which SHKVAL looks at, with yellow designation in ABRIS. This one also does not work correctly, but clearly demonstrates that ABRIS is able to read at least azimuth information of SHKVAL! Distance itself is wrong, since it points at 0m altitude. I can not imagine that this helicopter would be complete as a single crew attack helicopter without these 2 features. Without them this aircraft could execute precision strikes only based on the information given through DL by scouting helicopter. IMHO: the altitude information had to come either from: 1. entered value into PVI-800 console (no altitude symbols are present there), but still the workflow could be extended to the console to enter altitude after the angle coordinates. I would call this the simplest solution, but at this moment I do not find any evidence. 2. manipulated altimeter as demonstrated by @Hobel. This method was used by contemporary aircrafts such as Viggen, or e.g. Yugoslavian J-22. 3. or from ABRIS since it already knows details about altitudes for given coordinates of either helicopter or the target. It should be noted that our ABRIS had several A/D and D/A convertors and that they are documented in the manufacturer service manual as well as crew manual. Sadly they do not detail their purpose (perhaps take input from traditional cockpit instruments/sensors or even provide the output to them?). We can see in our own BS3 that ABRIS have A/D and D/A connected to something ( @Chizh perhaps your SME knows what they are used for? ). The rear of the ABRIS devices shows more or less standardized connectors used in aviation. One possibility for integration of ABRIS with rest of Rubikon would be usage of one of the digital interfaces (although perhaps a degree of paranoia in development may have led to explicit prohibition of such interface). Another possibility is to use D/A convertor in order to provide altitude as an offset signal for shkval slewing. One more curiosity is that the ADI itself provides the indicator showing altitude position relative to the desired altitude of the next waypoint (according to the manual). I recently found even the example instrument on eBay, but the seller told me it came from civilian aircraft, and the document I found on the ADI indicates that it's purpose is to assist during landing by giving position of measured altitude relative to required glissade. I am on vacation at the moment but I think I can lookup for those documents in my download folder if anyone smarter can figure out how the slewing of shkval based on target points actually worked.

Any confirmed DCS world fatalities?

You are welcome. Gazelle is my favorite helicopter. So fun to fly.

Dude, please think again. Radio signal is signal being the RADAR or Jammer. So if HOJ works, the RADAR based signal can also be used at least for proportional navigation based on measured angles. Few montha ago even the page from manual surfaced and was removed, so ED is aware it did exist. What remains unknown is exact mode of operation: - guiding on STT is one option. Clearly thia was doable in 80s. - guiding on other modes, e.g. SCAN/TWS is more complex: - update frequency may be in seconds. - There is a difficulty in correlating the right signals in presence of multiple emitter. Personally I think this weapon was usable against STT and less manouvarable targets in SCN/TWS modes