RunOnce in der EV

[Franz]

Ich hätte da eine Idee die eventuell dazu beitragen könnte damit externe Programmen dem Anwender "sympathischer" werden.

Es gibt doch bei Windows in der Registry einen Abschnitt namens RunOnce. Wie wäre es wenn es in der EV auch solch eine Variable gäbe? Näheres siehe Bild:

HG
Franz

 

 

[Neo]

Hallo Franz,

über eine Variable würde ich das nicht steuern, das könnte man auch expliziter als Eigenschaft der Anlage verwalten. Ich habe schon früher überlegt, wie man die externen Programme direkter mit einer Anlage verknüpfen kann. Die logische Schlussfolgerung wäre eigentlich, wenn die Programme ebenfalls Teil des Online-Katalogs wären, und man diese einfach in der Anlage "referenzieren" kann. Das Studio würde die Programme dann selbstständig herunterladen und nach Bedarf starten.

Technisch ist das alles kein so großes Problem, allerdings gibt es hierbei andere Punkte zu berücksichtigen, denn hinter den externen Programmen stehen normale Exe-Dateien, die ähnlich wie Makros bei Excel sehr viel auf dem Computer anrichten können, sei es absichtlich oder ungewollt durch einen Programmfehler. Ich selber könnte dafür gar nicht mehr haften, da ich die Programme gar nicht untersuchen kann. Das ganze müsste daher auf einer hohen Vertrauensbasis laufen.

Langfristig schwebt mir eigentlich eher eine ganz andere Lösung vor, nämlich die Unterstützung einer eigenen Skriptsprache. Mit dieser Skriptsprache würde das Studio dann analog wie Firefox Erweiterungen unterstützen, wobei die Erweiterungen dann nur auf die vom Studio angebotenen Funktionen zugreifen können. Das würde allerdings bedeuten, dass die Entwickler der externen Programme eine eigene/andere Programmiersprache nutzen müssten. Vorteil dieser Skriptsprache wäre dann aber auch, dass man diese auch optional in der Ereignisverwaltung nutzen kann, um richtige Abläufe zu programmieren.

Es gibt also 2 Optionen:

1. Direkte Verknüpfung von externen Programmen mit Anlagen auf einer hohen Vertrauensbasis
2. Oder die Einführung einer eigenen Skriptsprache, die langfristig die externen Programme durch eine interne Lösung ersetzt

Viele Grüße,

Neo

[FriLu]

Hallo Neo,

zu 2. fällt mir da spontan LUA ein...

Gruß Lutz

[Franz]

Hallo Neo,

als ich Deine Antwort las war mein erster Gedanke: Eigene Scriptsprache: Super!

Aber jetzt, nach einigem "Drübernachdenken" meine ganz persönliche Meinung:

Trotz der großen Anwenderzahl die das Studio inzwischen hat sind es (wenn ich recht informiert bin) im Moment 3 Leute die von der Schnittstelle Gebrauch machen. Ob's durch die Einführung einer eigenen Scriptsprache mehr werden? Wieder einmal ein Blick über den Tellerrand. Trainz hat schon sehr lange eine eigene Scriptsprache. Die Leute die Scripts schreiben sind, im Verhältnis zu der weiten Verbreitung des Programms, sehr wenige. Das mag unter anderem auch daran liegen, dass es keinen vernünftigen Editor dafür gibt. Intellisense usw.... Man ist inzwischen verwöhnt. Immer nur Notepad++ mit speziellen Addon's - das macht auf die Dauer keinen Spaß. Und EEP hat vor kurzem das von Lutz erwähnte LUA eingeführt. Auch hier habe ich den Eindruck, dass die Leute nur sehr zögerlich darauf anspringen. Spripts ist eben doch etwas besonderes und es ist nicht jedermanns Sache sich damit zu beschäftigen.

Das meine Gedanken dazu. Ob sich der Aufwand rechnen wird kannst nur Du entscheiden. Was mich betrifft: Ich würd's wahrscheinlich versuchen aber wenn der Einstieg sehr holprig wäre würde ich es wahrscheinlich sehr schnell wieder beiseite legen.

Und noch ein letzter Gedanke der aber wirklich nur für mich zutreffend ist... vielleicht noch für Easy. Wir schreiben unsere "Progrämmchen" gerne mit VB weil wir dadurch gezwungen sind uns mit dieser Sprache auseinander zu setzten was uns dann wiederum in die Lage versetzt auch mal für ein anderes Einsatzgebiet als nur für's Studio zu programmieren.

HG
Franz

 

 

[Neo]

Hallo Franz,

grundsätzlich sind deine Argumente nicht von der Hand zu weisen, aber ich denke es wird immer mehr Anwender als Programmierer geben, egal wie einfach die Programmiersprache/Skriptsprache ist. Bei den externen Programmen sehe ich im Moment das Problem, dass es hier eine große Einstiegshürde gibt, und viele Leute wahrscheinlich schon bei der Installation einer IDE aufhören. Ein Skript, welches direkt im Studio definiert und live getestet werden kann, reduziert die Hürde um einiges, sodass womöglich auch mehr Anwender Zugang dazu finden.

Aber wie du schon sagst, das Scripting wird erst dann interessant, wenn mindestens Features wie Syntax-Highlighting, Debugging und Unterstützung bei Fehlern/Problemen zur Verfügung stehen. Tendenziell würde ich mich hier auch gegen LUA entscheiden, selbst wenn die Sprache bei vielen kommerziellen Titeln eingesetzt wird, da sie von der Syntax her meiner Meinung nach zu stark von den gewohnten Programmiersprachen abweicht. Ich selber liebäugle mit JavaScript, denn dieses Sprache ist für einfache Aufgaben sehr leicht zu erlernen und hat eine recht saubere Syntax. Aber wirklich viel Forschungsaufwand habe ich in dieses Thema noch nicht investiert. Trotzdem glaube ich, dass das Scripting dem Studio auf lange Sicht mehr bringt als die Unterstützung der externen Programme (gerade auch in Hinblick auf die Ereignisverwaltung).

Viele Grüße,

Neo

[Franz]

Hallo Neo,

ich denke, im Moment macht es wenig Sinn weiter darüber zu diskutieren da Du, wie Du schreibst, noch keinen wirklichen Forschungsaufwand betrieben hast. Javascript wäre durchaus eine Überlegung wert. Zum einen weil man damit sozusagen "überall zuhause wäre" und weil sich, wie ich eben feststellen durfte, in Sachen Editoren einiges getan hat. Wenn' denn mal d'ran ist.

Darf ich, ohne Druck ausüben zu wollen, eine kurze Frage stellen? Wie sieht es mit meinen geliebten Normal Maps aus?

HG
Franz

 

[EASY]

Hallo,

... auch wenn nicht "spruchreif" gebe ich mal trotzdem meine erste Meinung dazu ab...

Der "Freiheitsgrad", daß man die Programmiersprache selbst aussuchen kann und "nur irgendwie" eine Verbindung zum MBS aufnehen muß, hat natürlich den Vorteil, daß man prinzipiell die Programmiersprache benutzen kann, mit der man sich schon beschäftigt oder die man mal gelernt hat. Hat natürlich den Nachteil, daß ein Nicht-Programmierer erst einmal einen großen Schreck bekommt (ob den Möglichkeiten, [die ja zu größtenteils eigentlich gar nicht gebraucht werden]) und sich dann sofort zurückzieht...

Eine eigene Skriptsprache für das MBS hätte den Vorteil einer überschaubaren Anzahl von möglichen Funktionen und man kann mit "Hallo Welt" erste Gehversuche machen und sieht das Ergebnis sofort im MBS. Es wäre auch eine hilfreiche Ergänzung zur EV, da komplexere Aufgaben zun einen nur sehr schwer oder gar nicht zu realisieren sind und man in einem Skript auch einen besseren Überblick hat als in der derzeitigen Form der Darstellung in der EV.

Persönlich wäre es für mich natürlich ein Rückschritt, da es (wie Franz schon angedeutet hat) für mich keinen über das MBS hinausgehenden "Nutzen" haben würde und ich dem MBS auch gerne einmal Dinge "entlocke", die über die reinen Schnittstellenfunktionen hinausgehen (... und daraus evtl. den Wunsch nach einer realen Schnittstellenfunktion ableite...)

Natürlich kann ich der Argumentation von Neo folgen, daß ich als "freier" Programmierer ein potenzielles (Sicherheits-)Risiko (ob gewollt oder ungewollt) darstelle, für das er nicht seinen Kopf hinhalten kann. (... daß "gewollt" nicht auftritt basiert auf Vertrauen... "ungewollt" auf Kontrolle)...

... so lasse ich meine erste Meinung dazu erst einmal stehen...

Gruß

EASY

[seehund]

Hallo,

beides hat seine Vor- und Nachteile. Beim Scripting im MBS wird s wohl keine Möglichkeit geben z.B. Mausposition und Click auf der Windowsoberfläche des MBS auszulesen und zu verarbeiten. Wäre wenn aber möglich dann das gleiche Sicherheitsrisiko wie bei einer mittels VB oder anderer Programmiersprache erstellten EXE.

Aber schon wieder was Neues, so langsam verliert der alte Mann den Überblick......

Es ist zwar schön alles zu automatisieren und zu animieren, doch wo soll dies enden??? Feste implementierte Funktionen im MBS wären mir lieber.

Gruß Seehund
 

[Neo]

Hallo Franz,

als Zwischenlösung könntest du bei Anlagen, die externe Programme nutzen, den Link zum entsprechenden Forumthema in der Anlagenbeschreibung hinterlegen. Dann kommen die Nutzer zumindest mit einem Klick zum Programm.

In Hinblick auf die EV wird es irgendwann das Scripting geben, und dort wird es wahrscheinlich auch als erstes eingesetzt. Vielleicht entsteht ja daraus dann ein Scripting auch für externe Programme.

Viele Grüße,

Neo

[EASY]

Hallo Seehund,

Zitat

Es ist zwar schön alles zu automatisieren und zu animieren, doch wo soll dies enden???

... in einem Programm, das sich stetig weiterentwickelt... Stillstand in einem Programm bedeutet in Vergessenheit zu geraten.

Zitat

Feste implementierte Funktionen im MBS wären mir lieber.

... warum dann nicht so etwas wie Plugins?... nicht jeder braucht alles und und ein "bewährtes" Plugin zum festen Bestandteil des Programmes zu machen ist ja kein Problem.

Ich sehe es (inzwischen) so, daß Neo doch das eine oder andere in die EV oder im MBS mit aufgenommen hat, weil durch ein externes Programm gezeigt wurde, daß es noch "andere" Möglichkeiten gibt... 

Momentan gibt es "Modellwünsche"... warum nicht auch so etwas wie "Pluginwünsche"? Neo ist ein Einzelkämpfer und ohne die Modellbauer sähe es bestimmt viel leerer im Katalog aus... dies läßt sich auch auf mögliche Erweiterungen im Programm übertragen... sie müßten nur (besser als jetzt) in das MBS eingebunden werden können.

Gruß

EASY

[quackster]

hallo,

nun überlege ich was das mbs können sollte.

im bezug auf die planungssoftware, fehlt meines erachten nur die möglichkeit die elektrischen anforderung einer anlage aufzuzeigen (weichen schalten,blockschaltungen, lichter ein- und auszuschalten, benötigte stellpulte  usw.).

im virtuellen bereich, ein steuerbarer rangierbetrieb inkl. drehscheibe, zusammenstellungen von zügen, das mbs-transportwesen mit be- und entadungen, rundflüge, festgelgte fahrpläne usw.

vieles davon könnte über die EV mittels vorbereiteten textdateien (containernr 01 - wagen 3/1 containernr 02 - wagen 2/4), die bei bedarf aufgerufen, verwirklicht werden.

mittels änderungsmöglichkeit der eigenschaften von objekten (position und rotation, oder farbänderung von bordmitteln, beschriftungsfeldern) könnten zb. lkw's ohne die bisher benötigten gleise an ihren bestimmungsort (x-, y-position) gebracht werden.

obwohl mir die EV mit ihren möglichkeiten (sie wächst  ja ständig) gefällt, würde ich mir eine bessere nachverfolgung eines ereignisses über nicht so viele fenster wünschen. sollte dieses nur über eine neue andere art der programmierung erfolgen können, wäre es meiner meinug nach ok, die schnittstelle bliebe ja wahrscheinlich unberührt davon.(ich würde nur ungerne auf die tools von z.b. Easy verzichten wollen)

vg quackster

 

 

[BahnLand]

Hallo,

ungeachtet dessen, dass die "Programmierer" unter uns jeweils ihre "Lieblings"-Umgebung besitzen, in der sie programmieren, und diese Programme dann auch mit dem Modellbahn-Studio kooperieren können, halte ich insbesondere für den Betriebsablauf eine Steuerung über eine vom Modellbahnstudio angebotene und damit integrierte Scriptsprache für eine ernsthaft in Betracht zu ziehende Alternative.

Nach meiner Ansicht hat eine solche Schnittstelle, die direkt bedient werden kann und hierzu kein externes Programm benötigt, den Vorteil, dass nicht zwei unabhängige Programme parallel nebeneinander her laufen (beide verbrauchen CPU-Kapazität) und dann zusätzlich noch eine fortlaufende Synchronisation erfolgen muss (auch diese Kommunikation kostet zusätzliche CPU-Kapazität). Ich erwarte mir daher von einem in das Modellbahn-Studio integrierten Scripting im laufenden Modellbahn-Betrieb deutliche Performance-Vorteile gegenüber der Lösung mit externen Programmen.

Übrigens wurde bereits früher angeregt, dass es zusätzlich zu dem heute bereits möglichen Export der Definitionen aus der Ereignisverwaltung auch einen Import geben sollte, damit man Erweiterungen der Ereignisverwaltung außerhalb des Modellbahn-Studios möglicherweise komfortabler bewerkstelligen kann, als dies heute mit der relativ umständlichen Bedienung der Ereignisverwaltung innerhalb des Modellbahn-Studios möglich ist.

Auch hier würde ich deutliches "Verbesserungspotential" über eine Scriptsprache sehen, mit der man die Erstellung von "baugleichen" Definitionen in der Ereignisverwaltung, die sich nur durch unterschiedliche Objekt-Bezeichnungen unterscheiden, innerhalb des Modellbahn-Studios "automatisieren" könnte, ohne dafür den Umweg über einen möglichen Export, eine Modifizierung außerhalb des Modellbahn-Studios und den anschließenden (Re-)Import gehen zu müssen. Neben einem erhöhten Komfort würde dies insbesondere auch zu einer niedrigeren Fehleranfälligkeit (z.B. durch Tippfehler) führen.

Fazit:
Ich würde die Bereitstellung einer vom Modellbahn-Studio unterstützten und direkt verarbeiteten Scriptsprache sehr begrüßen.

Viele Grüße
BahnLand
 

 

 

[Neo]

Hallo BahnLand,

die Skriptsprache ist fest eingeplant, und wird zunächst auch nur für die Ereignisverwaltung kommen. Für die externen Programme wird es eine automatische Verknüpfung geben, wie hier besprochen.

Viele Grüße,

Neo