A new Flight Simulator

[bomber]

Yeh but he did say he wasn't a programmer...

I think it was the thought behind it that was important to focus on.

[bomber]

Oooh beat me to it.

[IAHM-COL]

@Bomber

Any project that fails to recognise the differences between the core code and content is just doomed to repeat the same failings as FG.

Agreed. and Agreed.
Politics in this situation is and has been an ugly endeavor. Tell me about it, after I created FGMEMBERS and the hell that ensued.

Making not only core but content modular. See my philosophical proposal, first point, second point. Totally.
All content (even the core itself) being modular would be nice.

meaning plugin in a new addon must be in principle a blizz. And thus making your own aircraft a very easy endeavor in terms of integration. And whatever license you are choosing for your addon, your byzz, not the cores. Now, making some shareable code for better instruments and stuff, that could be great to expand the core, and make new aircraft constructions better.

r however taking FG and forking it,

about forking FG?!
I see advantages of non starting on zero. But I see disadvantages on the baggage that gets inherited. lack of multithreading, how to implement the modularization? Do we really want to continue the structural methods of content development? XMLs/AC3/Nasal? I'm arguing against almost every point here now, so Ok, yes, we can copy code from FG as liberally as we want (its GPL anyways), but literally forking is what I am not sure how I fundamentally feel about it. See Richard and I conversation bfore.

[bomber]

I've read that conversation...

But it's premise is that FG core direction is fixed and that it can't be changed.......

Agreed its probably difficult, not my bag i'm afraid.

Yet I think that politics holds FG back, that the failure to differentiate between core and content with those interested in core concentrating on it and working to help content developers as their no.1 goal....

Mutual respect between each party

[IAHM-COL]

In fact, looking over your code, your example won't work.

@Josh

Ok. I fixed it. Tested it. It works.
It is actually much simpler. Assuming that the Engine class (As it should exists) and can be imported, then all the code to implement that thing in your nasal with like 9 setprops is:

https://github.com/FGDATA/testingEngine ... gine727.py

Code: Select all

from FS_propertyTree import EngineJet_reverser
##Importing the Default EngineJet_reverser and modify it by inheritance

class Engine727(EngineJet_reverser):
    """The rev thrust function gets overloaded to mimmic the Nasal file example"""
    def toggleFastRevThrust(self):
        if not self.reverser and self.throtle_pos<=0.05:
            self.throtle_rev=0.5
            self.reverser_angle_rad=3.14
            self.reverser_pos_norm=1
            self.reverser=True
            return self.reverser
        if self.reverser:
            self.throtle_rev=0
            self.reverser_angle_rad=0
            self.reverser_pos_norm=0
            self.reverser=False
            return self.reverser


In comparison to the Nasal:

Code: Select all

var toggleFastRevThrust = func {
   var eng1thr = getprop("/controls/engines/engine[0]/throttle-pos");
   var eng2thr = getprop("/controls/engines/engine[1]/throttle-pos");
   var eng3thr = getprop("/controls/engines/engine[2]/throttle-pos");
   if (eng1thr <= 0.05 and eng2thr <= 0.05 and eng3thr <= 0.05 and getprop("/controls/engines/engine[0]/reverser") == "0" and getprop("/controls/engines/engine[2]/reverser") == "0" and getprop("/gear/gear[1]/wow") == 1 and getprop("/gear/gear[2]/wow") == 1) {
      interpolate("/engines/engine[0]/reverser-pos-norm", 1, 1.4);
      interpolate("/engines/engine[2]/reverser-pos-norm", 1, 1.4);
      setprop("/controls/engines/engine[0]/reverser", 1);
      setprop("/controls/engines/engine[2]/reverser", 1);
      setprop("/controls/engines/engine[0]/throttle-rev", 0.5);
      setprop("/controls/engines/engine[2]/throttle-rev", 0.5);
      setprop("/fdm/jsbsim/propulsion/engine[0]/reverser-angle-rad", 3.14);
      setprop("/fdm/jsbsim/propulsion/engine[2]/reverser-angle-rad", 3.14);
   } else if ((getprop("/controls/engines/engine[0]/reverser") == "1" or getprop("/controls/engines/engine[2]/reverser") == "0") and getprop("/gear/gear[1]/wow") == 1 and getprop("/gear/gear[2]/wow") == 1) {
      setprop("/controls/engines/engine[0]/throttle-rev", 0);
      setprop("/controls/engines/engine[2]/throttle-rev", 0);
      interpolate("/engines/engine[0]/reverser-pos-norm", 0, 1.0);
      interpolate("/engines/engine[2]/reverser-pos-norm", 0, 1.0);
      setprop("/fdm/jsbsim/propulsion/engine[0]/reverser-angle-rad", 0);
      setprop("/fdm/jsbsim/propulsion/engine[2]/reverser-angle-rad", 0);
      setprop("/controls/engines/engine[0]/reverser", 0);
      setprop("/controls/engines/engine[2]/reverser", 0);
   }
}


If you feel like trying it,
https://github.com/FGDATA/testingEngineFunction

There is only 2 source files there,

testing like

Code: Select all

python testing_engines.py


FS_PropertyTree is a very simple code that is generating so far only 1 class, the Engine, and this very simple engine only contains the three paramenter we will switch. This file allows the line:

Code: Select all

from FS_propertyTree import Engine

Then the other file implements a new class named Engine727, which gets the Class engine imported for the FS_PropertyTree, and then you add the functionality that you needed. In this case the ability to toggleFastRevThrust. The code I printed in this post above.

Now the rest of the testing file just checks such thing worked. First by creating an engine Stack of three engines and printing what they are. then by checking we can access/modify any of the values of any of the engines at will, but finally sending your function over the engine stack and printing it one more time to show the new function in the 727Engine was applied, just as the idea behind the nasal was.

So indeed, the code here above did the job, as I thought it would.

[Octal450]

Again what I just said:
I chose to not used object orientated/classes with my code because I wrote that reversing thrust system ages ago as a dirty temporary replacement when making the Airbus engine system -- but I never needed to replace it, so I didn't bother, and it wouldn't benefit the aircraft to rewrite it. Since it worked fine, I quickly added the same thing to the 727 when I built it.

I think you are wasting your own time here. But, each to his own. I'm no nasal genius and my code is not the best examples out there, but if you remove Nasal, I likely won't bother with this.

Unlike FGMEMBERS, which helps people, this project makes it harder for everyone. New languages, new everything... tiny user base. I'd rather learn programming for P3D or something (already know a decent amount of C++) which is already a mature sim.

Kind Regards,
Josh

[bomber]

Some will see the direction this topic has gone as being the natural order of things....

I see it as the political disease that infests flightgear.

A hypothetical questions been asked about a possible direction of development. Yet rather than stay at this level of discussion replies have been very much at the problem solving level. It's easy to do this and we've all seen it done many times on the FG forum to both derail questions about the possibility of doing things differently and question the competence of the person making \ asking the question. The ultimate stage is where a person says "if it goes this way, you can count me out"

Josh,.............Thorsten, Curt Et Al have taught you well, you now talk like them.

If core game engine code is split from content code then people like Josh and Me, content developers would simply judge the merits of the game engine and core development on the ease in which we can input content data, be it 3D, 2D, aerodynamic performance, engine performance, thruster performance, systems and effects.

Trust me if it was made easier, people would drop all their reservations and come running to add their content.... After all why do it the hard way ?

FG development has forgotten or never did give an arse about it and as such rather than content development increasing exponentially it's just plodding along. Because there's not this element of the two sides of the sim 'feeding' off of each other with continuous improvement.

FG core dev make their own direction up, they dont communicate with content developers so they never deliver anything that a content developer actually needs. There is no symbiotic relationship between the two elements of sim creation. In fact Core developers come across as believing content developers should simply be gratefull for what they have....

My personal belief is

No backward compatibility
One single physics engine of Jsbsim made to run different levels of data quality, from fudge, engineering or wind tunnel. Which can run multiple instances Ala Outerra.
Easier Input of plane data in a modular reusable manner.
Removal of the warplane phobia to help development of complex damage and instrument sysyems

[IAHM-COL]

My personal belief is

No backward compatibility
One single physics engine of Jsbsim made to run different levels of data quality, from fudge, engineering or wind tunnel. Which can run multiple instances Ala Outerra.
Easier Input of plane data in a modular reusable manner.
Removal of the warplane phobia to help development of complex damage and instrument sysyems

I think I allign with these as well.

1. No backward compatibility. There are a series of counterarguments here: a) not being possible to run the "large" aircraft collection in FG. b) making devs restructure content in a new way (which may require as Josh proposes re-learning new structure). I think a lot of effort is required to bring such "backward" compatibility. And I think it would be better to do it right from the get-go. Just as Richards say, it would also prevent development to just become just supporting and following such compatibility.

My personal point of view: Drop the extra baggage, like xml=configs, and nasal, and just get it done in a straight-forward way.
I still think if we can expose the property-tree to python-like objects, then suddenly the limit is the sky. (pun intended, but also literally)

2. One single engine FDM. Agreed, too. I think I dont' see any good reason to support Yasim (or other engine) from the get go. Loosing backward compatibility of the yasim placeholders? see #1 above. JSBsim seems the logical choice too, in terms of potential. I am dreaming that a wind tunnel instance could be generated that produces standard plots (that make sense) to judge how to apply FDM mods. I also think FDM development could be really nice in terms of modular python-like class development.

3. Easier input of plane data in reusable manner? This is one of the central points why I think it could be nice this would be made forward.

4. Warplane phobia? HAha. I don't have that. But I have phobia if all planes could be attacked. So a war-module that is switchable could be great. So I can fly safe online without feeling fear of retributions

Best,
IH

PS: Interoperability of MP? I was thinking of this today. How if multiplayer would accept connections from other Sims?

[bomber]

Simply run two or more (better more) servers of the sim multiplayer

1) Commercial present day
2) Combat present day
3) Combat Defined Date (1917, 1942, 1955, 1969, 2045)

[Octal450]

Hi Bomber,
I know you hate me and all, but I really don't know why you expect me to listen to you when you make such silly immature comments such as:

Josh,.............Thorsten, Curt Et Al have taught you well, you now talk like them.

The trick to developing complex aircraft is ignoring default/generics. They hold you back because they don't work well. I've had to do this many times in my Airbus'. You can make great warplanes with full damage and failure models. I made a simply failure model for the OPRF damage code enabled A330 MRTT, if you shoot at it, certain systems fail depending on the shot, etc.

Israel,
No idea what you mean by modular FDM.... Every airplane is different, and you can't just plug in wings and such, you make it less realistic. Each plane should be custom modeled to its real life counterpart.

And by kicking backwards compatibility, and using new languages for EVERYTHING, I doubt any FGFS developers will move over. So, what planes will you have, and where will you get the developers? With no examples of working planes, there won't be many users, causing not many developers to be interested, causing there to be no planes... etc. It's a circle, and to break it, you need to give developers a reason to use your sim, and so far, I see no advantages over FlightGear, only a different programming language.

Why do you think FlightGear is so bloated? One of my testing machines is ancient and it works just fine??? Sounds like you are just experiencing poor drivers, or something.

I just don't see the point. It sounds like you are avoiding fixing a flat tire by buying a new car. Instead of contributing and helping the FG project, you just get a new simulator...

Kind Regards,
Josh

PS: Seems you are turning into a Python salesmen... what type of Python are you selling and how much $$$?