Free Flight, Free Speech

If two pieces of software worked fine together in the past, and they do not now, there are two ways to go about it:

1) start digging blind into both pieces of software
2) narrow down the location to dig, with logic

If you know one piece of software did not change over the period the problem started to occur, you can validly conclude that you have to be in the other piece of software.

Yet there are people that deny this narrowing down, specifically when the problematic piece of software is their responsibility. Instead of making good use of the information, they demand of the other to dig in their code and prove that something changed there.

Doing such thing would be a complete waste of time, because you have already deducted that something has changed in that piece of software. Such behaviour loads the suspicion on the one that demands that he has ulterior motives for his demanding (unless he is plain stupid of course). Maybe he wants to delay the process? Or maybe he just enjoys the discussion so much that he wants it to prolong into a fight?

Anyway, it is just plain silly behaviour, wasting everyone's time.

Kind regards, Vincent

This has been at the root of a lot of my posts post an FG update...

And it's that things change, yet no warning of what 'might' be affected with your vehicle is notified to the wider development community.

So you end up with a plane that suddenly doesn't load or whose flight model now behaves differently (which I've had in the past). We are then each left with having to investigate our planes code and the nana-second disappearing console window to get an understanding of just what might be wrong.

Bare in mind this is after the core developers have studied their own planes and made good... so these guys already know the hoops that a planes developer will have to jump through.

Some of my posts are deemed a waste of time to read.... well these people can chose whether to read it or not. If I want my plane working I have no choice but to go through the investigation as above..

So who wastes more time around FG ?

I guess they enjoy the fight. Cause other than that, what is the purpose of arguing a "malformed xml" if the xml is to standards?

I think the thing is that fgrun since the Jumbolino isn't working anymore, doesn't accept PropertyList inclusions that don't stay in their directory but go up anymore (this is what brought me to this thought https://github.com/Harald67/c150/commit ... 351e318fd9 ) (I guess that is what this thread is actually about)

well.

1. can you explain in programming practices terms how the xml to the left (as it was before) is a malformed xml?
2. The JPack is an extension pack. It is not intended to be copied within each of the maybe 20 aircraft that includes it. The idea is to have the expansion pack be a separate "Extension" that can be globally updated. Therefore, such change as in the c150 is not applicable.

So far, as I see, the fact that FGRUNis was not capable to follow the include as expected, means there is was a bug in FGRUN. Not in the pack. Clearly, if it was fixed by a simgear correction: the bug was corrected where it should have.

Also. I pressume Harold is using an outdated FGRUn/simgear pair. On the current version, I tested whether the c150 was failing to list.
It does not fail



Include was:



Plane lists (now) in FGRUN just fine



Which means the FGRUN/simgear bug is now fixed, and the commit https://github.com/Harald67/c150/commit ... 351e318fd9 was not really a fix.

Well but why wasn't it a fix for old fgs then?

Hello D-ECHO,

I do not own the thread, so discuss freely. It would be nice though, if it is somewhat about the OP. If you ask "I guess that is what this thread is actually about (Jumbolino)", i must say no. It is about a general pattern of behaviour that can be recognized in many cases at the other forum (and anywhere actually). So if you feel the specific case of the Jumbolino fits the general pattern, do discuss it.

Kind regards, Vincent

This is exactly my beef about the 'security problem' that led to the UFO having a much severely reduced functionality. They don't want to discuss the reasons why they crippled the functions.

I mean yeah, I agree that security issues are present, but can they actually prove that opening an MS Explorer window in the Menu while FGFS is running, will cause such a huge and dangerous security breach? ( BTW I do this all the time when running AC3D windowed, while editing 3D shapes on the fly while updating the scenery 3D I'm working on..)

I would like to find the actual, well, I don't know what you call it, but when FG was hosted on Gitorious, you could look at the series of newly made FGFS nightlies and they would have a list of revisons, and when they were done, and the why's. You even got a breakdown of the coding changes if it was text editable. It's frustrating as I would think this could be changed back if I could open the pertinent bit in a Hex editor.

I am already starting to see a practical pattern evolve here. There is no good changelog. Things (planes) suddenly stop working, and the thing (plane) developer has no idea why. If he asks, the answer is: Go digging in the core source. Which gets near the meaning of the OP.

This is of course not a workable situation. Someone should write a letter to someone at the other end to request decent change logs.

Who the someone here should be is not hard. Could be me, could be an administrator, could be a developer like yourself.

The someone to send to at the other end i have no idea of. Do they have an officer concerning quality control of development, watching maybe iso standards? Or is it so disorganized that you have to approach the leader?

Well, let us know in the first place whether the changelog issue is the biggest issue.

Kind regards, Vincent