Does FlightGear has Multiplayer Combat mode?

[Thorsten]

No one with real coding skills should be making a gauge or a jet console...... make a tool that allows a modder to make dozen of the variations without having to learn code..

That's where FG is going wrong... it doesn't cater for the grunts, and it's why you don't have enough of them,.

Well...

Here's my personal experiment with this: Making terrain texturing look better. After a few years of coding and nagging others to code, we now have

* xml-configured regional texture definitions
* general-purpose xml-configurable effects for the terrain
* and the best - all controlled from the same file!
* and the whole thing documented in the wiki
* and my personal help for people who want to do it in the forum

It's the classical grunt task (to stay in your language, which I don't really care for much myself) - most of the actual work is gathering aerial imagery of an area, finding or making the textures you need and lots of trial and error with different texture schemes - almost zero coding requirement, the necessary xml you can pick up in an afternoon if you don't do cut and paste. And it makes a hell of a difference for the visuals of a region, more than any amount of CORINE data or static models can do.

The net effect is that I still do 90% of the regional texture definitions that are shipped. Why? You may argue that my time is too precious, but I actually want to fly in a certain region, and I want that region look reasonable, so if I don't invest the time, nobody else is doing it for me. I'm by now quite good with the workflow, so all it costs me is a few days.

Some folks use it for custom scenery, and every once in a while someone makes a definition that can actually go to GIT, but it's really the opposite of what you claim to be true - there's lots of time invested in an easy-to-use tool which enables people to make 'their' region much better - and what happens is that nobody uses it.

It's simply not true that the grunts would appear and start working if only they had the proper tools / the documentation / the whatnot. The fact of the matter is that I've almost never seen it happen, so by now my prevalent philosophy (born from that experience) is that I want to see very solid evidence that someone will actually use any tool requested from me before I consider coding it.

[Hooray]

It's simply not true that the grunts would appear and start working if only they had the proper tools / the documentation / the whatnot. The fact of the matter is that I've almost never seen it happen, so by now my prevalent philosophy (born from that experience) is that I want to see very solid evidence that someone will actually use any tool requested from me before I consider coding it.

We've actually tried that with the MapStructure framework, which is rather extensively documented now, and which even provides kind of a "plugin" or "module" system, where people can easily add their own map layers for custom stuff. While the documentation is obviously very popular (14k views within just 6 months), we still have to see someone else step up and actually adopt the system. Admittedly, FlightGear 3.2 is going to be the first release that will provide most of the building blocks required here, but currently it doesn't seem likely that there will be dozens of modules provided by others, despite us having taken the time to work out a system, and document it rather well. Still, I don't regret having spent that time, because the contribution is at least "future-proof" that way - i.e. it doesn't matter if we're around or not, because people can look up all the required info and actually understand the code sufficiently well to improve/maintain the system, or completely replace it once someone comes up with something better, without introducing regressions. That's the "placeholder" mentality that we recently discussed in another thread.

The majority of people making just comments and feature requests doesn't really care enough to actually use the requested feature to contribute something back to the project. That's why most of us filter by "track record", and e.g. by people who are about to use gitorious, build from source etc - based on personal experience, the likelihood of seeing someone contributing something back is exponentially higher once certain criteria are met, i.e. either a corresponding track record, absent that, a strong willingness to follow advice, or at least acquire knowledge and follow pointers.

Ultimately, the question still boils down to motivation - we've seen some very experienced contributors/core developers who agreed that certain features would be "good to have", but who still didn't care enough to actually work on those - at least, they stated so upfront

Seriously, the same people asking for GUI tools like an aircraft, scenery, texture or mission editor are usually the same ones who refuse to use existing tools like Blender, GIMP, QGIS/GRASS or even just a good XML editor.

Claiming that Nasal/Canvas would be "a failure as a tool" just because people can still implement slow code, is far too short-sighted - just because you are allowed to drive a car (or fly an airplane) doesn't make you an expert in car engines or airplane turbines - things like Nasal and Canvas are really just enablers, that are truly powerful in the hands of people who know how to use them, but that can still be misused by less-experienced contributors.

That is exactly why people are working towards more targeted frameworks on top of Nasal/Canvas - but it's a process that is very much still in progress, and probably will be for at least another 2-3 release cycles. Pointing out obvious shortcomings isn't going to help anyone though - certainly not as much as getting involved in one way or another

[hvengel]

..No one with real coding skills should be making a gauge or a jet console...... make a tool that allows a modder to make dozen of the variations without having to learn code.....

This implies that making gauges requires significant coding skill. This is definitely not the case in the vast majority of gauges since these are really very basic devices. A basic functioning gauge has the following parts.

1. 3D model which is made up of a handful of 3D objects (bezel, face, pointer(s)...) and a texture. Now it could be even easier to make new gauges if there were a standard library of 3D "instrument parts" (IE. a selection of bezels, knobs, pointers...) but these are very simple 3D objects and anyone who even tried a little bit can put together this part of a gauge. The hardest part is the texture for the face which is probably 70% to 80% of the total effort to create a typical gauge and almost every new gauge will need a new texture. No coding at all in this part.

2. XML to setup the animation for the gauge pointer(s) and to interface the gauge to the property tree. For many gauges this XML is very simple and this is a pure exercise in configuration and is exactly the type of activity that a "modder" would be expected to do. I don't consider this to be coding but others may not agree.

3. In a small number of cases the property tree will not have the data needed to drive the gauge animation directly. In JSBSim, in many cases, it is possible to create FDM functions for this and again since it is XML it is more of a configuration activity than a coding activity. But in a subset of these cases it may be necessary to write some Nasal code to get the data needed into the property tree. For YASim aircraft writing Nasal for gauges is probably more common than for JSBSim aircraft. Overall perhaps 4% or 5% of new gauges will require actual "coding" skill but in most cases these will be a relatively trivial coding task.

One other point that I think applies here. We have many people here who have extensive coding skills that are heavily involved in FG activities that don't need those skills. For example, I do a lot of aircraft work (3D modeling, FDM...) because I enjoy it even though, in my professional life for the last 25 years, I have worked as a software engineer. I do FG stuff for pleasure and although I do enjoy programming I get about as much of that "fun" as I need at work. So my FG activities are to do something different for fun although on occasion I will do some non-trivial coding that is FG related like the computing gunsight stuff I did earlier this year.

Which gets us back to coding and "gauges". The computing gunsight code was needed to implement what amounts to a very complex "gauge" (IE. a lead computing gunsight) for my aircraft project. This is a clear case where significant coding skills were needed to implement a "gauge". Any framework that would have allowed a "modder" to create this device seems like it is something that is nearly impossible to setup in a generalized system/framework for gauge creation. The "computer" for the gunsight implements a fairly complex set of computations to do something that is also very specialized.

That code is now in a shared location and is setup to be used to create new computing gunsights using the property tree to configure it and to interface to it. Using this a skilled "modder" can now create new very sophisticated gunsights with no coding beyond the XML that needed to do the interfacing and animation. The animation work will be nontrivial so this will definitely require a skilled "modder". Since we have a large number of aircraft that should have computing gunsights that are currently missing this functionality (probably because creating a good lead computer is difficult) this should allow for this situation to be corrected over time by the "modders" with very little needs for the involvement of the coders.

What I am getting at this for typical gauges "modders" can and are creating these all the time and it is only very complex highly specialized gauges that require actual coding skills to implement.

[Bomber]

When was permission given to you to inhibit evolution, to dicusse and formulate change ?

WE will never have a conversation whilst your first response is to tell all and sundry that I don't understand anything.

I understand that having loads of emails and pm's in the backgrounds, that creating little cliche groups has a negative effect on stimulus.

Over the last few years I've personal seen you announce that conversations should stop, lock threads and as in this one announce yourself to the original poster in a very 'know it all' manner.

And I've just seen a thread locked in the fdm forum because the person who started calling names, couldn't stand the heat in the kitchin. (not allowed to use the real word)

I've been here years and I've not seen anything that resembles a user requirement spec....and that's the first that that should have been done 15 years ago and kept as a live document so as people have an idea of where FG is going and where they can join in.

[Bomber]

Jesus hvengal..... It was just an example...

[hvengel]

And I was just pointing out that it was not a good example of what you were getting at. My post was not intended to be disrespectful and re-reading it I don''t see anything there what should be taken as an affront. So I don't understand the purpose of your last post. I will leave it at that.

[Hooray]

When was permission given to you to inhibit evolution, to dicusse and formulate change ?

See, that's why & where you keep failing all the time: you are constantly alienating people interested in your ideas, interested in contributing - people who are actually able to turn your ideas into working features. In the last two years I have met roughly ~20-30 new contributors who managed to get me interested and involved in their projects, without alienating me. And I know this applies to others like Thorsten for example. That's the whole secret - and we tried to cover it in the article that you refuse to read

WE will never have a conversation whilst your first response is to tell all and sundry that I don't understand anything.

I don't care as much about having conversations as implementing new features.
And others have told you before, our understanding about certain things is obviously relevant - your knowledge about FDM development, and JSBSim, is much more complete than mine obviously, and you have done a tremendous job with your aircraft/FDM development - so I am going to listen to what you have to say - but whenever you start talking about things like coding (and apparently also physics), it is obvious to other contributors that you don't know what you're talking about, while that is not such a problem, it starts becoming a problem, once you are not even interested in honoring the feedback you are given. That's exactly what I meant with being "reluctant" and "resistant".

I understand that having loads of emails and pm's in the backgrounds, that creating little cliche groups has a negative effect on stimulus.

I don't know, the devel list and forum are fairly public platforms, and so is the wiki - still, there's a lot of stuff going on behind the scenes obviously. In fact, compared to the forum, the devel list would seem basically "inactive" these days otherwise. And yeah, there is a lot of talking going on that we're not aware of, myself included. I don't believe that this is going to be successful, which is why I am pretty "religious" about using the wiki, and about encouraging others to get involved in the wiki. There's some very specific examples (as in actual FEATURES) in FG, that materialized through the wiki, but also through behind-the-scenes exchanges.

Over the last few years I've personal seen you announce that conversations should stop, lock threads and as in this one announce yourself to the original poster in a very 'know it all' manner.

you are free to have whatever conversation that you deem necessary, until someone points out your language of course.
What I say is not at all authoritative, as I've told you countless of times. But you even responding to me means that there are not many others taking even the slightest interest in what you're saying, probably because of the way you're communicating. Like someone recently pointed out to me privately: the more senior people don't even bother to listen to certain people, not just you, but also others.
It's happened to most of us, and even happens to the most senior core developers once in a while. Manpower is our primary bottleneck, it's not a shortage of good ideas (or criticism for that matter)

and that's the first that that should have been done 15 years ago and kept as a live document so as people have an idea of where FG is going and where they can join in.

According to what I've seen on the T4T forums, and accoridng to what I've been told by some T4T regulars, including yourself, you are not exactly a "role model" when it comes to project management.
You may complain all day long about the shortcomings of FlightGear, the project, the developers, the maintainers and its community - but your complaints are going to have ZERO effect, unless you try to be the change you want to see. Look at some more senior posters around here, who've made fairly similar postings in their early days (like myself) - we are trying to do something about it. It's not perfect, but it seems to work to varying degrees.

You refuse to get involved in the wiki, or even just read up on how the project works, and how to CAUSE the changes you want to see, based on ACTUAL observations, not some consensus - and to any sane person following your postings, it is obvious that you are constantly contradicting yourself, even completely apart from the technical/coding side of things.

Did it ever occur to you, that contributing to the wiki would allow you to shape the project the way you want ? Much more so than making a few dozen critical postings each week ... Be the change you want to see, embrace the void and try to fill it, and working within the limitations of how the project works - that's how some of the most accomplished contributors have managed to shape FlightGear quite significantly, despite strong opposition and lack of support from more senior contributors. Words don't matter as much as actions ... signal/noise, you know. All those wiki articles are there to save people like you some time - we've been trying to write articles in a "lessons learnt" fashion, articles that we would have hoped to have available when we were newcomers criticizing the project - we didn't have any of those. But hey, we figured we could be the change we wanted to see - that's really the key here. Others may not agree with us always, but that's not the point - we are at least doing SOMETHING, until someone steps up and replaces our efforts, which is when we'll be glad to adopt a "placeholder mentality" and hand-over our "stubs"

And I was just pointing out that it was not a good example of what you were getting at.

Agreed, actually it's an extremely good example in my opinion, and I was going to add it to the "Implementing new features for FlightGear" article, if that's okay ?

[hvengel]

No problem,