Search the Community
Showing results for tags 'acknowledged'.
-
acknowledged ED, Can you just remove the cockpit shaking
Hydrox posted a topic in Su-25 for DCS World
None of the other aircraft have it and that's the difference, they are playable. This is not. First it was just Su-25T and now Su-25A have it also. Both are unplayable in this condition and since you decided to encrypt certain files I can't do anything to fix it myself. And also if it's so realistic (which it isn't, just eye torturing), why doesn't for example Su-27/33 have it then? Well, if they had there would be much less flankers flying around in MP servers. So could you just restore Su-25s to proper flying condition? -
-
acknowledged Removing Trees on SA map - what's the secret?
cfrag posted a topic in Bugs and Problems
Hi, I'm trying to create a helicoper-based scenario in the beautiful SA map, only to be stymied by the fact that ham-fisted I can't seem to be able to remove some of the verdant flora on the map to make space for by base. I'm using a REMOVE OBJECTS ZONE action in a trigger AT START, but try as I might, the trees are very stubborn, and seem to resist their removal. Now, most obvious reason: I'm doing something wrong. Attached please find the preliminary (poc) scenario I'm working on. What am I doing wrong? All help and hints appreciated. Carpet Crawlers.miz -
acknowledged Inaccurate atmosphere parameters
Mad_Shell posted a topic in Weather System Bugs & Problems
This work is not mine, I copy paste what the dude (Maya on discord) wrote on the discord bug channel so his work attracts attention from ED. "Hi, has anyone thought that the sunrises & sunsets in DCS are a bit too purple? I'm a graphics programmer who's familiar with Eric Bruneton's (which is used in DCS) and Sebastien Hillaire's atmosphere models and I found a "bug" in their implementation which causes the sky to be too purple and developed a tool called ARPC which allows accurately calculating the atmosphere parameters. Basically both Bruneton's and Hillaire's models pick 3 primary wavelengths for red, green and blue to determine Rayleigh scattering and Ozone absorption coefficients, but this method simply doesn't have enough precision to take especially the Ozone absorption spectrum into account. ARPC on the other hand uses CIE 1931 XYZ color matching functions to take a weighted average of the coefficients for all wavelengths when calculating the coefficients for red, green and blue. This approach gets much closer the spectrally rendered path-traced reference, which has more blue-tinted sunrises / sunsets. It also calculates a few other parameters such as the scale height and ozone distribution more accurately, by using ISA instead of the constant temperature atmosphere used in Bruneton's and Hillaire's models. If anyone's from ED is interested, I can provide more technical details regarding how ARPC works. It's already open source (MIT licensed, so can be integrated to any commercial project without any royalties) and available on GitHub: https://github.com/FarukEroglu2048/ARPC Here's a quick comparison with the ARPC coefficients, I changed the coefficients in the shader code for it: Default Coefficients: ARPC Coefficients: Here's another comparison using a ShaderToy implementation of Hillaire's atmosphere model: Hillaire's Original Coefficients: ARPC Coefficients: To validate my approach with ARPC, I used a root finding algorithm which tried to find the scattering and absorption coefficients which minimized the error between the spectrally rendered reference and also converted a reference spectral light source and the transmitted light spectrum after it passes through the atmosphere into sRGB to solve for the coefficients. In both cases, the expected coefficients almost perfectly matched the coefficients calculated by my approach: Under the spectrum calculations section, the first line is Rayleigh scattering coefficients and the next line is Ozone absorption coefficients for red, green and blue, calculated using ARPC. And below them, the array shown by “x” contains the Rayleigh scattering and Ozone absorption coefficients that match the spectrally rendered reference the best, found by the root finding algorithm. You can see that they are in great agreement with the ARPC coefficients. Even without more rigorous tests like that, the results with the ARPC coefficients are visually very close to the spectrally rendered path-traced reference."- 3 replies
-
- 13
-
I tried to use the night vision goggles in the F-18 but they first showed up pointing left and zoomed in. After searching the forums I found a thread in the F-16 pages that stated that SSAO needed to be switched off. I did this and re-entered the mission and switched on the NVG with the result the they now point slightly right of the HUD and still zoomed in. Screenshot and track attached. This was in single thread not MT. F-18C NVG.trk
-
Hi, When i drop a bomb i have no tone. Yet my OSB " Tone" is boxed. I tried Tone 1 and Tone 2 with no result. The rotators on tour helphe left console are On. Thx for help
-
-
acknowledged Deck crew ignore request when SC is turning
toutenglisse posted a topic in Bugs and Problems
Minor bug. Or is it intended to be like this because deck crew will yell "what are you doing !?" if rearm/refuel procedure is in progress when SC is turning ? Deck-crew-request-bug-SC-turnung.trk -
At night, (at an airport such as Batumi)when I park under overhead lights, the top of aircraft is not illuminated. It is pitch black. Could this be fixed?
-
acknowledged WW2 planes can fly just fine without wing or wings.
vermu posted a topic in General Bugs
Hi, I don't know if this issue is reported already. I have been playing a lot of hours with ww2 planes with my friends after the new damage model was released. We noticed that when you crash on tree or some other object and loose your wing or wings the crash does not affect how the plane handles. You can fly just like nothing happened. The same applies if you collide in midair with other player and loose wing or wings. Nothing happens and you can fly just fine. I noticed that ghost gunners in bombers was patched but not this issue. -
I'm sure ED is aware the manual is outdated. I'm running 2.5.6.60966 and my version of the English manual has a modification date of 2020-12-20. Searching the manual for "coolie" should give the most promising results quickly, including the table HOTAS Commands - Throttle and a multitude of references to SOIs, swapping MFCDs and the very old "Coolie Hat Up" instead of "Coolie Hat Up Short" command. I can prepare a detailed list, but won't fall for the trap of compiling it in a forum post (*). Let me know if you need any pointers. (*) I prepared a detailed post describing exactly where the manual is outdated in regards to the Coolie Switch, SOIs and HMCS. Then the forum ate 90% of it. I mostly like the new forum, but "Undo" in the editor seems terribly broken.
-
acknowledged AI aircraft perform invalid CASE 1 departures
Bankler posted a topic in Bugs and Problems
BUG This is how AI aircraft currently take off from the boat during CASE 1: When spooling up, they turn the beacon on. When launching, the turn the beacon off. When airborne, they turn the formation lights on. Then they immediately start climbing to at least 1200'. SOLUTION This is what carrier based AI aircraft should be doing: Do not use any external lights at all (especially on and around the boat, but in general no lights during the whole flight). When launching, fly 300 kts IAS and climb to 500'. Continue along the BRC in this manner until 7 nm away from the boat. Then start following waypoints. REPRO Put a 4-ship Hornets on the Supercarrier, mid day, clear weather, with a waypoint somewhere on the map. Observe them in Spectator mode. REMARKS The bug is somewhat serious, since it stop players from using carrier based aircraft while performing realistic CASE 1 recovery procedures with human players. The AI aircraft will climb too high and risk collision with recovering aircraft. The unrealistic external lights handling kills some immersion by looking a little silly. They actually do turn off the lights before the landing, which is nice. Well done there! Even if providing the AI flights with waypoints trying to get them to hold speed and altitude, they will ignore them during the departure. This makes sense because they're in a departure AI state, but also stops us from working around the bug. Lights should generally stay off daytime even during CASE 3 with low clouds, for both departure and recovery. In fact, except for nighttime, they rarely come on at all. REFERENCES Track and miz attached. Hornet_AI_Case1_Bug.trk CASE1_Bug.miz- 5 replies
-
- 15
-
To put the TLDR first, our huey is underperforming by 3400lbs while being provided a lower available power than the real thing, and made slower than it's actually supposed to be at low altitude (which is where it normally operates) So what are my sources? Before that, lets start with a very simple summary of HOW WRONG the module's performance actually is. null Now, I won't act like that's the whole story with all the context, because it's definitely not. There are things like the transmission limit to take into account. But those sources, lets see them. Here are the 3 main sources, there are several other minor sources as well, however the majority of the data comes from these 3 documents. null So allow me to clarify something, our huey is one with a 1990s refit, it is the one with composite blades. You may have noticed, one of those sources explicitly mentions the composite blades in the title. That source is a performance profiling of our exact model of huey. Refits and all. Now, there's something else to talk about, the huey's operations manual. You might be familiar with this chart. This chart is useless. This chart doesn't tell us where the transmission limit is, it doesn't tell us how much engine power is being used to generate those speeds, it doesn't tell us ANYTHING. That chart is a significant misrepresentation of the huey's performance capabilities, because all that chart shows is a paper limit on the huey's speed. Vne, Velocity, never exceed. A scary term, used to define a speed you are to not exceed for assorted reasons. For the huey, the Vne is in place to keep the pilots from accelerating into retreating blade stall, nothing more. It's a paper limit to keep the pilots safe, it tells us NOTHING about how the aircraft performs. However, if you look at the bottom of that chart, "Data basis AEFA Project No. 84-33" Go back and look at top of the source that mentions the composite blades, that is AEFA Project No. 84-33. The data from that document was used to generate that chart in the manual. So before we go farther, how do we corroborate all our sources to make sure they're on the same page and providing us valid information. Cross checking. Take one set of data, and see if the patterns within it match the patterns in another set of data. We can do that. Here is the overall performance of a huey with the standard blades at 7,500lbs, derived from the data within the UH-1H flight profile performance handbook. Pay attention to the density altitude of 7500ft, you see where the yellow and red (transmission limit and power limit) lines intersect, that is where the engine can no longer provide enough power to max out the transmission. Now here is the hover performance chart from the composite blade document. Look at the rightmost line. "2ft IGE, standard day". You might have already noticed it. Incase you didn't. So our documents are in agreement, what do we do with this information? We start comparing it to the performance of our huey in DCS. Lets start with a more complete performance profiling of the real huey with the standard blades, once again, this data is derived from the UH-1H flight profile performance handbook. This data is for a huey with non composite blades. So there are multiple plots here, let me walk you through them. The first one that likely sticks out is the blue line since it's away from all the others, that is the Vne. The fact that it is placed lower than all the other data reminds us of the chart in the manual. I said that chart was useless, because as you can see by this graph, every single other plot of data performs significantly over what the Vne would have you believe. The next two that likely stick out are the red and teal lines. These are the performance of the DCS huey plotted onto the same graph, the red line abides by the incorrect EGT limit placed upon the module, the teal line ignores said limit and properly maxes out the transmission where it can. Next would be the green and yellow lines, the green line shows the maximum power the engine can normally push, regardless of any other factor, at sea level that would be 1340shp. The yellow line shows the maximum CONTINUOUS power the engine can push. This means the engine can run at this power setting indefinitely without much issue. And finally, the orange line, this line shows the safe limit of the transmission, specifically, 1158shp, or 50psi on the torque indicator. This is the huey's military thrust it can use this power for 30 minutes. This is not the LIMIT of the aircraft's performance, the transmission CAN PUSH HARDER, it just does so at the risk of being damaged. Yes, this means that, per this data, the huey should be able to reach 141knots in level flight. Something you'll notice, the teal line, our huey's performance, can't even reach the transmission limit at sea level. While, conversely, our huey's performance actually PASSES the real huey's maximum possible performance at higher altitudes. So, from this alone, you can see that the module's performance accuracy is not great. But that's not the whole story, that's just for the standard huey, and we haven't even gotten into engine performance per speed yet. We'll do that now. Here is a chart from the composite blade document, it shows the level flight performance in speed compared to the shaft horsepower generated by the engine to achieve said speed at a gross weight of 9500lbs at sea level in 15C temperature air, ISA conditions. On it, you will see a pink data plot. That is our huey measured by the same metric. 9500lbs, Sea level, 15C air temperature, ISA conditions. You'll notice that our huey isn't even performing as well as the huey with the standard blades, let alone the one with the composite blades. But first, how did I get the horsepwer data from the DCS huey, we don't have access to that data. Except we do. We are given the torquemeter, which when combined with the rotor RPM, we can derive the current SHP put out by the engine. As per our previously unreferenced source "Helicopter drive system load analysis". Pages 43-44 detail a formula to do exactly that, derive shaft horsepower from our torquemeter reading, and rotor RPM. Here is that formula. SHP=3.88*((10^-3*Rotor RPM)*((17.76*Torquemeter Torque)+33.33)) Now, you'll notice that graph shows the composite blades as being measured with the rotor at 314rpm, that's ok the difference in the result isn't exceptional, however here is a table showing the same data and including 324rpm on the composite blades. So, 639shp to push the helicopter to 100knots at sea level at 15C at a gross weight of 9500lbs. That would be 26.745psi on the torque indicator in the cockpit. As you can see by the pink line on the graph, however, we didn't even get close. We hit 36, possibly 37psi on the torque indicator at those parameters. Level flight, 9500lbs, sea level, 15C, 100knots. 36psi at 324rotor rpm, as per the formula, is about 845shp, over 200shp too high. Now, we can use this formula to find something dire. Lets make the huey as light as we can and see how it performs. 6100lbs, all it has is about 9 minutes of fuel Sea level 15C 100knots level flight about 30.5psi in those parameters. 722.8shp at 100knots. The real huey pulls 639shp in those parameters at 9500lbs. Our huey, at 6100lbs, is performing WORSE than the real huey at 9500lbs. Our huey is underperforming by over 3400lbs at low altitude. That is unacceptable. Interestingly, these high torque values also explain why we need an unrealistic amount of left pedal, which when combined with the incorrectly modeled tail rotor, brings about some interesting comparisons. So, now that we have the well documented performance profile from the standard blade huey, honestly, we could just use that one for our huey and it would be fine, the overall speed differences shouldn't be drastic, it'd be far more accurate than what we have now. As for why our huey overperforms so much at high altitude, I don't know. All my efforts were aimed at understanding its performance at low altitude as that's generally where players utilize the aircraft. I suspect it may be a combination of the engine not losing enough power at altitude and rotor mach drag not being modeled. However, for now, I believe this should be sufficient to warrant the developers looking at it. Please. Properly implemented, our torque indicator should actually max out at around 58.15psi while the N1% (gas producer) gauge reads 100% As it stands, we are using too much power, to generate too little speed, at too high of an EGT, causing us to have even less power. We are underperforming by over 3400lbs at sea level, it needs to change.
- 46 replies
-
- 38
-
- uh-1h
- performance
-
(and 1 more)
Tagged with:
-
Hello, HD bombs doesn't seem model allowed release envelope. Especially SNAKEEYEs (MOD 3A, 4) have rather tight release envelope (450-500 kcas). >500kcas is structural limit of retarding fins and <450kcas would case fins only partially opening. This result in bomb impacting long and may increase chance of self fragmentation. In less extend the same apply to AIR (BSU-49/B, BSU-50/B) but those limits are match more forbidding (200-700kcas).
-
AIM-120s fired in HOBS conditions do not acquire their target if the missile does not acquire the target instantly when coming off the rails. In my test setup, I am firing a 120C at a target flying straight and level at varying degrees off bore. The name of the track denotes what degrees off bore the target was when weapon release was pressed. If the target is slightly (~1-2 degrees) out of gimbal limits, this means the missile will never acquire the target. 120_hbs_38 - 38deg weapon release, 51deg motor ignition - 59deg first fin movement. As you can hear on the friendly radio, the missile acquires the target practically instantly when coming off of the rails and has relatively little issue guiding onto the target and killing it in a practically over the shoulder shot. 120_hbs_40 - 40deg weapon release, 54deg motor ignition - 61deg first fin movement. Despite only being a few degrees more off bore than the previous shot, the missile never acquires the target here. Likely due to the fact that the target was not within gimbal limits initially. Furthermore, the missile can be observed flying downwards, which is unusual considering the target and ownship are both flying straight and level, the missile should have no reason to fly downwards here. Additionally, a few seconds after launch, the missile has manoeuvred enough to put the target pretty clearly within gimbal limits. The target is flying straight and level, and the missile is being supplied correct and up-to-date datalink information. As the missile has an INS, is it not reasonable to assume that the missile should be able to guide itself onto the track of the target here despite it initially being out of gimbal limits? Aside from that, the missile should have plenty of energy and manoeuvrability to hit the target here, so I do not think this is an out of parameters shot. 120_hbs_40.acmi 120_hbs_38.acmi 120_hbs_40.trk 120_hbs_38.trk
-
The AIM-120 has an issue where if launching on a group of targets the missile will consistently acquire the wrong target when activating its seeker. When the missile goes pit bull, the missile will consistently acquire the trailing aircraft in a formation instead of the intended target. The two targets can have almost 1nm of separation between them, and the missile will always go for the trailing target on seeker activation. 120_group_leading shows this quite clearly. The missile is fired at the LEFT/Leading target in the formation, and acquires the trailing aircraft instead. Note that the missile displays unusual guidance, most probably due to receiving (in this case) incorrect datalink data for the wrong aircraft. When the situation is reversed and the trailing aircraft in formation is targeted, the missile has no problems discerning the two targets even with a much smaller separation between the two. 120_group_trailing shows this with a separation of ~500ft between the two aircraft, yet the missile acquires the intended target in this case. 120_group_1&2 show a DTT launch on both aircraft in a formation from a left offset angle. Despite both missiles being targeted at separate aircraft, both missiles go for a single target; the trailing aircraft in formation. Something important to note is that this only occurs when a formation of targets is attacked from a certain direction. 120_group_3&4 show that if the same formation as in 120_group_1&2 is attacked from head-on or a right offset, the issue does not occur and the missiles acquire the correct targets. 120_group_1.acmi 120_group_2.acmi 120_group_3.acmi 120_group_4.acmi 120_group_leading.acmi 120_group_trailing.acmi 120_group_1.trk 120_group_2.trk 120_group_3.trk 120_group_4.trk 120_group_leading.trk 120_group_trailing.trk
- 16 replies
-
- 10