Board index FlightGear Development Scenery

USS Nimitz Supercarrier

Questions and discussion about enhancing and populating the FlightGear world.

Re: USS Nimitz Supercarrier

Postby Thorsten » Sat Jul 14, 2018 6:32 pm

There won't be a public fork anymore and with so many people involved I don't see me contributing for the near future.


FG got where it is by being a collaborative venture. Of course we all know what's best for FG, but unfortunately that's a different thing for each one of us - so we sit down and discuss, and in the end we settle on a solution we all can live with and do it. That's in the nature of collaboration (and yeah, that puts me into the awkward position to not only code but also defend the AI GUI solution here which I didn't really argue for in the first place - but such is life).

It's completely okay if you don't feel comfortable with such a setup and want to be your own thing - that's what 3rd party hangars are for after all. So whatever has been said by FG developers, there's really no reason to give up your own development.

The only thing that won't happen is that FG-side development is done according to requirements set by 3rd party hangars - it's up to the hangars to maintain compatibility (or not) - there'll just be a fork then.

Either way, I am sorry for whatever mistake I made during the process (I wish I'd know) - I am grateful for the work you did, and I've just checked you're properly credited as the author of the animation works. I'd much prefer if everyone who is interested would work together and try to find common grounds, but sometimes that doesn't work out.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: USS Nimitz Supercarrier

Postby mhab » Sat Jul 14, 2018 9:21 pm

Hello and thank you to all who had some words of encouragement.

I think it is only fair to give some explanations from my side, (although it may result in tiring discussions)
So here are some thoughts on recent postings and a summary of why I decided to continue my own approach despite FG main stream.

@Richard: I fully agree to your wishlist of corrections/additions for carrier improvements.

@wlbragg: thanks for your encouragement and conciliating attitude

@wkitty42: I don't see how my approach and FG main could coexist.
I use relative paths for the carrier control props while FG approach uses absolute paths.
In other words: How should an english story be merged with a french/spanish/german or whatever episode and in any useful way grow together without being rewritten ?

Critical remark: How the current FG 2018 approach fits to the concept of every AI object having it's own subtree is a discussion of it's own.
Maybe it is a wrong approach to handle carriers as AI objects in general ?

I have suffered a lot until I somehow mastered the property tree logic and Nasal implications of AI objects.
It started with formation flight and wingmen handling and continued later with carriers, which can also appear as AI type "ship" or "escort".

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.
I simply didn't have the motivation to start every test from scratch, when I had everything working already in my approach.

Finally my analysis of FG 2018 pros and cons regarding carrier handling:
FG 2017.3/2018.1
As of 2017.3 Truman carrier was added to standard FG and some parts of the carrrier extension work were merged into FG.
In discussions in FG forum it was decided to not merge those parts which would be better solved by extending FG core functionality.
The work on the other carriers besides Truman was not merged to FG.

As new functionality in FG, carriers now need a specific dialog to handle carrier operations.
The carrier specific dialog can be opened via menubar or by clicking the tower of the carrier.
It needs to reside in gui\dialogs and it's name is defined in the carrier xml file.
Truman got a new optional animation for wave movement.

Discussion:
The partly merge into FG led to a situation, where some functionality is not optimum
compared to the state of development in the carrier-extensions project.

Some important shortcomings due to the partly merge are:

- 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.
- Tower view is not synchronizable to carrier
- glidepath is not usable for carriers

BUGS:
- Elevator wires are not shown, because the property to control them must be inverted to elevator property, which is not done.

- Elevator rails, Bay Door rails often do not raise/lower as intended
- do not move before/after elevator but simultaneously
- often do not move at all if more than one elevator is moved

CONCEPTUAL DISCUSSION:
The introduction of a carrier specific dialog allows to control a carrier exactly for the possibilities of the individual model.
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.
Clemenceau and Foch are 2 identical carriers and San Antonio has only moveable stern-bay doors (and isn't a full blown carrier i.m.h.o.).

Another conceptual problem is not solved by the FG approach.
In order to control carriers individually a carrier specific dialog seems to solve the problem.
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.

Thanks if you read until here
Mike-DE
mhab
 
Posts: 418
Joined: Thu Apr 18, 2013 11:59 pm
Callsign: D-MIKE
Version: 2020.3.4
OS: Win10

Re: USS Nimitz Supercarrier

Postby Thorsten » Sun Jul 15, 2018 7:17 am

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.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: USS Nimitz Supercarrier

Postby wkitty42 » Tue Jul 17, 2018 3:50 am

mhab wrote in Sat Jul 14, 2018 9:21 pm:@wkitty42: I don't see how my approach and FG main could coexist.

i don't know... i don't know your approach...

mhab wrote in Sat Jul 14, 2018 9:21 pm:I use relative paths for the carrier control props while FG approach uses absolute paths.

AFAIK, the only difference is a leading '/' or not... but maybe i'm not understanding what you are trying to say?

maybe you are speaking of directory traversal with "../"? that's a big ugly, if so... i'm cleaning up other scenarios now that have directory traversal used in them... they are broken on some systems and certainly will break if things are moved around again like was done when FGData was split into the current FGData and FGAddon...

the seahawk wingman demo is the first of these... with directory traversal, the only thing seen when running the demo is the drop tanks... the craft doesn't appear... i fixed the problem by cleaning up the directory traversal stuff and the craft appeared but there were log or console errors about the red, green, and white lights on the craft so i fixed them, too... this all started with a Mac user reporting a problem with the demo where they were not seeing the craft but they did see it if they copied the craft into the FGData directory where it used to reside before the FGData/FGAddon split... no one should have to ""pollute"" the default installation by copying files into the installation directories...

it should not take much work, really, to fix the differences that are causing you problems... directory traversal, even in the property tree, is just a really huge BadThing<tm>...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: USS Nimitz Supercarrier

Postby mhab » Tue Jul 17, 2018 8:02 am

Hello wkitty
Thanks for your continued interest.

Here is how I understand FG AI property handling.
If you load a carrier, the first one gets the subtree /ai/models/carrier/... the next one is loaded at /ai/models/carrier[1]/... and so on.

If you load Truman as a ship it is loaded as /ai/models/ship[x]/... and if you load San Antonio as escort of Truman it will be at /ai/models/escort[x]/...

If you want to use relative paths for animation you adress it like "controls/elevator/state/..." in the XML file but from Nasal you need to know the full path which depends on what is going on at runtime.

If you use e.g. /sim/model/truman/... everywhere your life is easy.
Thats how you work with aircraft.

AI models is a bit another world and to handle this gave me some headaches ...

Mike-DE
mhab
 
Posts: 418
Joined: Thu Apr 18, 2013 11:59 pm
Callsign: D-MIKE
Version: 2020.3.4
OS: Win10

Re: USS Nimitz Supercarrier

Postby Thorsten » Tue Jul 17, 2018 9:20 am

AI models is a bit another world and to handle this gave me some headaches ...


Maybe, but it's a solved problem, you don't need to figure it out again.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: USS Nimitz Supercarrier

Postby Richard » Tue Jul 17, 2018 11:41 am

mhab wrote in Tue Jul 17, 2018 8:02 am:If you load a carrier, the first one gets the subtree /ai/models/carrier/... the next one is loaded at /ai/models/carrier[1]/... and so on.
..

If you use e.g. /sim/model/truman/... everywhere your life is easy.

AI models is a bit another world and to handle this gave me some headaches ...


This is possibly one of the most commonly misunderstood aspects of the property tree and it also affects aircraft that are loaded over MP.

1. The general rule is that you must never include a leading "/" on any property path in your model xml files, or in your Nasal code.
2. The exception to this rule is the few properties that relate to the FG instance on which the model is running. An example of this is the properties related to environmental lighting.
3. Writing or modifying an absolute property should never be done.

All model xml files are loaded such that their property root is correctly adjusted already, and thus sim/model will be either /sim/model or ai/models/carrier[0]/sim/model, or ai/models/multiplay[0]/sim/model.

Any Nasal code (loaded from the model xml) needs to use the property root that is passed into the model xml in cmdarg (you can see this in my model xml for the F-14 [1])

Follow my rules above and it makes life so much easier.

If you use e.g. /sim/model/truman/... everywhere your life is easy.


Unfortunately that's wrong; and hopefully I've explained this well enough that you can see that it breaks rule(1) above. I've also just added a section to the wiki to cover this[3].

-------------------------
[1] Aircraft also need to use this model, and root based paths will pollute the property tree of the FG instance on which they are running; and worse than this having a property that starts with "/" can interfere with the model that the FG pilot is flying when MP models load. It is usually a bad thing to have a property path that starts with / (except for (2) above).
[2] https://github.com/Zaretto/fg-aircraft/ ... 4b.xml#L25
[3] http://wiki.flightgear.org/Modelling_gu ... erty_usage
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: USS Nimitz Supercarrier

Postby mhab » Tue Jul 17, 2018 7:11 pm

Hello Richard

Your explanation is perfectly right as long as you talk about the model XML file and Nasal code loaded from within that file.
If you address an AI object from an idependent dialog it is not so easy.

e.g. truman.xml dialog from FG 2018.x, which is one of the AIobjects dialogs called via pick animation or FG menu, works with controls that refer absolute pathnames.
... and to keep it as simple as possible in the carrier xml file the same properties are used to have direct feedback.

Dialog truman.xml:
Code: Select all
      <checkbox>
         <halign>left</halign>
         <row>1</row>
         <col>0</col>
         <label>Elevator 1</label>
         <property>/controls/truman/elevator[0]/state</property>   <<<<<<<
         <binding>
            <command>dialog-apply</command>
         </binding>
      </checkbox>

Truman model xml:
Code: Select all
"Nasal part"
...
      # init ai elevators
      setprop("/controls/truman/elevator[0]/state",1);    <<<<<
      setprop("/controls/truman/elevator[1]/state",0);
...

"Animation part"
...
  <!-- elevators -->
  <animation>
    <type>pick</type>
    <object-name>Elevator-1</object-name>
    <action>
    ...
      <binding>
   <command>property-toggle</command>
   <property>/controls/truman/elevator/state</property>     <<<<<<<<<<<<<<<<<
      </binding>
    </action>
    ...
  </animation>
...

So I was not precise enough to mention that I was talking about properties used in all possible situations, which includes Nasal functions and dialogs outside the model related XML and Nasal.

Mike-DE
mhab
 
Posts: 418
Joined: Thu Apr 18, 2013 11:59 pm
Callsign: D-MIKE
Version: 2020.3.4
OS: Win10

Re: USS Nimitz Supercarrier

Postby Thorsten » Tue Jul 17, 2018 7:25 pm

Okay mhab, have it your way. I've tried nothing but being supportive and helpful to you - evidently you don't want to talk to me for whatever reason - that's fine.

From where I stand, your main complaint is that you don't understand the current scheme (which I think is true), but refuse to listen to an explanation or ask for it. Which, well, has more to do with you than with any possible faults with the architecture FG settled on.

I guess some of us aren't cut out for collaborative work, so maybe we ought to leave it at that. Thanks for taking the time to bring up your grievances, I appreciate it.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: USS Nimitz Supercarrier

Postby Richard » Tue Jul 17, 2018 11:26 pm

mhab wrote in Tue Jul 17, 2018 7:11 pm:So I was not precise enough to mention that I was talking about properties used in all possible situations, which includes Nasal functions and dialogs outside the model related XML and Nasal.


The basic theory for the dialogs is OK; except that instead of writing to an absolute part of the property tree the dialog should probably be communicating with the carrier via Emesary - however at this point the dialogs are much less important than the other things that need work. My future plan is to embed the dialog within the model (somehow) and probably to change the core so that we can have model relative dialogs that have their property root already in the correct part of the property tree. The current scheme works fine for AI carriers, and I'm not at all concerned with a bit of extra Nasal to locate the appropriate part of the property to export the values to. Keyboard shortcuts again are something that can be handled effectively using Emesary - to route the shortcut to the active or closest carrier.

What I'm working on at the moment is to include the carrier in the replay. This is currently almost working, but after the replay ends the aircraft drops back onto the carrier deck (if it was previously on the deck). I fixed one problem where it would fall through the carrier deck after the replay (the groundcache was out of date), but I'm still seeing strange effects after the replay ends. I also have to include the rest of the fleet into the replay; but that should be relatively easy.

Next I'll probably work on the LSO view or getting the carrier to be included in the "nearest tower" search. or maybe grading the landing.

At some point I'm going to have decide if it is the right thing to go through all of the carrier capable aircraft and make them compatible with the carrier landing system; this will solve the problem of the aircraft and carrier being aware of each other; but there might be a better (more generic) way that I can achieve the same.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Previous

Return to Scenery

Who is online

Users browsing this forum: No registered users and 6 guests