User talk:Hooray
Dump space
Aircraft-set validation
- https://forum.flightgear.org/viewtopic.php?p=185963#p185963
- texture size
- file names / paths (spelling, case sensitivity)
- dependencies to other aircraft
Procedurally creating Cockpit GUI wrappers
See https://forum.flightgear.org/viewtopic.php?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: https://forum.flightgear.org/viewtopic.php?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)
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)
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)
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)
- What exactly do you have in mind ? It looks fairly clean to me - or is this about the usage of instant-cquotes ? If that's the case, we should come up with a consensus if we want to encourage such additions or not. --Hooray (talk) 14:51, 2 August 2014 (UTC)
- Hi,
- Last month I rewrote several of such quote sections. You explained you'd added them as place holders, so I thought we were on the same track now. I don't have the time nor desire to rewrite quotes into text every month, so that's why I asked you to do it this time.
- To list a few instant-cquote bugs (though that is not the main issue here, as explained above):
- quotes in quotes are hard to identify
- year is lacking from the date
- lots of unneeded nowiki tags
- html tags like br, ul and li
- Cheers, Gijs (talk) 18:54, 2 August 2014 (UTC)
- I've fixed a couple of the issues you pointed out - but like I briefly mentioned in the "commit" message: I am not sure where we're headed here. If there is to be some kind of "standard" to be established, that's great - but it better be made known first, or fellow contributors (like myself) won't know what to look for. As you may remember, I was the one to originally suggest that the newsletter be wiki-based - so I am fully supportive of the whole idea here, and want to follow proper procedures - and it is great that some folks are working towards improving things (including yourself and Johan_G) - but please don't just come up with your own rules and guidelines without 1) communicating and discussing them upfront and 2) coming up with a consensus that we all agree on.
- I certainly don't want to make your job more difficult - and I am sure you don't want to make mine more difficult.
- But this is a simple, and clear, issue of coming up with a few guidelines first - which should not be "personal". Otherwise, we're simply facing a situation similar to code/Nasal contributions, where different contributors don't quite agree with the style/nature and design of certain code - which usually boils down to statements like "not high on my todo list, but please be me guest" - which kinda goes to say, that this is not uncommon at all, and people -like me- who don't like certain contributions, more often than not, have to roll up their own sleeves to establish "best (better) practices", be it in the form of tailored tutorials, guidelines or corresponding contributions in the form of patches (or even just fixing broken newsletter templates so that they become editable again).
- Honestly, the number of people contributing to the newsletter isn't exactly large - there's really just a handful of regular contributors, so it should be fairly simple for us to establish a set of common rules. I am sure that the Instant-Cquotes script can be adjusted accordingly. But like I said previously, it's a cost/benefit issue from my standpoint: not contributing to the newsletter the way I do, would take away some less-structured entries, but also quite a lot of content. I don't think we need to make this any more problematic: there's really just 3-5 regular newsletter contributors - those should obviously be the ones to come up with corresponding guidelines.--Hooray (talk) 21:08, 2 August 2014 (UTC)
- Hi,
- it wasn't me who retracted your contribution yesterday, so not sure how I would be pushing my own rules. I asked you to clean it up, not to remove it. I've raised my concerns over using quotes on the wiki various times, so that should be no surprise. If I wasn't interested in hearing your opinion I wouldn't have come here.
- We could have lengthy discussions about it, but in the end you're the only one contributing quotes this way. It might be more efficient to just talk to you ;-) I think the following quote (ha!) is quite representative for my opinion (and yours as well?):
- Last month I rewrote several of such quote sections. You explained you'd added them as place holders, so I thought we were on the same track now. I don't have the time nor desire to rewrite quotes into text every month, so that's why I asked you to do it this time.
- With slightly more effort you can make an enormous improvement in readability and styling. The effort is smallest if done by the person who's read up on the subject (i.e. the one adding those quotes). Just look at the difference between [1] and [2] (ignore the broken heading templates there). In general I prefer quality over quantity, especially for something that we release into the world to promote FlightGear.
- We've got 28 days to show what we would like to end up with this month :-)
- Cheers, Gijs (talk) 14:28, 3 August 2014 (UTC)
Canvas snippet template
Hi, read your forum PM regarding a template for the canvas snippets. An early prototype is in my sandbox (currently only documentation of the parameters).
Any input on the parameters and parameter names are welcome (though the my not necessarily be implemented ;). I also would like some feedback on the intended content of two of them (see questions on the page).
Please respond on the templates discussion page.
—Johan G (Talk | contribs) 13:42, 21 September 2014 (UTC)
- Moving someones user pages could be considered to be impolite, though I can forgive you for that this time. I would already have done it myself if I had considered it ready.
- There is still some rather big wrinkles to iron out, in particular that I have yet to figure out how to put the script inside the syntax highlight tags.
- that is indeed a long-standing issue, we once talked about it a few months ago, and didn't find a simple solution that would be accessible to mere admins like us-which is why I simply moved the sytaxhighlight tags to the call/expansion site of the template, and left it out of the called template in my experiments. Not perfect, but at least it works without too much effort... --Hooray (talk) 18:26, 24 September 2014 (UTC)
Nasal documentation
Hi Hooray,
I really appreciate your input to my Nasal doc page. While I agree that most people copy & paste a lot of the time, I prefer examples to be quite simple. Also my coding style has be almost entirely influenced by examples across the wiki, so I don't tend to add exception handling or use call() , et al so often. Also, after the core library (non-extension) functions are done, I'll go through it again to clean it up. Again, thank you for the work you've done, especially with simplifying the examples.
P.S. Just a heads up, I'm actually called Red Leader [3] 
Red Leader (Talk, contribs) 04:06, 29 January 2015 (EST)
- Like I mentioned previously, I fully realize that some of your original examples may no longer be as straightforward due to my own edits, so please feel free to edit/revert things as you deem appropriate. In general, we have far too few people who really understand "call & friends", but once people understand how to use these tools, they tend to write much better code while also understanding internals much better (e.g. namespaces, hashes, classes etc). Thanks again for your high-quality wiki contributions, and especially your Nasal efforts (the template stuff will be very useful)!--Hooray (talk) 14:38, 29 January 2015 (EST)
The newsletter needs published
It's already September ;) Legoboyvdlp (talk) 08:51, 6 September 2017 (EDT)
Regarding Template:PDF link
I was going through uncategorized templates and categorizing them and writing documentation if they was not too hard to document when I stumbled across {{PDF Link}}.
I understand that you swiftly wanted to add links to the FG1000#Layers table, but why not spend the extra time and use {{cite web}} and refer to page numbers in text instead of creating an undocumented template pretty much for that use only? In addition it might be better to reference page numbers in text rather than as links as the pilots guide is is a bit of a hefty download at 600 pages.
—Johan G (Talk | contribs) 07:31, 8 May 2019 (EDT)
Howto:Record, analyze and replay multiplayer flights with network tools
Good catch. I was thinking about that when I realized I felt a need to describe the links on pretty much all pages I added it to.
Only a slight bit extra work to clean that up (before anyone get time to link to the redirect pages I deleted).
—Johan G (Talk | contribs) 08:53, 12 March 2020 (EDT)
Template:Logo
Regarding your edit summary when creating Template:Logo, see FlightGear wiki:Village pump#Meta template and templates for commonly used logotypes and icons.