Re: [Flightgear-devel] Online Map Server

2013-07-10 Thread Oliver Schröder
Hi Lloyd (and others),

I have disabled the map server because there are serveral issues (as
stated by Pedro Morgan).
I'm willing to host a map server, but my java script kungfu is too
limited to write a new one. If anyone is willing to rewrite the map
server I will be happy to host it.

Regards,
Oliver

Am 09.07.2013 22:22, schrieb Lloyd A. Stevens:
 I have noticed that http://mpmap01.flightgear.org/ currently shows:
 
 This page is temporarily closed. The map server is broken and needs a
 replacement.
 
  
 
 I recently set up a new Multiplayer Server(fgms) and I am also willing to
 host an Online Map Server.
 
  
 
 My server is on a multi-homed backbone.  I can burst up to 100Mb/sec.
 
  
 
 Someone will need to provide me with the necessary info, configs, etc.
 
  
 
  
 
 
 
 
 
 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 
 
 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] New FlightGear Multiplayer Server

2013-07-10 Thread Oliver Schröder
Hi Lloyd,

i wrote a private mail to you on monday but apprently it's lost in space ;)
So I repeat, your fgms.conf should look like:

# basic setting
server.name = mpserver02
server.port = 5000

# you can telnet to this port with this username/password
# and see statistics (nice cisco like CLI)
server.admin_port = 6002
server.admin_user = fred
server.admin_pass = fred

server.admin_enable = fred

# mpserver01 does this
server.tracked = false

# mpserver01 is hub
server.is_hub = false

# don't set this too high
server.out_of_reach = 100

# your only relay should be mpserver01
relay.host = mpserver01.flightgear.org
relay.port = 5000

# you don't need a crossfeed, it's only interresting for fgms-developers
# crossfeed.host = foo.example.com
# crossfeed.port = 5002

# you can add static entries of IPs which get blocked,
# but it's generally not needed and you can add them via
# the admin CLI
# blacklist = 123.123.123.123

And now the rest;

Am 09.07.2013 23:13, schrieb Lloyd A. Stevens:
 Thanks for adding my server.  I was only seeing local clients until I made
 the following change to my config file (I am guessing I was supposed to do
 this):
 relay.host = mpserver01.flightgear.org

fgms will ignore traffic comming from unknown relays and since the
multiplayer network is a star topology you should list only mpserver01
as your only relay. Currently mpserver01 is the only HUB,
Although multiple HUBs should work I have not tested a multi HUB
environment yet.
And for those interrested: Current traffic load on mpserver01 is around
10 MBit/s

 Should other fgms be told that I exist?  How would I notify them?

You (and all others) can reach all server admins with fgserver at
postrobot dot de
It's a pseudo mailing list and I try to keep the list of admins up to
date as good as I can.

 I also added the server to this list
 http://wiki.flightgear.org/Howto:Multiplayer#Servers
 Other places that need to updated for the new server:
 Link on above listed page shows Geographic locations of the servers are
 also available at Google
 Mapshttps://maps.google.nl/maps/ms?msid=213869436283721436186.000481c029e65
 3a30807cmsa=0ll=42.293564,38.671875spn=69.324015,173.144531

I also updated http://mpmap01.flightgear.org/mpstatus/


 http://mpmap02.flightgear.org/ server list shows my server as Hong Kong.

The very first mpserver02 was located in Hong Kong. I hope the admin of
this page (pigeon: wake up! :) reads this.

 http://mpserver15.flightgear.org/mpserverstatus/
 http://mpserver16.flightgear.org/ list shows my server as Kansas (but with
 correct IP address).
 http://flightgear.mxchange.org/mpstatus/ list shows my server as Kansas.
 Who should I contact to update these?
 Are there any other places the server needs to be updated?

The second incarnation of mpserver02 was located in Kansas. So this
information is also outdated. Unfortunatly all those links are
administerd by different people.

 Now that the server is active and appears to be working correctly should it
 be tracked? Should it act as a HUB?
From config file (my current settings):
 ##
 # Tracking server
 # set server.tracked = true to use it
 # only set this to true if the tracking server
 # admin allows it!
 server.tracked = false
 server.tracking_server = 62.112.194.20
 server.tracking_port = 8000
 ##
 # if set to true, fgms will act as a HUB server
 # a HUB server will resend packets received from
 # relays to all other relays
 # *only* set to true if you know what you are
 # doning
 server.is_hub = false

As long as you are not absolutly sure what you are doing you should:
- disable tracking
- disable HUB setting


 OLIVER,
 Thank you for updating the sources and pushing them to gitorious.  Even if
 I had access to do this I would have been unwary of doing it because I would
 hate to break a compile on linux since I have no way of testing it.
 
 I tested the new code on FreeBSD and decimal points are still missing in
 lines 107  113

I will check this tommorow. Unfortunatly I have no BSD to test. Perhaps
one day I have time to set up some virtual machines with different
operating systems ;)

Best wishes,
Oliver


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] New FlightGear Multiplayer Server

2013-07-08 Thread Oliver Schröder
Hi Lloyd,

I have updated mpserver01 and http://mpmap01.flightgear.org/mpstatus/
Thank you for providing me with feedback for BSD. I've updated the
sources and pushed them to gitorious so the source should compile out of
the boy now.

Regards,
Oliver

Am 06.07.2013 08:33, schrieb Lloyd A. Stevens:
 I had a bit of trouble getting fgms to build on FreeBSD 9.0.  The source
 I used was from
 
 git://gitorious.org/fgms/fgms-0-x.git
 
  
 
 ERRORS for: fgms-0-x/src/libcli/libcli.cxx
 
 /usr/include/malloc.h:3:2: error: #error malloc.h has been replaced by 
 stdlib.h
 
 Changes made to fgms-0-x/src/libcli/libcli.cxx
 
 #if !defined(__FreeBSD__)
 
 #  include malloc.h
 
 #endif
 
  
 
 ERRORS for: fgms-0-x/src/server/fg_util.cxx
 
 /usr/ports/local/fgms-0-x/src/server/fg_util.cxx:107: error: integer constant 
 is too large for 'long' type
 
 /usr/ports/local/fgms-0-x/src/server/fg_util.cxx:109: error: integer constant 
 is too large for 'long' type
 
 /usr/ports/local/fgms-0-x/src/server/fg_util.cxx:113: error: integer constant 
 is too large for 'long' type
 
 /usr/ports/local/fgms-0-x/src/server/fg_util.cxx:115: error: integer constant 
 is too large for 'long' type
 
 Changes made to fgms-0-x/src/server/fg_util.cxx (added decimal points for the 
 listed lines):
 
 if (bytes  1125899906842624.)
 
 ret_val = (bytes / 1125899906842624.);
 
 else if (bytes  1099511627776.)
 
 ret_val = (bytes / 1099511627776.);
 
  
 
 *The server is now running.*  The server is located in Los Angeles,
 California, USA on a multi-homed 100 Mb sustained connection.  This is
 my backup development server and is rarely used.
 http://ns3.galacticnet.com/stats/  Uptime is greater than 99% (up for
 461 days).  Intel(R) Pentium(R) 4 CPU 2.66GHz
 
  
 
 Logfile:
 
 05.07.2013 18:16:38 # This is newmpserver
 
 05.07.2013 18:16:38 # FlightGear Multiplayer Server v0.11.0 started
 
 05.07.2013 18:16:38 # using protocol version v1.1 (LazyRelay enabled)
 
 05.07.2013 18:16:38 # listening to port 5000
 
 05.07.2013 18:16:38 # telnet port 5001
 
 05.07.2013 18:16:38 # admin port 5002
 
 05.07.2013 18:16:38 # using logfile /var/log/fgms.log
 
 05.07.2013 18:16:38 # listening on 64.
 
 05.07.2013 18:16:38 # tracking is disabled.
 
 05.07.2013 18:16:38 # I have 1 relays
 
 05.07.2013 18:16:38 # relay mpserver14.flightgear.org:5000
 
 05.07.2013 18:16:38 # I have 0 crossfeeds
 
 05.07.2013 18:16:38 # I have 2 blacklisted IPs
 
 05.07.2013 18:16:38 # Files: exit=[/tmp/fgms_exit] stat=[/tmp/fgms_stat]
 
 05.07.2013 18:16:38 # My PID is 34144
 
 05.07.2013 18:16:38 Main server started!
 
 05.07.2013 18:53:15 New LOCAL Client: N1035G 108.228.5.67:61421
 (Aircraft/danube/Models/danube-osg.xml) current clients: 1 max: 1
 
  
 
 The IP is 64.69.45.88.
 
 If you want to add this server to http://mpmap01.flightgear.org/mpstatus/
 
 please provide me with correct values for my fgms.conf:
 
 server.name = newmpserver
 
 server.tracked = false
 
 server.tracking_server = 62.112.194.20
 
 server.tracking_port = 8000
 
 server.is_hub = false
 
 server.out_of_reach = 1
 
 #relay.host = mpserver01.flightgear.org
 
 #relay.port = 5000
 
 relay.host = mpserver14.flightgear.org
 
 relay.port = 5000
 
 # crossfeed.host = foo.example.com
 
 # crossfeed.port = 5002
 
 blacklist = 123.123.123.123
 
  
 
 ~Lloyd Stevens
 
 lists.sourceforge.net@boxisp. net
 
  
 
 (was this the correct place to post this?)
 
  
 
 (I still can’t get fgms-1-x to compile)
 
 
 -- 
 This message has been scanned for viruses and
 dangerous content by *MailScanner* http://www.mailscanner.info/, and is
 believed to be clean.
 
 
 --
 This SF.net email is sponsored by Windows:
 
 Build for Windows Store.
 
 http://p.sf.net/sfu/windows-dev2dev
 
 
 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Replacement fpr mpserver01.flightgear.org

2010-04-08 Thread Oliver Schröder
On Wednesday 07 April 2010 12:52:16 Mattt wrote:
 Oliver,
 
   To assist with my ambition for laziness, can you give me a round 
 figure for monthly bandwidth?


According to pigeon mpserver02 uses about 10-15 GByte per day.

 
Regards,
Oliver

   I may be able to assist - note, however, that my host is in AU. It is 
 on several redundant 100mb ethernet connections, though ;-)
 
 
 kyle keevill wrote:
  I may be able to do this. Gotta rumage through my stuff here.
 
  The floors still open for all.
  On Apr 7, 2010, at 5:40 AM, Oliver Schroeder wrote:
 

  Bandwidth is not easy to measure. I did some testing this morning and 
came to 
  these results:
 
  ~ 50 kbit/sec per directly connected client
  ~ 3 kbit/sec per idle relay server (same as direct connected clients for 
  active servers)
 
  With about 20 active users about ~ 650 kbit/sec over all with all known 
public 
  servers as relays.
 
  Maximum users I have seen was about 70 users.
 
  So I think a 10 MBit line will provide sufficient bandwith for current 
usage. 
  (DSL is not a good choice as the line will easily be filled).
 
  CPU and memory usage is not significant at all.
 
  I can not tell what bandwidth is needed for the mapserver, but it should 
be 
  quit moderate as well.
 
  regards,
  Oliver
 
  On Tuesday 06 April 2010 19:22:08 Pete Morgan wrote:
  
  Whats the bandwidth involved?  This is a pretty loaded server ?
 
  pete
 
  Oliver Schroeder wrote:

  Hello list.
 
  Unfortunatly my sponsor for mpserver01 will quit his contract for the 
  hardware. Thus I am in search for a replacement.
 
  If you are interrested in offering a unix host for hosting fgms (the 
  
  server 
  
  software, which does not need root access), please drop me an email. 
I'm 
  
  also 
  
  willing to continue to administer this server if you don't want to 
  
  administer 
  
  it yourself.
 
  The same applies to mpmap01.flightgear.org which is currently hosted on 
  
  the 
  
  same hardware.
 
  Any comments and especially offers are welcome
 
  Regards,
  Oliver
 
  
 
 --

  Download Intel#174; Parallel Studio Eval
  Try the new software tools for yourself. Speed compiling, find bugs
  proactively, and fine-tune applications for parallel performance.
  See why Intel Parallel Studio got high marks during beta.
  http://p.sf.net/sfu/intel-sw-dev
  ___
  Flightgear-devel mailing list
  Flightgear-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/flightgear-devel
 
  
 
 --
  Download Intel#174; Parallel Studio Eval
  Try the new software tools for yourself. Speed compiling, find bugs
  proactively, and fine-tune applications for parallel performance.
  See why Intel Parallel Studio got high marks during beta.
  http://p.sf.net/sfu/intel-sw-dev
  ___
  Flightgear-devel mailing list
  Flightgear-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/flightgear-devel
 

 
 
 --
  Download Intel#174; Parallel Studio Eval
  Try the new software tools for yourself. Speed compiling, find bugs
  proactively, and fine-tune applications for parallel performance.
  See why Intel Parallel Studio got high marks during beta.
  http://p.sf.net/sfu/intel-sw-dev
  ___
  Flightgear-devel mailing list
  Flightgear-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/flightgear-devel
  
 
  
  Kyle Keevill
  kyle...@gmail.com
 
 
 
 
 
 --
  Download Intel#174; Parallel Studio Eval
  Try the new software tools for yourself. Speed compiling, find bugs
  proactively, and fine-tune applications for parallel performance.
  See why Intel Parallel Studio got high marks during beta.
  http://p.sf.net/sfu/intel-sw-dev
  ___
  Flightgear-devel mailing list
  Flightgear-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/flightgear-devel

 
 -- 
 Cheers,
  Mattt.
 
  SpotSafe - WiFi Hotspot solution - http://spotsafe.net
 
  There are only 10 kinds of people.
  Those who understand binary, and those that don't...
 



-- 
i.A. Oliver Schröder
Systemadministrator/-programmierer
Network/Engineering IP-Services

Versatel West GmbH

Unterste-Wilms-Straße 29
D-44143 Dortmund

Fon: 0231-399-4479
Fax: 0231-399-4491
oliver.schroe...@versatel.de | www.versatel.de

Sitz der Gesellschaft: Dortmund | Registergericht: Dortmund HRB 21738
Geschäftsführer: Dr. Hai Cheng, Dr. Max Padberg, Joachim Bellinghoven

Re: [Flightgear-devel] Hurricane simulator development

2009-11-10 Thread Oliver Schröder
 MSG:  20091110/0300Z
   
  $$
  
  
  
  
  --
  Delusional Mail (http://www.delusionalmind.com)
  
  
  
 
 --
  Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
30-Day 
  trial. Simplify your report design, integration and deployment - and focus 
on 
  what you do best, core application coding. Discover what's new with
  Crystal Reports now.  http://p.sf.net/sfu/bobj-july
  ___
  Flightgear-devel mailing list
  Flightgear-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/flightgear-devel
 
 
 
 **
 This message is intended for the addressee named and may contain
 privileged information or confidential information or both. If you
 are not the intended recipient please delete it and notify the sender.
 **
 



-- 
i.A. Oliver Schröder
Systemadministrator/-programmierer
Network/Engineering IP-Services

Versatel West GmbH

Unterste-Wilms-Straße 29
D-44143 Dortmund

Fon: 0231-399-4479
Fax: 0231-399-4491
oliver.schroe...@versatel.de | www.versatel.de

Sitz der Gesellschaft: Dortmund | Registergericht: Dortmund HRB 21738
Geschäftsführer: Marc Lützenkirchen, Dr. Hai Cheng, Dr. Max Padberg, Joachim 
Bellinghoven


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Multiplayer setup on a lan

2007-10-16 Thread Oliver Schröder
Am Dienstag, den 16.10.2007, 08:56 +0200 schrieb Durk Talsma:
 Hi,
 
 Doesanybody know where I can find information on setting up a multiplayer 
 server on a local area network (LAN)? We'd like to demo the multiplayer 
 feature at the FSWeekend show in Lelystad, and we almost certainly don't have 
 an internet connection there.

There is nothing magic in a lan environment. Installation from the
sources should be pretty straight forward. Simply follow the
instructions on the webpage (http://fgms.sourceforge.net/download.php)

As far as I know, the server is only tested on GNU/Linux systems. It
may, or may not, run on other platforms.

Regards,
Oliver




-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Multiplayer setup on a lan

2007-10-16 Thread Oliver Schröder
Hi Durk,

Durk Talsma schrieb:
 
 Now, my next question was going to be how we could get a local copy of the 
 mapserver to work, but I guess that's not possible, because the mapserver 
 depends on google imagery, which is a noop with an internet connection...

You're right. The map server depends on google-map and therefore needs
an internet connection.

I've experimented with Atlas as an alternative, but it is focused on one
client. If you sent data of multiple clients to Atlas, the map jumps
from one location to antother. So it's no solution either (but perhaps
someone picks up the idea :-)

Cheers,
Oliver

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Multiplayer liveries...

2007-10-03 Thread Oliver Schröder
Hi List,

Melchior FRANZ schrieb:
 There's a TODO message in multiplaymgr.cxx that says:
 
   // A static map of protocol property id values to property paths,
   // This should be extendable dynamically for every specific aircraft ...
 
 This static list grows and grows and that's becoming a problem. I
 hardly ever take part in MP, because the amount of incoming data
 is just too big for my connection. And that's no surprise when
 even an UFO sends rotor angles, gear compression, tailhook angle,
 etc.
 
 This problem is the cause why I decided to make /sim/model/variant
 only an integer. But I agree very much with Syd that a string would
 be much better, or rather with Anmaster, that several strings etc.
 should be supported.
 
 I'm not an fgms or MP expert, but as far as I've understood the
 protocol is now relative simple. After an initial package containing
 e.g. the aircraft path, all further packages always contain all
 properties of the static list. There's no response from the clients
 necessary.

The current protocol is very simple and very static. We have a few
packet types and for every additional property we want to send, we need
to modify the sources and make sure we don't send more data than one
packet can transmit (the current maximum size of one packet is 1200 bytes).
That's one part I'm working on. The library is ready for testing in my
drawer and I'm more or less currently working to get it into working
code on the server side. But real life is in the way, sometimes. So my
progressing is slow.
The basic concecpt of my library is to write ID|value pairs to a buffer,
and the library takes care about this buffer and automatically creates
new buffers if the current buffer can not hold the data. For this, we
need a mapping for IDs to properties. This mapping should probably map
all possible properties. My idea to those IDs is: the ID encodes
automatically the space, this property consumes in a network packet in
xdr-units (4-bytes).
With this scheme, other applications know how many bytes to skip in the
packet for data they are not interrested in or have no knowledge of.
An ID1 means, the next 4 Bytes is the length of the property. For
all others ID/1 (integer division) is the length of the data.
For example, the Position  could have the ID 12, the orientation
120001, etc. Meaning the data consumes 12 bytes in the packet.
Anyone is welcome to simply do the mapping. Either via a static map, or
within the property tree itself. Volunteers, step forward.

 But this method can't be continued ad infinitum. Only the absolute
 minimum of data should be transferred, and this should be configurable
 on a per aircraft basis. I could imagine these types of data, in
 addition to the initial data package containing the aircraft path:


 
 (1) properties sent in every package without expecting confirmation
 
(a) always sent 
- position  orientation
- additional properties as configured by the aircraft
 
(b) like (a), but only start to send them after they changed to
a non-default value (zero/empty string) for the first time.
This can be predefined so that not every aircraft has to list
them all, but they wouldn't be sent when not necessary.
 
/gear/gear[0]/compression-norm
/rotors/main/rpm
 
 (3) send initially and whenever changed until confirmed
 (configurable by the aircraft)
 
   /sim/model/foo/livery=Aircraft/foo/Models/Liveries/blue.rgb

Which should be pretty simple and straight forward.

 
 Whether we can afford to transfer a livery path already with the
 current system in place must be decided by the MP gurus.

We can put the livery path into the current protocol, as an intermediate
solution. But in the long run head toward a new protocol.

Regards,
Oliver

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel