Warmbrak

I would be disappointed if the devs allocated time away from more important tasks to enhance a cheat mechanic that has very little use in the greater scheme of things. For realistic weights for landings, just turn the cheats off for that mission; no need to do it all in one mission.

And this is where things get real interesting. A pilot and RIO builds a working relationship and understanding that will be extremely hard to mimic even by two players that train together in the F-14B and play together on a regular basis. When the Lantirn pod is fixed on the wrong target, the pilot would just mention "nope, the one next to it on the left". The RIO will immediately understand what he means and will make the adjustment in a matter of seconds. Unless there is a shortcut command to 'point' a Jester in the right direction to make adjustments, there is no way that instructing Jester through the comms menu is going to produce a response in the same amount of time. The only way to achieve that reaction time and level of symbioses is either: 1.) Have a human that is always available when you fly, and train together for hours and hours to 'become one'; or 2.) Have direct shortcut commands to have Jester jump/snap between visible targets (in the Lantirn camera view) by pressing up/down/left/right to make it happen. The likelihood of the majority of DCS F-14B owners to ever achieve option 1 is pretty low. The second option seems like a darn good comprise and possibly the most realistic one. I think that is what @AH_Solid_Snakeis trying to convey here. The simulation is still there; nothing is being broken. There is no magic @draconus; being able to convey an instruction to your WSO or RIO with a 'grunt and a sigh' is a reality that is hard to simulate. So until Jester is able to handle voice recognition and make a target adjustment in under two seconds without the pilot having to look for a command in a menu somewhere, the shortcut commands for rear seat functions is probably the way to go. If you disagree, please take the time to offer a solution on how you would implement this mechanic. We can argue about what is true and not, but let's get practical and find a solution instead.

The keybinds option is problematic as there is no feedback on the warmup of the Lantirn pod and things like that from the back seat. I have tried the keybind mod in the past and it can work, but there are cases where it is easy to break the functionality and the pilot in front would have no idea what is going on. Your keybinds idea could work if HB implemented a simple Jester functionality that ensures certain systems are up and running in order for keybinds to work up front at all times. I am just not interested in learning the back seat, so switching seats do not appeal to me. Having Jester do Lantirn is one of the main reasons I got the F-14 when it was originally released, and I am still patiently waiting.

The server I play on features the CSAR script for pilots that managed to eject from their aircraft. These downed pilots can then be picked up by helicopters. The Gazelle is perfect to slip in and out of enemy controlled territory, and I was looking forward to using the door gunner variant on these missions for fire support. Sadly it appears that the door gunner can only be manned by you as the player. I think I may have been spoilt with the UH-1 and Mi-8 door gunners for these kind of missions, but I was under the impression that the underlying mechanism for door gunner AI is already implemented in DCS? I have tried occupying the gunner station myself and it is not my cup of tea. I am also not interested in entertaining another human in the cockpit so I am not looking for a multi-station solution either. Is there is chance that we could get door gunner AI for the Gazelle in future with a simple ROE selection that include No Fire - Return Fire - Fire at will options?

I created a small beach shack using the BlenderEDM plugin and placed it inside DCS World. The object and the textures show up correctly in game, but in ModelViewer 2 I just get the missing textures in the TEXTURES box. The model itself is located under the Saved Games DCS\Mods\tech folder and I have sub folder for Shapes and Textures. It seems like there are extra steps involved to get the textures showing up in ModelVIewer (who knows why when the main application has no issue detecting and displaying them). Can someone please point me in the right direction to get the textures detected in ModelViewer? Thanks!

If and only if the user targets the object directly. Most JDAM users know however to target the ground under the object and not the object itself to avoid slant inaccuracies. Sadly I am getting more direct hits with CCIP Mk-82's than with GB-38's at the moment. For high-altitude work I started carrying a mix of GBU-38's and GBU-12's again; JDAM for soft skin vehicles that doesn't mind a miss with a few meters, and then LGB for tanks. I was always under the impression that GPS weapons had premium GPS accuracy?

I only launch when IN ZONE and make sure the weapons have aligned to good quality - JDAM accuracy has decreased substantially since the last big stable update. It almost feels like a RNG has been built in as there is no consistency either. Before the patch I could reliably kill tanks with GBU38's from 10K and up; now at even lower altitudes it would miss entirely. It is hard to work out whether it is a problem with the GPS or the new zero alpha terminal mode to avoid 'slapping' the target. I would rather have it slap the target than miss by 20m altogether.

Thanks for the response.

I noted a while back that many of the air to ground munitions are not attached to the weapons pylons - there seems to be a fixed offset. I don't think it applies to all (I think the MK84's attaches correctly). This is in the current stable release on this date.

Thanks. Can you please explain how you initialise the process? In the Youtube videos I see folks turn on A2G mode, then under the Jester menu (weapons) there is a LANTIRN Utility option. I don't see that option in my radial menu at all. Also, does one need to activate/press the keys to get out of standby mode, switch to the TGP camera/tv and arm the laser? Also, how does one select the manual bombing mode required for GBU's from the front? How can one be sure that the configuration is correct without any feedback from the backseat?

The fix doesn't seem to be in the 7 October 2020 open beta update notes either. I fired up the Gazelle again today and wasted 15 minutes trying to troubleshoot the laser issue. Finally aborted my mission and came to check the forums - laser broken...

Sorry to revive this old post, but has there been any progress on the Jester/lantirn matter? I tried GBU12 for the first time today jumping to the back seat, and also trying the mod to operate the pod from the the front seat. I only fly air-2-ground missions, and I have no interest in having a human RIO or playing as a RIO. In my view being able to control the TGP from the front is not that unrealistic when trying to simulate a symbiotic workflow between two humans. What does frustrate me is that in some cases the weapon wouldn't release, and I had to switch to the back seat to work out why. Firstly, the laser was not armed. Secondly the weapon release mode was not in manual mode. In a realistic scenario the RIO would configure the system to allow successful weapons deployment. In some Youtube videos I see a LANTIRN - Utility option in the Jester menu under the Weapons section that I assume sets up the system, but in the current version of the Open Beta I cannot find that option. I checked the manual but it is still the Revision 1.0 release document with very little content on the Jester menus. I checked the online manual as well, but also very little information regarding the Jester options. While I am able to troubleshoot these issues by jumping to the backseat in single player, if I understand correctly, this will not be possible in multiplayer? Any updates on the current way of deploying GBU's as a solo user will be greatly appreciated.

This is one of the most awesome missions - thank you very much for your effort. If there is one thing that can be improved it is the vehicle spawning locations; there are simply too many instances of vehicles ending up on roofs or almost clipped into buildings. I don't know what variables are exposed to allow one to check placement offsets from buildings, but there must be a way to determine ground height at a coordinate position on the map? Can you build in a simple check to verify that a spawned object's location altitude above ground matches the intended ground level at that spawn coordinate? If the delta is too large, cull the unit and spawn it at a different location? I see trucks on multi-story building rooftops, T-80s climbing up the sides of buildings etc. on a regular basis. I specifically fly the Aleppo mission at this stage. I don't think I have ever encountered an A2G mission in any place other than in a built up area. Are there some A2G missions that take place outside of the cities (I know the SAM missions do)?

PBR - Physical Based Rendering materials/textures

Thanks for the comments gents. At the point in time where this drift occurred, I was still in Nav mode, and had not unstowed the TGP yet. I have a huge deadzone on my Warthog microstick to avoid any jitters, so I doubt whether accidental movement could have caused this, seeing that the TGP was not selected, nor visible in any of the MFD's. I will try that scenario again.

I flew a three objective mission yesterday that requires landing at another airfield to refuel and rearm. I did a cold start at the primary airbase, aligned using stored heading, and flew the mission (armed with MK82's and no TGP). No issues. I then landing at the secondary field, rearmed and refuelled (while the engine was at idle). I loaded up GBU12's, rocket pods and a TGP. I took off and headed to the target waypoint. At around 20 miles from the target, my waypoint tadpole started drifting, and the waypoint started moving by itself close to my current position. At this point I had to navigate VFR as my target waypoint decided to elope. I took out a sam with the rockets, and climbed out to take out targets with the GBU12's. Upon activating the TGP, I discovered that my pod was slewed to a waypoint far away, probably around where my target waypoint eloped to. After a lot of manual slewing, I finally managed to get the TGP to look at the target area. Long story short, my target waypoint moved by itself and I don't know whether there is an issue with alignment that could occur when rearming and refuelling in the F16, or whether the mere fact that I was carrying a TGP messed things up. I read on the forums now that the current TGP implementation doesn't use SPI, but moves the actual waypoint around? Is this true? This could account for my target waypoint moving, but I did not have the pod activated until I reached the target area. Has anyone else experienced a screwiness like this in the F16?

If I could add some fuel to the fire, seeing that it is 1 April and all... Let's assume for one moment that the additional revenue from a subscription could be beneficial to fixing the core elements in DCS that would benefit everyone. It is also clear that people who are enjoying the current free model would expect to continue to do so. One solution could be to allow Open Beta access only to subscription members ( I apologise if this has been suggested in this thread before). Being a subscription member would also allow access to voting on priority features/fixes in DCS. The stable release would remain free as always. The subscription should not replace the current fee model for modules, but there could be some kind of discount offered as an incentive for subscription members. This entire thread is the result of user frustration due to things taking forever to get fixed, and the OP has proposed a divisive but plausible solution. The way for ED to end this thread is to acknowledge this proposal, provide a response, and then shut it down.

I own a lot of DCS modules. I run a Thrustmaster Warthog HOTAS, as well Saitek Rudder pedals and Pro Throttle System. Every few updates or so, the inputs become corrupted and I have to redo them for an aircraft I may not have flown for a while. Due to some incompatibilities with other software I occasionally need to disable my HOTAS peripherals in Windows. When I do come back to DCS, some of my devices are swapped around, and I have to redo my control setup in DCS again. I had to reformat twice over the past year due to hardware failures/replacement, and even though I backed up my DCS settings folders, I had to redo my controls yet again. I fired up IL2 Sturmovik BoX the other day after I scraped the courage together to remap my controls after I rebuilt my system. IL2 detected my hardware, and noted that it did not recognise two of my devices compared to my previous setup. I gave me the option to pair my current devices to the old profiles and in less than a minute my control setup was back the way it was before and I was up an flying again. While DCS has a very flexible system, it is a real pain when it comes so system persistence, and it should not be necessary to have to remap controls for each and every module every few months. Please give us the ability to easily swap profiles between devices, and perhaps be a bit more proactive in detecting a user's setup and guiding them on how they can reconnect their devices with existing mappings instead of destroying the profile. I would like to map my controls for a module only once please.

This is a re-post from one that I made in the ME editing section a few months ago, but with no response from ED. A response on whether this is possible would be greatly appreciated. Problem While FARPs are great for helicopters, it is not friendly towards fixed-wing aircraft. Many have tried to place a FARP with a corner on a road so that if an aircraft touches it with a wheel, it is able to refuel/rearm. Others have made great objects to try and help with this, but there is always an issue with the placement of these objects, and in most cases these simply do not work, or destroy the aircraft in the process. Request: Can ED please consider adding a FARP trigger zone that can be created in the ME that will allow mission builders to place a little area on a road where aircraft can be rearmed and refuelled? Bonus would be to spawn an aircraft at these points on the ground. Optional Request Mod creators (such as the excellent DCS Marsden FARP have tried to overcome this issue, but it is impossible to place these objects flush with the ground. Objects like these really create interesting gameplay opportunities, but are held back by something in the terrain system that makes it impossible to place unless the ground is perfectly flattened in advance by ED. Please consider extending a hand to these modders to help make these mods fully functional. Original post: https://forums.eagle.ru/showthread.php?t=255799

I can confirm, both taxi and landing lights.

Thanks BIGNEWY, I can confirm that all my drivers are up to date, Windows 10 as well, and that I do not overclock. I am running on a new PC with vanilla DCS Openbeta and only official mods. I will run a repair and see if that makes a difference. I will see if I can make this happen again with the F-18 TGP.

Thanks NoJoe. The only thing I can really add are my log files. Even if I recreate the issue, a track file surely will not save on a hard system crash? Or should I give it a try?

I haven't flown for a while but the two times I took up the F-18 with a targeting pod and GBU-12's the flight ended with a hard system crash. I would enable the FLIR and start slewing to look for my target area. After a few minutes of flying over the target area and continues slewing, there is a stutter freeze that emerges. It feels at first like it is a temporary stutter, until the game freezes up entirely and my system does not respond. Alt Ctrl Del does not work, and I have to hard reset my PC. I have flown the KA50 for hours and the F-18 without targeting pod had no issues. This is both in 2.5.6.44266 and the previous version. I have never had this issue before, but haven't flown in a month or two so not sure when this may have been introduced. Is there a log file somewhere that may shed some light on what is happening? Edit: I attached my log files, which includes a crash log. I can try to create a track file, but I doubt that it will be available with a hard crash to my system. Logs.zip

This issue still persists today. Trying to make a mission with Harriers deploying from the Tarawa, but I keep getting the "flight delayed from start" issue.

Problem While FARPs are great for helicopters, it is not friendly towards fixed-wing aircraft. Many have tried to place a FARP with a corner on a road so that if an aircraft touches it with a wheel, it is able to refuel/rearm. Others have made great objects to try and help with this, but there is always an issue with the placement of these objects, and in most cases these simply do not work, or destroy the aircraft in the process. Request: Can ED please consider adding a FARP trigger zone that can be created in the ME that will allow mission builders to place a little area on a road where aircraft can be rearmed and refuelled? Optional Request Mod creators (such as the excellent DCS Marsden FARP https://forums.eagle.ru/showthread.php?t=222775 ) have tried to overcome this issue, but it is impossible to place these objects flush with the ground. Objects like these really create interesting gameplay opportunities, but are held back by something in the terrain system that makes it impossible to place unless the ground is perfectly flattened in advance by ED. Please consider extending a hand to these modders to help make these mods fully functional.