GeoS72

Can this topic be revived or investigated further? It's been on the back burner for quite some time.

Bumping the thread for increased visibility. I'd like to explore the potential to reposition the ControlsIndicator overlay for FC3 aircraft AND not break integrity check. This will help many of us with multi-monitor displays.

Bumping the thread for added visibility. ControlsIndicator file causes IC to fail. Can this issue be addressed, please?

Affirmative, Detailed scoreboard is broken. Overall points are good.

Rob, Thanks for the recommendation. Removed the B-2 mod and still had the same issue. I had to create a new DCS Saved Games profile, start DCS, then exit DCS, change the new DCS Save Games folder and finally restore my original DCS Save Games folder. Then I was able to get past the 10% choke point.

This god-damned game frustrates me to no end! I just want it to work consistently! The dreaded crash at 10% loading screen came back after updating to the current version of DCS. I had my VPN enabled previously and I was able to log in to DCS. When I attempted to join a multiplayer game, it loaded but then booted me after 30 seconds. That's a separate issue with NordVPN. Please check my NordVPN thread about that boon-doggle. After disabling NordVPN, I restarted DCS. Aaaaaand it's gone! DCS crashes! I ran the DCS log analyzer and this is what it said in the errors section: Attempt to index local 'b' (a nil value) on Line 77 in ./Scripts/image_search_path.lua So why is this happening? dcs.log

Here's a quick update: the problem appears to have resolved itself. Don't know how or why. I'd like to leave this open in case anyone else has a similar occurrence or wishes to share their experience/insight.

Quick update: I changed the name of my Saved Games\DCS folder to DCS.old. Then I ran DCS, it built a new Saved Games\DCS folder. I was able to get into the main DCS menu. Next, I exited the game. I then changed the name of this newly constructed folder to Saved Games\DCS.temp and reverted the folder Saved Games\DCS.old back to Saved Games\DCS. I then ran DCS and I was able to get back into main menu with all of my settings intact. The screenshots represent what I see when the error happens, create a new saved games folder, and then revert to the original folder. I also want to point out that I get the same result (crashing at 10%) even after a repair to DCS.

Yesterday, I encountered a very unusual error that is persistent. When I attempt to run DCS from the launcher, it crashes or freezes at the 10% mark. I ran my DCS log through the Log Analyzer (on Discord) and it said there is an error on Line 77 in the image_search_path.lua file. The analyzer claims there is a nil value on line 77. If I rename my Saved Games/DCS folder to DCS.old then allow a new one to be built, then DCS will run again. I can also get it to run ONCE after I delete this new saved games folder and revert to my old Saved Games DCS folder. This mess began when I exited a multiplayer server; the game became unresponsive and displayed a black screen. I had to end the task via Windows Task Manager. When I then reloaded DCS, I got a login error indicating my profile did not load properly and that any paid module was inaccessible. It is also key to note that my default wallpaper reverted to the default Caucasus screen. It was previously set to the Apache wallpaper. Additionally, I compared an earlier version of the image_search_path.lua file to the current version. They match! So the big question remains: What is the fix for this issue? FWIW: the affected code of the image_search_path.lua file is as follows: function addTexturesInMap(a_path) for file in lfs.dir(a_path) do local b = lfs.attributes(a_path .. '/' .. file) if (b.mode == 'file') then <---This is the offending line according to the DCS Log analyzer. mapTextures[file] = 1 end end end dcs.log This is the error that is reported from the DCS Log Analyzer: Error attempt to index local 'b' (a nil value) Line 77 Script ./Scripts/image_search_path.lua If the above errors point to DCS internal files, please conduct a !repair. Otherwise remove the respective unofficial mod.

Not to sound like a broken record, but the values your team tested are incorrect. Based on my limited test, a 20% survival rate from a rear aspect shot is unacceptably low. That's like saying there is an 80% chance of your computer crasheing upon loading Windows. Would you find that acceptable? Here are my questions: 1. What is the target that a missile (Fox 1, 2, 3, or other SAM) aims on the Hornet? From my perspective, it appears to be the pilot! 2. Why is the survival rate of the MiG-29S (as I tested) at 100%? 3. Does this imply values for the MiG-29 are incorrect or unrealistic? 4. (Speculative) Will the values for the upcoming MiG-29A (full-fidelity) have parity with the Hornet or similar Western aircraft? 5. Why does ED believe the survival values for the Hornet are correct? 6. What is it going to take to improve these values?

@ricnunes, You are welcome for test results and samples. While it is frustrating to contend with exceptionally poor survival rate of the Hornet pilot, there shouldn't be a need to beat up @BIGNEWY. He and the other mods have a monumental task of sifting through threads & responding to user posts. The tone set in your post could be easily misinterpreted as a personal attack. I don't believe that is the intended purpose of your post. Let's keep the conversation civil, please. I would like to explore this bug; or some may call it a 'feature', further. The reason for the delayed response could be caused by the evaluation of tracks & other data that were provided in my files. While I dislike the length of silence, please be patient. It is very easy for us, as users, to get all worked up because we are passionate about the game. Trust me when I say, "I get it!" I get equally frustrated when there is a very long delay in replies or the response doesn't match my expectation. I've had some positive experiences identifying problems which lead to fixes. Some take longer than others. Keeping the train on the tracks: I'm curious to see other test results in Hornet Pilot survival rates!

I noticed after the last update plus multiple hot fixes that any modification to the ControlsIndicator.lua file will now break integrity check (IC). Could someone please explain why this change was made? This is a BIG deal, especially for players, like myself, who have multi-monitor configurations. I don't recall seeing any notes about it in the change logs. Is this an oversight and/or can the ControlsIndicator.lua file be removed from the IC list?

I need to make a correction to my Integrity Check statement and controlsindicator file modifications. Apparently, a modification to the ControlsIndicator.lua file will now break IC.

@BIGNEWY, et al: Here is a more methodical approach to testing the Hornet Pilot survival rate. The Fulcrum Pilot survival rate was 100% on 2 separate runs. I modified the MIZ file to simulate a multiplayer environment. Each side has 10 spawns, each human pilot (me) is being chased by an AI pilot. The conditions are very similar: engage autopilot and wait for impact. I don't play the MiG-29 so I had to manually keep the jet level (the autopilot is foreign to me). All airplanes configured with 60% fuel, unlimited fuel (waypoint action) enabled, all missiles shot were Fox 2s (R-60Ms & AIM-9Xs for the respective side). The track files should play out as if I were in a multiplayer server and jumped into the next available slot. When you spawn into a new aircraft, the previous wave from the opposing force will despawn (had an issue with the final wave of the Hornet test). Here's the breakdown. The numbers next to each status represent the spawned round (e.g. 2 = 2nd Spawn): Take 1: Hornet Alive: 4 Hornet Death: 1-2-3-5-6-7-8-9-10 Fulcrum Alive: 1-2-3-4-5-6-7-8-9 (no 10th spawn due to trigger error) Fulcrum Death: No deaths Results: Hornet 90% mortality rate; Fulcrum 100% survival rate Take 2: Hornet Alive: 3-7-8 Hornet Death: 1-2-4-5-6-9-10 Fulcrum Alive: 1-2-3-4-5-6-7-8-9-10 Fulcrum Death: No deaths Results: Hornet 30% survival rate; Fulcrum 100% survival rate; combined Hornet survival rate = 20% (4 out of 20 slots resulted in pilot surviving missile hit). I agree with @ricnunes, @Racoon-1-1, & @ruxtmp that the Hornet mortality rate is far too high at 80%. Especially when compared to the 100% survival rate of the MiG-29S. That allows the frustration level to get VERY high. You guys are welcome to run the same MIZ and report on the results. I'll be even more curious to learn more about the tweaked/correct settings on pilot survival rates. If there are some open source docs that pertain to Hornet survival rates after missile strikes then I'm interested in reading about them. HornetvsFulcrumSurvivalTracks-Take01.zip HornetvsFulcrumSurvivalTracks-Take02.zip Hornet Survival Test-002.miz

@flanker0ne, Please excuse my misunderstanding about your level of participation. Thank you for clarifying it!

I created an ad hoc Hornet vs MiG-29S mission. Hornet client (me) in front with MiG-29S in trail about 5 NM. I tested with a variety of missiles but settled after 5 with the R-60M. Here are my initial findings from the single player environment: 20 flights total Hornet Pilot survives: 5 Hornet Pilot dies: 15 Survival percent: 25% alive, 75% dead. Track & MIZ files attached. Basic tests: Co-altitude with bandit at 20,000, once I spawned into the cockpit Autopilot BALT hold enabled and throttle set to 50%. Variables: I would add afterburner to increase heat signature; set Client altitude to 25,000 and kept bandit at 20,000; set co-altitude to 25,000 ft. Most of the time, I observed the Hornet from the F2 External View. That yielded the most deaths of the pilot. My pilot's survival did not appear to be correlated to in-cockpit view or external view. This test was done VERY late at night so my scientific method may be flawed. I'll revisit this experiment once I am well rested in the morning. Hornet-Pilot-Mortality-Tracks.zip Hornet Survival Test-001.miz

@Mapi, I haven't tried that method. However, my chief complaint is the display area which the TEDAC uses is actively blanked out for the pilot. If you carefully look at my screenshots, you could see a very small sliver of the Autopilot Controls Indicator overlay behind the blank out mask. In a very early iteration of the AH-64, this area was not actively blanked out so that area could be used to display either Controls Indicator (or both).

@BIGNEWY, +1 on the survival rate of the pilot. Based on my experience flying the Hornet & Tomcat in a multiplayer environment: it is exceptionally rare for my pilot to survive an incoming missile. The running joke when I fly multicrew RIO in the Tomcat: Goose's turn to eject the lifeless pilot and notify the Next of Kin. I'd say that 99.999999999999999999999999999999% of the time, the F-14 pilot will die and the RIO will survive any missile attack from any direction. I have ridden the Tomcat as RIO to splash down after being hit by a Fox 1 or Fox 2; the entire back end is spewing flames and tumbling like a weed while my multicrew pilot is dead as a door nail. Getting back to the Hornet pilot survival problem: it is exceptionally rare that my pilot survives after a missile attack. The percentage of death is equal to the Tomcat pilot percentage (discussed above). While your testing and adjustment to values may appear correct, could there be some unforeseen factors affecting the pilot survival rate? Nearly all of my stick time is in a multiplayer environment. Could there be something in that multiplayer setting to cause the higher mortality rates? Could you specify the conditions that were tested so we could replicate and confirm or disprove the results? To me, there appears to be a disconnect between the test environment and the 'live' environment.

@BIGNEWY & @flanker0ne, Has there been any progress to address this TEDAC export function? Could this issue be re-addressed, please? It's been over 1.5yrs since there was any acknowledgement. Thank you!

This is an example of my display setup. The Controls Indicator overlay is in the bottom right corner of the total screen resolution. Its placement is outside the visible viewing area of my additional monitors, presented by the yellow frame. The file attachment was scaled down for space-saving purposes. Placement of the overlay could go in any corner of the main display or in the visible viewing area. A lua file that would manipulate its position would be preferred, however, using a function similar to the SA-342 Gazelle would be another potential solution. That module gives you the choice of corner to place the overlay.

This is an age-old problem with FC3 aircraft. Could the ControlsIndicator.lua file be added to FC3 aircraft? This will help people with multi-monitors to place that overlay in to a visible part of the screen. The location of mine is buried in the bottom right corner of the total screen resolution, out of the normal view from my multi-monitor config. I see that the FC 2024 aircraft (F-86, F-5, and MiG-15) have a ControlsIndicator folder that allows the user to edit them. What are the obstacles that would prevent this from happening? Could the user be allowed to change the position of this overlay, pretty please and with sugar on top?

@Bigity & @ANDR0ID, Consider these 2 threads that I posted. They should provide the answers to your needs. Editing the controlsindicator & crew status lua files do NOT break IC! Do these links help resolve your problem? -DH How Do You Edit ControlsIndicator lua to Change Screen Position Mi-8 Crew Status Indicator Position

Roger. WinWing confirmed that the Orion 2 damper/spring kit will not fit in the Orion 1 base.

@Blackhawk163, if you have the Orion 2 joystick then the damping/spring kit should fit without issue. However, I have the Orion 1 joystick so I doubt the same damping kit would apply without any compatibility issues. Also note, if you spend $52 for the damping kit, that excludes shipping fees. I don't know if shipping fees are applied during checkout.

In early February, one of the springs in my Orion 1 F-18 joystick base broke. This thread was helpful in locating a replacement but the replacement spring is not an exact fit. Thanks to @Orko for posting a suitable replacement from Grainger. The part number listed (1NAV4) was out of stock at that time I was looking for a replacement. I then cross-referenced its specs to something in the McMaster-Carr catalog. The closest part crossed to this spring: Part number: 9044K245 Length: 1" OD: 0.36" Wire Diameter: 0.045" Extended Length @ Maximum Load: 1.43" Spring Rate: 21.8 lbs./in. Material: Music-Wire Steel End Type: Loop OD Tolerance: -0.004" to 0.004" McMaster-Carr Musical Wire Spring I replaced both X- and Y-axis springs in my stick with this substitute spring. Observation of using the new spring: 1. I do NOT use any joystick extensions, I alternate between the F-18 grip & F-16EX grip. 2. The spring rate is weaker than the OEM (WinWing) spring. 3. It is VERY easy to move the stick and it can easily "wiggle" when mounted to a chair and you get up or rock the chair. This ease of movement would increase significantly if you decide to use a joystick extension. 4. The time it takes to return to center is longer and could get you into trouble should you make rapid/violent moves from one extreme axis point to the opposite point. 5. Since the springs are weaker than OEM, it is easy to maintain pressure without fatigue. This is not a bad characteristic especially if you fly helicopters. I frequently fly the AH-64D and rarely use Force Trim, even on long-haul missions. This lower spring rate give me greater control of the helicopter without the stick trying to forcibly return to center. 6. Flying fixed-wing is not too bad; as mentioned in Item 4, the stick is not trying to forcibly recenter itself so you need to be mindful of swinging the stick violently from axis end to the other. This could be dangerous when flying low-level ground work or you have a sharp descent rate; the reaction time will be noticeably slower. 7. Most of these characteristics (good and bad) can be mitigated by thinking ahead of the aircraft and re-conditioning your muscle memory. I eventually reached out to WinWing for OEM replacement springs. I paid $37 for 2 springs (they bang you hard for shipping); 1 pair of springs is like $5 but bang you $32 for overseas shipping. They only ship replacement parts from China and not from their regional distribution centers. So that kinda sucks. When the replacement springs arrived, I compared them to the originals. They were too long! And they were long by a lot. After a little back-and-forth with them, they realized the wrong spring was sent. So 2 weeks and counting, the replacement of the replacement springs have not shipped. While I enjoy using the WinWing products, their customer service needs to get better. For the OGs who replaced their springs, how satisfied are you with the substitute springs? Did you find a different solution?