Su-15

[Hooray]

lo siento, pero no puedo comprender mucho ...

[vitos]

lo siento, pero no puedo comprender mucho ...

Lunnaya programma FG:

Estestvenno u was net vozmojnosti ponyat mnogoye - ego slishkom mnogo. Chto maloponyatno mne - na koy ego mnojit dalshe i dalshe kogda s nego proku net.

Vidno chtoby otchen umnym kazatsya.

A chto do menya - ya sdelal model, ya na ney "letayu" regulyarno. Eto bodrit - za otsutstviem vozmojnosti letat na nastoyashem samolyete.

[legoboyvdlp]

Yeah, I could. But not with people as You.

And YOU need to shut up and go away until you learn to be respectful.
You asked for help, you got it, you complain about it and call rude names.

[Thorsten]

That midlevels would not do in most of cases. Most of instruments is individual and have onwn special advantages and limitations.

I think you're confusing the difference between an instrument rendered in an airplane and the data structure used to feed it information. The instrument just shows the value of a property (a list of properties,...) - an altimeter shows a number, it can be a pointer, a digital readout, a tape,... I can generate that property in any number of ways.

However, given that FG never contains the concept of radar reflectivity attached to any scenery models, the only way you will ever get a working radar is to search the space nearby for AI or MP plane coordinates - you'll have to do this no matter what you want your radar to do. How you filter that list and display (or not display) it is a different questions.

To me point of sureness was then I recognized that there will not be any more or less real Moon at FG. Somehow it said that it will not add new levels but new and new midones instead.

Here we go again...

Since spaceflight your favourite metaphor, let's do it this way: Successful space programs build on the tried and tested, change a few steps at a time, re-use design which has been proven successful again. Revolutionary designs in rocketry have a way of exploding on the way up.

You plainly don't know whether the moon in FG will be in reach.

You had made a rocket which could reach orbit, coming with some simple orbital mechanics calculators for guidance.

Now? We have more than ten times more utility routines for spaceflight coming with the Shuttle than Vostok ever had. There's more two-body orbital mechanics like time to apsis estimation, inclination and longitude of ascending node. Intertial and LVLH pointing and tracking for automatic attitude management. PEG-4 guidance routines, soon also PEG-7 support. Numerical prediction of atmospheric entry interface. Range managing guidance for entry.

There's simulation routines for thermal balance of spacecraft. Routines to cover co-orbiting payloads, visualization of disconnected stages is worked out properly. You can detatch and re-attach an object in space. We have a feasible way of rendering firing thrusters in orbit.

We've even got some useful features into the core code in the process.

See why having all this is rather crucial for a simulated moon program? Getting the LEM attached to the tip of an Apollo craft is no different from detaching and re-attaching a playload to the RMS arm conceptually. You have to dispense with just letting discarded stages vanish (as done for Vostok) and continue to simulate things other than the main craft independently. You're going to need inertial pointing and guidance, numerical trajectory prediction beyond the nested two-body problem if you want to have any precision going to the moon or rendezvous the LEM with the Apollo going back.

Also, see the relation to your discussion with Hooray? In both cases, you just fail to see what intermediate steps are actually necessary to really achieve a goal. You'd rather re-invent the wheel from scratch because you're so focused on your final goal - which is why you will never go to the moon in FG, whereas I just might.

[vitos]

Another one self-advertiser. I do not mess anything with anything - I already have working thing, since to make everything by own self is not the best way only at case if things made by others is not made only, but open for usage really, and works well.

As of Moon - to land to the moon You need to have it. Not pseudo "Moon" implemented at nasal level and existed at special case as additional scenario started for someone only - which you would finally land at, what would not differ much from movie "Moon" landing - but Moon existed on same level as Earth - at same level of virtuality as Earth existed at FG at least.

That's why I was strictly against nasal EarthView - it's first steps to say what real Moon landings was faked really. Your "space Earth" is already fake. Real FG Earth is what seen without EarthView plugin on, as real FG shadows is what seen without Rembrand project on, and so on.

I am, as specialist, sure "real" Moon will be not in FG. It's caused ideologically.

Model of equal of level celestial bodies can be implemented in really equal human relations only. As of reaching both really, of course.

And actually it's the key for all I made and said here.

Heh, and it's the key reason why real Soviet N-1 Moon project failed - relations was not really equal. But, You know, there was quite fine "Moon" landings at Soviet movies - better than at American ones. And much earlier than it was at Holliwood.

[Thorsten]

Another one self-advertiser.

If you don't like advertizing your work, don't do it and delete the Su-15 screenshot thread. If, on the other hand, you feel you have a reason for that thread, don't criticize others - that's called hypocrisy.

That's why I was strictly against nasal EarthView - it's first steps to say what real Moon landings was faked really. Your "space Earth" is already fake. Real FG Earth is what seen without EarthView plugin on, as real FG shadows is what seen without Rembrand project on, and so on.

That's you being strictly against nasal Earthview on Sat Mar 24, 2012 : Whoa. Perfect.

Aw... that didn't really sound the same, did it now?

I have some disturbing news for you otherwise: Real time 3d rendering is based around the concept of faking things. Rembrandt doesn't compute any real shadows either (which you can easily see by the fact that neither clouds nor trees cast any, or that no object illuminated by a Rembrandt light will cast a shadow) - it's just a different way of faking it.

No reasonable rendering engine will ever show you something other than a textured sphere from orbit.

Generating moon terrain isn't difficult - you run the data through the terrain generating engine and texture it with dark grey gravel. But you'd still render the moon as a textured sphere before you descend to some 30 km or so and switch to the detailed representation.

I guess if you don't like 'faked' things, you should in general stay away from real time rendering and use raytracing to create still images.

Model of equal of level celestial bodies can be implemented in really equal human relations only.

And actually it's the key for all I made and said here.

Since the first sentence doesn't make any sense, I suspect that's most likely true - what you do doesn't make much sense given what your stated goals are

[Hooray]

To get back on topic, you don't have to use MapStructure for this - however, it was designed particularly for your use-case.
So you can just as well use the underlying, low-level, Nasal/Canvas APIs.

But I find it contradictory, given that you are basically refusing to use an existing framework that was specifically designed for this particular purpose.

Given the extremely basic nature of your questions, I think that you know enough about Nasal and Canvas to end up with working code/features - but that does not mean that you can come up with code that satisfies all requirements, including in particular performance and reusability.

Basically, you now know enough "to be dangerous" - i.e. you can now implement your ideas using Nasal and Canvas without using a suitable algorithmic approach.

You could look up the pointers I posted, i.e. code snippets and APIs - and sooner or later you will figure out that you need to add, update, animate and remove items on a dynamic map, which may be aircraft-centric or not.

So basically you are asking for all the tools to figure out how to do a dynamic map without using MapStructure, without understanding that you are going to reinvent the wheel.

Like Thorsten said, the key aspect here is processing AI/MP properties, doing terrain sampling and a bit of device specific "radar/antenna" modeling.

Given that you seem to have accomplished this already, I really suggest that you look at $FG_ROOT/Nasal/canvas/map/TFC.lcontroller and its searchCmd() method - it should look really familiar to you, because it is doing exactly that: processing AI/MP properties and filtering (searching) based on range to an aircraft.

If this is not immediately obvious to you at first glance despite your background in Nasal coding, it is mainly because there are some abstraction layers used in MapStructure - namely, MVC (=Model, View, Controller) separation (which is to say that searching takes places separately from drawing symbols), but also because of so called "delegates" - which is a fancy word for a design pattern where use-case specific functionality is implemented in callbacks (=Nasal functions) that are passed to a generic function.

These two design decision make it possible to come up with a shared framework that can be used by arbitrary aircraft and instruments, including even maps shown in GUI dialogs.

MapStructure is not necessarily "perfect" code (in fact, I would do it differently today), but it can be used by aircraft developers without having to understand any of MapStructure.nas at all - if you are looking at MapStructure.nas just to implement a new layer, you are doing something wrong - the whole framework is documented extensively on the wiki, including code snippets.

And you can look at existing layers and reuse/adapt those - e.g. by editing TFC.lcontroller to add radar functionality to it (=terrain awareness, and a basic radar/echo simulation) - to do that, you could edit the file directly, or create your own files using TFC.* as templates.

[Hooray]

Here's is what I was referring to:

http://wiki.flightgear.org/Canvas_MapStructure_Layers
http://sourceforge.net/p/flightgear/fgd ... controller

Code: Select all

var searchCmd_default = func {
   # TODO: this would be a good candidate for splitting across frames
   printlog(_MP_dbg_lvl, "Doing query: "~name);

   if (me.map.getRange() == nil) return;

   var result = [];
   var models = 0;

   # AI and Multiplayer traffic
   foreach (var t; model_root.getChildren()) {
      if (!t.getValue("valid")) continue;
      var t_id = t.getNode("id");
      if (t_id == nil or t_id.getValue() == -1) continue;
      models += 1;
      var (lat,lon) = (t.getValue("position/latitude-deg"),
                       t.getValue("position/longitude-deg"));
      if (lat == nil or lon == nil) {
         printlog("alert", "lat/lon was nil for AI node "~t.getPath());
         continue;
      }
      if (me.map.controller.in_range(lat, lon))
         append(result, TrafficModel.new(t, nil, me.layer));
   }

   #print("Found "~size(result)~" TrafficModel's in range out of "~models~" total.");
   return result;
};



most of this should look familiar to you, and it will in fact be much simpler than your own code, because it is not trying to be a terrain-aware radar, but just a TCAS layer.

But the underlying logic remains the same, like Thorsten said

[vitos]

Thorsten: I do say about my work at my thread. I do not go to Your thread to say that You are dumb and what my work is best. Comprehende?

Fake is thing what was made instead of making more real one which was possible to make. If You could fly to the Moon really then what You are flying to "Moon" at simulator is fake moon flight. If You could not fly really because of circumstances - well, simulation flight is best Moon flight You could afford.

So, if You can implement Moon at base level of simulation - it's real. If You do nasal rendering, nasal position accounting and so on instead - it's fake.

Hope it makes sense for You. If not - please, do make Your stuff somewhere else, or I will say what I am thinking about You same way as You said about me.

Hooray: I can make everything I need, and already made that. It was question of documentation level. I asked You to find example code of adding in some list of canvas objects at runtime, removing from it, and getting number of elements of it. What You provided here is other thing.

And, yeah, someone making things at basic level is dangerous for someone making midlayers and wanting to press and push others to use that.

[Hooray]

Hooray: I can make everything I need, and already made that. It was question of documentation level. I asked You to find example code of adding in some list at runtime, removing from it, and getting number of elements of it. What You provided here is other thing.

It is not, I answered exactly your questions.
And I invite others who speak English and Russian to help translate my responses to you.
A Canvas is just a texture in the global property tree. Using a Canvas is made easier through api.nas, but you don't have to use it in most situations.
Which also means that you can use other property APIs, e.g. referring to props.nas
I think I also explained particularly well why you don't want to use any of the lower level APIs.
However, it is obviously possible to still do so.

It seems, you are beginning to understand some of the problems you are facing, but you don't understand enough about Nasal and Canvas to see how this is done dynamically. I still provided the corresponding pointer, while making perfectly clear that your approach is misguided, and that you should take a look at the MapStructure framework - even if you don't want to use it (which is fine), you can learn how to do this efficiently, without turning your Su15 into a resource hog wasting frame rate and runtime due to poor update semantics/logics (see the m2000-5 or the extra500 for other examples on mis-using Nasal/Canvas like this).

Seriously, you can have the fastest 1000 hp car, but if never learn how to change gear but just use the 1st gear only, it is very likely that someone with a 40 hp VW beetle is going to be a better driver/user of the resources available to him than you are.

And that applies not just to the Nasal/Canvas debate, but also to using workarounds in Nasal space like EarthView, or overlapping efforts like ALS/AW: Nasal is there for a reason, it is used by people whose interests may be outside of core development - just look at bombable.

Under the hood, these "workarounds" still end up calling native C/C++ code at some point, and the people developing such workarounds will accumulate tons of experience along the way, experience that will also be applicable elsewhere, including native code (core development)

By now, you only understand how to mis-use Nasal and Canvas to come up with a working feature that is adding to the performance overhead of the main loop. And should someone want to reuse your work on a different aircraft, or even GUI dialog - possibly including different styling, and multiple instances - you'd find yourself in for a big surprise.

[vitos]

What I do comprehend - is what how to make my thing works. And it works fine. Question I asked was not about it.

Code You provided not gets number of elements by getCount or so - it uses foreach () to count it. It's the way I could make it myself without any questions. And You was not provided example of deletion from that list anyway.

[Thorsten]

I do say about my work at my thread.

You don't own forum threads - you just start them.

See, I realize fully well what your problem is - you previously thought yourself irreplacable and even wrote in the forum that no one can possibly redo your spacecraft work. Now it turns out that you're not irreplacable - in fact we can go far beyond it. I've said this before - you are a very gifted modeler - but you're not the best, and you're not the only one at this level.

And you'll always be beaten by a good team - because there's things you simply don't know whereas a good team has specialists for various areas - rendering for instance, see below. You simply have no idea how something that renders fast and is visually appealing needs to be designed - you have some philosophical idea about 'real' modeling which gives you the same pixels on the screen as 'good' modeling, except you're doing it much slower by disregarding optimization techniques. What Hooray tells you is the same theme.

So for all your talent, your lasting impact on FG is much smaller than, say, Hooray's, because you're not concerned at all about generalizing things, thus enabling others to join an effort, and because you prefer the grand gesture over sorting out the nitty-gritty details.

Fake is thing what was made instead of making more real one which was possible to make.

Yes - that's what real time 3d rendering is all about - since in the end it's all colors of screen pixels, it doesn't matter what the data structure behind is as long as the screen pixels look as they should. Which is why good design here is to use a fast-performing fake rather than a slow more real thing which looks practically the same on-screen.

EarthView is rendering Earth at the 'base level of the simulation' - it's an object in the scenegraph just like any other object, including the terrain mesh or your aircraft model. It's all the same - long lists of vertices with textured triangles and associated statesets. All that counts is updates the framebuffer fastest. Pixels on screen is all the reality there is to real time rendering.

If You do nasal rendering, nasal position accounting and so on instead - it's fake.

I guess you really need to understand how FG actually works at some point.

[vitos]

Are You trying to convince me to something? It's not about me.

I do know perfectly how FG works - quite old engine and tons of resource waste patches above it.

And I do know perfectly how community making all that is arranged.

[Thorsten]

Are You trying to convince me to something? It's not about me.

No, I'm telling you how things are.

I do know perfectly how FG works - quite old engine and tons of resource waste patches above it.

You clearly do not. Ironically, one of the main resource hogs is the lack of a LOD system for the terrain - i.e. we're not using enough fakes and waste resources trying to render the mesh 'real'.

[vitos]

I am not a thing. But when You do say something as "So for all your talent, your lasting impact on FG is much smaller than" - yeah, You do mind at level of Your own belongings.

That's quite old engine too, heh.

Why did we not made something together? Not because of me, nor of You - I hope so - but because I do have very clear view of how something should be made, and can not accept any other solution than better than mine.