J-man

Thanks for your replies. I will check how small the dedicated server can be, maybe we can symlink game files from the regular install to save HDD space... It´s too bad I can´t host (Dual Stack Light w/o ipv4 Port Acces) and I don´t think my friend who owns 0 carrier airplanes wants to get SC anytime soon .

That's not the ED employee I meant. What you quoted is what OP believed to be the issue. Look at what c0ff responds in the second post: "you have to install the module. It is included in the dedicated install, but not on the regular one. bin\DCS_updater.exe install SUPERCARRIER DCS will complain when run w/o --norender option, if you don't own the module, though." The way I understand this is that c0ff says it is possible to host SC Content as a client, but the module has to be installed manually via DCS_updater.exe, while the dedicated server comes with it installed by default. But this might REQUIRE the --norender option, making it useless as a workaround for my case anyway...

Thanks for the reply! The thread I read this in is this one: An ED employee explicitly states that it can be done with a client-hosted mission, as long as the module is installed... But maybe the "--noRender" option he mentions is a hard requirement for it to work, rather than for the game to not "complain" on startup. Does anyone happen to know if the dedicated server can share a directory with the regular game to save hard drive space? Having to install the huge game twice just to let me use the carrier that most of my group does not own anyway would be a bad tradeoff for our hosting player.

Hi, I´ve got a question regarding the SC Module: From what I´ve read in this forum, the host does not need to own the SC module for a client that does own it to use the new ships. But when my friend (who does not own the SC module) hosts a mission I made that starts me on the 2017 Kuznetsov, I am spawned in the air above it, as if I don´t own the SC module. I have read in a different thread that the host has to install the SC Module to make it work for other players even if he does not own it via "bin\DCS_updater.exe install SUPERCARRIER". We are both using the steam version so there is no DCS_updater.exe. I already tried sending him the SC module, which is correctly recognized by the game (and causes an expected message about not owning the module when starting the game), but I can still not use the SC ships as a spawn if my friend is hosting the mission. TLDR: Non-dedicated server host does not own the SC module. How can we make it work for clients owning the SC module while using the Steam version of the game?

This appears to have been fixed with the most recent update. Now the troops maintain formation and don´t get stuck behind hills anymore. They somewhat spread out when going through thick forested areas but they now always recover and catch back up with the leading unit. No more eternal suppression and no more getting-stuck-while-standing-inside-each-other.

This is what instant trim does. It trims instantly and any remaining stick input is added on top. If you don´t center your stick INSTANTLY after trimming, your helicopter will pitch violently. There is a way around this: Use the Re-Center trim setting (under special options). This will ignore any stick input after trimming until the stick is returned to the center position. And, MOST IMPORTANTLY: Don´t steer and then trim! Instead, always press and hold the trim button while moving the stick and then release it when you are done. Never move the stick without holding down the trim. This way, the shark flies smoothly and will not pitch over anymore.

Hi, I was playing with friends online recently and got hit by a ZU-23. I landed with a burning wing and we noticed two bugs: The fire fx does not move with the wing tip when the wings are folded up: null This can be quite the parking hazard: null In addition, the folding animation is not synced properly: The player controlling the plane sees a slow ~20 sec animation while other players see nothing for 15 sec and then see a fast ~5 sec animation of the wings folding. In one instance, the other players saw the animation revert and then start again. Seems to be an old bug, going by this post:

Wanted to report the same issue. The blade tips remain dark when the tip lights are switched on for me too. There is also an already reported issue with the back panel lights, so maybe something about the lights got broken at some point.

A force of elite infantry gets permanently stuck when attacking an inferior average force in uneven terrain with hills and vegetation: On flat ground, they advance while covering each other and destroy the smaller force with only minor casualties. Here is a mission and track showing this: WorksOnFlatGround.miz WorksOnFlatGround.trk Now the same setup but on hills with tropical vegetation. When only told to advance to the next waypoint, they sometimes manage ok and sometimes get stuck in treelines or behind the crest of a hill. They then remain permanently stuck there and never advance further. Sometimes they will kneel next to an enemy without engaging each other while other times, they run past the enemy and get killed by a single enemy. When the AI has the order to attack the enemy group instead of just walking to the next WP, they often get stuck after killing the first hostile, while inching towards the next hostile in smaller and smaller steps, but never reaching the engagement point. This means that even if set to immortal, the infantry does not reliably engage the enemy or move to the next WP. I tried disabling dispersion but going by some other posts, that is also broken right now. It looks like they have trouble getting a line of sight to the enemy and remain suppressed indefinitely. If the player kills the hostiles, this sometimes causes the infantry to dislodge and move up until they encounter the next enemy. I don´t know how well the replay system captures the AI behaviour since, as far as I know, it only records player inputs. So here are a few different missions and screenshots showcasing the issues. Just run them a few times. StuckOnHillsAndVeg.miz Test2.miz Test3.miz StuckOnHillsAndVeg.trk StuckOnHillsAndVegVersion2.trk StuckOnHillsAndVegVersion3.trk StuckOnHillsAndVeg4.trk Here are a few images of what I´m talking about: Half ran past the hostiles and got shot without firing back while the other half was camping behind the hill and waited there indefinitely. When told to attack the blue group, they kill the first enemy at the treeline and then get stuck there. There is no movement even at 100x time factor. When encountering some hostiles, a part of the group gets stuck there to engage them in a staring contest while the rest moves on just to get stuck in the same situation further down the island. As a result, the large group diffuses into small groups and would take large losses were they not set to immortal in this image. This scenario too showed no movement even at 50x time factor.

Bump! This is still the case 7 years later (or you had a regression)!!! If the unit/group dies, the isInZone check defaults to true! This appears to happen with any zone-function.

Do NOT delete the JF-17! I did more testing today, deleting most units in the editor and then launching the mission. By deleting units until it didn´t crash on load, I narrowed it down to the units on the airfield the player starts at. But then, when I thought I found the units that caused the crash, the mission stopped crashing even with the units present!!! I have no idea why this happens, but the mission works now, even when no changes are made... It crashed yesterday even after restarting my PC, it crashed today unless I delete the units parked on the airfield, but now it just works even if I don't delete any units! So you don´t have to change anything, this might just be some very weird DCS bug... Thanks for responding to my bug report in any case.

Hi, thanks for the reply. I removed all mods (except for TacView) before reporting this issue. I´m on the latest OB on Steam and tried to load the mission in both launch options, single and multi-threaded. I should also mention that this is the only mission where I experienced the bug, I can open other missions on the same map with no issues. I will try deleting the 2 JF-17s parked on the airfield and see if the mission still does not load and report back.

Hi, whenever I try to start the 4th mission "Sniper", the game crashes during loading at the "Sim PostStart" stage. This happens if I start the mission from the Campaign menu, as a standalone mission or via the mission editor. In the editor, I can load the mission fine and see all units placed, but when I start the mission, it crashes during Sim PostStart. I assume this has something to do with initialising an invalid or incorrectly placed JF-17 unit because the crash Log ends on: "2024-01-07 15:51:45.139 ERROR WORLDGENERAL (Main): Error: Unit [JF-17]: No cell for property record CREW_1."

I reported the same issue back in March and got no response.

Hi, I noticed that the BRT Button on the TEDAC Frame affects the TEDAC Image brightness when the IHADSS overlay is active and affects the IHADSS overlay brightness when the IHADSS overlay is inactive. I believe this behaviour is flipped, as it would make much more sense if the BRT button would change the IHADSS overlay brightness while the overlay is visible and the monitors' brightness while the overlay is disabled. I´ve attached the relevant track file. Note that I only demonstrated this with the BRT button, but the contrast button, the symbology button and the reset button also have the same issue. BRTControlSwitched.trk

Honestly, every time I start this game, I spent more time debugging what broke again now, than actually playing the game. For anyone that want to use the ships heli pads until ED manages to fix this issue in 10 years time: The sliding only occurs if the ship is moving. Therefore a workaround is to have the ship wait for the player to take off before it starts moving on to the next waypoint. Likewise you can use a moving zone trigger to disable the ship ai when the player is near it so it comes to a hold independent of any waypoint actions. It is unrealistic and extra work for mission makers, but still better than to wait for ED to fix this years old bug.

Units that drive over the dam fall into the spillway and get stuck. The Unit appears to not drive on the road mesh, but on a part of the spillway slightly beneath the road mesh. Then it falls down into the spillway and the convoy is stuck. When arriving at the spillways from the other side, the units try to drive around it and get stuck too. Here are pictures, a track and a mission that shows the issue: null null null SyriaDamBug.trk SyriaDamBug.miz

Hi, I did set WP1 on the PVI and then choose route mode. I left the switch in the gyro position and did not cycle it, since that is what the training mission tells you to do. I flew the training mission a few times, and sometimes the helo flys to the location selected on the PVI but then quickly looses precision and starts to drift strongly by WP 3/4, and other times it misses WP 1 by a wide margin but still switches to WP 2 after a while, as if the position the PVI thinks it is at is already significantly different from what the ABRIS shows it to be. Then again, the ABRIS also likes to turn the opposite direction of the helicopter in turns and than spins wildly to get back to the right orientation. I have no such issues when flying the BS2 version of the mission, so I still assume this is related to the other issues reportet with the autopilot/INS system in this forum. Edit: Not really sure why this thread is marked as "Correct as is", I doubt the helo is supposed to have INS drift in under 5km of movement in a straight line. It is not as if I am the only one reporting INS precision errors.

Yes, this is really dangerous. Whenever I am in level flight and press my trim button, the helo doubles the pitch down. I´m using the Re-Center trim mode since I have no FFB Stick. This does not occur when I hold the trim button before moving my stick away from the center position. It almost appears like trimming takes the stick input pre-trim and adds the stick input when the trim button is released. So when I pitch down 20° manually and then press trim, it trims for 40° (20° Pre-Trim Stick Input + 20° Trim Stick Input). And if my stick is centered and I hold trim and move to 20° down, I get 20° trim (0° Pre-Trim Stick Input + 20° Trim Stick Input). Since I´m using the Re-Center trim mode, what I would expect to happen is that when I press the trim button, the current input is stored as the base input value each frame until I release the trim button, at which point the base input value remains what is was before I released the trim button and my actual stick input value is set to 0 until I recenter the stick.

Hi, in the Nav Training Mission, when following the instructions and engaging the route mode, instead of flying to WP1 as intended, the Ka-50 flys to a different location that is not marked as as WP on the ABRIS and then switches to WP2. When setting the take-off Airfield as a Nav Target on the PVI, the helo misses the airfield by a similarly large distance. I assume the nav alignment is not set correctly at the hot start of the mission... Here is the Track: https://www.dropbox.com/s/q3n1tn5p8k7nyp2/BS3_En-Route_Navigation_Training.miz_23122022_15-03.trk?dl=0

The outside does look nicer I think, but the inside gets over-exposed. This is an issues when modeling Eye Exposure as if the whole image is beeing looked at by the player. In your screenshots, the helo is off, but the landing gear lights appear as bright and washed out as they do in my 2.8 Screenshot where 3 of them are supposed to be lit and 3 dark. In any RL images of the Ka-50 I can find on google, the lights look as they did in 2.7, distinctly colored green or red, even when off. I also have a suggestion for improving the new exposure effect: In real live, the eyes adapt to the brightness of what ever you are looking at directly but in a video game, the exposure is based on everything on screen, even if the player is not looking out of the window but on the instruments, leading to an overexposed instrument panel. In RL, if the pilot looks on the instruments, the pilots eyes would apapt to the low brightness of the instrument panel and the out-of-focus outside in the pilots peripheral vision would become very bright and vice versa. This difference between exposure for what is on the whole screen v.s. exposure for what the player is looking at is a major issue for people without headtracking, as they usually don´t limit the screen content to just the instrument panel by leaning forward (or zooming in) but usually have a more static view that covers the panel + the outside. There will almost always be a huge light intensity difference between the outside and the inside of the cockpit (at least if you use correct PBR Values for the sun). Based on the 2.8 Screenshots,it appears you have only one global exposure value for the entiere image, you will likely always either underexpose the outside to have realistic inside lighting OR overexpose the inside of the cockpit to have good brightness values on the outside. In the Unreal Engine, there is a relativly new post processing setting called "local exposure". This allows subsections of the screen to havet smoothed independent exposure. This compensates for not knowing at what part of the screen the player is actually looking (outside or inside), keeping every part properly exposed, even in scenes with high brightness variance like an aircraft cockpit. Take a look at an example here: https://forums.unrealengine.com/t/local-exposure-is-in-ue5-main/274274

Agreed, at my end, even in the default 8:00 am, clear sky setting for weather and time, the cockpit looks washed out and it is hard to even tell wich of the landing gear lights are lit when the display is not in shadow since they are a foggy white now. The cockpit lighting certainly looks worse and his harder to read than before. I can also confirm that the hud is thicker or blurry compared to how it looked before. Can you tell, without looking at the lever itself, if my gear is up or down: Compared to how it used to look in similar conditions (older screenshot, pre-syria release, but still representative of how it was before 2.8): nullnull

Depends, how many new bugs are we going to get then? I wouldn´t mind a bit of Halloween fun, if the rest of the game wasn´t outright broken. As you very well know, I´m not the only one reporting these Easter Eggs as bugs because it´s hard to tell intentional changes from the accidental ones if you release a new major version right before adding seasonal easter eggs. As it stands right now, I spend more time testing and reporting issues than actually enjoing the game.

Considering how many real bugs you added with this update, for adding such intrusive changes, clear communicating that they are Halloween Eastereggs and not bugs would have been very much appreciated. Like many others, I thought the constant green tint was a bug, you know, like the broken reflections and double language buttons in the KA-50... At least add a one-click option to disable such changes next time around and maybe don´t release them together with a buggy major version update...

Funny, I never saw any of the easter eggs, I only got the green tint. Who the <profanity> releases such intrusive changes "for fun" at the same time as a major version change that comes with plenty of real bugs?! And to disable them I have to edit the game files? Why is this not an option in the menu or at least clearly communicated? Whats the point of tinting the image green during the day anyway?? This would be ok if it was a special event that has to be triggered by the player, like flying at midnight upside down or something like this. But a permanent change that is annoying at best during daytime missions? Is the concept of [green] considered a funny reference now or something? I assume the other issues like lightbleeding, terrible reflections, broken AI, broken missiles, broken button labels and broken Autopilot are also some clever joke?