User talk:Hooray

From FlightGear wiki
Jump to navigation Jump to search

Dump space

Aircraft-set validation

Procedurally creating Cockpit GUI wrappers

See http://flightgear.org/forums/viewtopic.php?f=4&t=16438&p=187343#p187343

High-Level Architecture

Hi,

do you plan to write subtantial articles on all the HLA subjects? If not, it might be better (for now) to list all the abbreviations/terms on the High-Level Architecture page. The articles I mean include Federate, Federation, RTI. Please let me know what you prefer (or perform the merge if you support that ;-) ).

Cheers, Gijs 13:33, 18 April 2012 (EDT)

Nominating articles for deletion

Hi,

could you please use the "new" template in the future? See {{Delete}}

Thanks! Gijs 20:33, 16 July 2013 (UTC)

Bump. The new template has some mandatory fields, so please check the template page to see how it should be used.
Gijs (talk) 15:30, 5 August 2013 (UTC)

The done, not done and pending templates

I undid your addition of parenthesis to the {{done}}, {{not done}} and {{pending}}. I can't any longer stand the combination of parentheses, which are usually a way to mark text as less important, and bold text, which usually is a way to have the text standing out or emphasize something. Really a typographical shouting whisper, that kind of made my eyes sore. ;-)

If you want to de-emphasise the text Done|Not done|Pending, I would instead suggest using italics, which are generally less of an emphasise than bold text, while still standing out from the surrounding text. Alternatively, to emphasise the text further I would instead suggest using bold and italic text.

Johan G (Talk | contribs) 10:35, 9 August 2013 (UTC)

fps does not rise up when I turn shaders off

Regarding: http://www.flightgear.org/forums/viewtopic.php?f=37&t=21046 Please check the Article: Troubleshooting problems for a possible solution.

--HHS (talk) 18:14, 14 October 2013 (UTC)

Canvas Documentation/TODO

Hi,

please don't mix documentation and TODO lists (like http://wiki.flightgear.org/index.php?title=Canvas_Element&diff=63398&oldid=63381) Especially the Reference section of the Canvas (see sidebar) is meant as user documentation. As using the Canvas doesn't require knowing C++ we should not mention anything there on how to extend the C++ code base. Also a documentation should describe to the user what is possible and how do use it. Not what will maybe get possible in the future.

You can move this to a separate page, but please always keep in mind who is going to read a certain page, and what is the information intended to be presented.

TheTom (talk) 23:18, 16 October 2013 (UTC)

Recommended Property Tree Enhancements#Permission handling related

Hi Hooray, just so you know, what Thomas committed today is just a wrapper API to set a value and mark it as read-only. The ability to have read-only nodes has existed for a long long time, e.g. see /sim/fg-root, by using setAttribute (READ vs READ | WRITE, also possible from Nasal). So I think the point in the article is mute? —Philosopher (talk) 16:10, 20 October 2013 (UTC)

Yeah, I know - I looked at the commit when I left a comment there. But most of the article is outdated anyways, OTOH as can be seen, some of the old ideas are not all that bad, and may even become increasingly important again - I haven't checked when the code was added or when the article was written - but one thing is true: until today, we haven't really differentiated between property mutability like initial startup state, and that's definitely something that's going to be important as part of efforts like Reset & re-init. As mentioned in response to the commit, we would ideally show SG_LOG() warnings whenever such "readonly" properties are modified. Many related issues are not immediately obvious, but property-based subsystems like the canvas would ideally also declare their own properties as input-only or output-only (readonly), e.g. by extending the PropertyObject<> code - this would be particularly useful for anything related to the replay system, or the flight recorder system - but the multiplayer system would also benefit from being able to directly tell what properties are input/output properties, and obviously this also applies to our existing multi-instance master/slave code, which needs to be currently set up manually. So setting attributes to communicate property mutability/scopes seems like a sane idea still today (regardless of how long the underlying code has been in place) - sync'ing multiple fgfs instances with canvas displays would also become simpler that way. So while many things in that article are kinda outdated/moot, I think the last 18-24 months of core development have shown some of the underlying ideas to be still applicable to a certain degree. Thus, I'd hesitate to delete anything there at the moment - but I'm also not overly eager to update things... I just ended up updating the section because I saw todays commit. --Hooray (talk) 16:25, 20 October 2013 (UTC)

Latest newsletter edition – Nice edit

That was a pair of nice edit-saving edits. :-)

Johan G (Talk | contribs) 22:33, 3 December 2013 (UTC)

The needed Git navigation template

Err, did you have a look at the source of {{building}}, I think you would consider it quite feasible to add the template yourself... ;-)

The {{navbox}} template is currently undocumented, it is one of those more tricky ones to document. In (un?)due time it will be, I hope.

Johan G (Talk | contribs) 00:45, 7 December 2013 (UTC)

This wasn't intended for you, I just didn't want to copy/paste things (yet), but also didn't want to forget about it - thanks though, yes, I do realize that I should have the mental capacity to handle the implementation of this :-) --Hooray (talk) 00:51, 7 December 2013 (UTC)
Ah, ok. :-)
Johan G (Talk | contribs) 01:04, 7 December 2013 (UTC)

TODO and FIXME templates

I saw that edit. ;-P

I have sometimes pondered {{todo}} and {{fixme}} templates, though I'm not sure they are an all too good idea, at least not in articles meant as user documentation.

As for mockups, how would something like these look: User:Johan G/Todo and fixme template sandbox?

Johan G (Talk | contribs) 16:46, 8 December 2013 (UTC)

In this particular case, {{Incomplete}} would be more fitting I'd say...
Gijs (talk) 17:05, 8 December 2013 (UTC)
Indeed it is, but sometimes it is a bit too general. For those cases when someone needs to mark a paragraph or maybe just a sentence there is currently only {{clarify}}, I think. For a sanbdox or a page under heavy development it is a bit discrete I think.
Johan G (Talk | contribs) 17:22, 8 December 2013 (UTC)

The colour coded MVC diagrams are great

I really like those colour coded MVC diagrams you added to the MapStructure article. While I am familiar with the MVC concept I have not even tried to get a concept for how it is implemented, since I am not that interested in Nasal presently. Those diagrams give me at least some understanding of the structure with even a quick glance.

When I first stumbled upon the MVC concept when reading about some of the ideas behind SmallTalk, either on Wikipedia or more probably WikiWikiWeb (The Portland Pattern Repository), there where no illustrations and it took a day or two to wrap my mind around the concepts. Those diagrams will probably help new Nasal and aircraft developers immensely. Thank you! :-)

Johan G (Talk | contribs) 02:46, 8 February 2014 (UTC)

They're cute too! ~.^ —Philosopher (talk) 04:12, 8 February 2014 (UTC)

lol, "cute" ? You aren't in a good position to judge things, this is primarily YOUR work Philosopher that we're documenting here!!
The primary idea was to document the main concepts.
We are facing the problem that we're having an increasing number of people wanting to do related projects, without knowing how to do them properly.
They would often rather start from scratch than try and understand a framework that's too difficult/obscure.
In general, MapStructure has become a solid foundation already - and we have enough people here who should be able to pick up the concepts and help maintain it over time.
But speaking from experience, the code isn't exactly straightforward - i.e. had you used conventional classes and inheritance, we might have 3-5 more people willing to play with it - but what you have come up with is a bit too sophisticated for the average FG contributor.
As you may remember, I also faced a steep learning curve there when I was working with it - and you even said that you had the same issues when you abandoned the code for a while.
Which is why I added some more explanations and diagrams.
So as long as the framework is sufficiently documented and self-explanatory, it will be less work for us, because others can help with it over time.
I am not sure if MapStructure is a good place for people to start with Nasal hacking though...
That's basically the whole plan. So there'll probably be more diagrams. They are simple to add, using yuml - i.e. just 2-3 minutes even for complex diagrams.--Hooray (talk) 06:29, 8 February 2014 (UTC)

FGCamera not yet in Git

Hi,

FGCamera is not yet in Git.

Gijs (talk) 21:25, 6 March 2014 (UTC)

I know, but it's available for download, and we've previously promoted addons that never made it into git. On the other hand, I do agree that it would be better to focus on features (=including aircraft) commonly available in "stock" FG - then again, most people do not seem to bother updating the changelog regularly. It seems to be pretty safe to add things early on and review things when editing the changelog later. Otherwise, we tend to forget most recent additions, because most of us don't really enjoy going through 6 months of forum threads, devel list postings, newsletters and commit logs. FGCamera is just a base package addon so far, so doesn't need to be committed to SG/FG to be useful. Still, I do agree that it would make sense to get it reviewed/discussed and committed. Would you be willing to help get it reviewed in time for 3.2 ? --Hooray (talk) 21:59, 6 March 2014 (UTC)

Talk:FlightGear Newsletter June 2014

Hi,

please have a look at my comments on Talk:FlightGear Newsletter June 2014

Cheers, Gijs (talk) 20:51, 23 June 2014 (UTC)

FlightGear Newsletter July 2014#FGCanvas Updates

Hi,

could you please clean up FlightGear Newsletter July 2014#FGCanvas Updates so we can publish the newsletter?

Thanks! Gijs (talk) 14:45, 2 August 2014 (UTC)