FlightGear Newsletter July 2014

5 years of newsletters

The newsletter started in July 2009. (more to write here, just so we don't forget about it)

Would it be an idea to provide some sort of weekly or monthly newsletter? I often find out that there are new things I didn't new about or other users that don't follow all topics won't know if there's an awsome plane released. That's why I think we need a newsletter. Possible things to write about could be: - New planes that are released. - New scenery projects (like a new/redrawed airport, things like the corse scenery etc.). - New FG releases (this is not very often, but it should be in the letter if so). - New forum features/subforums and other news from the forum. - News from the wiki (only detailed and large tutorials, or new portals etc. so not every new article ofcourse) - Events that will be held within a short periode or (links to) screenshots of the latest event(s). - The first 3 or 5 pictures of a screenshot contest. If you got other idea's, post in this topic so we could extend the list. I don't really know what's best way to provide the letter. But we have some options: - a topic that's closed, only open for people that are making the letter (at the moment this sounds best to me). - emails send to all forum-users (I don't really like this myself). - a .pdf file with a link on the main page of http://www.flightgear.org - or even something else I would like to write the letter, but if there are other people to we might split stuff (someone for scenery news, someone else for aircrafts etc.). Please respond and vote in the poll. Tips/ideas are very much appreciated. — Gijs (Mon May 26). Newsletter. (powered by Instant-Cquotes)

The devel-list is great, I'm subscribed to, but not simple to read. It's more like the forum. Usually I don't want to or have time to read through all emails. So I delete most of it without reading anything more than the subject. We don't want to read a lot of topics if we only want to know what function is new and what it does. The the users (so not the developers) want something more ease to read/check. With some screenies of what they will get with a new function etc. So my idea was to make it especially for users. Events aren't listed on the pages you gave nor some other stuff we could place in the newsletter. In the letter all important news to know will be listed together. If we get this of the ground it could be a great way to reach users to (for events etc.). So I think the newsletter still will be a addition to the lists. — Gijs (Mon May 26). Re: Newsletter. (powered by Instant-Cquotes)

At one time a few years ago we attempted to launch a newsletter. We had two volunteers, but we never got even the first issue out. It's a lot of work so we need a pretty dedicated volunteer. I've heard of other folks using scribus, but even open-office writer would probably be just fine. Let's not get too caught up in the details of a print/publishing quality layout if we have to sacrifice time for content and just getting the newsletter out on a regular time frame. There are a bazillion ideas for articles. I could dust off my unpublished "yasim howto" for instance. That ended up being about 10 pages (so not newsletter material really) but I could trim it down to a teaser article and we could post the full version on the wiki or something? But if you are willing to get a newsletter rolling, that would be awsome. — curt (Tue May 27). Re: Newsletter. (powered by Instant-Cquotes)

Gijs is right when it comes to being a Developer or a User of FG is Vastly different. I know when i first started here i had no clue about lots of developmental things, now i talk of writing .xml files, modelling nasal scripting. That is due to people describing things is basic easy to understand" Laymans" terms and not the kind of language that the DEvs use (understandably of course) — MaverickAlex (Thu May 29). Re: Newsletter. (powered by Instant-Cquotes)

Since 16 to 3 voted for Yes I will release the first Newsletter as soon as possible. — Gijs (Thu Aug 21). Re: Newsletter. (powered by Instant-Cquotes)

Why not simply start a new page on the wiki where anybody can provide contents, so that whenever it's time to send out a newsletter, the draft from the wiki could be taken? That way, it wouldn't be too much work for a single person - more like a "community-driven" newsletter, while this may appear to sort of defeat the purpose, not all newsletter recipients are necessarily also wiki users. — Hooray (Fri Oct 03). Re: Newsletter. (powered by Instant-Cquotes)

FGCanvas Updates

Since the early Canvas days, we started toying with the idea of providing an FGPanel-equivalent integrated right into FlightGear using the Canvas system: Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend. If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than sending per-frame pixel surfaces over shared memory or sockets / pipes. — Hooray (Sun Jul 06). FGCanvas Experiments & Updates. (powered by Instant-Cquotes)

The whole discussion dates back to the early FGPanel days:

I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people). It will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone. Anyway, all off-topic! — zakalawe (Tue Nov 02). Re: FSWeekend 2010. (powered by Instant-Cquotes)

Since then, we made some first FGCanvas experiments, and things proved to be fairly tricky, because many C++ subsystems were not exactly easy to make entirely optional, and because of all the implicit assumptions in Nasal code that is unconditionally-loaded from $FG_ROOT/Nasal, and which assumes to have a full session up and running: Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas... — Hooray (Sun Jul 06). FGCanvas Experiments & Updates. (powered by Instant-Cquotes)

Fast forward a year later, many of those show stoppers have already been resolved, mainly thanks to the work done by Zakalawe and TheTom, who've both been working on reset&re-init, but also overall better run-time re-initialization support, as can be seen in the screen-shot below: FGCanvas Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are: flight (FDM) scenery (tile manager, ephemeris) view manager lighting terrasync Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas) — Hooray (Sun Jul 06). FGCanvas Experiments & Updates. (powered by Instant-Cquotes)

This means that there's basically just a handful of subsystems that now need to be made optional, and that FGCanvas will actually become reality. I am going to help rework MapStructure and the ND code in order to ensure that there's no implicit assumptions on running instruments locally, so that we can eventually also drive displays remotely via properties. Roughly a year ago, I already posted some screen shots showing a FG instance that replicates a canvas property tree via telnet's "subscribe" command - it was a hack, but it worked well enough. Even though using UDP-based PUB/SUB, or maybe HLA, should probably scale better. Given the recent progress in this department, I am guessing that it may take us another ~2-3 release cycles until this materializes "automagically". In the mid-term, I would hope that we could agree to provide some dedicated API for implementing and initializing subsystems, to ensure that most future subsystems can be easily made optional/run-time configurable, which will entail establishing dependencies among subsystems in some "run-levels"-like setup, which will also touch Nasal bootstrapping, i.e. the stuff we're currently doing in FGNasalSys::init(), but which we're hoping to move into scripting space. — Hooray (Sun Jul 06). FGCanvas Experiments & Updates. (powered by Instant-Cquotes)

I'll revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support). FGCnvas definitely sounds like an excellent idea. — Philosopher (Sun Jul 06). Re: FGCanvas Experiments & Updates. (powered by Instant-Cquotes)