Java API

[Chris]

Moin,

ich bin in Java zu Hause und habe zu meiner Freude festgestellt, dass 3DMS eine ziemlich mächtige Progammschnittstelle hat. Ich baue daher gerade an einem Java API, das schon ganz ordentlich fortgeschritten ist, wenn es auch noch nicht alle Kommandos und Ereignisse beherrscht. Das API erlaubt sowohl das Senden von rohen Kommandos und Empfangen von Ereignissen als auch die komfortablere und einfache Interaktion mit 3DMS über Java-Objekte, die im Hintergrund mit 3DMS verdrahtet sind.

Um einen Eindruck zu vermitteln:

tdms = TDMS.getInstance(); // Sucht auf de Netzwerk
Commander commander = new Commander(tdms);
EventReceiver eventReceiver = new EventReceiver(tdms); // Optional, wenn man Ereignisse braucht

System.out.println("Version :" + commander.getVersion());

Rail rail = commander.get("G706");
rail.setActiveTrack(1);

eventReceiver.addEventListener(EventRailEntered.class, new AbstractEventReceiver<EventRailEntered>() {
            @Override
            public void receiveEvent(final EventRailEntered pEvent) {
                Rail rail = pEvent.getRailEntered();
           }
}

Mit <100 Zeilen Code habe ich mir z.B. einen "Autowire" Mechanismus geschaffen, der Gleise und Besetztmeldung auf Stellwerkselementen (und Textlabels mit Zugnamen) rein aufgrund der Benamung zusammenschaltet - in 3DMS muss ich nichts weiter tun als das Gleis "G<name"> nennen und den Stellwerk-Baustein "B<name>" (und den Text "T<name>"); das war's. Keine Ereignisse, keine Verknüpfung, auch keine vom Programm erzeugte - Autowire ändert nichts an der Anlage.

Ist so was für die Gemeinde von Interesse? Bei genügend Feedback würde ich zumindest mal die JARs verfügbar machen.

Gruß,

Christian

[metallix]

Hi Chris

Ich denke jedwede anwendung welche die performance von MBS stabilisiert oder verbessert wuerde von allen willkommen geheissen werden. Mit stabilisieren/verbessern meine ich anlagen mit grosser = rechnerintensiven EV. Ab gewisser groesse der EV in abhaengigkeit zu den leistungsmerkmalen des verwendeten rechners kommt es vor das einzelne befehle, speziel wenn viele quasi gleichzeitig ausgefuehrt werden sollen, ignoriert werden. Da fahren z.b. fahrzeuge einfach weiter anstatt anzuhalten, oder fahren nicht los wie befohlen. Gleichzeitig geht natuerlich auch die FPS-rate runter, speziel wenn die grafik karte eine einfache ist. Wenn ich deine beschreibung richtig verstanden habe wuerde deine app viele EV eintraege ersetzen und somit die fehlerquote beim abarbeiten der EV reduzieren.

Bleibt nur die frage ob nicht die neue V5 version, die ja in baelde erscheinen soll, auch die unterstuetzung deiner app akzeptieren wird und in wie weit einige der schwachstellen der vorgaenger version bereits beseitigt sein werden.

Cheers

Tom

[Andy]

Wenn die Schnittstelle erhalten bleibt, kann auch diese API aufrecht erhalten werden. Aber etliches wird dann intern über Lua laufen und damit werden komplexere Dinge innerhalb von MBS geregelt werden, die einem Plugin auch erst mal beigebracht werden müssen. Das ist dann doppelt gemoppelt.

Gruß
  Andy

[Neo]

Hallo,

die Schnittstelle wird auch in V5 noch erhalten bleiben, und auch darüberhinaus wird es weiterhin die Möglichkeit geben, sich per Netzwerk mit dem Studio zu verbinden. Wie die Verbindung dann aussieht, und ob es hier eine direkte Verbindung zu Lua in der EV gibt, wird sich dann zeigen müssen, aktuell habe ich nur Ideen, aber noch keine konkreten Umsetzungspläne.

Viele Grüße,

Neo

[Chris]

Hallo,

Danke für das Feedback! Interessant zu hören, dass für v5 Scripting mit Lua vorgesehen ist, was sicher mehr möglich macht als was die Ereignisverwaltung hergibt. Ich habe bisher nicht den Eindruck, dass ein Java API herbeigesehnt worden ist :-) Ich werde trotzdem weiter daran arbeiten, weil das schon für meine eigenen Spielereien mittlerweile eine sehr nützliche Grundlage ist. Ich denke auch, dass die TCP-Schnittstelle wohl erhalten bleiben wird; sonst wären ja etliche Plugins zum Zugang abgeschnitten. Wie Tom schreibt kann ich in einem externen Plugin aufwändige Dinge tun, die die Performance von 3DMS nicht nach unten ziehen.

Zu "Lua in 3DMS" fallen mir zwei Sachen ein bzw. auf: Lua kommt auf dem Platz der beliebtesten Programmiersprachen gleich auf Platz 33 (Java liegt auf Platz 1, und JavaScript, Python und PHP liegen in den Top 10). Ich weiß schon, dass Lua nicht völlig esoterisch ist (z.B. im embedded-Bereich wird es verwendet), aber ich kenne niemanden persönlich, der darin programmiert. Da stellt sich die Frage, ob Lua so viele Programmierer anziehen wird. Dann ist es so, dass ich bei Java/ außerhalb 3DMS mit den Tools meiner Wahl programmieren kann (wie z.B. mit Eclipse oder IntelliJ); bei Lua würde ich dann vermutlich in 3DMS programmieren?

[Goetz]

vor 9 Stunden schrieb Chris:

ich kenne niemanden persönlich, der darin programmiert.

Du findest Lua in sehr vielen Spielen wie z.B. Minecraft oder Factorio.

Meines Wissens eignet es sich besonders gut für diese Art der Integration in Programme. Und es ist - wie Python - sehr Einsteiger-freundlich.

 

https://en.wikipedia.org/wiki/List_of_applications_using_Lua#Video_games

Bearbeitet 26. Mai 2019 von Goetz

[Neo]

Hallo Chris,

vor 10 Stunden schrieb Chris:

ob Lua so viele Programmierer anziehen wird

tatsächlich lautet die Frage, ob Lua so viele Nicht-Programmierer anziehen wird? Für einen Programmierer spielt es am Ende keine Rolle, ob er in Java, JavaScript oder Lua programmiert, die Konzepte bleiben mehr oder weniger gleich, die Syntax ist schnell erlernt. Bei einem Programm wie dem 3D-Modellbahn Studio geht es aber darum, Leute, die gar nichts mit Programmierung am Hut haben, für eine Scriptsprache zu begeistern, um so die vollen Möglichkeiten auszureizen. Und hier hat Lua einen großen Vorteil, weil der Sprachumfang eher klein ist und die Sprache sehr schnell erlernt werden kann. Wahrscheinlich ist das auch der Grund, warum Lua bei Spielen der Quasi-Standard ist.

Viele Grüße,

Neo