norman99

Don’t confuse naval ground power units and their intended functions with civil aircraft ground power. Civil aircraft are designed to use ground power as part of there every day operations. Loading and unload cargo/catering/cleaning pax all require power, so aircraft use ground power to minimise apu usage. To facilitate this, the electrical systems onboard modern aircraft have no break power transfer systems. My understanding of navy ground power units are they are primarily use by maintenance crew, and are not used in an operational sense. Because of this, there is simply no need to include no break power transfer as a feature in the aircraft.

Wow, just found out this bug is over 3 years old! Surely no one actually thinks that this is acceptable? ED’s disregard for things that are just ‘too hard’, no matter how important, never ceases to astound me.

This issue is extremely frustrating, as it basically breaks TWS multi-launch functionality. As soon as the first missile is launched, the radar instantly creates a track file for the outgoing missile , and re sorts the tracks. Using the NWS/undesignate button to step to the next target selects the missile instead. Launching on more than one target therefore becomes almost impossible, as the TDC cursor has to be used, extremely difficult in a time critical situation. It should not work this way, it’s literally what track file priorities and the NWS/undesignate button are designed for. Whilst I’m no expert, I’m extremely sceptical about the ability to track (or at least display) outbound missiles. Why have the missile fly out cue and associated symbology, if that is the case?

Hopefully..... eventually..... Sounds promising. Haha.

On multiplayer servers, I always receive RWR lock & launch warnings from AI aircraft 70nm-100+nm away, as they engage other aircraft, so long as they are pointing roughly in my direction (+/- 45 degrees). Whilst I understand getting false warnings if I'm very close to the aircraft actually targeted, what currently happens seems very unrealistic. Below is an example of receiving a lock RWR warning sitting on a carrier deck, whilst the source SU27 engages an F-14 70nm away. On a multiplayer server so I don't have a track. I don't seem to get this in single player. Not sure if it's a Hornet RWR problem, or a general DCS radar/AI issue.

Drastically improved AI is actually a prerequisite of dynamic campaign development. There's absolutely no point in having persistent force levels and units, if AI aircraft all 'bingo & eject" every second flight. Within a day there wouldn't be any aircraft left to task....

Any additional update on this bug? It’s extremely frustrating to get the lost cue, and loose the time to active, during every launch.

I’d imagine STD HDG isn’t used for carrier ops. As already mentioned, aircraft are almost continuously re spotted (moved around on deck), especially during cyclic ops, so it doesn’t make sense to use this function.

Realistic carrier group formation, with substantially greater distances/separation than what is normal in DCS. Probably only suitable for the Marianas map.

What we desperately need is a separate sea state control. Hopefully that'll be part of the new weather system.

The main DCS manual includes embedded PDF outlines, which enable you to access a table of contents whilst reading any page. Very helpful for a reference document, rather than having to go back to the contents at the start of the document every time. Unfortunately, the F/A-18 Hornet manual has always been missing this detail. Hopefully it can be included some time soon in the future.

Cool. If that's the case, I hope we get that sort of resolution in DCS.

My understanding about AG radar usage in Gen 4 aircraft was its primary task was to remove INS drift in the pre GPS era (or due GPS jamming). The radar is used to identify a large object with a known location, such as a bridge, warehouse, runway threshold etc, whilst on the run in to the target. Then, using a known offset (bearing and distance) from this radar fix, the target position can be updated and displayed more accurately. Whether you simply drop bombs on the updated designation in auto/CCRP, or use it to help visually acquire the target would be mission/weather/weapon dependent I guess.

Impossible to tell from a video, but I really hope some significant improvements are made to AI logic, ATC, & flight/wingman coms. We keep hearing about "constant development", but actual progress on these items is glacially slow. For SP only players, these have a huge impact on the quality of literally everything we do. The cynic in me understands there's no revenue to be made here, but fingers crossed for some nice surprises. Also interesting there wasn't anything hinting at Supercarrier improvements, even something as simple to show as light wands. Almost seems as though the Supercarrier is dead in the water....

So this issue is a major problem for any mission without GPS available, as it completely breaks unguided bomb delivery. It was reported over a year ago, and has been discussed in multiple threads. Can we please have an update on this, other than just "reported". Can we expect a fix, or is the Hornet only ever designed to work correctly in post 1994 dated missions? @BIGNEWY

A lot of us share your frustrations re SuperCarrier ongoing progress and support. Yet it remains eerily silent in this part of the forums..

My take on needing to press F9 first is so that the view system can first “select” the ship, so to speak. Picture a scenario with multiple aircraft carriers present. Using F9 cycles through the ships present. When the correct aircraft carrier is the current focal point, using RCtl+F9 then cycles through the relevant sub views for that specific aircraft carrier. Whilst this may or may not be how the view system is supposed to work, when you think of it this way, it kinda makes sense. Obviously it’s one extra, and unnecessary step if only one aircraft carrier is present.

Exactly this!!!! All the talk about the dynamic campaign revolves around its design, the RTS engine, how logistics will work etc. The huge elephant in the room is the in game AI unit behaviour. Without this getting a fundamental overhaul, the dynamic campaign simply won’t work as expected. I think it’s going to be a substantially longer and bumpier road ahead than many people expect.

This paragraph from the Hoggit Wiki describes you problem exactly. “On the Stennis and Nimitz SC objects there are 4 spawn points that are available only at mission start. These 4 are in the "six-pack" part of the ship. When there is a PLAYER skilled aircraft set in the editor the player will ALWAYS spawn in the first position. Anything that spawns at least one second after mission start will spawn in the next available spawnpoint.” The simple solution is to delay the start of your specific flight by at least 1 second using the late activation flag. This will move your spawn point from the six pact to the next available spawn position. Combined with this, use the spawn position diagram in the SC manual to determine how many aircraft need to spawn at mission start prior your aircraft, in order to place your aircraft in the desired location.

These two links should help. https://www.seaforces.org/usnships/cv/Aircraft-Carriers.htm http://www.gonavy.jp/AirWingsf.html

One of the reason we need a seperate “sea state” control, so we have the ability to change swell size, regardless of wind conditions. I want to be able to land (well, crash actually...) on this.

In your video, it looks like the cloud motion is scheduled to the direction of travel of both the aircraft, and the carrier. In less I’m missing something, I don’t see much wrong here. Remember that the wind direction in DCS (the ME and reported by ATC) is reversed compared to real life wind reporting standards. It indicates the direction the wind is blowing towards rather then the direction it is coming from. (This really needs to be changed as the weather system is improved.) In DCS to set a northerly wind, usually reported as 360°, the wind need to be set to 180° in the ME.

Deck crew are either in a launch or recovery state. They can’t do both at once. Hence the need to wait for all arriving aircraft to trap before launching is available again.

Unfortunately the entire altimetery system in DCS is currently unrealistic. It is built around an “absolute true altitude” concept, where AI aircraft, aircraft systems & sensors, mission editor features, and basically everything else related to altitude at all, only use the exact true altitude, regardless of the air pressure, air temperature or altimeter setting. I wrote the below in another thread, but I’ll past it here as it’s relevant too. My hunch is that DCS has basically been "fudging" correct altimetry for some time. Seems the underlying code all uses "DCS true" altitude, and only in some specific cases, such as player/client aircraft altimeters, does it appear as though any additional pressure correction is able to be applied. I guess 10+ years ago, when the entire ecosystem was no where near as complex or realistic as it is now, this wasn't really noticeable. Unfortunately with the plethora of additional data sources and emphasis on realism that DCS has today, it is starting to become a notable issue. All aircraft. Including AI, should have the ability to correct their altimeter for changes in pressure, and all systems that use altitude as an input such as radar, datalink etc, should be using this corrected figure. Unfortunately, I picture this as a hugely complex issue to solve though. The weather system, AI logic, and individual avionics of almost every aircraft in the game would need to be updated. As I said, this is a tough one for ED. There is most likely so much code, both new and old built on top of the original "true alt' concept, that it would be a massive task to change this effectively.