Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: . Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Freitag, 21. Oktober 2011, 15:32

FSInn-Server

Hallo,

ich möchte einen FSInn-Server auf meinem vServer einrichten. Allerdings finde ich die Serverdateien nicht. Bzw. weiß ich auch gar nicht, ob der Server auch FSInn heißt oder das nur die Bezeichnung für den Clienten ist.

Ich wäre sehr dankbar wenn mir jemand einen Link zum Download geben kann und dazu eine Anleitung zum Erstellen des Servers. Die Seite des Herstellers ist leider nicht mehr verfügbar.

MfG
Florian

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Rocky« (21. Oktober 2011, 15:38)


2

Freitag, 21. Oktober 2011, 21:40

Fsinn Server

Hallo wir benutzen FSINN auf dem Server, ich hätte die Dateien für dich und könnte dir behilflich sein.

johannmarcel@freenet.de

www.v-hp.de

LG Jobi

3

Dienstag, 15. Mai 2012, 22:34

Der Server läuft sehr gut. Noch mal vielen Dank.

Nun möchte ich jedoch auch das Wetter aktualisieren lassen. Geht das auch mit der Uhrzeit, dass diese bei allen gleich ist mit den jeweiligen Zeitzonen?

Bei weather ist folgendes eingestellt:


[weather]
source=download
server=tgftp.nws.noaa.gov
dir=data/observations/metar/cycles/
ftpmode=passive

Diese Daten scheinen jedoch nicht aktuell zu sein, da der Server nicht connecten kann. Kann mir bitte jemand eines posten, dass auch funktioniert und auch mit guten Wetterdaten?

4

Mittwoch, 16. Mai 2012, 00:23

Der Server läuft sehr gut. Noch mal vielen Dank.

Nun möchte ich jedoch auch das Wetter aktualisieren lassen. Geht das auch mit der Uhrzeit, dass diese bei allen gleich ist mit den jeweiligen Zeitzonen?

Bei weather ist folgendes eingestellt:


[weather]
source=download
server=tgftp.nws.noaa.gov
dir=data/observations/metar/cycles/
ftpmode=passive

Diese Daten scheinen jedoch nicht aktuell zu sein, da der Server nicht connecten kann. Kann mir bitte jemand eines posten, dass auch funktioniert und auch mit guten Wetterdaten?

Von der Adresse her müsste es passen, denn wenn Du mal....

ftp://tgftp.nws.noaa.gov/data/observations/metar/cycles/

in Deinen Browser eingibst, bekommst Du die aktuellen Datensätze (.txt-Dateien) angezeigt, die Du auch öffnen kannst.

source=download sollte in Deinem Fall auch korrekt sein, da Du ja die externen Daten haben möchtest.

Ich kenne den Aufbau Deines Netzwerkes nicht. Aber es kann sein, dass Dir ein "active" statt "passive" helfen könnte. Probiere es mal aus.

Bei uns ist vom Original nicht mehr allzu viel nachgeblieben, sodass ein Vergleich schwierig wird. Wir haben da im Zusammenhang mit dem Wegfall der mcdu.com-Server soviel umgefrickelt und arbeiten mit mehreren verteilten Servern, die unterschiedliche Aufgaben wahrnehmen.


5

Mittwoch, 16. Mai 2012, 10:27

So wie es aussieht, hat sich das Problem über Nacht von allein gelöst.

Vielen Dank, aber ich lasse dann den ftpmode erst mal auf passive. Mal schauen, was der Server die nächsten Stunden noch so ausspuckt.
Erst bekam ich eine Meldung, dass die metarnew.txt nicht zu metar.txt verschoben werden kann, da die Berechtigungen fehlen. Durch nun scheinen sogar diese in die metar.txt eingetragen zu sein und laut Log ist nun auch alles in Ordnung. Ich habe das Log nun gerade noch mal gelöscht und warte nun die stündliche Aktualisierung ab.

Btw.: Lässt sich das Aktualisierungsintervall verkürzen?

Log:

16-05-112 12:10:00 DP3: METAR: Starting download of METAR data
16-05-112 12:10:00 DP3: METAR: Starting download of METAR data
16-05-112 12:10:07 DP3: ** METAR: Can't move metarnew.txt to metar.txt: Permission denied
16-05-112 12:10:07 DP3: METAR: Installed new METAR data.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Rocky« (16. Mai 2012, 12:54)


6

Mittwoch, 16. Mai 2012, 13:34

Ich wusste gar nichts von einer "stündlichen" Aktualisierung! Unsere log.txt wird sofort aktualisiert, wenn ein Ereignis stattfindet. Wenn ich mich jetzt einlogge, finde ich die Connection in der nächsten Sekunde im Log. Es gibt aber durchaus ein paar Merkwürdigkeiten beim FSD. So zum Beispiel bei der Übernahme von Neueintragungen in der cert.txt. Früher habe ich immer schön treudoof einmal täglich den Server neu gestartet, damit die Neueinträge der letzten 24 Stunden übernommen werden. Auf einmal war das nicht mehr nötig. Es dauert genau eine halbe Stunde, dan hat der Server das von selbst übernommen. Und keiner weiß, warum das plötzlich so war. Mag sein, dass wir da durch Rumgefrickel und die diversen selbstgebasteltelten Tools, die auf dem Server laufen und den FSD unterstützen bzw. am Leben halten, irgendwas indirekt angetriggert haben.

Ich schätze mal, dass das plötzliche Funktionieren ebenfalls durch eine internes Neueinlesen der FSD.conf ausgelöst wurde. Kann es sein, dass Du nach der Änderung der FSD.conf zunächst keinen Neustart vorgenommen hast, der nunmehr stattgefunden hat?

Wie sieht denn Dein FSD überhaupt aus? Homeserver? Windows oder Linux? WAN oder LAN? Bei WAN: Wie hast Du das P2P-Problem gelöst?

Übrigens: Noch zu Deinem vorletzten Posting, denn da tauchte ja die Frage auf, wie das mit der Aktualisierung des Wetters bei den Clients sei.

Die Clients aktualisieren selbstständig, wenn das Wölkchen im FSInn Control Panel neben dem Servernamen erscheint. Das Intervall lässt sich zwischen 1 und 300 Sekunden einstellen (Default ist - glaube ich - 5 Sekunden). Man ist natürlich leicht versucht, da den kleinsten Wert einzustellen, um ein möglichst aktuelles Wetter zu haben. Das ist aber nach unseren Erfahrungen kontraproduktiv, denn da muss dann das Netzwerk dauerhaft in diesen kurzen Intervallen 'ne Menge Daten schaufeln (die metar.txt kann ganz schön groß sein) und auch an den FS durchreichen. Das kann zu blöden Effekten führen, die u.U. zu regelmäßigen leichten, aber unangenehmen Rucklern im FS führen. Besser ist es, da 300 sec einzustellen. Entweder fällt dann dieser Ruckler gar nicht mehr auf, denn der FS hakelt immer mal irgendwo/irgendwann und ein Miniruckler alle 5 Minuten wurd da schlichtweg untergehen, oder aber die Last verteilt sich in diesem langen Zeitraum besser. Bei kurzen Intervallen dagegen kommen diese Ruckler dann richtig schön regelmäßig, was dann wirklich auffällt. Dieses Ruckeln muss nicht zwingend sein. Das hängt ein bisschen von der Leistung des Rechners ab. Es wird aber umso wahrscheinlicher, je mehr Tools von außen den FS anzapfen. Beim FS2004 konnten wir das recht gut sehen, wenn der FSNav aktiv war. Der arbeitet mit einer hohen Aktualisierungsrate bei der Übernahme von Daten aus dem FS. Sind da eine Menge Mitflieger zu erfassen und darzustellen, kommen diese Ruckler so alle 3 bis 5 Sekunden. Wird dann aber noch das FSInn-Wetter mit hoher Frequenz aktualisiert, dann braucht's erheblich weniger Flieger, um dieses Ruckeln auszulösen.

Die Frage ist nur, wie wichtig man eine absolut zeitgleiche Wetteränderung für alle Beteiligten nimmt.

Aber das sind eben alles Effekte, die beim Client zu beeinflussen sind und nicht serverseitig. Der Server holt sich das Wetter 1x pro Stunde ab. Wenn Du unter dem Link
ftp://tgftp.nws.noaa.gov/data/observations/metar/cycles/
nachschaust, wirst Du feststellen, dass auch dort die Daten stundenweise sortiert sind. Hier serverseitg etwas ändern zu wollen macht keinen Sinn. Für etwas Abwechslung in Sachen Wetter sorgt das System selbst, indem es das Wetter innerhalb dieser Stunde in einem gewissen Rahmen wechseln lässt. Dieser Rahmen orientiert sich an den eigentlichen Wetterdaten. Leichter Regen bedeutet also nicht, dass es die ganze Zeit leicht regnet, sondern dass es hin und wieder mal mehr oder weniger regnet, manchmal aber auch trocken ist, insgesamt aber ein regnerischer Wettereindruck gegeben ist. Hinzu kommt, dass man in der Regel mit relativ hoher Geschwindigeit in der virtuellen WEelt unterwegs ist und man es dadurch auch mit lokal unterschiedlichem Wetter zu tun hat.
Tatsächlich ändert sich das Wetter ja auch in der Realität nicht alle paar Sekunden. Da sind selbst 5 Minuten noch relativ schnell. Unterschiede bei den verschiedenen Clients wird man nur haben, wenn der Server nach einer Stunde neue METAR-Daten hat. Dann kann es - je nach Einstellung im Client - bis zu 5 Minuten dauern, bis es der letzte Client mitbekommen hat. Der erste kriegt es vielleicht unmittelbar mit, weil er eh gerade aktualiiert, der andere hat vielleicht gerade vor wenigen Sekunden aktualisiert und ist erst in nicht ganz 5 Minuten wieder dran.

Da muss man eben mal schauen, was individuell am sinnvollsten ist. Man sollte aber auch bedenken, dass gerade beim Onlinefliegen die meisten Piloten irgendwelche Zuatztools laufen haben, die zusätzlich auf den FS zugreifen. Und daher würde ich empfehlen, den Intervall-Regler möglichst weit nach rechts zu schieben.


7

Mittwoch, 16. Mai 2012, 19:43

Erst mal vielen Dank für die ausführliche Antwort.

Mit der Aktualisierung das war auf das Wetter bezogen, den Zusammenhang hätte ich wahrscheinlich deutlich machen müssen.
Ja, der Server wurde morgen um 5 Uhr serverseitig neu gestartet. Der FSD-Server läuft auf einem vServer mit Windows und P2P musste bei uns im FSInn abgeschaltet werden, da es sonst zu einem Crash mit den Mitspielern kommt.

Zu dem Wetter dachte ich mir, dass durch eine häufigere Aktualisierung der Metar-Daten der FSX-Fehler beim Windrichtungswechsel abgestellt wird. Da wenn man mit FSAirlines oder auch FSPassengers fliegt ist es ärgerlich, wenn man einen Overspeed durch die Fehlerhafte Programmierung des Windes bekommt, da dieser plötzlich sich um 180° wendet.

Der FSX hat ja auch schon eine Aktualisierung von 15 min. und wenn das nun eine Stunde dauert, wird sich der Effekt, denke ich, stärker negativ auswirken.

8

Mittwoch, 16. Mai 2012, 20:41

Von einem "Windrichtungswechselfehler" im FSX weiß ich nichts. Das heißt aber nicht viel, da ich mit dem FSX nicht auf einer Welle schwimme.

Aktualisierung des Wetters ist serverseitig einmal pro Stunde. Ich schrieb es ja schon, mehr geben die Quellen auch gar nicht her. Variationen in gewissen Grenzen rund um die vorliegenden Daten der aktuellen Stunde werden eben vom System eingespielt. Nur weil Regen angesagt ist, heißt es ja nicht, dass es eine Stunde am Stück regnet. Und wenn für die Stunde die Wndrichtung - was weiß ich - mit 270° und 10 kts angegeben ist, dann wirst Du bei beiden Werten gewisse Schwankungen haben - das ist ja in der Realität auch nicht anders.

Ob das nun beim FSX zu Fehlern kommt........ keine Ahnung, siehe oben.

Ich kann nur aus vielen gemeinsamen Flugstunden berichten (z.B. DWT), dass das Wetter auf allen beteiligten Rechner weitestgehend gleich ist. Wenn da jemand eben noch Regen hatte und der dann plötzliich aufhörte, dann konnten die anderen das nach wenigen Minuten bestätigen. Eben nach max. 5 Minuten, bzw. bei deren nächster Aktualisierung. Das gilt genau so für die Windrichtung und -stärke.

Nur waren wir ausschließlich mit dem FS2004 unterwegs. Da wir keine Flüge mit dem FSX unternommen haben, kann ich hier keine Erfahrungen wiedergeben.

Wieso crashen Deine Mitspieler unter P2P? P2P bei FSInn ist problematisch, weil mit dem Wegfall der mcdu.com-Resolver eine wichtige Komponente ausgefallen ist. Dies führt dazu, dass die für P2P notwendige eindeutige Adressauflösung nicht mehr stattfindet. Die Folge ist, dass eine Reihe von Daten einfach verpuffen, wenn sie über einen Client, der hinter einem Router (anderer Adress-Raum) oder einer Firewall steckt (Daten werden geblockt und verworfen) geroutet werden. Da FSInn (vermutlich aus Performance-Gründen) die Daten nicht prüft, bleibt das unbemerkt und es wird mit verfälschten Daten gearbeitet. Daraus resultieren dann aber keine Crashes, sondern lediglich ein paar unschöne Effekte wie das Springen und falsche Positionieren anderer Flugzeuge.

Crashes höchstens insofern, wenn Du damit den Zusammenstoß von Flugzeugen meinst. Das kann durchaus passieren. Beispielsweise wenn der relative Abstand eines Fliegers zum eigenen durchgereicht werden soll, aber hier einfach eine Null ankommt, weil der tatsächliche Wert an einem beliebigen P2P-Client im Netzwerk verpufft ist. Dann kommt der relative Abstand NULL. Heißt: De andere Flieger scheint am eigenen zu kleben, obwohl er tatsächlich ein paar Meilen entfernt ist. Wenn dann die Ansturzerkennung nicht deaktiviert ist, bedeutet das natürlich "Crash", und zwar zwischen Flugzeugen.

Beim Onlinefliegen sollte man auf jeden Fall die Absturzerkennung abschalten.

Dass nun unter P2P ein Rechner bzw. der FS crashen soll, kann ich eigentlich nicht nachvollziehen.

Ihr werdet vermutlich das Problem haben, dass P2P schlichtweg nicht einwandfrei funktioniert. Der Grund ist...... siehe oben! Will man es dennoch nutzen, muss man sich etwas einfallen lassen, was einen einheitlichen Adressraum schafft. Wer hinter einem Router sitzt (und das tun heute die meisten) befndet sich in einem anderen Adressraum, sodass sein Client für das Routing unter P2P nicht funktioniert, aber trotzdem verwendet wird.

Außerdem muss man sicherstellen, dass ALLE Beteiligten ihre Firewall für FSInn-P2P offen haben. Schon ein einziger Teilnehmer, dessen Firewall für FSInn-P2P dicht ist, wird bei ALLEN anderen für dumme Effekte sorgen, weil sein Client die Daten verfälscht. Auch die Daten, die gar nicht für ihn bestimmt sind.

Es hat lange gedauert, bis wir dahinter gekommen sind, und noch länger, bis wir Lösungen hatten. Diese Lösungen machen das System kompliziert - vor allem auch für die Leute, die damit umgehen sollen. Das Dumme ist, dass man diese Probleme nicht serverseitig als Admin lösen kann. Die Lösung liegt eindeutig beim User bzw. Client. Heißt: Man muss ihm die Mittel zur Verfügung stellen, aber er muss sie einbauen, konfigurieren und benutzen. Das - so unsere leidvollen Erfahrungen - klappt meistens nicht. Irgendwelche Leute hast Du immer dazwischen, die genau das nicht tun, sich dann trotzdem einloggen und bei allen anderen für Verdruss sorgen. Hier mussten wir serverseitig Wege finden, die Leute zu zwingen. Wenn man all das hinbekommen hat, funktioniert P2P einwandfrei.

Alerdings mit einer nicht unwichtigen Einschränkung, die den FSX betrifft. Er bindet nach unseren Erfahrungen einfach zu viele Ressourcen des Rechners an sich. Die Nutzer haben ihn in der Regel bis zur Grenze des Sinnvollen hochgefahren und sind nicht bereit, Abstriche zu machen. Da bleibt dann leider was auf der Strecke. So zum Beispiel hat das Netzwerksystem des Rechners nicht mehr die Priorität, die es bräuchte, um einen einwandfreien und vor allen schnellen und gleichmäßigen Dataflow zu gewährleisten. Man mag nebenbei ohne Probleme surfen und auch downloaden können, aber die P2P-Daten kommen einfach nicht mehr "just in time" an, sondern unterschiedlich verzögert, was dann auch wieder zu einem Springen der Flieger führt. Beim FS9 gibt es da weniger Probleme, ein FSX-Client kann dagegen schon mal dafür sorgen, dass bei allen Beteiligten der Spielspaß getrübt wird. Einziger Weg: Die Features des FSX massiv runterzuregeln. Aber mach das mal einem Nutzer klar, zumal derjenige, der die Effekte auslöst, in den wenigsten Fällen von diesen selbst betroffen ist.

Merke: FSX ist beim Onlinefliegen kontraproduktiv!

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »vETNH« (16. Mai 2012, 20:44)