We can start with the landing gear retracted

[abassign]

So no issue if you use nasal and state system. The issue is only if you want to use JSBSim plus state system without nasal?

My problem is to make JSBSim work correctly depending on the input data, obviously if JSBSim starts when all the data are not present ... I have a problem ... Certainly NASAL is another problem, another programming language only known to those who program in FGFS, NASAL was born as an embedded language in the XML code and in my experience it is not easy to use python as an embedded language as it means having a virtual machine for each embedded process ... honestly I don't know, but it seems to me that this it was the objection on the part of those who claimed NASAL that in some respects it has a similar approach to Erlang. Java Script could be an useful alternative ... coupling Java Script to an XML is a simple thing, but I don't know how efficient it is for FGFS, Java Script is a very powerful language and sometimes it can seem like killing an ant with an elephant ....
Instead the JSBSim entry is very different, the XML is compiled and reduced to a series of calls to C ++ functions, which correspond to the modules, JSBSim has no variables, but only the output values and any hidden memory variables inside the individual blocks. JSBSim has many elements in common with a functional language, only the blocks are described in XML.
For me JSBSim is convenient as it is clear what happens and with well-defined timing, made essential in an RT (Real Time) language.
The problem is that JSBSim is an external language and therefore it must be called during the execution of the main program, theoretically (I would very much like this solution), it could be executed as a separate task, but anyway when JSBSim starts .. the simulation starts when a plane is stopped on the runway .. changes little .. but if instead the plane starts the simulation in flight, a landing gear out at 350-400 nm ... for a dozen seconds frankly it is not a beautiful thing ... Obviously there are various ways to solve it, but the simplest and most correct way for me is to start JSBSim at the right time or when the aircraft's programmer thinks the right moment has arrived.

[wkitty42]

@wlbragg:
I think his issue is as usual [1] ...

Meanwhile, I asked you to stop writing on this post,
if you don't have useful information for the question I asked at the beginning!

if you don't want to read Thorsten's posts, then go to your UCP (user control panel) and add his account to the friends&foes->manage foes tab... it is that simple...

[Necolatis]

I don't think this is straight forward to solve with JSB, but if I were to venture a guess on how to do it:

Make a channel like this:

Code: Select all

<channel name="Init" execute="init-in-progress">

Then add the property "init-in-progress" to set file and set it to 1.
Add also "init-passed" to the set file and set it to 0.
Now add a execute="init-passed" to the gear channel.
Add to init channel something that sets the gear position to 1 or 0 depending if the aircraft is in air or not.
Add under that a summer that always outputs 1 or similar component that is easy to get to output only 1, and set it to output that to "init-passed".
Add now below that a summer that always outputs 0 or similar component that is easy to get to output only 0, and set it to output that to "init-in-progress".
The order of those 3 components are important!
I do think you need to use the <output> tags inside the init channel for gear position and also inside the gear channel for the same, since they share property, else JSB probably wont work or give errors if you use name=.

Init channel will only be ran once, it will set the gear position and thereafter allow the normal gear channel to execute, and thereafter disable itself.


Untested, just an idea.

[Thorsten]

obviously if JSBSim starts when all the data are not present

Obviously it does that only for you, since the rest of us can use the state overlay / presets.

NASAL was born as an embedded language in the XML code

Wrong.

For me JSBSim is convenient as it is clear what happens and with well-defined timing, made essential in an RT (Real Time) language.

If you know how to program, it's also clear in Nasal what happens. Likewise if you understand timers you get well-defined timing (and if you do not you do not).

Nasal is simply a different tool suited for tasks JSBSim is not (and vice versa). So is GLSL - you can write rendering in Nasal, it's just a very bad idea.

Obviously there are various ways to solve it, but the simplest and most correct way for me is to start JSBSim at the right time or when the aircraft's programmer thinks the right moment has arrived.

Obviously people have already solved it, the correct approach in FG is the state overlay which can be coupled to a Nasal approach if you need more complex decision logic.

[GinGin]

For example, I remind you of your denying the evidence on my question regarding the lack of visibility of airport lights when approaching ... but then, fortunately, with the help of others, it was solved with only some code correction.

Come on Abassign, be a bit objectif on that one.

Problem that was solved had nothing to do with yours , and we have been plenty to take the exact same screens with same conditions without observing what you saw.
Plus the real life return about the real low brightness Of night lighting system

That kind of statements just don’t make you serious and impartial

[Hooray]

Certainly NASAL is another problem, another programming language only known to those who program in FGFS, NASAL was born as an embedded language in the XML code

It's primarily used inside FlightGear, but other than that, it's based on JavaScript/ECMAScript concepts.
It's close enough to JavaScript, that the fg side of things (extension functions) would look exactly the same - the primary restrictions are due to that very layer, i.e. are more related to fgfs rather than Nasal.

You will find rather detailed discussions elaborating on the merits/background of Nasal, JavaScript or Python etc, by searching the forum for:

• Nasal inside Algoscore
• Nasal and ECMAScript
• PSL (plib scripting)
• PSL (plib scripting)
• Nasal GIL Python
• Nasal vs. AngelScript
• Nasal vs. Erlang

in my experience it is not easy to use python as an embedded language as it means having a virtual machine for each embedded process ...

See: search.php?st=0&sk=t&sd=d&sr=posts&keywords=nasal+FGPythonSys+GIL

honestly I don't know, but it seems to me that this it was the objection on the part of those who claimed NASAL that in some respects it has a similar approach to Erlang. Java Script could be an useful alternative ... coupling Java Script to an XML is a simple thing, but I don't know how efficient it is for FGFS, Java Script is a very powerful language and sometimes it can seem like killing an ant with an elephant ....

Honestly, the bottleneck is elsewhere - while Nasal is indeed a niche language, and while we could certainly gain from a more mainstream language like Python etc, the "bottleneck" is not due to Nasal - even the GC related bottleneck (mark/sweep) has more to do with the way Nasal is integrated inside FlightGear than with Nasal per se.

See: search.php?st=0&sk=t&sd=d&sr=posts&keywords=javascript+llvm

The problem is that JSBSim is an external language and therefore it must be called during the execution of the main program, theoretically (I would very much like this solution), it could be executed as a separate task,

You can instantiate jsbsim in another thread, and you could also hook it up to a property tree living inside that thread.
It's not as complicated as it may sound actually, I once wrote a little tutorial to illustrate how JSBSim can be used in a "standalone" fashion: http://wiki.flightgear.org/Implementing ... ear#JSBSim

With that being said, I am not getting the impression that any of this contains the solutions for your problem, rather it seems you are looking for a problem by posting "solutions" ?

But again, Nasal is hardly the issue here ...

[legoboyvdlp]

Problem that was solved had nothing to do with yours , and we have been plenty to take the exact same screens with same conditions without observing what you saw.
That kind of statements just don’t make you serious and impartial

Plus the fact that he posted screenshots in which it was working fine without any change to the lighting I think my conclusion would be that there might be little interest in being serious and impartial :/

[abassign]

...

I state that I do not know how the discussion on NASAL came about, my problem is JSBSim which starts when the data relating to the flight situation are not present (or reachable by JSBSim).
Personally I work a lot on JSBSim and relatively little on NASAL, I often develop something with NASAL, but often I convert it to JSBSim when the meaning of the written code is clear ... It will surely be my suicidal craze, you know what life is like, there is is who has fun with little ...
However if NASAL is so similar to JavaScript (not by chance I use KDE-Kate to develop and edit NASAL with the JavaScript formatter inserted), I am sure if it was JavaScript and not NASAL ... it would have been easier for many and maybe many posts of complaints would not be there. I must however remember that when I program with specific languages for control systems (SIEMENS for example) ... it is exactly the same thing ... it is necessary to learn some "strange" language or a modified basic ... otherwise you cannot develop.

...

For the visibility of the landing lights something happened, my impression is that many hadn't noticed it before .. I did the test on three machines, with different versions of Linux and Windows 10 (my partner who develops 3D) we all had the same problem (which I documented) ... then suddenly, after a couple of updates and a very long sequence of offenses ... everything came back in place ... miracle, sight difficulty overcome by me, mists disappear from others ... I do not know, I only know that it has been solved and now I see the same airports with the correct lights and I can make night approaches.
So I did my job well and now, after months of observing the lighting problem, I see things ok ...

@For all of you reading this post

Opensource software development is not a contest of personal selfishness, but a race of generosity and curiosity.
Curiosity makes us follow new paths with sometimes negative results, but sometimes positive and when the results are positive, it is a beautiful moment for all of us.
Generosity gives us the possibility to develop together a common project, to spend our time to produce something good, something that remains and does not go away with us and that in the future can be the basis for the joy of others who we will never know.

In conclusion, years ago I taught my nephew to fly on FGFS, he liked it so much that he is now doing aerospace engineering, only for this I consider FGFS a success and I am infinitely grateful to this project!

[bugman]

I state that I do not know how the discussion on NASAL came about, my problem is JSBSim which starts when the data relating to the flight situation are not present (or reachable by JSBSim).
Personally I work a lot on JSBSim and relatively little on NASAL, I often develop something with NASAL, but often I convert it to JSBSim when the meaning of the written code is clear ... It will surely be my suicidal craze, you know what life is like, there is is who has fun with little ...

Your 'suicidal craze' about not using Nasal for a task that should be completed using Nasal is what started the discussion about Nasal

Regards,
Edward

[GinGin]

For the visibility of the landing lights something happened, my impression is that many hadn't noticed it before .. I did the test on three machines, with different versions of Linux and Windows 10 (my partner who develops 3D) we all had the same problem (which I documented) ... then suddenly, after a couple of updates and a very long sequence of offenses ... everything came back in place ... miracle, sight difficulty overcome by me, mists disappear from others ... I do not know, I only know that it has been solved and now I see the same airports with the correct lights and I can make night approaches.
So I did my job well and now, after months of observing the lighting problem, I see things ok ...

Good for you then.
"Sequence of offenses" is also very subjective.

But like it was said in the relevant post https://forum.flightgear.org/viewtopic.php?f=5&t=36288, the changes made had nothing to do with your intial problem, mist had nothing to do with that at all, but settings maybe... ( like stated the person who made the light changes..... )

The only problems fixed was that dynamic lights would not work. The static approach lights and runway / taxiway lights.... are just the same as they were.

When we made screens to compare what you had with what an other person observes, you often don't really answer or see what you want, so hard to have a constructive discussion as we don't really know what is the current setting and modifications you made to vanilla files .
One thing is fixed and magically now the thing that didn't work before for you ( but others yes) and that was untouched works now. Probably that one of the issues you mentionned was fixed, but it didn't explain the problem you had for approach and fog etc that we didn't observe, Hard to see clear in that

Anyway, it is not the main concern there and I don't have anything personal against you,far from it, but it is often the same pattern when you post an issue.

[wkitty42]

@For all of you reading this post

Opensource software development is not a contest of personal selfishness, but a race of generosity and curiosity.

errrmmm... sorry, no... it is not a "race"... it isn't about who gets there first... it is about generosity and curiosity, though...

[Thorsten]

Curiosity makes us follow new paths with sometimes negative results, but sometimes positive and when the results are positive, it is a beautiful moment for all of us.

There's a difference between exploring a new path and using a screwdriver rather than a hammer to get a nail in. There's nothing new about the latter - it's been discarded a while ago since people make tools.

If you are nevertheless curious about hammering with screwdrivers, you can certainly satisfy your curiosity in your own spare time, but you should definitely not

* ask people with hammers why your approach does not work and for suggestions how to make it work
* complain that the thing you're working on should be completely re-structured to allow screwdriver-hammering
* suggest others did something wrong because your screwdriver doesn't work properly
* or involve others in your wild goose chase

Curiosity definitely is not a mindless pursuit of some strategy set in advance (like we see from you here) - it has to do with listening to answers given, with a liking for the truth of things and with trying to actually find out.

We don't see much of that from you here though - mostly we get lectured on your latest theories on how FG works (hint: Some of us wrote the things you so generously try to explain to us...)

Oh - and as long term FG contributors, we also absolutely like to be lectured what OpenSource is and what it isn't.

[Thorsten]

I did the test on three machines, with different versions of Linux and Windows 10 (my partner who develops 3D) we all had the same problem

Sadly you kept that information from us in the relevant thread. And sadly, you are still keeping the information of whether you tested with a vanilla install or whether you applied any custom changes /config.

Also, many screenshots you posted were (as far as could be judged without knowing the underlying parameters) quite okay - only later in the process did we get to see screenshots which were not - which however was entirely on your end, because when people tried to reproduce the very same situation they could not.

Instead of providing any of the information that would actually make a debug process move, you opted to lecture us like The problem seems clear to me that it is geometric in the management of point sprite The point sprites are constructed as "brightness" as a function of the angle of view.

Sadly, the issue that's clear to you is obviously not set that way in the code.

Rather than doing anything debug-relevant, we see you go off on your own agenda:

In my opinion this way of proceeding is correct for the spot light component, but a light emitter for lighting various parts of the runway is not a laser, but a device composed of two parts: a spot emitter and a screen and / or reflector and an area of land that is indirectly illuminated. These components do not seem to be present in the current "point sprite" simulation and therefore perfectly justify the behavior I observe and the effect of darkness

Which raises the question Jonathan or Hooray have hinted at - were you ever actually seeing a genuine issue - or were you simply unhappy with the way things worked and doctored a bug report with the aim of getting people to re-implement the lights according to your own plans? In other words - are you really desperately looking for a problem to get others to apply the solution that's already in your mind?

I don't know whether it's true, but your constant tendency of lecturing people how FG systems really work goes poorly with your lack of ability to diagnose and fix issues on your own.

it does seem relatively clear though that it's not about getting any help here - both Richard and Nikolai have posted JSBSim hacks for your original problem, yet you have ignored both messages.

Go figure.

[abassign]

For example, I remind you of your denying the evidence on my question regarding the lack of visibility of airport lights when approaching ... but then, fortunately, with the help of others, it was solved with only some code correction.

Come on Abassign, be a bit objectif on that one.
Problem that was solved had nothing to do with yours , and we have been plenty to take the exact same screens with same conditions without observing what you saw.
Plus the real life return about the real low brightness Of night lighting system
That kind of statements just don’t make you serious and impartial

Perhaps you don't remember, but the problem was fixed around October 6, 2019:

[url]https://forum.flightgear.org/viewtopic.php?f=5&t=36288&start=60
[/url]

Perhaps you don't remember that others, like me, have noticed the problem ... My impression is always the same:

We do not see what we do not want to see or what we are used to seeing and if someone points out to us that reality is different we get angry saying that it is not possible, looking for ridiculous excuses thinking that others are demented or crazy. I advise many of you to stop behaving like children and I would try to look more carefully at what others are pointing out, because often there are problems in the code that we have not noticed.

I do not care if the correction apparently, for you, was not related to the problem .. simply after the correction the problem had disappeared and with it the fog in Th's brain ... and perhaps also of others.
Unfortunately, as you well know, OpenGL programming is complex and full of pitfalls and so it is normal for such things to happen. But it is not normal not to want to admit it, as there is no technical or economic reason that requires the need to hide the error.

This is the conversation ...

[Thorsten]

We do not see what we do not want to see or what we are used to seeing and if someone points out to us that reality is different we get angry saying that it is not possible, looking for ridiculous excuses thinking that others are demented or crazy. I advise many of you to stop behaving like children and I would try to look more carefully at what others are pointing out, because often there are problems in the code that we have not noticed.

Let me put this carefully.

We have 'many of us' who see one thing, and are consistent in what we see. And we have 'you' who sees quite another thing. We have the 'many of us' who consistently tell you that Nasal is the best tool to set up an FDM config and that this can be done right after FDM init, and we have 'you' who insists that this takes 'tens of seconds' and doesn't work. We have 'many of us' who worked on a change on blinking lights and 'you' who insists that non-blinking lights were changed. We have 'the many of us' who see their aircraft initizlizing with gear down on the runway and 'you' who does not.

Who is it who should look more carefully at what others are pointing out - the 'many of us' - or perhaps 'you'?

(Oh, at least one of the screenshots which supposedly shows 'the error' is a rather crazy test by myself for which the code was never published and which existed only on my harddisk - do you not know what is on the shots you post, or do you simply not care?

Perhaps you don't remember that others, like me, have noticed the problem ...

We do not remember, because if they did, they never bothered to post it and you never bothered to tell us - so these others may in fact be completely fictional.

it is not normal not to want to admit it, as there is no technical or economic reason that requires the need to hide the error.

Yes, I really wish you would admit when you made an error in your custom setup / modification - but for some reason you always blame it on the rest of the world.