Re: [Flightgear-devel] More ideas on dogfighting

2007-05-12 Thread Gene Buckle
On Fri, 11 May 2007, Martin Spott wrote:

 Gene Buckle wrote:

  Horsepucky.  Combat in Flight Gear would _never_ be a shoot-em game.
  Virtual != Real.  EVER.  If your little linoleum lizard can't understand
  that, it's YOUR fault.  Don't nanny-state me because you can't grow a
  pair.

 Hey, thanks for providing such a nice occasion to laugh at you,


You're quite welcome.  I'll be here all week.  Please don't forget to tip
your waitress.

g.

-- 
I'm not crazy, I'm plausibly off-nominal!

Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-12 Thread Stefan Seifert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ampere K. Hardraade wrote:
 
 While development over the past few years might give the preception that 
 Flightgear is a game, Flightgear is actually meant to be a serious flight 
 simulator.  Things that go boom are cool in games, but they are also useless; 
 more so in a simulator.

Regardless of any ethical or directional questions, getting combat
simulation to work decently, would also bring improvements for serious
flight simulation:

* better and more precise multi player
* collission detection, which could make formation flight even more
exciting and realistic (you won't dare to come too close to your wing
man if you can really collide)
* a damage model with which one could train for example one-wing flight
like in the video posted here

Apart from that, the code would surely benefit from adding a different
usage pattern. This usually leads to cleaner code and better
abstraction. And of course if the document got implemented as a side
effect of combat simulation, the rest would benefit as well.

So the question would be: are these advantages (and a larger user base)
worth the increased perception of FlightGear being a game?

Nine
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGRZjZ1QuEJQQMVrgRAhbUAJ9Po9Bew/xJ5ijoGDkJ37LhSbFqIACeMqK2
2VRSSJ2bABwIUcuLdLuQ7JI=
=GRKh
-END PGP SIGNATURE-

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-12 Thread Stuart Buchanan
--- James Palmer wrote:
 I have a better idea on what is involved now for adding dogfighting to
 FG.
 Thanks to all who have given me input,.. Keep it coming.

snip

Hi James,

It is wonderful that you are so enthusiastic about contributing to the
project, and commendable that you are really thinking about what you are
doing, and discussing it on the list. However, I think it is time to add a
bit of pragmatism here that others have touched on but not really
emphasized nearly enough IMHO.

What you are suggesting is very, very, ambitious. As I understand it, you
intend to

1) Completely re-architect FG
2) Completely re-write the MP protocol
3) Add collision detection
4) Improve sub-models for munitions.

Off the top of my head, I'd say that represents something in the region of
6 man-months of full-time work, plus about the same again in bug fixing
(remember, this has to work on almost every platform known to mankind). Do
you really have an entire year to work on this for 7 hours every weekday?

The architecture document you refer to has been around for a while, and
while it offers an improved architecture for a flight simulator, it isn't
at all clear how we can separate the existing monolithic core of FG into
the different components. More to the point, as far as I know, no-one has
actually attempted to implement it, even though there are contributers
here who put many hours into FG each week.

There is also the minor issue that you aren't very familiar with the code,
having not (as far as I am aware) made any contribution to the project
before. Inevitably this means you will have a learning curve ahead of you,
both to really understand the code, and The Way Things Are Done.

I really don't want to discourage you from contributing - I am sure that
you wouldn't be suggesting this set of enhancements if you didn't have a
lot to offer the project. However, I would humbly suggest that you look
for some smaller features to implement before starting on such a large
project.   Obviously, you will need to find something that appeals to you,
but here's some random suggestions to whet your appetite:-

- Improved weather system. Currently when the METAR updates, the weather
changes instantaneously, causing control problems. A more intelligent
weather system would be of great benefit, and an interesting challenge.
- Ridge-soaring. Implementing orthographic lift and mountain waves would
enhance the gliding features immensly.
- Same aircraft MP. A nice stepping-stone towards dog-fighting would be
implementing a MP capability for two users to share the same cockpit,
allowing pilot/copilot or instructor/student

Once again, you obviously have a lot to offer to project. It would be a
great shame if this was wasted on a huge project that might not complete.

Best regards,

-Stuart


  ___ 
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today 
http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html 

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-12 Thread James Palmer

Stuart wrote:
What you are suggesting is very, very, ambitious. As I understand it, you
intend to

1) Completely re-architect FG
2) Completely re-write the MP protocol
3) Add collision detection
4) Improve sub-models for munitions.

Off the top of my head, I'd say that represents something in the region of
6 man-months of full-time work, plus about the same again in bug fixing
(remember, this has to work on almost every platform known to mankind). Do
you really have an entire year to work on this for 7 hours every weekday?

End quote:

Yes.. I am aware that Rome wasn't built in a day and that you eat an
elephant one byte (little nerd humor) at a time.
I also have an advantage that I am not alone.  I will be working on this
development with my coworker jwagner.
I am currently in the process of a more detailed proposal, and I'd
appreciate your critique (and everyone else's) when I have it complete.
I do have quite the learning curve ahead, but challenges are what keeps
skills sharp.  I think your time estimates are probably close to what it
would take.  Fortunately, we do have quite a bit of time to spend on this.
I don't want to wait for nearly a year before having anything to show, so
I'm planning to implement the change in phases.  I haven't defined the
phases in hard terms yet, you'll have to wait for the more detailed
proposal.

Again thanks to all who responded.
The dialog is much appreciated.
Regards,
Jamesw

On 5/12/07, Stuart Buchanan [EMAIL PROTECTED] wrote:


--- James Palmer wrote:
 I have a better idea on what is involved now for adding dogfighting to
 FG.
 Thanks to all who have given me input,.. Keep it coming.

snip

Hi James,

It is wonderful that you are so enthusiastic about contributing to the
project, and commendable that you are really thinking about what you are
doing, and discussing it on the list. However, I think it is time to add a
bit of pragmatism here that others have touched on but not really
emphasized nearly enough IMHO.

What you are suggesting is very, very, ambitious. As I understand it, you
intend to

1) Completely re-architect FG
2) Completely re-write the MP protocol
3) Add collision detection
4) Improve sub-models for munitions.

Off the top of my head, I'd say that represents something in the region of
6 man-months of full-time work, plus about the same again in bug fixing
(remember, this has to work on almost every platform known to mankind). Do
you really have an entire year to work on this for 7 hours every weekday?

The architecture document you refer to has been around for a while, and
while it offers an improved architecture for a flight simulator, it isn't
at all clear how we can separate the existing monolithic core of FG into
the different components. More to the point, as far as I know, no-one has
actually attempted to implement it, even though there are contributers
here who put many hours into FG each week.

There is also the minor issue that you aren't very familiar with the code,
having not (as far as I am aware) made any contribution to the project
before. Inevitably this means you will have a learning curve ahead of you,
both to really understand the code, and The Way Things Are Done.

I really don't want to discourage you from contributing - I am sure that
you wouldn't be suggesting this set of enhancements if you didn't have a
lot to offer the project. However, I would humbly suggest that you look
for some smaller features to implement before starting on such a large
project.   Obviously, you will need to find something that appeals to you,
but here's some random suggestions to whet your appetite:-

- Improved weather system. Currently when the METAR updates, the weather
changes instantaneously, causing control problems. A more intelligent
weather system would be of great benefit, and an interesting challenge.
- Ridge-soaring. Implementing orthographic lift and mountain waves would
enhance the gliding features immensly.
- Same aircraft MP. A nice stepping-stone towards dog-fighting would be
implementing a MP capability for two users to share the same cockpit,
allowing pilot/copilot or instructor/student

Once again, you obviously have a lot to offer to project. It would be a
great shame if this was wasted on a huge project that might not complete.

Best regards,

-Stuart


  ___
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up
for
your free account today
http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net

Re: [Flightgear-devel] Latest OT/OSG/SG/FG unusable

2007-05-12 Thread gh.robin
On Sat 12 May 2007 02:29, Georg Vollnhals wrote:
 Georg Vollnhals schrieb:
 

 Just as a feedback, compiled without problem with the latest
 SimGear/FlightGear CVS. Now my old framerates are back. Really a big
 difference!
 There are several strange little display errors but I can live with that
 until OSG svn is usable again.
 Gérard, merci beaucoup once again :-)
 Regards
 Georg


Hello Georg,

Thanks for your feedback.

In order to give a more precise information, which could interest everybody

That SVN version is 

entry
   committed-rev=6465
  
   committed-date=2007-04-10T11:09:38.755579Z
   
  
   repos=http://www.openscenegraph.com/svn/osg;
   revision=6465/


-- 
Gérard


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-12 Thread James Palmer

Thanks for the input Harald.

-I'm going more away from Solution #2 and more toward Solution #1.

-Yes I'm aware that I need to be aware of the ground.  I haven't given it
detailed thought yet, so the details here are still a bit fuzzy.  I plan to
consider this more when I write the proposal.  I'm not sure whether the
client or the FDM server should keep track of the ground.  If the client
keeps track of it (for himself only), then the FDM server could just keep
track of sea level for AI objects. (yes I know there are points below sea
level).
Like I said.. I haven't had time to think about it yet.

-I'm not sure about the hz that each will run at.  At first glance though, I
think your numbers may be a bit slow.  I'm hoping for better than that, but
we'll see.

-You are correct on adding all AI objects to the network.  I plan on
implementing that.

-I'm moving more away from that model, so I don't know yet how I plan to
solve that problem.

James

On 5/12/07, Harald JOHNSEN [EMAIL PROTECTED] wrote:


James Palmer wrote:

 Server Coordination:
 Some discussion on how to coordinate AI-Ballistic and AI-missile (yet
 to be created) with players was had yesterday.
 Basic Problem: Jet A is travelling at mach 2 and he has a slow
 Internet connection (200ms latency).  Jet B is approaching him from a
 direct right angle (i.e. Jet A will exactly cross Jet B's gun sight
 very shortly)  When Jet A's pilot realizes that he is about to be
 toast, he makes a hard turn, but at mach 2 he will travel
 approximately 450 feet before his slow packet reaches the server.
 This is a very simplified example, but it gets the point across.  I
 need to figure out the best way to minimize the effects of Jet A's
 latency and determine the best method of position coordination between
 players.

 Suggested Solution #1 - DFMP is server driven and server coordinated:
 The dogfighting MP (DFMP) should be server driven (thanks to Lethe for
 the insight into this direction) and server coordinated.  Clients
 should send user input information to the server and let the server
 calculate where the player is on the earth and inform the player of
 it.  The server would also be responsible for determining whether a
 collision has occured.  This is the approach taken by many of todays
 MP Internet games.

Note that in those games there is no client side to compute position,
etc, and in mono player mode the server is run on the client computer.
Since it's allways the server that do the computations the games react
the same wether you are in mono or multi player.

 Changes for this approach include :
 1-an overhaul of the MP protocol.  Currently users send a UDP message
 on their position to the server which then updates the other players
 AI-Aircraft models (I think I understand this correctly,.. if not
 someone please chime in).  Clients would now have to send user input
 information to the server.  The server would have to model the FDM of
 the craft they are using, determine its new position and then update
 the client and other DFMP players on the clients new location.  These
 calculations and updates would happen for every DFMP there is on the
 server.
 2 - a change in the client side of MP protocol to send only user
 input, and to accept new positions from the server that is driving.
 3 - the server would need additional collision detection (hit-box
 relative to the size of the craft flown)

You realize that you need to compute intersections with the terrain too
(for the fdm and other objects that you launch).



 Suggested Solution #2 - DFMP is client driven and server coordinated:
 The DFMP should be client driven and server coordinated.  Clients
 would be responsible for calculating their own FDM and position on the
 earth.  Each client would send its position information to the server,
 which would maintain a list of aircraft and AI positions.  The server
 would only be responsible for passing position information to all
 players and determining whether a collision has occurred.  To further
 reduce the effects of latency, vector extrapolation may be used to
 determine a player's position when no new information packet has
arrived.

Extrapolation is done in the two scenario because knowing the real
position of things is a special case (your sims run at 50 hz and the
server send packet at 5 hz for example).

 Changes for this approach include :
 1- Adding AI objects to the MP protocol so that gun and missile
 information can be transferred.

*Every* AI objects must be sent on the network ; aircrafts and missiles
are just one of them. On a mp server the world must be synced, a carrier
must be at the same position on all client. If I open a hangar door on
my client it must be opened on all client computer.

 2 - the server would need additional collision detection (hit-box
 relative to the size of the craft flown)

If the server computes all collisions then you need the terrain too. Or
the server computes what he can and the clients compute 

Re: [Flightgear-devel] Data change log for next release

2007-05-12 Thread John Wojnaroski
John Wojnaroski wrote:

The other thing I didn't notice mention of is the superb improvement in
ground 
type representation in YASim which finally gives us water (with
waves/swell) 
for seaplane operations and of course correct behaviour on other
surfaces for 
other types of aircraft.
   

  

I'm sure John W. will pick this up when he goes through the flightgear
source changes.




I'll have that done over the weekend, then you all can ping on me.  ;-)

JW
  

OK, here is the first cut for major changes/updates sorted by date of 
inclusion.  I'm defining major as a clearly visible attribute or 
feature of the simulation that is readily apparent to the user.  There 
were many, many changes and I still need to work my way through 
identifying the changes that were bug-fixes,  performance improvements 
(run and compile times), coding standards, etc etc.

MAJOR UPDATES
===
Air to Air Tacan
Improved soaring scenarios
Refueling capability on MP network
Use of all textured fonts on panels
Interactive/scripted control of AI aircraft
Passive mode for autopilot
Addition of fluxgate compass
Addition of GSDI for helicopters
Addtition of new MIL-STD HUD
Dynamic sun color changes
Addition to read and parase airway data files
Major improvements in taxiing and ground operations of AI aircraft
Addition of protocol for Garmin 400 series
Improved ground properties feel with YASIM aircraft
New altimetry method

I'll try to finish up the rest over the weekend.  If someone would add 
these to the wiki list

And another thing...

I've been bemused by all the discussion vis-a-vis flightgear as a combat 
simulator and am somewhat agnostic on the whole question.
As Curt noted we've already crossed over into the twilight zone.  If 
you're opposed to the idea then lets remove ALL models of military 
aircraft AND civilian derivatives and ALL operations that have a 
military/combat purpose (e.g: tacan, HUDs, air-to-air refueling, carrier 
operations, etc).  By the same token, if you are of this opinion and use 
any of these models or features your argument and position seems a 
little disingenuous.

I've not done a count by type of the aircraft in Flightgear, but there 
are a large number of military aircraft which are designed and built for 
one reason only and one reason only -- combat or combat support.  I'm 
not a big fan of selective morality -- Oh, I like to fly these 
airplanes and build the models, but...

Perhaps we provide a delete function in FlightGear.  Those who feel 
military/combat aircraft and operations are immoral can use the feature 
to remove all vestiges of the same and sleep peaceful at night knowing 
their version is safe and pure.  ;-)

And one more thing...

Flightgear is more than a game and while there are highly sophisticated 
and sound engineering elements to the code I would not classify it as a 
true flight simulator, rather within a context of lower, limited 
applications. For a *real* flight simulator one might consider:

1) an RTOS as the basic architecture,
2) improved earth model using 2nd and 4th order bessel functions,
3) 6 DOFs  that provide member bending aero data versus rigid fix body 
point mass solutions,
4) high precision input control systems with 12 or 16 bit accuracy,
5) control force feedback systems,
6) interrupt driven software/hardware interfacing, and
7) fully collimnated visual display systems

Please don't misunderstand,  FlightGear is a great piece of work and the 
collective effort of a number of bright and dedicated individuals.  Plus 
you can't beat the price! 

Well, enough of my rant.

Regards
John W.

   


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] John's position on combat simulation; Was: Data change log for next release

2007-05-12 Thread Martin Spott
John Wojnaroski wrote:

 As Curt noted we've already crossed over into the twilight zone.  If 
 you're opposed to the idea then lets remove ALL models of military 
 aircraft AND civilian derivatives and ALL operations that have a 
 military/combat purpose (e.g: tacan, HUDs, air-to-air refueling, carrier 
 operations, etc).  By the same token, if you are of this opinion and use 
 any of these models or features your argument and position seems a 
 little disingenuous.
 
 I've not done a count by type of the aircraft in Flightgear, but there 
 are a large number of military aircraft which are designed and built for 
 one reason only and one reason only -- combat or combat support.  I'm 
 not a big fan of selective morality -- Oh, I like to fly these 
 airplanes and build the models, but...

Sorry, John, this has nothing to do with selective morality - as you
allege. After reading these lines I'd say you have severe difficulties
telling the difference between flying and shooting/killing.

To make understanding it easier: Many/most of the old but also the
modern warbirds are fascinating aircraft from a technical as well as
from an aviatic point of view - no doubt. Yet this is significantly
different from actually performing the shooting at some other aircraft
or dropping bombs.

 Flightgear is more than a game and while there are highly sophisticated 
 and sound engineering elements to the code I would not classify it as a 
 true flight simulator, rather within a context of lower, limited 
 applications. For a *real* flight simulator one might consider:
[... lots of interesing features ]

Certainly not all of these features are part of FlightGear's
development goals - multi-platform portability for example excludes
using only RTOS' exclusively as foundation of the simulation.
Nevertheless you should consider that the fidelity of such a simulation
is always depending on how much manpower is available for implementing
these features. You sound a bit like a weisenheimer by judging the
goals of the FlightGear project just by features that are _currently_
not implemented.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest OT/OSG/SG/FG unusable

2007-05-12 Thread Matthias Boerner
Hallo Georg,

I have done a fresh checkout of OSG, PLIB, SimGear and FlightGear  
today at 3 pm in the afternoon. Everything compiled without a problem. 
But I don't realize a drop in frame rates. But in contrast to my last 
checkout of 24th April I get about 10-20 frames more. So I think 
everything is fine with OSG.

Regards

Matthias

On Friday 11 May 2007 22:30:06 Georg Vollnhals wrote:
 gh.robin schrieb:
  Again,
  After many research, i have found an OSG svn/cvs   version which
  suit to me, good frame rate close to that one i get with plib (plib
  with 3D clouds and shadow).
 
  That version is dated   10-04-2007.
 
  Regards

 Hi Gérard,

 as my OSG framerate has dropped from 85 to 13 I want to go back to
 the OSG version you mention.

 Can you help me and tell me what command for *svn* to use to download
 the version 10-04-2007?

 Thank you very much in advance

 Regards
 Georg EDDW

 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Radar improvement

2007-05-12 Thread gh.robin
On Fri 11 May 2007 19:13, Vivian Meazza wrote:


 Actually, the problem doesn't lie within the code affected by this
 improvement - the offending file is Instrumentation/od_gauge.cxx, and
 AFAIKS see the problem is in osg, not in our code. When that is fixed, the
 radar, improved or otherwise will work fine.

 Vivian




Vivian,

That is nice, your explanation means
that your improvement can be submitted.

Now we are confident that Martin or Melchior will give the green light.
And so everybody could get profit of that Radar improvement.

Regards
-- 
Gérard


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-12 Thread Ron Jensen
On Sat, 2007-05-12 at 11:06 -0500, James Palmer wrote:
 Thanks for the input Harald.
 
 -I'm going more away from Solution #2 and more toward Solution #1.

James,

Correct me if I'm wrong, but doesn't Solution #1 require the server to
run the FDM therefor preventing anyone but the server owner from
adjusting the FDM at all?  Also if the server owner doesn't / won't add
new FDMs we're stuck with using whatever FDMs they feel like adding?  

While this may be a good thing from a gaming perspective I believe it
would be a very bad thing from an overall open source/flightgear
perspective. There are several interesting military aircraft available
for FGFS that either aren't GPL-able or not part of the base package for
other reasons.

How will this scale when we have 20+ aircraft flying around each
spawning multiple sub-models/AI aircraft the server is also responsible
for tracking?

The number one rule for any pilot (fighter or otherwise) is:
FLY THE AIRPLANE
If you don't (can't) do that nothing else matters.  Offloading the FDM
to another computer subject to server lag is not a good idea.

Thanks,

Ron



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] A-10 update: remove NOOP settimers in radar.nas

2007-05-12 Thread alexis bory

hi,

Attached: .diff file made from  $FGROOT/Aircraft/A-10

Description: Remove NOOP settimers.


Thanks to commit,

Alexis

Index: Nasal/radar.nas
===
RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/A-10/Nasal/radar.nas,v
retrieving revision 1.1
diff -u -p -r1.1 radar.nas
--- Nasal/radar.nas 5 Dec 2006 20:55:43 -   1.1
+++ Nasal/radar.nas 12 May 2007 22:57:00 -
@@ -139,7 +139,7 @@ boreSightLock = func {
 }
 
 
-settimer(setlistener(ai/models/model-added, MPjoin), 0);
-settimer(setlistener(ai/models/model-removed, MPleave), 0);
+setlistener(ai/models/model-added, MPjoin);
+setlistener(ai/models/model-removed, MPleave);
 settimer(MPradarProperties,1.0);
 settimer(boreSightLock, 1.0);
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] John's position on combat simulation; Was: Data change log for next release

2007-05-12 Thread John Wojnaroski
Martin Spott wrote:

John Wojnaroski wrote:

  

As Curt noted we've already crossed over into the twilight zone.  If 
you're opposed to the idea then lets remove ALL models of military 
aircraft AND civilian derivatives and ALL operations that have a 
military/combat purpose (e.g: tacan, HUDs, air-to-air refueling, carrier 
operations, etc).  By the same token, if you are of this opinion and use 
any of these models or features your argument and position seems a 
little disingenuous.

I've not done a count by type of the aircraft in Flightgear, but there 
are a large number of military aircraft which are designed and built for 
one reason only and one reason only -- combat or combat support.  I'm 
not a big fan of selective morality -- Oh, I like to fly these 
airplanes and build the models, but...



Sorry, John, this has nothing to do with selective morality - as you
allege. After reading these lines I'd say you have severe difficulties
telling the difference between flying and shooting/killing.

Ooo,  I don't think so.

To make understanding it easier: Many/most of the old but also the
modern warbirds are fascinating aircraft from a technical as well as
from an aviatic point of view - no doubt. Yet this is significantly
different from actually performing the shooting at some other aircraft
or dropping bombs.
  

Ahhh, so the basis for acrobatic manuevering was...and the reason 
you need to put 9G's on your body is.  Your first point is quite 
correct, but again fly them to you heart's content and DON'T complain if 
others wish to do the same and simulate combat. That is all I am saying,

Flightgear is more than a game and while there are highly sophisticated 
and sound engineering elements to the code I would not classify it as a 
true flight simulator, rather within a context of lower, limited 
applications. For a *real* flight simulator one might consider:


[... lots of interesing features ]

Certainly not all of these features are part of FlightGear's
development goals - multi-platform portability for example excludes
using only RTOS' exclusively as foundation of the simulation.
Nevertheless you should consider that the fidelity of such a simulation
is always depending on how much manpower is available for implementing
these features. You sound a bit like a weisenheimer by judging the
goals of the FlightGear project just by features that are _currently_
not implemented.

Let's be clear, FlightGear is not a game, nor is it a simulator.  Of course, an 
RTOS precludes multi-platform portability and given that as a goal the features 
mentioned are difficult if not impossible to implement or simply so labor/team 
intensive that it is impractical to attempt without a significant financial 
investment.  But don't allude to the fact that FlightGear is a flight simulator 
any more than FS200x is a flight simulator, or X-Plane or any other PC product 
for that matter.

Regards
John W.




-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-12 Thread James Palmer

Harald,

You are correct, solution #1 does require the server to run all of the FDM
for all players in multiplayer mode.
However, I think you are incorrect about additions or adjustments to the
FDM.  When using FG in single player mode, the player has both the client
and server on the same machine.  The difference is that the UDP traffic
never leaves the machine, and the local machine only has one instance of the
FDM (therefore single player).  Feel free to add or tweak the FDM as you
please.  If it is a sound change, I'm sure whoever is maintaining the
multiplayer server will have a method/schedule to grab changes from the CVS
if they so choose.

I still have some research to do on scalability of the proposal.  On first
glance, I think (don't know) it will scale just fine.  The server is just a
mega FDM crunchin' machine.  It won't have any graphics information to
handle, just the FDM(s).  My original intent was a system capable of up to
30+ planes with full submodel capability running at once.  We'll see what I
run into as I continue to read through the core material of FG.

I agree with you that server lag is a major concern.  But I think on single
player mode (with no server to lag) it will not be an issue, and on a
multiplayer server it would yield better results than the current
multiplayer structure.

In your experience, Harald, what has been the approximate ratio of FDM vs
Graphics vs remainder code on CPU time?  Has anyone done work on clocking
the various subroutines in FG to determine this?  (Perhaps I underestimate
the CPU time required of the FDM?)

Regards,
James


On 5/12/07, Ron Jensen [EMAIL PROTECTED] wrote:


On Sat, 2007-05-12 at 11:06 -0500, James Palmer wrote:
 Thanks for the input Harald.

 -I'm going more away from Solution #2 and more toward Solution #1.

James,

Correct me if I'm wrong, but doesn't Solution #1 require the server to
run the FDM therefor preventing anyone but the server owner from
adjusting the FDM at all?  Also if the server owner doesn't / won't add
new FDMs we're stuck with using whatever FDMs they feel like adding?

While this may be a good thing from a gaming perspective I believe it
would be a very bad thing from an overall open source/flightgear
perspective. There are several interesting military aircraft available
for FGFS that either aren't GPL-able or not part of the base package for
other reasons.

How will this scale when we have 20+ aircraft flying around each
spawning multiple sub-models/AI aircraft the server is also responsible
for tracking?

The number one rule for any pilot (fighter or otherwise) is:
FLY THE AIRPLANE
If you don't (can't) do that nothing else matters.  Offloading the FDM
to another computer subject to server lag is not a good idea.

Thanks,

Ron



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel





--
James Palmer
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-12 Thread Stefan Seifert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James Palmer wrote:

 In your experience, Harald, what has been the approximate ratio of FDM vs
 Graphics vs remainder code on CPU time?  Has anyone done work on clocking
 the various subroutines in FG to determine this?  (Perhaps I underestimate
 the CPU time required of the FDM?)

You could simply run stand-alone JSBSim (http://www.jsbsim.org) to see,
how much CPU a FDM needs. I'd guess that Yasim lies in the same range.

Nine
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGRnoG1QuEJQQMVrgRAvskAJwO+nEGGYgwEDjmjTSgeQUnn1oYMgCffZuL
wA0Q57BtKtfX0itJE4YgJlI=
=9OAG
-END PGP SIGNATURE-

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-12 Thread Bill Galbraith
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Stefan Seifert
 Sent: Saturday, May 12, 2007 10:38 PM
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] More ideas on dogfighting
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 James Palmer wrote:
 
  In your experience, Harald, what has been the approximate 
 ratio of FDM 
  vs Graphics vs remainder code on CPU time?  Has anyone done work on 
  clocking the various subroutines in FG to determine this?  
 (Perhaps I 
  underestimate the CPU time required of the FDM?)
 
 You could simply run stand-alone JSBSim 
 (http://www.jsbsim.org) to see, how much CPU a FDM needs. I'd 
 guess that Yasim lies in the same range.
 
 Nine


I think that was investigated a few months ago. JSBSim FDM took only a
couple percent of the CPU, or course depending on your hardware and what you
were drawing. I don't think it's anything that you need to worry about.

BIll


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-12 Thread Jon S. Berndt
 I think that was investigated a few months ago. JSBSim FDM took only a
 couple percent of the CPU, or course depending on your hardware
 and what you were drawing.

 BIll

I didn't see that one. In any case, I just made a 200 second scripted test
run, which took 42 seconds on my 2 GHz clunker. The execution time took
about 2% of the actual corresponding real time. Also, I ran JSBSim
standalone in realtime mode, and it took about 2% of the CPU. Or, so I
thought. I watched the CPU usage when I wasn't running JSBSim, and it was no
different: still 2% of the CPU was being used. :-)

Jon


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-12 Thread Ron Jensen
On Sat, 2007-05-12 at 20:14 -0500, James Palmer wrote:
 Harald, 
 
 You are correct, solution #1 does require the server to run all of the
 FDM for all players in multiplayer mode.
 However, I think you are incorrect about additions or adjustments to
 the FDM.  When using FG in single player mode, the player has both the
 client and server on the same machine.  The difference is that the UDP
 traffic never leaves the machine, and the local machine only has one
 instance of the FDM (therefore single player).  Feel free to add or
 tweak the FDM as you please.  If it is a sound change, I'm sure
 whoever is maintaining the multiplayer server will have a
 method/schedule to grab changes from the CVS if they so choose.

I believe you missed the point.  Many aircraft are not in the CVS for a
variety of reasons(1)(2)(3), and much developement work has been done on
aircraft while flying on the current multiplayer servers.

I personnaly loathe the concept that someone has to vet and install
every change I want to make to an aircraft I'm developing if I want to
fly it with/against other people. 

I'm also concerned this seems to be a move away from everyone being on
one (or two) large multi-player networks (which makes syncing FDMs even
harder).   So no more watching others fly on mpmap software...


(1) http://www.jentronics.com/fgfs/
(2) http://home.comcast.net/~davidculp2/hangar/hangar.html
(3) http://perso.orange.fr/GRTux/tux/index-en.html


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel