How to do Train Services

[merspieler]

Before I spend lots of time and a certain someone here on the forum tells me I've been doing it all wrong (cause that has never happened /i)

How would I implement a regular train service?
I can already query the Route from osm.
The DB API should be easily query-able too to get the time table.

I was going to do it based on the ICE demo... or is there a better way? Also, since this is a suburban train, how do I add all the stops to the route?

[portreekid]

A few years ago I tried something like that. The breaking point for me were

* There was two options either on_ground=true for the flightplan or false. On ground doesn't work since the track is not really flat. The other needs a pre calculated elevation.
* The train code is broken. The carriages don't pitch correctly. At the time I wasn't versed enough in C++ and now I'm in the AI rabbit hole.

The C++ traffic manager could be made generic and used for trains/ferries/aircraft. Since it's currently a performance hog and runs to often I want to touch it anyway.

[Hooray]

It''s probably safe to assume that the AI system is basically unmaintained at this point
In fact, here are Durk's own thoughts about the status of the AI traffic system and restarting a more generic and more decoupled module instead: https://wiki.flightgear.org/FGTraffic

Regardless of limitations in the AI/C++ code, you probably can get quite a bit done using just Nasal and property rules in conjunction with LOD/effects

Assuming you have access to railroad network info (OSM?), it should not be that difficult to load that into fgfs and move some 3D objects around using these networks.

For the visualization part of everything, you'd want to look at LOD + effects/shaders.
If you also need terrain interaction, you'd want to code up a pseudo "train" FDM to account for "steepness" of terrain.
If you also need sound, you'd want to use a LOD scheme for that, too.

A number of folks have previously done work related to this - so there's tons of existing work to be looked at/borrowed from, it just isn't well integrated at this point.

Here's the ground services addon that could probably be adapted to load train/road networks into fgfs to monitor different networks/trains at the same time:
https://wiki.flightgear.org/Ground_Services

It might make sense to come up with a dedicated "TrainZZZ" addon and then simply take it from there, to see how far you get.
Once there is some traction, C++ folks are obviously going to get involved to help optimize any bottlenecks
A number of folks have used this approach previously - for instance, the Advanced Weather system came to be like that.

Then again, if you know C++ and are familiar with the SG/FG code bases, you could just as well review/improve the AI subsystem, which would probably be less work in comparison - but see the FGTraffic article to learn more about the architectural issues of that approach before doing any work in that area.

https://wiki.flightgear.org/Traffic_Shader

[wkitty42]

It''s probably safe to assume that the AI system is basically unmaintained at this point

It''s[sic] probably safe to assume that you have not been watching portreekid's work on the AI code over the last year or two... i mean

[merspieler]

The DB API should be easily query-able too to get the time table

No it isn't... their "open data" is behind a pay-with-your-data paywall. And even after signing up and getting that api key, their API was broken... on the ssl layer already.

The C++ traffic manager could be made generic and used for trains/ferries/aircraft. Since it's currently a performance hog and runs to often I want to touch it anyway.

I'd be in for a collab... I'm not familiar with the code base but am happy to do the data creation part that gets fed into the AI system.
I've already created a route in the format of the ICE demo but for now with fixed speed and always onground = true. Speed info isn't available for the part I've looked at (not for sbahn, only the long distance rails had speed tags in osm). "onground"... munich sbahn has the "stammstrecke" which is a tunnel and also the last bit at the airport is a tunnel so I need to fix that. Probably onground = false and then set a negative altitude offset so the train disappears.

It''s[sic] probably safe to assume that you have not been watching portreekid's work on the AI code over the last year or two.

... or even read their reply...

Assuming you have access to railroad network info (OSM?)

Yes

Here's the ground services addon that could probably be adapted to load train/road networks into fgfs to monitor different networks/trains at the same time:

I'll take a look at that.


As for LOD, I think two models should suffice. One low res model for when you're away and a detailed model when you get closer.

[Hooray]

You would need the effects/shader side of things, because that's what most end-users are likely to see anyway. Seeing an actual animated 3D model is only likely for approaches/takeoffs and helicopter OPS after all. Anything involving conventional flying, LOD will kick in and a set of illuminated textures/points will do the job just fine, especially at nighttime

Other than that, I don't know if a handful of commits over the course of the last 8 weeks, suddenly turn the AI system into a "maintained" component?

To judge for yourself, it's fairly easy to look at the list of related commits here: https://sourceforge.net/p/flightgear/fl ... rc/AIModel

Besides, it's also pretty safe to assume that the shortcomings of the AI system that Durk himself pointed out in his FGTraffic related devel-list postings are there to stay, Durk himself referred to major parts of the AI system as a "dead end". Unfortunately, that isn't likely to be changed by a handful of commits or a single contributor.

Obviously, a single person with a lot of time on their hands can work wonders, too.
So I will be glad to be proven wrong, I guess time will tell, but please don't hold your breath folks (I am sure portreekid can clarify the scope of his work)

[david.megginson]

One quick warning: the Nasal GC seems to have issues, eventually slowing the frame spacing to unusable levels with "Advanced Weather" enabled after 30 minutes on my computer (16 GB RAM, 16 core CPU). Whatever you do, I don't suggest building anything else complicated on top of Nasal until the GC situation improves.

[wkitty42]

Other than that, I don't know if a handful of commits over the course of the last 8 weeks, suddenly turn the AI system into a "maintained" component?

portreekid's first contributions, going by my thunderbird mail spool of the flightgear-commitlogs mailing list, were back around June 2021... those were some runway tests for the unit test stuff... at some point, i think their name changed on the list (midnight ploughboy) and they also started making their own commits (from portree_kid) instead of having james do them (from portreekid)...

commits by portree_kid actually started back in 2017 and all have been related, in some way, to the AI craft... initially to the actual craft, flightplans, and scenarios but more recently they have been actual code updates, fixes, refactors, etc... this work really starting more about June 2021 as mentioned above... granted, he's not the fastest nor does he commit often but his work is coming along and he's been fixing a lot of things that have been wrong with the AI craft flying about in FG when the AI are enabled...

in my mind, portreekid is maintaining the current AI code and i have doubts that Durk will actually get his new stuff ready in the next several years... especially considering how long it has been with the existing code and how long the bugs have been around in it with no fixes in sight... then i started digging in and talking about things some years back as i added tons of logging to my local install and starting asking questions and pointing out things which brought others to the table... that ending up with portreekid taking the reins and moving ahead where i could not due to several factors...

please also note that i applaud Durk for his work on the AI code and i'm certainly not being negative about his contribution... it would have been nice, though, to have more fixes done over the years but i do also understand how IRL can get in the way which it apparently did in a huge way in his case...

[portreekid]

Yes for the people who don’t know the Portree Kid by the Corries, the Midnight Ploughboy is Portree Kid‘s sidekick. Yes AI Maintainance is more than 8 weeks and I’m pretty familiar with the system, fixed numerous bugs and am actively maintaining it. Although it has so many brittle bits I wouldn’t call it maintained as it’s bound to break. Just fixed runway exits at EHAM since it would pick up the runway end instead of the actual exit. There are even massive traffic tests that integrate everything but are just commented out

[portreekid]

Due to my day job as a software architect I'm not up to a complete redesign of the AI code. I have a very good insight into the current code, though.

[merspieler]

would you be open to chat on matrix/mattermost/irc/<other foss chat platform> about how we could work together on this?

[Hooray]

Due to my day job as a software architect I'm not up to a complete redesign of the AI code. I have a very good insight into the current code, though.

FWIW, long before "FGTraffic" was brought up, Durk reached out to a number of folks on the devel-list trying to get enough people involved to re-implement the current /models based C++ code to instead use MP mechanism, to inject traffic that way. That's probably one of the lowest hanging fruits to get the AI traffic subsystem to run outside the main loop, and to sync traffic across multiple fgfs instance (think multiplayer, multi-instance, FSWeekend/LinuxTag style setups or dual pilot/shared control)

Basically, everybody and their dog agreed that this would have been the right way to approach things.
Subsequently, there was the long-standing hope to use something like HLA/RTI or DIS.

More recently, Erik implemented support for DDS and Richard implemented his Emesary system - both of which could be useful, given that HLA/RTI never really seemed to materialize (so far)

[portreekid]

would you be open to chat on matrix/mattermost/irc/<other foss chat platform> about how we could work together on this?

Yes of course. Currently I'm on the FG discord or @PortreeKid@mas.to
I'm slowly freeing up to starting something bigger. The bugs are down to like 2% percent of aircraft loop when parking. That's while the traffic manager runs every second even though departures are by the minute and possibly none in the next hour.

[merspieler]

Well... shitcord isn't FOSS and my masto instance blocks yours (among others due to inadequate moderation) ... and masto isn't really a chat anyways.
You still have that mattermost account from the hackathon, you can use that or join the matrix space, link in the signature below.

[portreekid]

Due to my day job as a software architect I'm not up to a complete redesign of the AI code. I have a very good insight into the current code, though.

Basically, everybody and their dog agreed that this would have been the right way to approach things.
Subsequently, there was the long-standing hope to use something like HLA/RTI or DIS.

I absolutely agree. That is just a detail how the module is "glued" in to Flightgear. Currently it isn't a true subsystem/module. The ATC is intertwined with AI and also drives the GUI with the nearest towers. Only if it is isolated and gets a proper interface we can think about any distribution. I am refactoring and clearing up a bit, but there is no clear interface yet.