Jump to content

Bestandskraft

Members
  • Posts

    133
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. A similar issue was discussed here.
  2. This may be related to the bug described here.
  3. Awesome, thanks. Just for my peace of mind: The white markings at the outer edges of the turn scale then do not indicate any specific turn rate, but exist merely to aid the pilot in setting the turn needle between the center and outer markings to establish a half-standard rate turn?
  4. I cannot categorically prove that the following is a bug, I would simply ask the dev team to check whether the turn indicator is working as intended. According to NATOPS, "[a] needle-width deflection of [the Turn-and-Slip indicator's] pointer will initiate a 360° turn in 4 minutes." Tests conducted by me have confirmed that this is correctly simulated. A needle-width deflection thus indicates a half-standard rate turn. However, a two needle-width deflection (put the white on the white) which I would expect indicates a standard rate turn in fact does not do so in the game. My tests have shown that a 180° turn with said deflection takes approximately 50 seconds instead of 60. Some basic aerodynamic math confirms the discrepancy: For example, at 289 KTAS, a 3° per second turn rate should be achieved at a bank angle of 38°. In the game, at 289 KTAS, a two needle-width deflection coincides with a bank angle of approximately 44° on the VDI. If the indicator is modelled correctly as is, I request information about how (or if) RL F-14 pilots were able to fly standard rate turns precisely. Incidentally, I can confirm the findings reported in this post concerning a significant difference between the bank angle indicated on the VDI and the Standby Attitude Indicator.
  5. Both F-14A and -B AI's break with unswept wings in 2.7.5.10869.
  6. Interesting points, it appears I was wrong. I initially stumbled upon this issue due to the Takeoff Checklist where the pilot confirms that the spoiler module is ON. When performing a maneuver flaps takeoff, the module is then actually OFF during takeoff and switches on with weight-off-wheels. I find it odd that is is neither mentioned as a note to the Takeoff Checklist nor to the section describing a maneuvering takeoff, then again the fact that spoiler effectiveness can be increased during a no-flap/maneuver flap takeoff abort by lowering the flaps is mentioned in the Aborted Takeoff section. In any case, I'm happy and this report may be disregarded.
  7. I cannot categorically prove that this is a bug since the NATOPS flight manuals are not totally clear on this, but I believe the outboard spoiler module should be energized and pressurized (SPOIL ON) when the maneuver flaps are extended. Right now, the module is deenergized with only maneuver flaps extended. Reasoning: The outboard spoilers are driven by the outboard spoiler module. If this is deenergized, the outboard spoilers therefore should not move or at least droop down. In the game, when on the ground with ANTI-SKID/SPOILER BK ON or BOTH, the outboard spoilers will extend with the flaps slightly extended with the flap handle; in this case, the outboard spoiler module energizes (SPOIL ON). When leaving the flaps in UP but moving the maneuver flaps to 10° (i.e. beyond the point where the outboard spoilers deploy when using the flap handle), the outboard spoilers remain retracted and the spoiler module shows OFF (if it was previously ON, there is a short delay before the indication changes). The closest thing to a proof for my position is para 11.9.4. in NATOPS (it seems to be consistently numbered for all publicly available versions) which states that for in-flight refueling in HIGH mode, "[f]laps should be selected to 10° with the maneuver flap thumbwheel, which still functions normally with outboard spoiler module power". IMHO, if the maneuver flaps work normally with outboard spoiler module power, they can do so only because the outboard spoiler module is ON with the maneuver flaps extended.
  8. This post contains several tracks and detailed instructions on how to reproduce the bug.
  9. Unfortunately, the bug still exists in 2.5.6.59626. Good news is that I have finally been able to reproduce it. As far as I can tell, the bug occurs: only in multiplayer, only as a client, definitely on the carrier, and possibly on airfields (didn't test the latter), only when spawning from ramp. Steps to reproduce: create a mission where spawn time is after mission start time, fresh start DCS on server and client, start server, connect as client and join into the first F-14, click "Briefing" and "Fly" before spawn time (spawn time is 45 seconds after mission start time in the attached example), observe the "Your Flight is Delayed to Start" message (the bug also occurs when a different aircraft is preventing your spawn temporarily, setting spawn time after mission start time just is the easiest way to reproduce the bug), hit "ESC", "Select Role", select the second F-14, hit "Briefing" and "Fly", wait for the spawn, do an automatic startup (the bug occurs with a manual startup as well, however with an automatic startup we exclude non-standardized player input), release the parking brake, advance throttles, note that it takes approximately 92% RPM (95% RPM in the F2 view) to break free of your parking position (without the bug it only takes approximately 80% RPM (85% in the F2 view)) to start rolling, taxi to the CAT and launch, note an AoA spike to approximately 27° (25° in F2) during launch (without the bug, max AoA is 15° (14° in the F2 view)), probably indicating an out-of-limits aft CG location, note a sluggish acceleration to 300 KIAS. I have attached 4 tracks to illustrate the problem; 2 server tracks and 2 client tracks. The bugged client track immediately desyncs after brake release since during replay the aircraft is non-bugged, therefore the excessive power setting necessary to break free of the parking position translates to the aircraft running over the edge of the deck. Note that the spawn delay by itself it not the cause of the problem, since when simply waiting until your aircraft spawns without selecting a different slot, the bug does not occur. server-20210127-131858_without_bug.trk overweightbug-20210127-131809_without_bug.trk server-20210127-102604_with_bug.trk overweightbug-20210127-102511_with_bug.trk
  10. Not sure if it's worth fixing this as you'd be hacking around a DCS almanac problem but I thought I'd mention it anyway. Contrary to real-life, DCS assumes the (I think) entire Persian Gulf theater to be situated in the +4 time zone, whereas e.g. Iran actually uses a +3.5 time zone. A similar issue occurs in other theaters but I'll use PG as an example. Reference the attached .cf. According to your calculations, sun elevation at steerpoint 0 at approximately 16:40:17 at N 27 24.780 E 051 18.639 is 0°, which I interpret as sunset or close to it (we might disregard rounding errors and sunset being defined as the upper edge of the sun touching to horizon and elevation being referenced to the center of the sun's disk since those differences are not relevant to my point). Test-flying the associated sunsettest.miz and using the Armed Speedboat as a vantage point (it being located on the waterline as opposed to the carrier let alone the F-14 airborne), sunset actually occurs at around 17:40:00, so approximately 1 hour later than calculated. According to suncalc.org (reference screenshot), the sun should set at 17:12:17 at that location. Reviewing the attached .acmi recordings of the .miz (be sure to select the correct time offset of +03:30), one can see that at 17:40:00, the Tacview sun has long set, whereas it actually sets at pretty much precisely 17:12:17. This proves/leads me to conclude that the DCS almanac is essentially correct but does not always correctly account for time zones, Tacview uses the correct RL almanac but sometimes shows the incorrect sun position with reference to DCS, CF has a one-hour difference to the DCS almanac and a half-hour difference to the RL almanac, at least in the conditions indicated above. actual_sunset.acmi dcs_sunset.acmi sunsettest.cf sunsettest.miz
  11. Hey Viper39, some more inconveniences I noticed (I hope I was able to reconstruct the logic correctly, it's somewhat convoluted): When saving a mission in the DCS mission editor whose .miz was exported from CF, group, pilot and waypoint names immediately (i.e. before any export) revert to the ones set in CF, unless the .miz was originally created in the DCS mission editor, exported and then re-imported, in which case only the waypoint names revert. When a mission originally created in the DCS mission editor is exported to CF, any changes made to the custom callsign in CF are not carried over to the group and pilot names when re-exporting to .miz. When a .miz is originally created in CF, group, pilot and waypoint names get deleted when exporting the mission to .stm (Static Template) in the DCS mission editor. When a .miz is originally created in the DCS mission editor, then exported to CF and re-exported to .miz, waypoint names get deleted when thereafter exporting the mission to .stm in the DCS mission editor. Pilot names are modified as follows: When a group was called "Test1" and the corresponding pilots "Test11" and "Test12" prior to exporting the .stm, after the export and reimport of the .stm to the DCS mission editor the pilots are then called "Test1-1" and "Test1-2". This is related to point 7 in my previous report: Since locked ETAs do not get exported to .miz, any activity duration set on a waypoint is ignored in-game. The only way I have found to actually make a CF delay work in DCS is to manually copy the CF-calculated ETA of the waypoint following an activity to the DCS editor, lock that ETA and the GS of the remaining waypoints until the subsequent activity.
  12. When using triggers to generate map markers to make e.g. navigation fixes defined as trigger zones selectable in the Jester wheel, not all programmed map markers will show in the wheel. I have tried for several hours to reverse engineer the exact logic behind which markers show up on the wheel and which don't, to no avail. From the attached screenshot it appears that every other marker is not displayed, but my tests have shown that the problem is more complicated than that (e.g., there are exceptions to this rule depending on which "Value" a marker gets assigned and in which order the markers are positioned in the trigger actions list. Conversely, ALL the programmed markers will show on the F10 map without issues. When manually adding the markers on the F10 map after mission start, all of them will be present in the wheel as well.
  13. Recently bought and started using CF and so far I'm loving it. Nevertheless, here are a couple of bugs (or yet to be implemented features) I've found: A flight's inhouse frequency gets exported fine from the .miz to CF (as in: it appears as the frequency on all the waypoints), but is reset to the default when exporting the .cf back to .miz. Tested with F-14A/B, F/A-18C Lot 20 and KC-135 MPRS. Waypoint frequency change commands generated in a .cf (as in: the frequency associated with a waypoint) get exported fine to a .miz (i.e. to the waypoint actions list), but when importing that same .miz back to CF, any digits behind the dot, if present, get truncated. Aircraft tail numbers / board numbers / MODEXs are not imported from .miz to CF even though the aircraft configuration menu features an "Eastern Callsign". Tanker track speeds set in the mission editor get reset to default when importing a .miz to CF and then exporting back to .miz. When exporting/importing a .cf to .miz or the reverse, tankers' AAT frequencies are correctly transferred, but the "Unit" parameter in the "Activate TACAN" command is reset to "Nothing" when exporting from .cf to .miz, causing the AAT to not transmit. I take no particular credit for this discovery since this phenomenon has already been reported by ScAvenger001 and Legendofdino. For any mission generated originally in CF, the Description on the right panel in the Mission selection screen you get to from the main DCS menu shows "DictKey_descriptionText_1". Modifying the Situation in DCS or CF has no effect. If the .miz was originally generated in DCS, this does not occur. Locking an ETA in CF does not lock it in the .miz, while locking an ETA in a .miz does lock it in CF. Mission briefing slides get exported every time the .cf is exported to .miz (there being no option not to export the briefing), so we end up with various of the same slides in the .miz package if the .cf file is itself based on a .miz import. This may be related to the "Fixed double CF kneeboard files when re-importing .miz" bug above. The following results in a hang in the DCS mission loading screen: Create a mission with CF. Export mission to .miz. Import mission to CF. Export mission to .miz. Open .miz in game. The following results in the mission being loaded just fine in DCS: Create a mission with CF. Export mission to .miz. Open mission in DCS editor, re-save. Import mission to CF. Export mission to .miz. Open .miz in game. Finally a feature request: Would it be possible to make the DDM format selectable for the Nav log, or even better, make it possible to select/deselect which coordinate formats are put on the Nav log?
  14. On a complete unrelated topic, I tried intensively to get bookmark injection to work and here's what I found: On a German keyboard with a German keyboard layout selected in Windows, the only key that actually causes a bookmark to be set is "`" (the key to the right of "L", on a U.S. keyboard this is below the ESC key). Neither the "2" (key to the right of "`" on a German keyboard) nor RALT+B have any effect. What's more, using the Thrustmaster TARGET software, I have been unable to program a key to produce the "`" character so it is recognized by Tacview with a German layout selected (the character is recognized just fine by the DCS Options/Controls menu, i.e. when I press the joystick button, the key "`" is produced in the assignment panel). When software-switching to a U.S. layout, a HOTAS-programmed "`" works just fine. To avoid these problems or generally problems with international keyboards, would it be possible to either include a key option that has no special characters (such as "c", "u" etc.) or include an option to use a DX button or make it possible to configure the desired hotkey by modifying a .cfg file or similar? Cheers.
  15. Hey Vyrtuoz, the following 100% repeatable problem occurs for me with Tacview 1.8.5. Advanced (Windows 10 Pro, RTX 3080, latest drivers): I have two monitors, one main monitor (Display Port, 3440x1440, 100 Mhz) and one secondary monitor (1920x1200, 60 Hz). As long as Tacview is closed while displayed on the main monitor, everything works fine. However, once the program is closed while displayed on the secondary monitor, during the next start attempt, Tacview will freeze while loading the map, regardless of whether a mission is loaded or just the basic program. When HKEY_CURRENT_USER\SOFTWARE\Raia Software Inc. is deleted, everything is back to normal until the program is again positioned on the second monitor and closed. EDIT: Reason was the Nahimic service as described in your FAQ. For others affected by this issue, here's how to disable that service: How to disable the Nahimic Service | Eng - YouTube
×
×
  • Create New...