Su-15

[Hooray]

It was not about helping me - as I said, I already made everything by mysefl, and there is proving screen. It was about proving You had said truth and everything is documented well. But You was wrong, and, considering You still not agreed it yet, lied. You are liar.

I suggest that you get in touch with other forum users who speak both English and Russian, and then review my responses - you will probably find no reason then for the name calling you are -once again- using.

I think your main issue is probably related to English and maybe Nasal/Canvas concepts, despite having written tons of Nasal code over the years - I assume you don't have any other background in coding, right ?

The postings I made in this thread contain the answers to all your questions, I am sorry that you cannot see/understand that. And your questions demonstrate fairly well that you still have a lot learn, which is fine - but please don't expect us to put up with this kind of attitude at the same time.

Personally, I am trying to stay out of this - but like I said, the real designer/developer of the MapStructure framework is Philosopher,

And he seems to be around currently. I haven't seen him respond to any of my PMs recently, and I was thinking that he must be either in some sort of witness protection program, or about to skip high school entirely to write his PhD thesis directly , but maybe you can convince him to provide the degree of support that you need, which I failed to provide.

Thanks for the ride though ...

[Thorsten]

Thorsten: Of course. But any change in each pixel is visible, while You just cant make it quite same at two different models.

Unless the detail of your model is smaller than a screen pixel, in which case the rasterizer will operate and sample one (or a few) locations inside the screen pixel and you can make them look the same. Texture mipmapping conceptually works the same to reduce detail from far away.

So of course you can.

It's quite clear that you have no idea how rendering works internally, both in general and in FG, that you have no idea how various FG modules all connect to the same rendering backend which is really done by OSG, it's clear that you have no idea how such knowledge would help you design models which render much faster.

It's equally clear that you have no interest in learning anything new.

So you're producing models which hardly anyone flies because they end up being slow even on a gaming laptop. You use lots of time which you could use to make your planes better to re-invent things others have done - not because you're actually interested in re-deriving them for educational purposes, but because you're too proud to admit that whatever you have in mind might not be optimal because you're not really an expert for the matter at hand and can't take any critique - since your view is that way, it has to be the best way.

Great job. I hope you enjoy the experience.

[Hooray]

Not, You was not tried to be helpful. You tried to push others, me particularly, to do something for You.

To be fair, I am not the one asking you to spoon-feed me with Nasal/Canvas tutorials and examples.

I have provided 1:1 mentoring in the past in similar situations, and probably will do so in the future, regardless of any "attitude" - as long as I am interested in the corresponding effort - which, for me, translates into:

• not being specific to a single aircraft/use case (GUI dialog)
• not specific to a single contributor
• not restricted to supporting a single instance
• not specific to a single style/theme
• reusable/modular design
• encapsulated to ensure that performance can be improved over time

I never asked you to do anything "for me" in the context of this discussion, the only thing I remember asking you is to post a link to your Nasal code so that we can take a look.

Many MapStructure users will never have to touch MapStructure.nas at all - so don't worry about being exploited through the advice not to re-invent the wheel, I was trying to save you some time. And I was trying to ensure that other users can reuse your code on their own aircraft/dialogs, while getting good performance and a future-proof upgrade path.

If you are not interested in that, that's also fine - Thorsten also ended up disregarding the MapStructure approach in favor of using pure Nasal/Canvas - just look at his trajectory map, which is strictly procedural code using global variables and "flags" - so you don't have to use any of the ideas we mentioned - however, somewhere down the road, you will inevitably figure out that some advice may not have been all that bad - e.g. Thorsten is now contemplating to turn his MFD code into a class that supports multiple computer instances and keypads.

Equally, omega95's VSD (vertical situation display) is not using MapStructure at all - both of these could be considered to be about features that MapStructure wasn't designed for (vertical mapping and orbital maps) - however, it was in fact designed for horizontal mapping.

You may not like what I wrote, or what Thorsten said - but you may still learn a whole lot about collaboration by checking out the c172p thread - I don't think either of us is involved in that, so I am not biased here.

[Lydiot]

vitos,

I opened this thread to see what the plane was, read through the first few posts and saw a beautiful plane. Then I made the mistake and read the rest of the thread. Now, you say you want people to respect you and your work, and just so you know, the way you talk to other people makes me not only have zero respect for you, but I also have zero interest in your work any longer.

I hope that's what you wanted to achieve here... because that's what you've achieved.

Stop being rude to people. You're not that special.




PS: Curious how this behavior has been allowed to continue for so long in this thread.

[clipper996]

PS: Curious how this behavior has been allowed to continue for so long in this thread.

I can already see the admin eating popcorn with his legs resting at the table, just looking at vitos as he's steadily accumulating reasons for a ban, and just waiting to finish off the popcorn so he can finally get rid of this self-obsessed maniac.

[Hooray]

to be fair, vitos definitely belongs to a relatively tiny group of people who are extremely skilled when it comes to 3D modeling and FDM development - so there is a certain track record that needs to be taken into account.
At some point, vitos certainly was among the top 5 contributors involved in aircraft/FDM development, especially keeping in mind that he's operating in "lone wolf mode" - whereas others able to come up with similarly sophisticated aircraft usually team up with others to accomplish these things.

The other thing to keep in mind here is that vitos may be mis-guided at times, but that his work does inspire others to come up with novel features in response to such discussions, I think the vostok/EarthView relationship is pretty interesting for example - equally, Thorsten's revamped interest in spaceflight can probably be also attributed to some of vitos' postings and efforts.

Some of us tend to be motivated by proving people wrong, which is unfortunate - but also a fact, I know that I have come up with features and code simply because I disagreed with other developments at some point.

So while the nature/tone of this discussion may be annoying, it may be more influential than some of us may expect - for instance, at some point some of us were similarly annoying when it came to discussions involving the lack of a 2D rendering API (not unlike modeling a performance database in FlightGear, or space flight) - fast forward 5 years later, we actually have such a 2D rendering API (via Canvas).

Equally, others don't seem to get tired to point out that a reasonable weather/combat simulation cannot be implemented on top of the existing FG architecture - yet, there are Advanced Weather and "Bombable" proving people wrong.

It is definitely true that non-native code (aka Nasal) does have its issues - but then again, I don't see anybody on the horizon to re-implement a weather engine (or a combat simulator) in C++ space.

Nasal is extremely accessible, especially to people who are not core developers, i.e. who don't have commit access, but who may still want to prototype compelling features, without depending on core development, and without being restricted by all the inertia of the core developer group.

So, whenever we are seeing useful stuff implemented in scripting space it is usually symptomatic of a deeper problem, i.e. lack of interest/momentum (or even just manpower) at the core development level to pursue some ideas.

Like Thorsten mentioned, under the hood, the Nasal approach will end up using C++ and OSG code just like native C++ code is doing - it will just use a few more abstraction layers.

This is also how Canvas works internally - and this approach has major advantages, too - because the integration layer exposing certain functionality (e.g. via Nasal extension functions and/or properties or listener-based subsystems) can be extremely self-contained and "encapsulated" - which means that regardless of the Nasal module in question, there is a single entry point to this functionality, which is to say that this is also where things can be benchmarked/optimized in a holistic fashion.

Compared to much of the existing legacy code in fgfs (splash screen, PUI, HUD, 2D panels), Nasal code does have the advantage that it is straightforward to re-implement while using OSG internally - which can be also seen in the "pui2canvas" effort.

Overall, Nasal does have its issues - but it is fairly hard to come up with buggy code that breaks the simulator for others - especially in the light of all the segfaults, crashes and leaks we've been seeing during the last 2-3 release cycles, Nasal may not be the worst option - especially for those not overly experienced with developing cross-platform software.

And to be perfectly honest, Nasal's main issue is the GC, and maybe the lack of thread-safety when it comes to extension functions - but solving this is relatively straightforward, especially compared to fixing/porting all the buggy C++ code that is currently unmaintained.

Given the number of leaks and segfaults we have seen which can be attributed to "new" code, it is not such a bad idea to implement features in a language that cannot easily leak/crash or break the simulator.

Sometimes, we need "reverse motivation" (that is an actual term) to do something and act - for instance, look at the Qt5/Phi debates we have seen - coding a simple parser in Nasal would take only a fraction of the time that it took to have all those debates on the forum. And I think Thorsten mentioned something similar about vostok/EarthView at some point.

[vitos]

Update: radiocompass shows distance to NDB beacon.



BTW, if I did not mentioned that earlier - radar has autolhold option. It works with far or not much maneurable targets - allows to keep formation for example.

[clrCoda]

Gentlemen,

I wanted to thank you all, those that provided a detailed discussion of how these things work, how these things work together, and how things are perceived by those that work these things.

This might just be the most instructional thread I've ever read at FGforum. The arguments bring out the details that some of us appreciate learning.

Thank you for your ( mostly ) kind persistence in these matters.
My respect
Ray

[Thorsten]

Hm... 8 fps for a cockpit shot with low visibility and no scenery outside in view.

I rest my case.

[vitos]

Hm... 8 fps for a cockpit shot with low visibility and no scenery outside in view.

I rest my case.

2Gb of memory, Athlon 64 4000+. Ten years old computer and still 8fps. And some dudes who just could not - do not interested really - to start model themselves, since they are not a pilots. With exactness not.

"One who was born to creep just cant fly.".

[Thorsten]

Framerate is still poor for a cockpit-only shot.

And some dudes who just could not - do not interested really - to start model themselves, since they are not a pilots.

Sorry, I don't bother with non-GPL stuff any more, my time is too short to waste it on things which don't feed back into the project.

[vitos]

Sorry, I don't bother with non-GPL stuff any more, my time is too short to waste it on things which don't feed back into the project.

I still have a second for fallen.

It does not matter which rule someone follow. It matters what someone do.

[Thorsten]

You can go all day taunting people that they're not real pilots if they don't fly your planes. Fact seems to be that virtually no one does it, and certainly not for the reasons you claim - two reasons I know are a) not GPL and b) too slow to bother. I think lack of accessible documentation has also been cited as a reason in this thread, and in fact you continue to taunt people that they have to learn Russian if they want to fly it.

Except, it's just a good plane among others, so why should people put up with this? There's nothing exceptional - for instance Richard's JSBSim F-14b and the F-15 are excellent examples of high-quality fighter jets, they're GPL and nobody has to put up with being taunted by you to fly them.

The screenshots are pretty, but nobody is going to be impressed by a plane which sits on the runway at 8 fps. How's that working out for you?

[Hooray]

I don't think you can draw conclusions about the 3D model without also having some baseline data first, including different aircraft/locations and runtime settings, but also hardware specs.

2Gb of memory, Athlon 64 4000+. Ten years old computer and still 8fps.

Regarding frame rate, you can open /sim/rendering/draw-masks via the property browser to disable/enable different scene graph branches and see how much of an impact the cockpit/aircraft model really has. You would probably want to start up in a location without scenery though - e.g. using the minimal startup profile.

PS: I don't think "being a pilot" is a requirement for coming up with a 3D model (or vice versa) - if I remember correctly, Thorsten mentioned that he holds/held a PPL-C at some point (with most of us having at least a PPL or CPL in fact) - so I don't quite see how this is helpful.

Keep in mind that others around here do hold ATPL and ME-CC ratings, as well as degrees in aerodynamical engineering - still, they don't mention this all the time

[geed]

Just want to add my two cents here:


Vitos, this plane is beautiful - amazing to look at! It features an extremely detailed cockpit, which is, what I like about it. A detailed cockpit is needed to fly an aircraft Beatiful work.

But I can't get if off the ground as, even on my strong machine, it mostly freezes Flightgear or makes it run at something around 7fps or less.
And, I don't see any instructions anywhere. I will not, nor will anybody else on Flightgear earth, use Google translator to work out a way to fly this thing...

Provide an instruction if you want the world flying it. Your work just lacks this one thing.






I read through the whole thread. I wish I didn't.


Here's a quote of yours a little earlier in this thread:

By the way, are You flying something for time at FG multiplayer? Since, You know, there at MP some crazy guy somewhere at Germany, who does not fly a thing, but sits at some airport, demands others to follow his commands, and to "neglect" ones who do not follow it immediately.

I am just not interested in being that way.

But, you are, Vitos.
You demand, that everyone follows your point of view and you completely neglect any different opinion.

Change your way of dealing with people and they will change their way of dealing with you.
Only you can take the first step.