I don't see how my approach and FG main could coexist.
Well, let's try to outline a few ideas, shall we?
- JBDs do not automatically raise when catapult is locked and JBDs are not lowered automatically after catapult is released
- Flight ops are not initiated when a catapult is locked, so antennas may remain standing upright instead of being rotated down.
Someone may correct me if I'm wrong, but I believe in reality the JSBs can be lowered and raised independently of whether an aircraft is in the catapult. Thus, the fact that they're raised when an aircraft is engaged is a procedural issue.
Thus, for consistency I left it in this state such that if you want to follow correct procedure, you have to operate the catapult and JBDs and don't see this as a shortcoming.
It begs the question whether (since we simulate things from the aircraft perspective) this should be automated. However, turning to launch course or recovery course are not automated, catapult engage is not automated, catapult fire is not automated, elevator operation is not automated - all these are tasks not done by the pilot in reality - so it seems a bit arbitrary that this particular bit should be. Similarly with the antenna.
I have no strong feelings on the point - a merge request to change the behavior if people prefer it differently is welcome.
- Tower view is not synchronizable to carrier
I suspect Richard might be addressing that...
- glidepath is not usable for carriers
I think I argued that elsewhere and there was a good measure of agreement from many users - FG aims to simulate reality, and having a ladder in the air pointing to a carrier is not an aid you have available in reality.
It is not even a valid aid, because the implementation of the ladder as a fixed 3d model
moves with the carrier, i.e. at no point in time does it resemble the actual glideslope you ought to follow.
It simply teaches you bad habits and the wrong cues during approach. It's something out of an arcade game, not something a realistic flightsim can be proud of.
- Elevator wires are not shown, because the property to control them must be inverted to elevator property, which is not done.
- do not move before/after elevator but simultaneously
A simple merge request to the behavior you'd like can fix this today.
(Actually, as far as I recall, I kept the timing and ordering of the animations I found in the carrier pack where feasible - the exception being elevator timing, which needs to be relatively long to play along with JSBSim sampling the interaction with the ground at FDM rate and being treated to a series of shocks from animations running at framerate).
A downside however is the fact, that currently 4 carriers of Nimitz class are supported, which have more or less the same characteristics and 4 highly redundant dialogs exist side-by-side.
Actually since the Truman is equipped with more goodies than the Nimitz, they're not exactly redundant. But realistically, the actual downside here is that you have an increased harddisk usage of 20 KB or so.
I can live with that. It's basically a non-issue - it's not clear to me why you even mention it...
(Architecture optimizers could also think of letting the carrier declare what features and controls it provides and build a dialog from that procedurally, but... the code to do so would likely be more than 20 KB worth of harddisk space and it's not worth my time...)
However, keyboard shortcuts need to know which carrier they refer to and need a concept of knowing an "active" carrier if they do not affect all carriers.
First of all, key bindings are among the most valuable pieces of real estate FG has - given all the ideas people have for them, we could fill every slot about four times. There also needs to be room for aircraft maintainers to assign keys AND for people to define their private key bindings - otherwise this leads to all sorts of bug reports due to overlapping bindings erasing each other (they're generally nasty...)
So introducting FG-wide key bindings is something that should be done very carefully.
FG-wide key bindings make sense when
* they affect basically every craft (or use case)
* they make a task that it done 'often' shorter
* they take place in a time-critical situation where letting go of controls to fiddle with he mouse is awkward
None of these is true for operating carrier elevators.
Having said that, as in the case of the glideslope, these things which differ from the general philosophy are best shipped in the form of an addon - people who prefer to have these kinds of features can simply opt-in and install the addon. So here we can have the cake and eat it.
It is a question of a handful of Nasal lines to bind the keys to a function that identifies the active carrier (I suppose that's usually the closest one - the dynamically built AI-object list in the GUI shows how the Nasal underlying this would look like) and passes the command to this carrier only.
So there's really no big conceptual issue here - the FG approach permits you absolutely to do what you want, but your approach does not permit the per-carrier control that's required.
(Alternatively, such key bindings could reside aircraft-side of course - it is certainly true that carrier-capable aircraft run into this more often).
The work on the other carriers besides Truman was not merged to FG.
I actually think if you want a high-quality Nimitz, the approach should not be to add effects and models on top of the existing low-poly lowres texture Nimitz model, it should be to use the Truman model and change the texture to show the right name and number, then add the relevant changes to the xml - it's perhaps 10 minutes work, and you don't end up with a mash-up of different quality, you have a second carrier group with the highest quality.
I have spent 2 days trying to somehow get to work my additions with the new Truman and other carriers and then decided to dump it.
You know, that's the thing about collaborative work - you could have simply asked 'how would I go about if I want to do XXX' and I'd have told you... would have saved you two days of frustration. Others here may testify that I'm generally trying to be open and helpful to make such ideas happen.