Determine"Altitude" of various Fresh Water Lakes?

[Hevii Guy]

Preamble: I know a lot about bolts and bolting (I make my living as an industrial Bolt Geek, traversing the globe, making sure that plants don't blow up, bridges don't fall down, cranes don't collapse or wind turbines don't throw blades because their critical bolted joints failed). However, when it comes to coding, I'm like a 7 year-old who has found his parents' keys to the car and decides to take it out for a spin; I know just enough to be incredibly dangerous.

Working from wlbragg's generous code, I've tried to create a new property in my ship's xml file called "modltyp" ie:

Code: Select all

<entry>
      <type>carrier</type>
      <name>FGS_Braunshweig</name>
      <modltyp>boat</modltyp>
</entry>

I've done this because in some cases, "callsign" contains variables other than just "fleet". For example, in the vinson_demo, each ship has it's own unique callsign. The Vinson's is "Vinson", one of the escort's is "CG-57" and so on.
I had then edited wlbragg's most recent nasal code (not the array example) by replacing all instances of "callsign" with "modltyp" and "fleet" with "boat" as follows:

Code: Select all

# main() ============================================================

#this requires that all ships have "<modltyp>boat</modltyp>" in their respective XML


var main_loop = func {
  foreach(var shipN; props.globals.getNode("/ai/models", 1).getChildren("carrier")) {
    {
      if (string.match(shipN.getNode("modltyp").getValue(), "boat")) {

        aiParent = shipN.getNode("modltyp").getParent().getName() ~ "[" ~ shipN.getNode("modltyp").getParent().getIndex() ~ "]";

        var currentLat = props.globals.getNode("/ai/models/" ~ aiParent ~ "/latitude-deg").getValue();
        var currentLon = props.globals.getNode("/ai/models/" ~ aiParent ~ "/longitude-deg").getValue();
        var terrain_elev = geo.elevation(currentLat, currentLon);

        props.globals.getNode("ai/models/" ~ aiParent ~ "/elevation-ft").setDoubleValue(terrain_elev);
      }
   }
  settimer(main_loop, 10);
}

setlistener("/sim/signals/fdm-initialized", func {
  main_loop();
});

Nope. Nada. No joy. Clearly, there must be more to it. Just as there's more to driving than careening from curb to curb...

[Thorsten]

Working from wlbragg's generous code, I've tried to create a new property in my ship's xml file called "modltyp" ie:

There's different types of xml in flightgear. You can create new properties only in what is

<PropertyList>

but there's tags which switch the content to different modes - for example <aero> passes all enclosed xml stuff to the Flight Dynamics Model for parsing, so what's passed there won't show up in the property tree under <aero> but is initialized as chains of functions executed by JSBSim.

Likewise what's inside a <scenario> tag is pre-defined content parsed by the AI system - whatever other tags you add there are not going to be recognized and will be ignored.

If you want to add properties to an AI ship, you need to do it in a different way. For instance, the Truman registers a lot of properties via its own Nasal code enclosed in the model xml wrapper.

https://sourceforge.net/p/flightgear/fg ... truman.xml

You can find statements like

Code: Select all

      var carrier = "Truman";
      var pathc = cmdarg().getPath();
      var self = cmdarg();
(...)
      var jbd1 = aircraft.door.new(pathc~"/surface-positions/jbd[0]", jbd_transit_time, 0);
 

Which register the Jet Blast deflector controlling properties under the path ('pathc') the model is occupying in the property tree. In that way, you could also register a type.

[wlbragg]

I've done this because in some cases, "callsign" contains variables other than just "fleet".

Yes, that was a work around and only feasible if "callsign" wasn't being used.

So in this case I would suggest using the "array" option.

[Hevii Guy]

So in this case I would suggest using the "array" option.

I shall do that. And, I'm also going to jump into another car and careen against lines of code in attempt to try something really funky like create a new property

[Hevii Guy]

If you want to add properties to an AI ship, you need to do it in a different way. For instance, the Truman registers a lot of properties via its own Nasal code enclosed in the model xml wrapper...

Thanks for the enlightening comment, Thorsten. Would you suggest that I add var mdltyp = "boat"; at line 25 of, for example, the truman.xml file and also to the other ship's xml files within /Models/Geometry/ ?

I would hope that after doing so, I can then use wlbragg's code and substitute "callsign" with "mdltyp" and "fleet" with "boat".

I have a feeling that many people who have always wanted to sail a convoy of carriers upon say, Lake Michigan (rather than below it's surface), would find this exercise and hopefully its successful results to be very helpful!

[Hevii Guy]

I just noticed that not all "ship" files contain embedded nasal code in their respective xml files. Ouch. This is a bit of a brick wall...

[wlbragg]

If you explain what it is your trying to accomplish overall, we might be better able to suggest the appropriate course of action.

[Hevii Guy]

If you explain what it is your trying to accomplish overall,.

I'm sorry if I didn't make this clear! It's really rather simple:

Just as I can choose to fly in any part of the sim world, I'd like to be able to have the option of engaging with AI ships in any part of that world. Currently, one can only do this if one limits one's choice in this regard to the oceans. Since the AI ships in their current coded form assume that they're floating upon water at Mean Sea Level, attempts to use them on lakes or rivers at higher elevation means that rather than sailing on the surface, they're actually sunk beneath the waves. This somewhat detracts from the intended experience!

I suppose that what I'd like is to have the same functionality as AI vehicles have when they're incorporated in different parts of the world at elevation. As they merrily drive along, they seem to remain on top of the simulated ground, following it's contours, rather than plowing into and under the dirt.

[Thorsten]

Generally you probably want some kind of Nasal script which loops through all AI ships currently loaded, for each of them checks the terrain elevation and type (you don't want to steer your ships towards land) and adjusts altitude/course accordingly.

Alternatively, the script could reside with each ship and adjust the ship itself.

It's not conceptually difficult to create such a script - you just need to read positions from the property tree, do geodinfo() queries, process them and write new properties in response - but since geodinfo() is one of the most expensive functions you can call, if you want to have good performance, this needs to be structured carefully that you have only one such call per frame.

I suppose that what I'd like is to have the same functionality as AI vehicles have when they're incorporated in different parts of the world at elevation.

I've never looked at AI ground vehicles - but can't you simply declare your ship a ground vehicle if the functionality to follow terrain already exists? Seems easier than to rig a ship manager...

[Hevii Guy]

...can't you simply declare your ship a ground vehicle if the functionality to follow terrain already exists...

Sounds good to me! Is a body of water's surface always considered to be the local terrain?

...Seems easier than to rig a ship manager...

That sounds even better! Any suggestions on how a code-neophyte such as I am can begin? I'm hoping that there is some cut'n'paste-able code that I can apply from terrestrial AI's to floating AIs.

[Thorsten]

Sorry, as I said, I have no experience with AI ground vehicles. I gather they're declared similarly to ships, so if you just take one that does what you like and replace the 3d model by a ship, it might already be enough (?)

[Hooray]

My suggestion would be to stop tinkering for a while and instead do a little research to see what we have already in the form of various Nasal scripts, modules and addons and then see if/how they could be adapted for your particular use-case. For instance, see this: viewtopic.php?f=36&t=15842&p=327731#p327731

And maybe, take a look at this :https://forum.flightgear.org/viewtopic.php?f=6&t=23799

[wkitty42]

the problem is that without tinkering and figuring stuff out, most of the existing stuff is gibberish... i've looked at a lot of code, xml, nasal and some C and unless i've been tinkering with something similar, most of it is pure gibberish... that classification should go away as one becomes more and more familiar with the code but until then, tinkering is the way to learn...

[Hooray]

Yes, that's a very good point - but it may save you tons of time (tinkering) if you start looking at related stuff/code, and focus your tinkering there.

[wlbragg]

I'm also going to jump into another car and careen against lines of code in attempt to try something really funky like create a new property

I asked you what it is your trying to do because I thought you had a solution to your problem by using and "array" containing the names of the ships in your "fleet". Beings the "callsign" was also being used for other purposes "array" was the best option to be able to control a fleet.

Now you want to make a property, for what purpose? Instead of using the "array" idea? If it is to replace having to loop through the array of names the problem would be you have to associate that "new" property with each ship somehow. If you look at the property tree for each ship you'll see that each ship has the same properties available. If you want to add to that list by creating a new property, say you want to add a "fleet" property that contains a matching "fleet" name so you can have several unique fleets driven. You still have to add the fleet property to every "ship" type by looping through all the ships and adding it universally (which would be unnecessary), or you have to provide a list of ship names for those you want to add the new property to (back to looping through an array). It then becomes an unnecessary step. Just consider your original idea of looping through an array of names as being that "fleet" list. What I mean is each array of names is its own fleet.

Thorsten suggestion was to do what the code we've been compiling actually starts to do. It is, at this point, a simplistic ship manager composed of a dozen or so lines of code. It already incorporates a minimalistic geo-reference for elevation at x-y location. All that might be left to do is extend the geo portion to poll terrain to avoid land.

Thorsten's other suggestion is simply using the existing ground vehicle AI system for your ships controller by declaring your AI ships as a ground vehicle. There are some examples in fgdata/AI, like a couple trains I believe. There may be vehicles too. But I'm not sure that is going to get you anywhere different other than it may solve for elevation automatically which we already did. What other functionality is to be gained by declaring it a ground vehicle VS a ship? I guess it is worth trying, just look at some ground vehicle examples, the AI definition and XML should basically be the same or similar. See if by declaring the ship a "ground vehicle" instead of a "carrier" or "ship" gets you what you need. I am not even sure of what tags are available in the AI system, or what ones are pertinent, ship, aircraft, carrier, ground, etc?

So back to the array option, I think most of your functionality has already been solved. Why switch to a ground based system at this point? What is it you are still trying to achieve that has not been achieved? Or am I missing something?