Hogeo

You are free to think that "In combat missions, the carrier does not orbit, but sails like the carrier in Ace Combat. In war, you never know what will happen next, so you have to deal with it flexibly, and launch/recovery is not always done in a safe area where a diversion airfield can be set up. This is the way real carrier operations should be." And I do not deny those who like that type of mission, and I do not want such missions to become impossible to create. However, if this topic is a wish topic for people who want to realize more realistic carrier operations, posting such opinions goes against the purpose of the topic. Aircraft and carriers are very expensive military assets, so they are operated in places where threats are absolutely not allowed to approach under any circumstances. If an aircraft carrier, which is the pride of America, were to be sunk by carelessly operating in an area where threats are expected, the disappointment and dismay of the American people in the U.S. military would be incomparable to the national feelings that arose as a result of the Vietnam War. But when you think about it, carrier operations in the Pacific War were very risky. Even the Japanese Navy's attack on Pearl Harbor was a strange event, with nearly 200 aircraft launched at once in the open sea with no alternative airfields. I can't help but wonder if they didn't plan carefully enough because it was the early days of carrier operations, or if it was actually a US Navy plane with Japanese markings that was launched from a US Navy aircraft carrier (which may be why there were no US aircraft carriers anchored at Pearl Harbor at the time). And I suspect that the current conservative US carrier operations, which are determined to "never let US soldiers die," were built on the accumulation of such experience. Oh, sorry. I've digressed, but that's why merging with cyclic ops is inevitable in order to avoid posting incorrect opinions. If this is not done, it would be unreasonable to complain that wishes in the same context are intentionally split up, making the number of wishers appear small and difficult to realize.

Shouldn't this topic be merged with the topic of cyclic ops? The wish here is something that is included in the cyclic ops that are always carried out when an aircraft carrier conducts air ops. In other words, if cyclic ops are realized, the wish discussed here will naturally be realized on a higher level.

I'm sorry. I read Jackjack171's post and realized that I was also posting things that were disrupting other people's wishes. I deleted those my posts. I may have just wanted to show off some knowledge that I had gained. I'm grateful to Jackjack171 for giving me this awareness and opportunity.

If ED wants to continue using the phrase "the most detailed and realistic simulation" to describe the module, ED must fully implement carrier operations that is not a hard thing for ED to do, even if it means rebuilding the Supercarrier from scratch. We bought the Supercarrier because we trusted ED, and we're stating our opinions on the wish list. ED should not treat your customers' feelings with contempt.

I've been researching it for a few years, and I'm finally able to form these opinions. Every time I learn about various actual operating methods, I am amazed at ED's attitude of claiming to have been making "flight simulators" for 15 long years. The word simulator is given to something that virtually reproduces a real situation, so if DCS World is a simulator, there can be no operations that do not exist in reality. Aircraft carriers never perform launch/recovery operations while sailing in a straight line. They always set up a diversion airport, stay in an area of sea where they can reach it in an emergency, and perform launch/recovery operations while turning. And aircraft never take off or land while heading downwind. The only place where aircraft carriers which takeoff and landing operations are performed on an aircraft carrier that sails forever in a straight line, or where takeoff and landing can be performed even when heading downwind are allowed to appear is in a shooting game that does not need to pursue realism, such as Ace Combat. Despite this, DCS World's Supercarrier, which is called a flight simulator, only has a shooter-like aircraft carrier. What does this mean? If only shooter-like modules are available, ED should stop calling DCS World a flight simulator. Instead, ED should call DCS World a shooter game. ED should not scam people into paying high prices by making them believe that they can experience a real war in the game by making them watch promotional videos. But ED will argue: "Even starting an aircraft engine is a lot of steps, and can players do it? If it's not reasonably simplified, no one will play it." So what percentage of DCS World is realistic? I've been saying for years that it's not realistic to be able to take off and land on a downwind-bound aircraft carrier. And this is common sense in the aviation, and it will never be operated like that in real life. But ED still hasn't abolished it. It's true that in reality, it may be possible to ignore the tower's instructions, or to take off and land downwind on a runway without a tower. It's very interesting that they don't reproduce the most common operations, but they do faithfully reproduce the ones that are rarely performed. I can only think that ED is deceiving people by calling DCS World, a shooting game that is far from reality, a "simulator" under the pretext of "simplifying it for the players". You may say, "If you think so, you just need to stop playing DCS World. ED is not forcing you to buy or play mods. And even though you complain to us like that, you recently bought new maps and mods. It's you who should realize your own contradiction." If ED claims like that, it must be understood that they are confessing that "ED continues to sell mods while knowing that they are defrauding people's curiosity."

I thought the mission file I attached in my last post was too simple, so I re-created it with a more accurate schedule. I thought that the group ID and the order in the plane.group table would determine the spawn sequence, which would determine the spots, and then the taxiing order would be determined by the parking location. But to park on the street, it had to be placed in the top index of the plane.group table. So I created a mission file with the following order and group ID assignments: plane.group={ [1]=MISR MIO(F-14) groupId=23, [2]=SHARP(F-14) groupId=24, [3]=Delete1(F/A-18) groupId=20 (dummy aircraft group for parking E-2s on spots 7-8), [4]=AEW(E-2) groupId=21, [5]=FCF(E-2) groupId=22, [6]=RTNK(S-3B) groupId=29, [7]=CAP1(F/A-18) groupId=30, [8]=CAP2(F/A-18) groupId=31, [9]=CAP3(F/A-18) groupId=32, [10]=CTTG(EA-6) groupId=33, } When I flew this mission, I got the following results: 8:50 Mission start. Spawned PG, E-2s and fighters parked on the street 9:00 Spawned other fighters 9:05 PG & E-2 engine start. But there is no way to delay the takeoff of the helicopter, so it takes off immediately. 9:15 fighters engine start 9:20 E-2 taxi start. The E-2 on spot 7 started taxiing, but the E-2 on spot 8 did not start taxiing, even though it was spawned before the fighters. And because there is no way to delay the launch, the E-2 launches without waiting for the launch time of 9:35. 9:30 fighters taxi start. But surprisingly, even the fighters on the street do not start taxiing. In conjunction with that, the E-2 on spot 8 does not start taxiing either. 9:35 PG & E-2 launch start. This is the original launch time for the PG and E-2. 9:45 fighters launch start. This is the original launch time for the fighters. I don't understand why this result occurred. And I don't understand why Supercarrier has specifications that are so difficult for hobbyist mission creators to understand. I imagine this is a preferential treatment for third-party companies that have access to paid support. So I've once again come to the conclusion that it's impossible to implement realistic cyclic ops using Lua scripts that hobbyist mission creators can implement. test_airplan_event1-ver2.miz

I tried to implement the Case II departure procedure. When the aircraft is more than 7 DME away from the carrier, several Russian helicopters are spawned in the sky, and the Controller.isTargetDetected function is used to detect them and find the next direction to head. However, when the cloud density is 8 or less, visible=true is returned even if the helicopter is not visible due to the clouds, and conversely, when the cloud density is 9 or more, visible=false is returned for helicopters at altitudes above the cloud base, even if they are visible. If visibility can be judged not by a simple cloud base or thickness setting, but by judging whether an object is visible as seen by the human eye, it should be possible to ascend through gaps in the clouds. Also, in my implementation, I cannot set the altitude from launch to 7 DME to 500ft, or fly at a constant 300KIAS throughout the entire departure procedures. The implementation of Case I/II Departure procedures and the rough implementation of Case III report call are implemented in a series of processes called by the flib_CV_departure_ops:go_case_departure() function contained in flib_CV_departure_ops.lua. The contents of the lua files included in the two mission files are identical, and their licenses can be considered public domain, so please feel free to use them if necessary. I hope this will help you fully implement Case Departure Procedures in Supercarrier. test_CASE II deperture_cloud_density=8.miz est_CASE II deperture_cloud_density=9.miz

To clarify the conditions for each case, I created the diagram below. Anyway, such basic things must be completed as a priority over the creation of other new mods one after another. Sorry. I made a mistake myself, so I have corrected it. null

I set the fog with visibility=4.85nm(29,528ft) & thickness=3,000ft, and flew from about 5 DME/2000ft away to see the carrier. Although I could not see the carrier, the marshal instructed us on Case I recovery. If the visibility is less than 5nm, the marshal must instruct Case II recovery. Also, even when the cloud base was 2952ft (900m), the marshal instructed Case I recovery, and even when the cloud base was 984ft (300m), they instructed Case II recovery. Marshal must instruct Case II if the cloud base is less than 3000 - 1000ft, and instruct Case III if the cloud base is less than 1000ft. However, it seems that since the standard is based on meter values such as 900m and 300m, it does not work properly with the foot standards described in CV NATOPS and CV PROCEDURES. When setting the weather, the units are mixed and it's difficult to understand, as even though the panel shows it in feet, the implementation seems to judge it in meters. I would like it to be fixed so that it can be set correctly in the units shown on the panel. Also, for fog, if the thickness value is small, the fog height is too low, so even if you set the conditions for Case II/III, the marshal may not instruct Case II/III. In other words, ED will need to not only revise the case judgment logic, but also clearly state the conditions for setting Case II or Case III in the operation manual or somewhere similar. However, the biggest problem is that despite the fact that these have already been reported, they are giving a response as if there is no problem without investigating them. Although it has been quite a while since the release of Supercarrier, the fact that the conditions for the case, which is the most distinctive US Navy aircraft carrier operation, has been attracting attention from many players, and is written in the supercarrier operation manual, have not been implemented correctly, is even considered to be a clear indication of ED's attitude toward flight simulator development. test_CASE_I_in_fog.miz

It seems odd that US amphibious assault ships only have the LHA-1, and there are no CH-46E Sea Knights, despite the existence of AV-8B flyable mod.

In Operation Enduring Freedom, CIA agents and Special Operations forces who were conducting undercover operations in Afghanistan traveled on horseback. So I think we need to be able to have those people on horseback function as FACs.

Adding airports around Afghanistan is important because they would have been bases for transport aircraft, tankers and CSAR aircraft carrying humanitarian aid during the early phase of Operation Enduring Freedom. PAFB Shahbaz Jacobabad was also the base where Apaches and A-10s were deployed during the early phase of Operation Anaconda in March 2002. PAFB Shahbaz Jacobabad is a must-have for these mods. And one more request: I'd like to see Pakistan Air Force Base Faisal added. I believe this was intended as a divert airfield for the aircraft carriers stationed in the North Arabian Sea.

I should have asked for a larger US East Coast map coverage. Because Florida is home to NAS Mayport and Jacksonville OPAREA. It was also the home port of the USS JFK. Also, I'd love to see mods for USS JFK and USS Kitty Hawk, or skins for them for USS Forrestal.

As already mentioned, in San Diego, there is NAS North Island, the home base for the Pacific Fleet's aircraft carriers and their CVWs. And in the waters southwest of San Diego, there is the Southern California Range Complex(SOCAL Complex), where carriers and CVWs conduct training and CQ before deployment. So I think an expansion of the DCS: Nevada map is inevitable for DCS: Supercarrier. In my opinion, it needs to be expanded by at least double its current height and width.

Departure procedures have been a long-standing request. It seems that Case III (though there is no voice report) has been implemented. But the others are not yet. In Case I, after taking off from the carrier, you just fly from the carrier to 7DME at an altitude of 500ft at 300 knots, and then you can navigate freely. This does not seem difficult to implement, since there are only altitude and speed restrictions up to 7DME. One example of how to implement this is to aim for a waypoint at alt=500ft, speed=300kts a few nm ahead at 1 second intervals until 7DME, and when the AI aircraft leaves 7DME from the carrier, fly to the waypoint originally set for the AI aircraft group. When I implement it like that, it climbs to about 1000ft immediately after taking off. After that, it tries to fly down to 500ft. I would like to eliminate this first climb up to about 1000ft. Case || is a bit special, and you must avoid flying through the clouds. 1) Fly at 300 knots at an altitude of 500ft from the carrier to 7DME. 2) If you find a gap in the clouds 7DME from the carrier, the 500ft altitude restriction is lifted, and you can climb through the gap (i.e., it is the same as case I). 3) If there is no gap in the clouds that you can climb through, keep your altitude at 500ft, pass over the 10DME Arc as in case III, leave the 10DME Arc on the departure radial, and fly in search of a gap in the clouds. 4) If you find a gap in the clouds, the 500ft altitude restriction is lifted, and you can start climbing. The question here is how to find a gap in the clouds, but I think you can determine this by flying some kind of target in the sky that is invisible to the player, and using the Controller.isTargetDetected() function to determine whether the target is detectable with DetectionType=visible. If I were to implement this, the player would see the target (i.e. an aircraft not on the plan flying), which would raise the question of why such an aircraft is flying. So I would like to see this implemented in Supercarrier.