All Activity

Какие боеприпасы там есть ?

HARM IDs: 414 Project 22160 132 Tor M2 415 Project 22160 with Tor M2KM 134 Pantsir-S1 135 IRIS-T SLM STR

Thanks for the feedback!

I noticed this completely by accident. It doesn't bother me much. I usually look straight ahead and to the sides, rarely at the stars.

It still reproduces on last patch

Just for my own understanding, because I am interested in the reasons "why," as well. Going over the chucks guide again, the engine is fed from the fore and aft reservoir tanks. The reservoir tanks are fed via the corresponding fore and aft internal tanks. The fore and aft internal tanks are fed via the internal wing tanks. The wing tanks are fed via any of the 3 external fuel tank options. From what I am reading (and cross referencing the chucks guide), in layman's terms, the external tanks are drained first. Then the INTERNAL wing tanks will be drained. Then the Internal fore and aft tanks will be drained, and lastly the fore and aft reservoir tanks will be drained. That makes sense. The filling diagram seems less clear - from either ground or air receptacle, fuel is fed into centerline external tank and the fore and aft reservoir tanks, and then into the external wing tanks, via the externals? If that is the case it should not mater what the fuel state of the aircraft internal tanks are? Or does the fore and aft reservoir tanks feed the internal wing tanks, which in turn feed the external? Even then the centerline tank should fully fill anyway? I suspect this is a problem with the chucks diagram, as it seems to imply that the rest of the fore, aft, and resveior tanks are all filled in series AFTER the external and internal wing tanks are filled. This does not seem to align with the real world case as stated by RogueSpecter or the model's behavior in game. RogueSpecterGaming, from reading your technical comment, specifically that the valve to the line outlet of the internal wing tanks is open when the wing tanks are not full, and closed when they are, would mean that if the draining sequence was reversed for fueling, that once the wing tanks are full, that valve for the line out (or the inlet into the internal wing tank from the refuel manifold?) is closed, and therefore unable to fuel the external tanks? As to why the internal wing tanks fill before the external, is that a consequence of residual pressure in the externals? At that point it's a DiffEQ problem about how quickly the external tank can depressurize vs the rate at which the internal wing tanks are filled, with a supposed equilibrium around 5,000 pounds IRL, and 4000 lbs in-game. That makes sense. I think. Regardless, thank you for the technical explanation.

It was mentioned as a known issue in the change log and will be fixed.

Firstly, use the DCS in bin and not bin-mt. They’re both multithreaded (and identical) and bin-mt is being removed in the future. Secondly, this issue for 2d or VR?

Because of how the radars and weapons are configured it wasn't compatible with the Combined Arms player control features. But you'd be happy to hear I'm currently reworking both the Tor M2 and Pantsir S1 to implement player control of them.

Damn! But fine then I'll take the trial version and see I wanned to use him`s ai.

Their communication has been proven poor. You better not waste energy at monitoring it atm. There are performance issues not found in other maps, yet to be addressed. I like the map, the work put on it and gladly took my time to showcase it as much as possible on the forum. The communication issues and the weird performance drops bellow 900ft people are experiencing is heartbreaking.

Just read: Requirement : DCS Ka-50 3 Module

Не верные характеристики РЛС и ОЛС Панциря С-1 как по дальности обнаружения, азимуту и углу места. Есть исправленный вариант. Панцирь не может обстреливать 4 цели одновременно такое ощущение что дали панцирь прям из мода без каких либо правок. Если на него устроить налет из КР томагавк он буквально мечется между целями и не знает то ли с пушек стрелять то ли с ракет

Don’t remember where I got it, but hopefully it meets your need: https://1drv.ms/f/c/ba8d40d87db99c2e/Ei6cuX3YQI0ggLomDQIAAAABV-wpLaQ96_oJhOnOf9G-qQ

Why Mi-28 it’s not showing for me?(i dont have Ka-50)

Hi, any update on the project?

July 4th, still have a little while to wait... News from yesterday's newsletter sounds promising: "...As we further develop the underlying eyetracking models and resolve OpenXR bugs, we expect to release advanced performance enhancing features such as Foveated Rendering and Quad Views. This means that Beyond 2e can enable performance intensive games like iRacing, DCS, and Microsoft Flight Simulator 2024 to run more easily on PCs."

Just uploaded (and fixed the above) this one, a Fictional "Su-33" Scheme. I couldn't get it to work with Russia, so it's USA and USAF Aggressors for now, unless either the mod works for me, or something:

Dammit i wondered about the nvid driver I’ll roll that back!!! Cheers for that!

do you need the intercooler open when not using the turbo?

The IRIS-T SLM TRML-4D rotation rate is operating rather slowly. I'm sure there are IRL operating modes that allow for a slow rotation rate, but it would make sense for it to be modelled at it's highest known capability which allows for a track update rate of <1s, which obviously can't be achieved with the rotation being this slow even with the look-back/forward scanning. Hensoldt themselves no longer publicly state the rate, but an archived page does: https://web.archive.org/web/20241111032523/https://www.hensoldt.net/products/radar-iff-and-datalink/trml-4d/ It can also rotate at least noticeably faster in Hensoldt animated marketing videos: How fast exactly it rotates I'm not sure, but it should at least be fast enough to support the <1s track update time. Also supported by several secondary sources: https://armyrecognition.com/news/army-news/army-news-2024/germany-provides-6-additional-trml-4d-radars-to-ukraine https://www.aviacionline.com/hendsoldt-to-deliver-six-trml-4d-air-defense-radars-to-ukraine https://vpk.name/en/718027_capable-of-detecting-and-classifying-aerial-targets-the-apu-announced-the-delivery-of-a-new-batch-of-trml-4d-radars.html Thanks for reading!

So found a couple things. The jitters and shaking that's when staying still, not tracking related, was from the Nvidia Driver 580.97 I believe. Rolled back Nvidia Driver to 580.88 and it's gone. Tracking lag, where it went very low fps and tracking isn't accurate, was from the 1.41.2 client. I'd installed it over the 1.40 client. Went back and removed Pimax in Add Remove Programs. Stopped the Tobii VR4PIMAXP3B Platform Runtime service and deleted all Pimax folders, even those under user/AppData. Rebooted and reinstalled the 1.41.2 Pimax Play. Then tracking was much better. For how long, don't know. Haven't been able to use it for more than a few hours so far. But it had been fine yesterday, seems to get worse over time.

I'm at work and do not have the ability to view your track replay at present, however I believe what you're experiencing is parallax. The maverick seeker head(s) and the TGP do not share the exact same line of sight to a point on the ground, there is a difference in position for each of the optics. This means that after you boresight them at a given distance, looking at or trying to lock a target at a different distance will introduce SOME error called "parallax" (the effect whereby the position or direction of an object appears to differ when viewed from different positions, e.g. through the viewfinder and the lens of a camera.) The amount of parallax error varies with the difference from your boresight range that you are trying to ID/Lock/Engage a ground target. The reason it "behaves" how you want to when using the active pause is that you are at a single, steady, and unchanging distance to the group of targets (the few dozen feet difference between the targets is negligible). Where-as when you are actively flying, you could be anywhere between 15+ to 5 miles from your intended target depending on your approach & etc. I usually try and boresight my mavs right around 8-10nm, and try and lock targets at that same distance. As far as I can tell, he was not cursor-zeroing the SPI after initiating a pint/area/INS track on a location with the TGP (or other sensor), causing the offsets to remain in effect with all other steerpoints in his flight plan.

Official announcement from the dev will be helpful on this issue otherwise I am on hold for this terrain.

Looks it's probably Jupiter and Mars or Saturn there. They shouldn't be visible during day. I can try tuning the Star.fx settings a smidge to get rid of it.