Rakuzard

Danke für das Feedback! :) Naja. Das wäre ja nicht ganz uneigennützig. Denn so, wie ich mir das gerade vorstelle, können wir das auch wunderbar im Geschwader brauchen. :) Damit meinte ich, dass die Werte dafür schlicht noch nicht angezeigt werden. Auch so Späße wie Optimum Cruise Altitude werden schon ausgerechnet, nur noch nicht angezeigt. Hmmm. Höhe gibt der Nutzer eh an. Geschwindigkeit wird bisher immer ausgerechnet, aber eigentlich ist eine Möglichkeit zum Überschreiben der Geschwindigkeit nicht schlecht. Man will nicht in jeder Situation immer kurz vorm Stall fliegen...

Ja. :D Das unterstütze ich. Aber davor will ich noch die F-5 und die UH-1 fertig kriegen (auch wenn die beide quasi parallel laufen). :doh: Ich sag ja, ich seh den Wald vor lauter Bäumen nicht - danke! Welche denn? :D Werde ich nicht machen. Ich weiß was du meinst und was du möchtest. Mit einer Exportschnittstelle ginge sowas. Dann müsstet ihr euch nur ein Tool basteln, was die exportierten Daten einliest und euch in eine MDC baut. *meld* Dauert nur 5-10min. Kann man ganz gemütlich in der Mittagspause machen. Oder ich denk mir am Wochenende etwas komplexere Flüge aus, speicher den Flugplan ab, lade den Flugplan Montags wieder mit aktualisiertem Wetter (das Wetter auf unserem Geschwaderserver ist tagesaktuell) und speicher mir die MDC. Steht eigentlich schon im ersten Post :P Prototypenphase ungefähr von August/September 2016 bis März 2017 - circa Anfang Dezember 2016 hab ich das intern im Geschwader 'veröffentlicht' kompletter Neubau der GUI/des Frontends von Mitte März 2017 bis Ende Juli 2017 seit August 2017 Wartung, Bugfixing und Featureentwicklung In der Prototypenphase war das noch mein "Mittagspausenprojekt", weil ich da auch noch sehr viel Zeit investiert habe, einfach nur Werte abzulesen. Aber mittlerweile ist das ein Ein-Mann-Feierabend-Projekt. Ich hab fast jeden Tag nach Feierabend daran rumgeschraubt - und wenn es auch manchmal nur ein oder zwei Zeilen Code waren.

Ich würde behaupten ja. Ich vermute, dein Router bietet eine Lösung an, mit der du direkt Ports von bis freigeben kannst und nicht nur einzelne Ports. Also sollte eine Eingabe á la "10308 - 10308" zielführend sein. Aber ohne das genaue Routermodell zu kennen ist das nur Spekulation, ob dein Router dann nur einen Port freigibt. Und es ist auch nur Spekulation, ob du deinen Router meinst und nicht doch deine Firewall ;) Mit so wenig Infos kann ich leider nur raten.

Ich werte das mal als gutes Zeichen :D Du würdest mit unserer MDC vermutlich nicht viel anfangen können. Und um genau das Problem drehten sich die letzten zwei Seiten. Wenn ich RAMP veröffentliche werde ich auch eine Import-/Export-Struktur schaffen. Ich weiß nur noch nicht in welcher Form. Aber ja, auch VRler habe ich im Hinterkopf - wobei die sich die Riftnutzer eigentlich einfach das Browserfenster in die VR legen könnten :P (Zumindest hab ich letztens ein Video gesehen, in dem sich jemand ein Video eines Flugzeugs in das virtuelle Cockpit in der VR gelegt hat - abgefahren) Da das Video der letzte Post der vorhergehenden Seite ist poste ich es nochmal, da ich nicht möchte, dass es jemand übersieht: 5n8HgSTQL4o

Das musst du nicht :D Ich versuche auch echt wegzukommen von der technischen Diskussion, aber das gelingt mir einfach nicht... ... vielleicht hilft das hier? 5n8HgSTQL4o

Neben den technischen Gründen, die ich nicht besser hätte erläutern können, möchte ich RAMP in die Toolchain für unser Geschwader integrieren. Die Kombination daraus wird es dann für uns zu einem richtigen Flugplaner machen (Callsign-, Frequenzvergabe, Zeitplanung, Luftraumreservierung, etc.) direkt mit verlinkter MDC. Davon ab will ich (und vielleicht auch andere?) RAMP auch einfach mal auf einem Tablet nebendran offen haben beim fliegen. Als Desktopapplikation schwer machbar. Und als profansten Grund habe ich das Projekt genutzt um mich in (für mich) neue Technologien und Frameworks einzuarbeiten - ich verdiene mein Geld mit sowas. Mir hat das auf jeden Fall auch zig mal mehr Spaß gemacht als die letzte WPF-Applikation, die ich geschrieben habe und es war sehr viel weniger Aufwand und Frust dabei. Ja, effektiv ist es im Moment ein (sehr aufwändiger) Taschenrechner. Woher kommt deine Abneigung gegen Programme, die im Browser laufen?

Exakt. :) Das ist zumindest die mir bekannte Abkürzung dafür. Auf deutsch hab ich es mal mit "NN" übersetzt :D Ich glaube meine deutsche Übersetzung ist teilweise eh zum quieken, aber die wird bestimmt nochmal angepasst.

Da will ich mir gerade noch gar nicht so detailliert Gedanken drüber machen ;) Ich will erstmal rausfinden, ob sich der Aufwand einer Veröffentlichung (und damit verbunden der Aufwand, für alles was ich dafür noch tun müsste) überhaupt lohnt. Ich bin da noch unentschlossen. Ich mach heute Nachmittag mal ein kurzes Video, wie ich mein eigenes Tool benutze (und versuche, dabei nicht zu schnell zu sein :D). Dann mal weiterschauen.

Ja, das macht Sinn und ja, die API hatte ich den vorhergehenden Posts schon angedacht und anskizziert. Wie gesagt, ich merke ihr wollt eine Ex- und Importmöglichkeit. Ich weiß nicht, ob ich mich auch dem Export aus dem Miz widmen werde. Aber eine Ex- und Importmöglichkeit in einem "RAMP-spezifischen" Format wird kommen. Das dient dann auch gleichzeitig dazu, sich selbst Flugpläne abzuspeichern.

Hey, danke für die Anmerkungen :) Ich hab die Daten für die Screenshots einfach wahlfrei zusammengeklickt, ohne auf fachliche Korrektheit zu achten (ja, mit dem Wind würde ich in Nellis eher von RWY 21 starten). Das mit dem TO hast du richtig erkannt. Hier kannst du mit den gegenläufigen Pfeilen auch die Einheit wechseln. Bei der Richtung ist es TO oder FROM, so kannst du das Format eingeben, was du hast. Wenn du den Wind aus dem ME nimmst, dann wäre TO die richtige Wahl, wenn du nicht manuell umrechnen willst. In der ganzen Umweltdaten-Box kannst du mit den gegenläufigen Pfeilen die Einheiten durchschalten. Und ab hier beginnt dein Denkfehler. Der Wind 330/05 gilt auf Meereshöhe. Nellis liegt auf ~1840 Fuß über Meereshöhe. Jetzt muss man wissen, dass DCS in den drei eingebbaren Windschichten eine "Zwischenschicht" auf 2000 Fuß einzieht. Hier setzt DCS die gleiche Windrichtung wie auf Meereshöhe, verdoppelt aber die Geschwindigkeit. Fragt mich bitte nicht warum, aber das ist so. Sieht man auch sehr gut im Missionseditor. Dementsprechend bläst beim Takeoff in Nellis der Wind in Richtung 330 mit ungefähren 10 Knoten (RAMP rechnet das genauer als ich gerade überschlagsmäßig)! Und damit sind die Angaben unter TOLD ziemlich korrekt - nämlich genau das doppelte von dem, was du für eine Windstärke von 5 Knoten ausgerechnet hast :) Und danke für das Angebot, aber ich glaube das müssen wir weder im TS, noch per PN durchgehen :D Diesen Sinus-, Cosinus und Tangenskram krieg ich noch hin :) Ja und ja.

Ja, ich mach mal ein Beispiel in Videoform dazu. Wird mir hier langsam auch zu technisch, aber es kommen halt auch mehr technische Fragen :D Auf jeden Fall! Die ganzen NFMs liegen schon lange bei mir rum :) Das Tool ist NICHT an einen DCS Server gebunden! Es hat eigentlich gar nichts mit DCS zu tun. Wenn du in DCS offline fliegen willst kannst du es trotzdem zur Flugweg- und Performanceplanung nutzen. Es ist einfach nur eine Webapplikation - mehr nicht. Es hat keine Schnittstellen zu anderen Systemen und man muss auch nichts installieren. Browser auf, Adresse eintippen, los geht's. Ich denke, das wird im folgenden Video klarer. Weniger Daten, die zum Client übertragen werden müssen, dadurch deutlich kürzere Ladezeit und insgesamt schnellere Berechnung (das ist schon ziemlich intensiv, was da gerechnet wird...). Aber wie oben gesagt, ich muss das nochmal abwägen und rumexperimentieren. Ja, definitiv! Dazu ist es gedacht! Man braucht für RAMP auch keine Ahnung von ATC oder so, das fließt da gar nicht ein. Man muss nur wissen, wohin man fliegen will und was man da machen will. Sobald man seinen eigenen Flugplan hat kann man den in RAMP eingeben und bekommt die Performance berechnet. Wie oben geschrieben: Browser auf, Adresse eingeben, los geht's. Es gibt keine "Bindung" an einen speziellen DCS-Server oder so einen Kram.

Ah, du meinst ein proprietäres Tool eures Geschwaders?! Da ich das Tool nicht kenne kann ich da nichts zu sagen. Aber mit sehr sehr großer Sicherheit wird RAMP kein simples Textfile mit nur dieses fünf Werten rausschmeißen, sondern eher eine JSON-Datei mit allen eingegebenen Werten. Bevor ich sowas mache werde ich auch sicherlich noch viele Gedanken in das JSON-Scheme stecken, um es robust und vor allem abwärtskompatibel zu gestalten. Was ihr dann mit der exportierten Datei aus RAMP anstellt ist erstmal eure Sache. Aber ich seh schon - auch aus den anderen Kommentaren - dass euch eine Ex- und Importfunktion wichtig ist. Das priorisier ich mal hoch. Momentan laufen die Berechnungen alle serverseitig und die Daten (Flughäfen, Prozeduren, Daten über Flugmuster, Daten über die Beladungsoptionen, ...) werden alle serverseitig vorgehalten - nicht alles davon brauch ich auf dem Client. Größtenteils ist das noch ein Relikt des Prototypen, weil ich das blind als Server-Client-Architektur realisiert habe und mich für den "Neubau" größtenteils auf die GUI konzentrieren wollte. Ich überlege jedoch schon ein paar Wochen, ob ich die Berechnungen auf den Client schiebe. Ich muss das mal gegen eventuelle Ladezeiten und co abwägen.

Genau, das muss man testen. Mein letzter expliziter Test ist schon eine Weile her, aber da waren die Werte überraschend exakt. "Expliziter Test" heißt, dass ich mir einen Flugplan zusammengebaut hab und wirklich so genau wie möglich nicht vom Flugplan abgewichen bin (Steiggeschwindigkeit, Reisefluggeschwindigkeit, Strecken, Sinkparameter, ...). Bei dem Punkt könnte ich unter Umständen durchaus motivierte Betatester brauchen, die ab und an mal die errechneten Werte ... "überfliegen" :D Und dann eventuell auch bei einer möglichen Korrektur der ermittelten Werte helfen. Ist auf jeden Fall schon länger geplant. Ich werde es allerspätestens dann umsetzen müssen, wenn wir vom Geschwader das erste Mal in den Kaukasus verlegen. Das sollte gar nicht mehr in allzuferner Zukunft legen. Muss ich mal schauen, wie ich das realisiere. Hatte ich so bisher nur sehr spezialisiert auf dem Schirm (für unser Geschwader; ist sogar im Prinzip schon implementiert, aber halt nur für uns). Eventuell eine Art "Download"-Funktion des Flugplans und für die Datei, die da rausplöppt wieder eine Hochlade-Funktion. Ein Speichern auf dem Server werde ich nicht anbieten, da ich dafür Userregistrierung, Login und Ähnliches bauen müsste - das will ich vorerst nicht. Ich will keine Daten von euch speichern müssen und mich um die Datensicherheit kümmern müssen, zumindest im Moment nicht. Und einfach so Flugpläne von jedem abspeichern lassen und diese dann auch wieder laden können, das würde viel zu unübersichtlich und auch viel zu viel werden, wenn RAMP echt Anklang findet. Im Prinzip das gleiche wie oben :D Klar, wenn ich Daten aus RAMP exportiere, dann sollte ich sie auch wieder importieren können. Was für ein CDU Tool? Und "in einfacher Weise automatisiert auseinander generieren lassen" versteh ich ehrlich gesagt nicht.

Ich glaube ich zeig euch einfach bei dem nächsten Flug, den ich plane wie ich RAMP benutze. Das sollte einiges klarer machen :) Momentan tippst du die Wegpunkte händisch in die mittlere Spalte (FLIGHTPLAN) ein. Punkte für bekannte Approaches und Departures sind fest hinterlegt und werden automatisch bei Auswahl der Dep/App eingetragen. Es sind momentan alle Flughäfen und alle bekannten SIDs/IAPs/CVFPs/Recoveries/VFR Departures der Nevada-Karte hinterlegt. Statt benamter Punkte können hier auch Koordinaten (MGRS oder diverse Variationen von Längen-/Breitengrad) eingegeben werden und auch Offsets gehen. Valide Eingaben sind zum Beispiel LSV, APEX; 11S PA 12345 54321; 11S PA 123 456; 31°,-115°; LSV OSET 210/15; und so weiter... Einen Export des Flugplans nach DCS hab ich momentan nicht geplant und würde weitere Probleme aufwerfen, z.B. welchem Client im Multiplayer man diese Wegpunkte gibt. Ein Import der Wegpunkte einer .miz-Datei ginge schon eher, siehe letzter Post. Ist bis jetzt sehr weit unten in meiner Planungsliste, da wir das Feature bisher nie gebraucht haben. Wie erhoffst du dir es denn? :)

Auch bei nicht geplantem CAS gibt es aber sinnvolle, zu ermittelnde Werte: wie lange kann ich über einer AO loitern und wie weit kann ich mich von meiner Homeplate entfernen - jeweils ohne einen kritischen Fuelstate zu erreichen? Noch liefert RAMP die Werte nicht, aber das ist vermutlich mit einer der Punkte, die ich demnächst angehen mag. Das mit den ZSleds wird noch dauern. Das ist nicht mehr trivial, sobald der Luftwiderstand ins Spiel kommt :D Momentan nur ausschließlich über RAMP. Ich hab mal über eine Import-Funktion nachgedacht, aber effektiv hab ich das Thema von der Priorität her sehr weit nach unten geschoben, da wir es im Geschwader schlicht nicht brauchen. Und mein Fokus lag erstmal auf der Funktionalität für den Betrieb des Geschwaders. :) Prinzipiell habe ich es aber noch auf der Liste stehen und wenn es genügend Anklang findet werde ich es bestimmt auch umsetzen.

Für jede Chart eine andere :) Genau die lass ich nämlich ein Tool aus den Datenpunkten suchen. Naja, ich sträube mich noch ein wenig, es als Missionsplaner zu bezeichnen... dazu kann es noch zu wenig Missionsplanung :D Deshalb erstmal "nur" ein Performanceplanungstool. Ich hab da für den Crashkurs schon durch die NFM-400 gestöbert. Gefühlt würde ich gerade sagen, dass es sogar weniger ist, als für die A-10C. Die AV-8 wird eher technisch eine Herausforderung für mich, weil ich ein Flugzeug stellenweise wie einen Helikopter behandeln muss (es braucht keine Startbahn)... aber darüber mach ich mir noch Gedanken Zum Debriefing eher nicht. Dafür ist es auch nicht gedacht. Tacview ist und bleibt DAS Debriefingtool. Zum Briefing nicht-taktischer Inhalte auf jeden Fall, weil du effektiv die gesamte Flugplanung da drin hast. Für uns generiert das Tool unsere MDC (die vJaBoG 66 Piloten haben noch einen Reiter "MDC", den allerdings nur wir sehen) und wir müssen kaum noch was selbst eintragen.

Es fehlt nur Zeit. :) Daten sind alle vorhanden. Die realen Manuals sind öffentlich zugänglich. Zeit ist zwar auch öffentlich zugänglich, aber für mich gerade echt nicht im Überfluss vorhanden :D Momentan glaub ich eigentlich nicht, außer du hast Lust zum Betatesten. Gerne per PN. Glaube das würde den Thread hier sonst sehr langweilig gestalten. Vor allem, weil die Formeln nicht mehr so direkt "menschlich lesbar" sind, wie man es vielleicht erwarten würde ;) Sind einfach nur Polynome. Grob anskizziert hab ich echt nur das "durcharbeiten" der Charts automatisiert. Wenn du in eine Chart mit deinem Gross Weight reingehst und deine Pressure Altitude dazugibst, um irgendeine Geschwindigkeit rauszukriegen, dann ist das bei mir eine Funktion mit genau den beiden Parametern. Wobei ich die Pressure Altitude vorher noch gesondert aus der vom Benutzer ausgewählten Höhe und dem QNH ausrechne... Steht auf jeden Fall auf dem Plan. Vor allem auch, da wir einen Einsatz der AV-8 im Geschwader auf langfristige Sicht nicht ausschließen (bzw. dem Einsatz eher entgegensehen). Mein utopisches Ziel ist es ja eh, da alle Module zu integrieren. Aber da sprechen wir in ein paar Jahren noch einmal drüber ... :D

Hey Freunde, das hier ist der Hauptgrund, warum es 2017 nicht so viel von mir auf YouTube zu sehen gab (neben dem Aufbau des vJaBoG 66). :) Was ist es? RAMP ist ein Tool zur Performanceplanung. Mit anderen Worten rechnet es die Performance-Charts aus und ermittelt Werte, wie zum Beispiel eine Rotationsgeschwindigkeit, benötigte Rollbahnlänge, benötigter Treibstoff und so weiter - über einen ganzen Flug mit noch viel mehr Werten. Der Name ist ein Akronym für "Rakus Attack and Mission Planner". Das ist ausnahmsweise mal nicht auf meinem Mist gewachsen, sondern yurgon hat die initiale Idee dafür eingebracht. Ich fand es sehr passend, denn solch eine Planung macht man im Normalfall, während das Gefährt im Prinzip noch auf der "Ramp", also dem Vorfeld steht. Mit diesem Thread möchte ich euch hauptsächlich erstmal erläutern, was das Tool ist, was es kann, was meine Motivation dahinter ist und ich möchte herausfinden, ob die breite (vorerst deutsche) Öffentlichkeit überhaupt Interesse daran hat. Warum...!? Angefangen hat das ganze Thema Performanceplanung bei mir so richtig, als ich das vJaBoG 66 zusammen mit Borin und yurgon ins Leben gerufen habe. Das war so August 2016 rum. Irgendwann hatte ich einfach keine Lust mehr, immer mit 100% Treibstoff abzuheben oder auch meine Erfahrung sagen zu lassen, wieviel Treibstoff ich Pi mal Daumen für einen Flug mitnehmen muss. Und sowas wie eine Rotationsgeschwindigkeit oder andere relevante Werte wollte ich auch nicht jedes Mal händisch ausrechnen. Das macht einerseits nicht sehr viel Spaß, wenn so viel kostbare Freizeit vom eigentlichen rumfliegen abhält und... jedes Mal vor dem Geschwadertraining alle Performancecharts durchgehen, um den Flug zu planen? Puh. Danke. Da hatte ich echt keine Lust drauf. :cry: Ein wenig später fiel mir dann das Stichwort "Regression" in Arme: im Prinzip eine Möglichkeit der Mathematik einen vorhandenen Graphen in seine Formel (zumindest annäherungsweise) zurückzuwandeln. Ab dem Zeitpunkt war mir eigentlich klar, dass man dafür wunderbar ein Tool zur Arbeitserleichterung bauen kann. Im Prinzip muss ich nur eine graphische Oberfläche um ein paar Formeln bauen. Retrospektiv kann ich nur sagen: Gott lag ich falsch damit. Nachdem die ersten paar Charts der A-10C "verformelt" waren habe ich eine kleine Oberfläche dafür gebaut und das ganze in eine Webapplikation reingeschraubt. So konnte schonmal jeder bei uns im Geschwader sich selbst die Performancewerte für einen Takeoff der A-10C ausrechnen lassen. Die Oberfläche zu dem Zeitpunkt war absolut gräslich und wirklich nur ein Prototyp. Ein paar Eingabefelder und eine Tabelle mit den Werten als Ausgabe. Aber es reichte erstmal. Größtenteils in meiner Mittagspause (mein Arbeitstitel war lange Zeit "Mittagspausenprojekt", bevor es dann RAMP wurde) habe ich Werte aus weiteren Charts abgelesen - ja, alles händisch! - und irgendwann alles zu Formeln verschraubt. Die flossen auch in das Tool rein und ein paar Monate später konnte man sich für die A-10C alle Flugphasen ausrechnen lassen. Noch ein paar Wochen später und unsere Mission Data Card wurde von RAMP generiert. Das war allerdings alles bisher nur hastig in einen Prototypen geschraubt, der einerseits von der Oberfläche, als auch vom Programmcode her echt schrecklich aussah. Ich bin teilweise selbst nicht mehr durch den Code gestiegen (für die, die sich auskennen: jQuery ist der Teufel!). Und hinzu kommt, dass RAMP alles andere als benutzerfreundlich war: man musste die Flugphasen genau so eingeben, wie sie die Performance-Charts verlangt haben. Das heißt, man musste den Missionseditor nebenbei aufhaben und Strecken messen. Da ging mehr! Sehr viel mehr. Ich hab das Potential gesehen, was da drin steckt und wollte zwei Dinge machen: erstens eine vernünftige Oberfläche mit einer vernünftigen Technologie und zweitens die Ebene der Performance-Charts komplett wegabstrahieren, um zu einer richtigen Flugplanung zu kommen. Die Distanz zwischen zwei Koordinaten auszurechnen ist in unserem Zeitalter wahrlich kein Hexenwerk mehr. Im März 2017 habe ich angefangen, RAMP komplett neu zu bauen. Dieses Mal mit ordentlichen und hoffentlich auch zukunftssicheren Technologien. Die einzigen Überbleibsel von dem ursprünglichen Mittagspausenprojekt sind die Codestücke im Backend, die effektiv die Werte ausrechnen. Alles andere habe ich zwischen März und Juni neu geschrieben und sehr viele neue Funktionen implementiert. Bei dem ganzen Neubau hatte ich auch im Hinterkopf, dass ich nicht nur die A-10C unterstützen möchte - sondern im Prinzip jedes Muster. Für mich ist also auch eine Art Framework entstanden, in das ich neue Formeln für neue Muster relativ schnell integrieren kann. Der Part, der dabei am längsten dauert ist immer noch die Formeln überhaupt mal zu erstellen. Währenddessen hat Borin eine Art "Datenbank" mit realen Navigationspunkten erstellt, die wir einerseits in Tacview (dazu an anderer Stelle mehr) und unserer Geschwadermission eingebaut haben aber auf die andererseits auch RAMP zurückgreift. So muss man nicht länger Koordinaten eingeben, sondern kann direkt z.B. APEX eingeben - man muss nur die Punkte kennen. Mittlerweile bin ich selbst ziemlich zufrieden mit RAMP - genauer gesagt so zufrieden, dass ich doch allmählich über eine Veröffentlichung nachdenke. Was kann es? Zum momentanen Zeitpunkt kann man mit RAMP einen kompletten Flug für die A-10C planen und bekommt viele der Werte aus den Performance-Charts. Teilweise sind auch die F-5E und die UH-1H schon integriert. Man kann den Flug mit Hilfe von Koordiaten oder fixen, wohlbekannten Navigationspunkten planen. Neben den reinen Zahlen bekommt man auch graphische Ergebnisse über die Höhe zu jedem Wegpunkt und den Treibstoffverbrauch. Von den eigentlichen Performancecharts sieht man in RAMP nicht mehr viel. Man wählt sein Muster, seinen Start- und Zielflughafen, seinen eigentlichen Flugplan und schon sieht man alle Ergebnisse. Die Ergebnisse werden kontinuierlich bei jeder Änderung aktualisiert, aber vermutlich baue ich hier für ein eventuelles Release noch eine kleine Bremse ein. Da ich mich ja doch irgendwie der deutschsprachigen Gemeinde verschrieben habe gibt es RAMP nicht nur auf Englisch, sondern auch auf Deutsch! :) ... und das wars? Noch lange nicht. Ich hab noch sooo viele Ideen dafür! Eine bessere Karte... eine Karte, die man anklicken kann und es wird automatisch ein neuer Wegpunkt in den Flugplan eingeführt... mehr unterstützte Muster... Unterstützung für andere Terrains (Kaukasus, SoH)... mehr Graphen und vor allem interaktivere Graphen (z.B. Wegpunktinformationen in die Graphen reinbringen)... mehr Werte (maximum range / maximum loiter time und viele mehr) und letztendlich noch die namensgebende Angriffsplanung. Die Angriffsplanung würde einen ZSled-Generator beinhalten, aber das ist wesentlich komplizierter als Charts mittels Regression umzubauen. Da bin ich noch in der Konzeptions- und Prototypenphase. Und jetzt ihr! Wie ganz oben gesagt möchte ich hier im Prinzip erstmal rausfinden, ob sich ein Release lohnt. Habt ihr Fragen? Ich mach das jetzt seit über einem Jahr, ich sehe da sicherlich den Wald vor lauter Bäumen nicht mehr und habe mit Sicherheit unbeabsichtigt viele Fragen offen gelassen. Würdet ihr das Tool benutzen? Wenn ja, wie und wofür? Wenn nein, warum nicht? Mir ist dabei auch vollkommen klar, dass nicht jeder virtuelle Pilot so tief in die Materie einsteigen möchte - und das ist auch voll okay! RAMPs Zielgruppe ist nicht die Gesamtheit aller virtuellen Piloten auf diesem Planeten. :) Unter Umständen und je nachdem, in welche Richtung das Projekt RAMP noch geht suche ich auch Betatester. Einerseits fliegerischer Natur, um die Ergebnisswerte zu überprüfen und andererseits technischer Natur, um Bugs oder gar Sicherheitslücken zu finden. Langsam aber sicher ist die Codebase doch so groß, dass ich alleine nicht mehr alles weggetestet bekomme. Ich bin auf euer Feedback, eure Reaktionen und eure Antworten extrem gespannt. Und zu guter letzt - weil ich scheinbar echt eine Niete bin, technische Dinge nicht technisch auszudrücken :D - ein erklärendes Video, was vielleicht einiges klarer macht: 5n8HgSTQL4o - Raku

Da hilft dir Google am besten weiter, denn jeder Router und jede Firewall wird anders bedient. Da kann man keine richtig pauschale Aussage zu treffen. Einfach mal nach "[dein Routermodell] port weiterleiten" suchen. Äquivalent für die Firewall mit "[deine Firewall] port öffnen" Und nein, es müssen nicht beide Router die gleichen Einstellungen haben. Minimalistische technische Antwort: Wenn du der Server bist, dann muss deine Infrastruktur so konfiguriert sein, dass dein PC eingehende Anfragen annehmen und beantworten kann. Wäre das von Haus aus schon so konfiguriert, dann könnte im Prinzip jeder von außerhalb nur mit deiner IP auf deinen Rechner oder dein ganzes Netzwerk ( = jedes Gerät in deinem privaten Netzwerk) zugreifen - mehr oder weniger. Das will natürlich keiner, also sind fast alle eingehenden Verbindungen von deiner Firewall erstmal blockiert, vor allem auf Nicht-Standard Ports. Hinzu kommt noch, dass dein Router (der Name spricht hier Bände: das Teil sucht und findet Routen) gar nicht weiß, an welches der Geräte in deinem Netzwerk er das eingehende Signal (z.B. auf Port 10308) weiterleiten soll. Da musst du dem Router sagen "wenn auf 10308 was ankommt, dann gib das meinem PC, der kümmert sich um alles weitere". Und so gelangt das Signal aus dem Internet über Port 10308 durch deinen Router, zu deinem PC, durch deine Firewall und schließlich zu DCS (das auf dem Port horcht und eingehende Anfragen auf dem Port beantwortet).

Nö das passt schon, gibt schon viel zu viel Stickies hier. Eventuell hat es den Server wieder dahingerafft, kann ich erst heute Abend nachschauen.

Ich wollte den Thread hier eigentlich gestern schon zusammenführen mit dem Thread für den Kölner-Raum... hab dann aber doch nochmal die Entfernungen nachgeschaut :D Und ja, da macht ein eigener Thread eigentlich schon Sinn. Ich hoffe, es finden sich genügend Leute für einen Stammtisch - wobei zwei eigentlich schon genug sind, um sich gemütlich zu treffen und den Anfang zu machen! Doodle aufmachen und los geht's :)

Das sollte durch den Server nicht eingestellt werden. Es sollte das gelten, was bei dir in den Optionen eingestellt ist. Falls dem nicht so ist muss ich das mal ändern, weil solche Optionen will ich eigentlich nicht vorgeben. Ich hab da keine Pläne. Hab absolut keine Zeit nebenbei noch Missionen zu designen :) Falls jemand eine richtige Mission auf dem Server spielen will: siehe erster Post.

Um einer Frage vorzubeugen, die dann bestimmt demnächst kommt: PRS funktioniert nicht bei den Stationen 5 + 7 :) Man kann zwar PRS auswählen, es geht aber nur eine Bombe raus. Die beiden Stationen liegen zu nah beieinander, um zwei Bomben gleichzeitig abzuwerfen und zu garantieren, dass die sich nicht doch zu nah kommen. Das kann ja durchaus katastrophal enden, so ein paar Fuß unter dem FLugzeug.

Es ist sehr gut möglich, dass ich für die Props gar keine Presets vergeben hab. Äh... bist du dir sicher, dass es klar ist? Weil das, was ich meine, hat mit dem Runwayheading absolut nichts zu tun. Ich meine, dass einfach jeder bei Starts und Landungen immer nur die linke Seite (= Hälfte) der Start-/Landebahn nehmen soll. So kommen sich zwei, die sich entgegen kommen nicht in die Quere. Ein beliebtes Problem ist ja immer, dass es jedes Mal mindestens einer schafft auf die Runway zu rollen, während man selbst auf dem Short Final ist :D

Soweit ich weiß ist der Fehler bekannt :)