Jump to content

Quip

Members
  • Posts

    224
  • Joined

  • Last visited

Everything posted by Quip

  1. It's not like this mission is difficult to recreate. You see everything needed in the youtube clip too. But here: Bk90 test.miz
  2. ADDENDUM The problem seems to be linked to the altitude of the target (area). Above a certain altitude, the AI will not attack, even if the terrain is perfectly flat. Let's agree that a lake is perfectly flat. In the first image, the lake is at 2077 m, and the AI will not attack In the second image, the lake is at 2077 m, and the AI will not attack In the third, the lake is at 1078, and the AI attacks as expected I have tried many more altitudes, and 1462 m doesn't work. It seems to be tied to altitude somehow. But it's all very random. It may be linked to the altitude at which the AI is looking to drop the Bk90's. As the area nears 1200 or 1300 meters, the AI starts behaving erratically. In the 1148 meter test, over a lake (img 4), the attack is done very late, like under 2 km range, as opposed to the normal 7 or 8 km over flat terrain. Sometimes, the AI won't drop both Bk90's (which it's set to in the mission). Heatblur should look into this.
  3. This video shows a problem I have run across with the Viggen. The way the AI will behave changes completely based on where the waypoints are on the map. There's no way for me to create a mission if I can't rely on the AI behaving somewhat predictably. Hope someone has an explanation and solution for this odd behavior. @IronMike https://youtu.be/nF3eQTVPAC4
  4. I wish the ME could "lock" editable items (units, waypoints, trigger zones). Not only hide them. This is to avoid them to get nudged all the time. It's a basic function in any UI where you deal with multiple objects.
  5. Hey. I just noticed I'm getting these artifacts which looks like the side panels are pixelated, with the VR Shaders. Yes I have tested with and without and they occur with the shaders only. And the effect is visible in VR too. I only took the screenshot in 2D because it's easier. I only see it on some textures and in some aircraft and under some specific lighting conditions only, mainly when it's dark. If you you look at the image you can see the effect on the side panels including the switches. But nothing on the center panel. Anyone else? Any work arounds?
  6. So my friend and I have solved it. Mission 2.2 requires you to takeoff on rwy 08 (now 07), but the mission that comes with the game, as well a the mission from 2020-09-13, has you facing the opposite way. We added 3 m/s of wind down the rwy and that fixed the mission.
  7. I've been trying to figure out how to succeed in Mis 2.2 (IFR Nav). As soon as I get into the zone W (yeah, I've looked in the mission), which is just before the marker, I get a mission failed. I don't seem to be able to turn on flag 4 no matter what, and honestly I don't see how I could. Flag 4 requires 5 minutes of flying with flag 3 ON, which has not happened since I'm at takeoff, or that I reach another zone a bit into the mission, inside zone W. Have you really been able to complete mission 2.2 dated 2020-09-13 21:12? If so, I really don't see what I'm doing wrong. Also, as a side note: I don't understand why zone 10 is to the west and zone VOR to the east, since it looks by the triggers that we're expected to hit these zones in the reverse order. But this might just be me missing something. Regards
  8. I think I showed you this already Palten, but in case you or I missed it... https://docs.google.com/presentation/d/e/2PACX-1vRZJOoR_6NxKpN1AwQPeal8fHJ1V9poCUxI2-SX--rKqJNlBxgN7Nnl8AUAFfgX7RbhsaDJBE5Ctfqj/pub?start=false&loop=false&delayms=3000
  9. It's a Swedish missile: passive aggressive. Normal
  10. That's a third thing in fact (I think, if I understand you correctly). So here's a scenario. 1. You have a cartridge with the only runway in it (Swedish military bases at the time had only one runway and never two in parallel!), let's say it's a 09-27. So you load it and the pre-designated runway was the 09. But now you need to takeoff and due to "things"... 2a ...you need to change to 27. In this case you just go to Bana/Gräns (runway/limit) and you press LS once more to switch to 27. In fact, you don't even need to do this as when you start rolling, the automatic reference point update which is made between 100 and 200 km/h will notice if the runway heading is reversed. Or more to the point: it will expect the runway to be the reverse one (27 in our case) if the actual heading (compass) differs from the supposed (BANA) by more than some 40 degrees. So as long as you're on the same runway, you're fine even if you don't manually change the runway heading 2b ...you need to takeoff from a taxiway with the heading 110. In this case you *need* to enter the correct heading in BANA (runway) manually. If you don't the automatic fix will completely mess up everything. Since your heading 110 is "close enough" to 90 it will tell the system "this is 90" and your navigation will be off by +20 degrees. 2c ......you need to takeoff from a taxiway with the heading 180. In this case you *need* to enter the correct heading in BANA (runway) manually. If you don't the automatic fix will completely mess up everything. Since your heading 180 is not close 090, the update will tell the system "this is 270" and your navigation will be off by -90 degrees. So if you've landed at a random airport, not only do you need to do the NAV-BER-LS-NAV dance, but you must also make sure you have the correct heading setup. If you don't the auto reference update during take off will mess up your navigation. Now an important point: If You *don't* do the "dance", then the system isn't in take off mode and won't do the update. This is why it doesn't matter to most sim-pilots. As far as teh CK37 is concerned, you have only flown at 0 km/h and at 0 meters for a while. The HUD (as per your question) doesn't show any of this. This is something you can tell from the yellow marker on the CI/Compass. During take off the HUD shows you three different displays: 1. the correct rotation speed (which switches to) 2. the correct climb attitude (with or without burners) (which switches to) 3. and the correct time to retract gear (which no one ever cares about in real life). This is what the NAV-BER-LS-NAV resets.
  11. I will repeat myself one last time: NAV-BER-LS-NAV resets the CK37 and HUD to its "Take off" configuration. It's *the way* to do that, and the only way to get the HUD to display its take off mode once again upon landing.
  12. No it doesn't. We're not talking of the same thing. The system is built as I explained it. If you want to get the "take off mode" on the HUD you need to to the BER-LS-NAV thing. There's no way around that. This is also the only way you can really setup the NAV system to accept a different airport/runway heading if you relocate. Now, it's not game breaking. You can take off without the HUD setup to display the rotation speed and the correct climb out angles. However, to use the plane properly you can't land and take off without BER.
  13. After a landing you need to switch BER, select LS as waypoint and back to NAV to setup the plane for take-off again. So that trick is a no-go.
  14. I don't think so. I think the push to Stable was done to aid in selling the Super Carrier to a wider audience.
  15. I reported this during the LOMAC beta. They also know all this during pitch black darkness and through overcast.
  16. It's "Already reported" because ED know of the bug in OB. That this was the first time it got reported for Stable doesn't seems to matter. That's not how ED work with bugs I understand now. Rather, don't work. My bad.
  17. "Already Reported"?? It sure wasn't reported for this version of the game (Stable 2.5.6.49798) when I posted. It is reported for the Open Beta yes. But that doesn't make it already reported. I fail to see how making something new "already reported" will help... Alas, I digress. Just get it fixed.
  18. This is in fact why I don't support ED having the whole OB vs Stable ordeal. Proven fact: Reported Backwards compatibility breaking bugs (regression testing) in OB don't get attention and are pushed through to Stable. This is not an accident. This is lousy quality control management.
  19. OK, so the bug is there in "Stable" too. See attached mission. This bug is an effect of the new and improved path finding. This will break TONS of missions out there. And what's really needed is a way to make aircraft not taxi on start. Make them "hold" at runways etc. In my opinion, this is a game breaking bug. And I know it's been reported several times in OpenBeta, so why was Stable released with this in effect? test.miz
  20. Guys I haven't seen this previously, so I created it. This is a simple "Tutorial" on how the AJS FR22 is integrated with the Mission Editor and/or the flights that occur in the mission. Hope this helps someone. But the TL;DR is that for this to work (it does) the mission designer must really be on top of the flight names in the mission.
  21. The system is the one developped for the Harpoon (originally for the oh-so-naughty
  22. It depends on on-set. The airframe is strong enough for 12Gs. Both in real and in the game. But you can rip the wings off at 8G too if you don't manage the on-set
  23. Hey I've yet to play with the Group radios in the AJS, but now that I get started I have ran into a problem. Someone maybe has the answer... When I look online for how the Group radios are supposed to work, the Kneeboard is to show the different flights and their corresponding radio groups, such as
×
×
  • Create New...