Board index FlightGear Development

help required combat flight sim

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Re: help required combat flight sim

Postby Mossie » Mon Aug 29, 2011 2:00 pm

Torsten wrote in Mon Aug 29, 2011 1:00 pm:And what is your main focus in your combat flight sim? Is it more the visual effects or is it combat flying?
The latter is basically advanced aerobatics which all of our FDM are not very good at. Specially the fast maneuvers are a real challenge for any FDM. E.g., I don't think we can model a snap roll correctly, asymmetric stalls are another issue but should be doable. Basically all 'abnormal' maneuvers may be far from reality.
I am sure improvements in this area receive a very welcome from the community and there is a good chance to get answers for your technical questions.

Torsten


The sim is to focus on multi crew bomber action. So this adds in fighters, obs roles and maybe ground attack. Photo recon as well for those after action reports. It will initally focus on early WWII European front, Battle of France then on to other areas. Consideration also to WWI bomber action, but that is for later.

So FM will need work along with a few other items to make combat more imersive. Help will always be welcome, even if it is "we did that before, look here".
Regards, Gerry "Mossie" Mos
--------------------------------------------------------------------------
Mossie 3D CAD, "Prompt and Precise"
http://mossie3dcad.com/

http://ww1-aircraft.info/
Mossie
 
Posts: 111
Joined: Thu Dec 27, 2007 3:22 pm

Re: help required combat flight sim

Postby Hooray » Mon Aug 29, 2011 2:18 pm

FlightGear has already multi-crew support - this is also all working using the property tree and NASAL SCRIPTS, check out some of the aircraft to see how it is working, the wiki also has some more details.

Basically, there the property trees of several instances synchronized using the multiplayer protocol, so that different instances get to see the same views, effects and actions.

http://target4today.co.uk/forum/viewtop ... topic=1084
[8/25/2011 5:21:33 AM] Simon Morley: We're offering to change their code which they can incorporate back or not... It'd be nice if they could see the benefit of what we do but not essential


I am sure that most people can see the potential benefits of what you are planning to do, but to be truly beneficial, your changes must obviously be compatible and align well with the rest of the ongoing FG development.

Regarding anti-cheating measures:

[8/25/2011 5:23:12 AM] Simon Morley: A combat sim requires that the players are confident that cheating is not taking place..
[8/25/2011 5:24:18 AM] Simon Morley: And to achieve this some level of ' game' security must exist
[8/25/2011 5:25:04 AM] Simon Morley: Some black box element has to be in place
[8/25/2011 5:26:24 AM] Simon Morley: Imagine you're hiding in cloud but on their front end it's a clear day
[8/25/2011 5:26:52 AM] Simon Morley: It's night for you but mid day for them
[8/25/2011 5:27:26 AM] Simon Morley: Rain for you but clear day for them
[8/25/2011 5:28:12 AM] Simon Morley: You're flying with a complex damage model but opponent has non
[8/25/2011 5:29:02 AM] Simon Morley: He looks like a spit on your fe but on his is an f18
[8/25/2011 5:31:59 AM] Paul Guhl: well, this type of cheating can be prevented
[8/25/2011 5:32:06 AM] Simon Morley: I might be struggling to see past cockpit bar and your opponent not
[8/25/2011 5:32:24 AM] Paul Guhl: we can assure that sl version running in compitition mode is binary wise same
[8/25/2011 5:32:55 AM] Simon Morley: Yes but are you intending to ask fg dev to be able to do it
[8/25/2011 5:33:37 AM] Simon Morley: How would you achieve that
[8/25/2011 5:33:53 AM] Simon Morley: Not a file comparison
[8/25/2011 5:35:49 AM] Paul Guhl: as for the cheating prevention: it will be feature extension of FG, only in SL code brunch
[8/25/2011 5:36:07 AM] Paul Guhl: code is publically available ergo we don't violate any lic. obligations
[8/25/2011 5:36:28 AM] Paul Guhl: BUT we ensure that the opposite is not using some hacked binary file
[8/25/2011 5:36:43 AM] Paul Guhl: modified executable which drops our cheat prevention mechanisms alltogether


This is sort of possible to implement in FlightGear, just by moving the FDM logics out of the client-process and do all FDM/damage calculations on the server-side and then only propagating the results to the client for visualization.

There is a document available detailing the architectural modifications necessary to do that here: http://wiki.flightgear.org/images/1/1e/ ... ecture.pdf

There are also several ideas to actually implement this. Most of them based on using the internal property tree for exchanging variables with a server-side property tree. This would make it possible to centrally manage certain "crucial" properties and regularly update/re-compute them using a server-side FDM process:

http://wiki.flightgear.org/Distributed_ ... FlightGear
http://wiki.flightgear.org/Remote_Properties

This would make the current multiplayer protocol obsolete.


[8/25/2011 5:45:05 AM] Simon Morley: Your responsibility is to not use fg code in commercial use...
[8/25/2011 5:45:34 AM] Simon Morley: Its also to keep open any changes you make to fg code
[8/25/2011 5:45:34 AM] Gerry (Mossie) Mos: effectively we are asking to extend FG to inculde secure 3D, and secure combat operations, with anti-cheating facilities.
[8/25/2011 5:46:11 AM] Simon Morley: But your black box isnt fg code... And so isnt a part of gpl licence


This is correct, and obviously such a central "property tree server" could also be easily closed-source if necessary, as the GPL would be circumvented.


[8/25/2011 6:01:31 AM] Paul Guhl: i'm working out the ugly build process for FG. it's nearly complete for windows and just started on linux
[8/25/2011 6:01:42 AM] Paul Guhl: building fg might keep me busy for a day or two
[8/25/2011 6:02:07 AM] Paul Guhl: anyone tried FG ? first off suggestions and change requests?
[8/25/2011 6:04:28 AM] Paul Guhl: @All: we now know what we have. We should work out a prio ordered list of features to develop


Just FYI: the FG build process is much less ugly than it used to be, it now uses cmake which makes many things much easier.
Agreed on the priority list, we could then help you find some answers.

[8/25/2011 6:05:19 AM] Paul Guhl: from developer point of view it might be a good idea to integrate the gui code and give FG a true gui framwrok with graphics, to give it 2d face
[8/25/2011 6:51:34 AM] Paul Guhl: gui code i would totally replace by my library


This is a long-standing issue, check out the wiki where you can find links to various discussions on replacing FG's built-in GUI with something better: http://wiki.flightgear.org/OpenGL_GUI_RESOURCES
http://wiki.flightgear.org/Proposals:GUI_related

You can probably also find more discussions in the FG devel list archives.


4. Method of building and getting plane in game is poor or not there at all, this method will be critical to get people on board


this should be possible by re-using FlightGear itself: FlightGear is internally already able to process all important file formats, so you could probably hack FlightGear to support a different startup mode so that it can become an editor for creating cockpit panels, instruments and such - possibly even GUI files (dialogs) etc.

This should be quite possible to do and much easier than creating something from scratch.

[8/25/2011 6:11:22 AM] Gerry (Mossie) Mos: 5. A viewer that allows testing of models and thier animation outside the game, with abbility to see the model hirarchy, so we can see where corrections are required.
[8/25/2011 6:12:09 AM] Paul Guhl: good thing, gerry, would you put the issue into bugzilla?
[8/25/2011 6:12:17 AM] Paul Guhl: we can give the tasks the prio then


You can use/hack osgviewer here.

[8/25/2011 6:13:04 AM | Edited 6:13:19 AM] Paul Guhl: FG has a model viewer already but probably without tree view for the properties
[8/25/2011 6:16:32 AM] Paul Guhl: btw, not only FG features 3d cockpit, but it is also clickable and connected to the game events


This is all working via the property tree (see $FG_ROOT/Docs and the wiki)

[8/25/2011 9:50:09 AM] Paul Guhl: what is most badly needed on FG side, what should be the next feature to come
[8/25/2011 9:53:19 AM] Kevin: we need some kind of battle plan...a "laymans" list
[8/25/2011 9:53:43 AM] Paul Guhl: basically, put and good ideas to the bugzilla
[8/25/2011 9:54:10 AM] Paul Guhl: then we can go over the list and just pick most attractive and most important tasks to become the next steps


Yes, and maybe focus on the less controversial features in the beginning ? ;-)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: help required combat flight sim

Postby Bomber » Mon Aug 29, 2011 3:29 pm

I've a question...

Is there a very basic JSBsim FDM... to help me understand the very minimum of information that's needed..

In fact just enough to make it sit on the runway... no really flight capability at all... no fancy nasal code.. just the 3d model..

Simon
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1934
Joined: Fri Dec 14, 2007 7:06 pm
OS: Windows XP and 10

Re: help required combat flight sim

Postby Hooray » Mon Aug 29, 2011 7:48 pm

In response to: http://target4today.co.uk/forum/viewtop ... topic=1071

2) Terrain: my initial probings into this haven't shown any clear path to being able to create or edit "scenery', as they call it. That's worrying. Simply put, the old feature list for terrain needs to be supported and terrain needs to be editable to bring it in line with any past era.


http://wiki.flightgear.org/Howto:_Create_custom_scenery

In general, FlightGear supports the use of "standard" GIS tools such as GRASS.
But there are also a number of custom FG-specific tools such as FlightGear Scenery Designer (fgsd), taxidraw, and terragear (the FlightGear scenery compiler).


3) Graphics; is Flight Gear a step back to older technology (see Strike Fighters), or can this support shaders, bump mapping, texture atlases and the new(er) graphic standards coming online with IL-2/CoD, A-10, etc.


FlightGear does support shaders, it also has a very powerful "materials" system that can be used together with shaders.

http://gitorious.org/fg/fgdata/blobs/ma ... ME.effects
http://wiki.flightgear.org/Howto:_Use_t ... n_aircraft
http://wiki.flightgear.org/Howto:_Shade ... FlightGear
http://wiki.flightgear.org/GLSL_Shader_ ... _Resources
http://wiki.flightgear.org/Shader_requests

4) Flight Models: haven't been able to find any source data for any flight models for any planes yet. So, the same questions remain. Will Simon be able to port his plans (re: Spitfire) into Flight Gear? Is this FG robust enough for the levels of detail we want?


FlightGear itself uses OSG and it should be able to deal with even complex geometry, but conversion to FG can sometimes be difficult to get right.

5) Combat elements: this seems to be purely in Paul's lap, but some reassurances are needed: how confident is Paul in being able to write, basically from scratch and from the floor up, all elements of ballistics and weaponry (from basic lead bullets to smart bombs and radar technology and countermeasures)?


no need to write these things from scratch, there are various parts of FG that all provide support for many of these features to a certain degree, in fact the AI system provides supports for both ballistic objects, as well as remotely driven AI objects - so that more complex weapons can be completely implemented in scripting space or by having a dedicated controller system implemented in C++

Most of this should be fine to implement in scripting space.

6) Flight systems: FG already has its own list of systems to "link" to. Is this list exhausive enough for a combat sim? Does it support the various engine types, hydraulics, fuel, oil, heat, manual/auto systems, etc.? Bailouts?


no, it doesn't - and it certainly isn't exhaustive enough for your needs, but creating new systems, avionics and instrument types is fairly straightforward to do.

For instruments, basically all you need to do is to derive a class from SGSubsystem/FGInstrument and then implement the class.
There are plenty of examples in the FGFS source tree.

For cockpit instrumentation please see $FG_SRC/Instrumentation: http://gitorious.org/fg/flightgear/tree ... umentation

For aircraft systems, please see $FG_SRC/Systems: http://gitorious.org/fg/flightgear/tree ... rc/Systems

Please note however that most of the code in Systems can be considered depreceated, this is largely because most users have found that using Nasal scripting is more flexible and more powerful than implementing configurable systems in C++ space.

So many more complex systems (like hydraulics, electrical etc) can be more easily and more quickly implemented and maintained in scripting space. You can find numerous examples in the FGFS aircraft folder ($FG_ROOT/Aircraft): http://gitorious.org/fg/fgdata/trees/master/Aircraft

There is also an increasing number of instruments that are just implemented in scripting space using Nasal scripts.

7) Online support: I see more stuff for AI than I see for supporting MMOG. Again, worrying. Is it possible? Is it feasible? What are the player/load limits? What about cheating/griefing countermeasures?


The AI system is just very well documented and being actively developed.

The multiplayer component is not currently under active development, but there are various features being planned, you may want to have a look at these links:

http://sourceforge.net/projects/fgms
http://wiki.flightgear.org/Howto:_Set_u ... yer_server
http://wiki.flightgear.org/Distributed_ ... Simulation

Basically, fgms (fg multiplayer server) is a fairly simple implementation of a multiplayer server for FlightGear.

It is expected that the fgfs multiplayer system will eventually be completely revamped or even replaced by the ongoing DIS/HLA efforts: http://en.wikipedia.org/wiki/High_level ... ulation%29
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: help required combat flight sim

Postby Bomber » Mon Aug 29, 2011 8:01 pm

anyone had any problems with METRIC inputs into JSBsim ?
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1934
Joined: Fri Dec 14, 2007 7:06 pm
OS: Windows XP and 10

Re: help required combat flight sim

Postby Thorsten » Tue Aug 30, 2011 7:26 am

After sleeping things over...

I basically have my hands rather full working on an integrated weather system, and there are plenty of things on the to-do list like working out the math just how to make clouds interact realistically with terrain elevation. However, I don't mind committing some of my time to help other projects along if it's in my area of expertise (theoretical physics, complex systems, AI,...). But since my time is valuable, I do the same which probably every other person in this forum does who has ever done more involved development work - I evaluate what you propose according to several criteria to see if it makes sense to spend my time doing it. I do so because I don't like spending two months doing something to see the collaborator walk away (been there, done it) or to see a project descending into chaos (seen it, haven't liked it). My criteria are in particular:

Do you have a clear idea what your project involves?

It seems to me you do - you're talking sense to me when you talk about damage model and flight model, it makes sense to me that you'd like to be able to modify the terrain to go back to the 1940s, so you obviously have thought about the problem sufficiently.

Do you have a clear idea what is already there?

My answer to that is a 'no'. You make a great deal of A flight sim doesn't take into acount damage with regards it's FDM.... simply because in a flight sim damage isn't that all encompassing as in a combat flight sim.., but that's simply not true - JSBSim couldn't care less if it simulates an intact or a damaged plane - it computes movement based on forces and coefficients - if you alter the forces and coefficients to agree with those of a damaged plane, then you get the behaviour of a damaged plane.

The only relevant question is - can you do this at runtime. The answer to the question is 'yes', as the Vostok model has clearly demonstrated - the behaviour of the TDU is radically different from the behaviour of the carrier. So all you need is a damage model which alters coefficients in a JSBSIm FDM at runtime whenever the code decides a hit has taken place. The damage model itself doesn't need high computing power, it'd be basically a table that tells how to alter coefficients based on where the hit was.

As for system failures - there are many planes which support random failures of, say, the hydraulic system (the SenecaII is an example with a rather sophisticated failure simulation). Naturally, the same system can simulate bullet damage to the hydraulic system.

Flightgear also has a submodel system which allows to drop ballistic objects with initial conditions. That's, among other things, bombs and bullets. There is also an event generated by the impact. Several models have animations of blast clouds and/or craters - not really high visual quality, but the principle is there. I know how to do all sorts for clouds - I sure also know how to do blast clouds... As the Nellis bombing range AI scenario demonstrated for the first time, plausible damage on targets can be visually simulated. Flightgear also has an existing wildfire system - so firestorms caused by incendiaries can be simulated.

Another part of a WW-II sim would be AI opponents - AAA, fighters, ... As the bombable script demonstrates, these can be done well in scripting space (so far, with limited AI, but that can be improved).

As for multi-crew support, that has existed for a while (I think the 747 is an example,... never used it myself though).

In fact, as far as I see, all components are basically somewhere - some rather sophisticated, some rudimentary, to be much improved, but it's not empty space. As you quite correctly deduced, bombing of civilian targets are not what many people want in Flightgear (which is why nobody has brought all these things together so far), so your final product needs to be some fork/mode. But as Hooray said, it makes sense to keep the amount of stuff to be forked to a minimum. A damage model for instance can well be used for birdstrike in civil aviation.

Will it help Flightgear?

I don't want to commit my time to two different pieces of code - so ultimately I have made a decision that I'm developing for Flightgear and not for Crazy Aviation or any other project. So, I'm interested if there is a net gain for Flightgear to be seen. Dependent on just where you fork, that will be there or not. Since you talk about stripping to the core and rebuilding, my preliminary assessment is that in your plan as proposed, there will not be a gain for Flightgear.

Will my voice be heard?

Naturally, I don't just want to be coding slave - if I am to commit my time, ideas and work, then I want to get to shape the project to some degree in return. The answer to that question is again a clear 'no' as the discussion about the mouse control has shown to me. This doesn't seem to be about discussing and finding an agreement which suits everyone, this is about doing things your way, and that's not up to discussion.

So, with three 'no' and a single 'yes', I wish you the best of luck. As I said, I find many aspects of the problem interesting and would work (sometimes even have worked) on them, but I don't see this going into a direction I'd feel comfortable with. Which is why I will remove myself from this thread.
Thorsten
 
Posts: 11106
Joined: Mon Nov 02, 2009 8:33 am

Re: help required combat flight sim

Postby Hooray » Tue Aug 30, 2011 12:21 pm

Thorsten wrote in Tue Aug 30, 2011 7:26 am:As for multi-crew support, that has existed for a while (I think the 747 is an example,... never used it myself though).


Just to add to this, please see: http://wiki.flightgear.org/Dual_control for documentation on how to set up and use dual control.
There's more detailed info available here: http://www.gidenstam.org/FlightGear/DualControl/
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: help required combat flight sim

Postby Bomber » Tue Aug 30, 2011 12:33 pm

Torsten... everything you've said seems reasonable, it's your hobby afterall.

I'm sorry the worded ripped offended you... it was intentionally used so as to gauage the response, and to forewarn that the intention isn't just to 'bolt on' a combat element to Flightgear.

Flightgear remite is to 'do it right'... well so ours and bolting on a combat element isn't right...yes I'm sure it can be done but if a combat sim isn't built from the base up then the seams will show.

With regards the FDM's... There has to be standards, a combat sim can't have one plane using one type of FDM and another plane a different type, so a descision had to be made prior to coming here that we're to use JSBsim as the core....

We also looked at how JSBsim was being used and how it could be tied into a damage model and decided it was best to start again with it... It's a coefficient build up aproach (as you know) and using AoA as it's core variable, forces and moments can be calculated factoring in damage...

I've rewritten the Spitfire's FDM from the bottom up... it looks nothing like what been seen before... In principle it should work, now with help it'll take me a couple of days to put in place, without help months of trial and error... it don't matter to me it's my hobby afterall.

Now with regards the mouse.... a discussion that suits everyone ?

We're an old team... been going years and mouse control for piloting was thrown out a long time ago..

I brought the mouse issue up deliberately to gauge the response and to lay down a marker... We'd like help from existing FG community, we think we in turn will be able to contribute to the FG community in a positive way, we hope we can all get along and there not be a 'them and us'... but we're not bringing all out previous descisions to the FG community to be discussed and eventually ratified when it suits everyone here or 'help will be hard to find....'

We want to get things done, not debate about it for the next 3 years.

We expect resistance to change, it's natural. But to hold a gun to our head over the mouse issue seems a little extreame.

I hope I haven't offended you, I said T4T won't use mouse control for pilots, now that's not to say that FG can't use mouse control now or in the future with any code additions we bring.

I hope that you watch us as we develope more using the core FG code, and after a while come foreward with advise and suggestions, which we do value.

Regards

Simon
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1934
Joined: Fri Dec 14, 2007 7:06 pm
OS: Windows XP and 10

Re: help required combat flight sim

Postby Thorsten » Tue Aug 30, 2011 1:37 pm

Now with regards the mouse.... a discussion that suits everyone ?


Well, speaking for my part, yes. You're here asking for help from the Flightgear community. Help is hard to find in the first place (that's a fact, not a threat - there are calls for volunteers for many different projects that go unanswered). So consider from my perspective:

You're planning to fork in a substantial way. The difference for me is - as long as what you're doing is Flightgear, I will care that my own development work (integrated weather system) runs fine on your system because I develop for Flightgear. If T4T is off to the degree that I'd have to download and compile different code, then I won't care that my weather system runs (it may or may not, dependent on what you do to the environment) - it has become your problem. Not because I am mean, but because I don't have the time and inclination to maintain compatibility to two different development branches. Whenever you develop using a different repository, you are 'them' and we are 'us'. We can be a friendly 'us' and 'them' as between Flightgear and JSBSim, we can exchange code, people can be part of both projects and maintain compatibility and work together - but the basic fact is that there is 'us' and 'them', and (probably like many others) I feel responsible for my part in 'us' but not for my part in 'them'.

With regard to mouse control, you're proposing software I won't be able to use. Naturally, my degree of interest just dropped 90% - again not because I am mean, but because I am less intersted in something I won't be able to use. If you ask a question I happen to know the answer to, I'll still answer, but I'll certainly not actively look for solutions to your problems or information you need.

That's not resistance to change, that's not holding a gun to your head, that's simply cause and consequence.

I'm not claiming to speak for the Flightgear community as such, but I'm prepared to guess that many people think in a similar way. This community is far more likely to get involved if you involve it - and that'd mean opening your previous decisions for debate - than if you ask people to get involved with a project of your design which is no longer up to debate (speaking of resistance to change...). Again, that's your call, I'm not threatening in any way, I'm simply trying to explain how things (according to my best understanding) are and what the likely consequences of your project design are. I don't mean to imply that I or others would actively block you if you're not doing it 'the Flightgear way' and hold information back. I hope that is sufficiently clear.

I hope I haven't offended you, I said T4T won't use mouse control for pilots, now that's not to say that FG can't use mouse control now or in the future with any code additions we bring.


Well, you haven't offended me, you have just shown to me that I don't want to be part of your project - no hard feelings from my side.

As for FG using mouse control in the future, it's there for a reason and it's unlikely to go away for the same reason, so I am not and was never worried.
Thorsten
 
Posts: 11106
Joined: Mon Nov 02, 2009 8:33 am

Re: help required combat flight sim

Postby Bomber » Tue Aug 30, 2011 1:50 pm

Thanks for your reply Thorsten it's seems a reasonable attitude....
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1934
Joined: Fri Dec 14, 2007 7:06 pm
OS: Windows XP and 10

Re: help required combat flight sim

Postby Hooray » Tue Aug 30, 2011 2:05 pm

Bomber wrote in Sun Aug 28, 2011 4:21 pm: in ripping the present FG system down to it's core and then rebuilding it with a slant towards combat flight sim..
I'm sorry the worded ripped offended you... it was intentionally used so as to gauage the response, and to forewarn that the intention isn't just to 'bolt on' a combat element to Flightgear.


Well, you know - the thing is we get to see new forum members posting interesting "project ideas" here every month, sometimes even several times per week. And we know from experience that "ripping FlightGear down to its core and rebuilding it" isn't going to happen that easily, it's not necessarily because of objection from the community - quite the contrary, sometimes people actually post ideas that everybody agrees would be great additions to FlightGear, ideas that would quite obviously involve tearing down some major subsystem and replacing it with something better.

Really, FlightGear is where it is now after 10+ years of ongoing development, many contributors (especially core developers) are long term contributors who have contributed to FlightGear for several years.
Still, FlightGear is a complex piece of software and there is probably not a single core developer who is familiar with ALL of FlightGear (features, code etc).


This is not to discourage you, but what you are proposing is a huge undertaking - especially if your strategy is to "tear down & rebuild" (honestly, apart from that I consider it perfectly possible and reasonable).

Don't get me wrong, I don't know how many skilled C++ developers you guys have at your disposal, nor do I know how many of you guys are familiar with advanced maths, physics, computer graphics and 3D simulation and OSG in particular, yet all long-term FlightGear users know for a fact that there is usually a short supply of C++ developers, knowing not only how to program in C++, but also familiar with 3D graphics, OpenGL/OSG programming and many other aspects that are important when creating/developing a simulator.

On the other hand, we have numerous people here contributing to the FlightGear base package, i.e. contributing to the platform that the FlightGear core (and thus its developers) provide - that they provide for others to build upon.

No matter if it's scenery, aircraft, AI scenarios or whatever: many things that were originally never planned to be supported, are implicitly supported because of the lose coupling between highly configurable and flexible systems.

So we are really standing on the shoulders of giants here, because we are now -after 10+ years- in the position to create significant new features within the constraints of the FlightGear base package, without even touching the C++ source code at all - simply because FlightGear has become so flexible and extensible.

All of this became possible by some important architectural decisions, such as for example the use of XML and plain text files for pretty much all configuration files in FlightGear (and thus open file formats in general), a publicly accessible tree of state variables that can be easily inspected and modified at runtime (the property tree), without any sort of obfuscation taking place - similarly, the decision to embed a scripting language that can be used for scripting the entire simulator was another important decision.

So I guess you see where I am coming from: new people now asking to "tear down & rebuild" the whole thing, or people asking to introduce DRM-like measures into FlightGear (content protection) are of course not going to receive a very warm welcome ;-)

Again, I consider what you want to do perfectly possible, but I advise you to rethink your strategy: your decision to build upon FlightGear to create a combat simulator illustrates an admirable degree of foresight and experience that many other people with similarly ambitious ideas lack, but announcing to "rip out parts" and rebuild the whole thing is very unlikely to happen anytime soon.

And like I said before: this is not necessarily because we don't want to see this happen: you could probably talk to any core-developer and each of them could tell you that there are a number of parts that SHOULD be ripped out and replaced eventually (i.e. such as some legacy code), but more often than not, things are simply not as easy as they may appear at first glance.

If you take a look at the mailing list archives or at the wiki, you'll certainly find plenty of things in the fgfs source code that everybody agrees should be replaced eventually. The FlightGear multiplayer system is just one example, and the GUI was previously mentioned - just to name two things off the top of my head.

And if people who have experience working with the code for a number of years refrain from making some important changes, you may want to re-consider your strategy.

After all, this is all "for fun" - it's an open source project, so it should be "fun" and enjoyable.

Maybe, there are some "rock star" C++ developers among you that can fix FlightGear and contribute in significant ways fairly quickly, even if that were the case, you'll have a better chance of getting your code upstream (if that really is your goal) by coordinating your plans with the fg core developers and asking for recommended paths to proceed.

And getting your code contributed back is obviously a good idea because it will be much less of a maintenance burden for you guys if your changes become part of the mainline.


Ultimately, this being open source, you don't need the approval of anybody - as long as you obey the requirements of the GPL, but rest assured: it will be much easier to deal with the FlightGear community and to get help if you play it "nice" and this very help will be very much needed in the beginning.

Suggesting "drastic" changes is all neat and dandy, but after familiarizing yourself with FlightGear you'll probably see quickly that it doesn't really need drastic changes at all:

We have witnessed this in the "Local Weather" project, you could say it now *optionally* replaces the old system, but to work properly it only needed a way to switch off the old code - which just involves setting a bunch of properties (variables) from a Nasal script. There was no need to completely remove the legacy code, it was just made optional by setting a switch at runtime.

Similarly, the bombable script leverages hard-coded C++ code for instantiating AI models dynamically - but the objects are controlled from scripting space.

So if you are looking for the biggest bang for the buck, then using the Nasal approach is certainly a worthwhile path to pursue - simply because you can get started doing the interesting stuff right away, there is no need to code for several weeks or even months before you get to see interesting results.

During that time your C++ developers can prioritize where they want to contribute to fgfs and what they want to change/add, coordinating their plans with core developers. For example, the JSBSim project has always been very responsive when it came to accommodating new feature requests originating from community members.

Of course, once you find that some things cannot be done from scripting space, you'll still need to enhance the C++ code and make the necessary modifications.

But if your situation is in any way similar to FlightGear's situation, then you'll probably have more potential artwork creators (modelers, scripters etc) than experienced C++ developers available ?

And if that's the case, then you'll find the Nasal route very much satisfying and rewarding - because your artwork folks can get started creating artwork, scripts and content right away, while your C++ developers could work on improving the underlying interface and required hooks.

The good thing here is that we have plenty of code snippets that people could use to borrow code from, in addition to some good documentation in the FlightGear wiki.

Combining existing FlightGear systems in novel ways, adding new code to them and adding some new systems and scripting hooks is certainly MUCH easier than a major redesign effort.

In the case of the Local Weather project this was the successful path - still, that doesn't mean that you can't re-implement certain parts in C++ space, like it is currently being done (to improve performance).

You are in the lucky position that we have already a handful of related features and scripts available, so it would be just a matter of combining existing stuff and determining the limitations in order to improve things, flug's bombable script ("script" is an understatement actually) is not only well-commented but also comes with a bunch of files such as todo lists, readme files and plans for the future.

Finally, I second Thorsten's final statement: Speaking as someone who is quite obviously also interested in your project, I am myself also much more interested in supporting such an effort if I can see your work being directly useful and usable by the core FlightGear project, that includes acceptance by the fgfs core developers.

Which implies -at least to me- that you create a topic branch at gitorious to make it easy for everybody to track your work.

If your conclusion really is that you need to re-architect most of FlightGear, then I'd suggest to have a look at the Combat Simulator Project (CSP) instead:

Image
http://sourceforge.net/projects/csp/
http://sourceforge.net/apps/mediawiki/c ... =Main_Page
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: help required combat flight sim

Postby statto » Tue Aug 30, 2011 9:57 pm

I've often thought of what it would take to make FlightGear a combat simulator.

I loved to play Sierra's Red Baron growing up. If you could make FlightGear return the result of a flight to a 'launcher' program similar to the FlightGear startup program, i.e. "landed safely with % kills", "shot down", "crashed", et cetera, I don't think it would be all that hard to modify the main FlightGear package to work within those constraints.

Basically, adding features to FlightGear (through planes/custom scenery) and then calling those features from the command line through a custom program versus creating a separate program based on FlightGear code.
Custom Scenery available from http://www.stattosoftware.com/flightgear
statto
 
Posts: 2112
Joined: Fri Jan 25, 2008 9:57 pm

Re: help required combat flight sim

Postby Hooray » Tue Aug 30, 2011 10:21 pm

statto wrote in Tue Aug 30, 2011 9:57 pm:I loved to play Sierra's Red Baron growing up. If you could make FlightGear return the result of a flight to a 'launcher' program similar to the FlightGear startup program, i.e. "landed safely with % kills", "shot down", "crashed", et cetera, I don't think it would be all that hard to modify the main FlightGear package to work within those constraints.

Basically, adding features to FlightGear (through planes/custom scenery) and then calling those features from the command line through a custom program versus creating a separate program based on FlightGear code.


I think you are making this more complicated than it needs to be: even without modifying the FlightGear core you could already provide some form of "performance report" evaluating a mission. flug's bombable script is basically already doing this, just by printing to the console window. But it could just as easily show a summary of kills, hits and so on by using an XML dialog instead.

Internally, flug's bombable script maintains already a log of such data - so it would just be a matter of adding some Nasal processing code and an XML dialog to the package so that an evaluation can be shown to the user.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: help required combat flight sim

Postby statto » Tue Aug 30, 2011 10:32 pm

Hooray wrote in Tue Aug 30, 2011 10:21 pm:I think you are making this more complicated than it needs to be: even without modifying the FlightGear core you could already provide some form of "performance report" evaluating a mission. flug's bombable script is basically already doing this, just by printing to the console window. But it could just as easily show a summary of kills, hits and so on by using an XML dialog instead


Possibly - but if you call FlightGear from an external program which parses this data, you could in effect make something of a 'game'. The external program could limit selectable airplanes to a specific time period, allow for pilot tracking, control for WWII-era scenery by using a different folder than normal, et cetera.
Custom Scenery available from http://www.stattosoftware.com/flightgear
statto
 
Posts: 2112
Joined: Fri Jan 25, 2008 9:57 pm

Previous

Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest