Namensvergabe bei Import von Anlagen

[HaNNoveraNer]

Hi

Beschäftige mich gerade mit Modulen.
Ich speichere so ein Modul als Anlage mit GBS und LUA Scripten.

Wenn man nun mehrere Module in eine neue Anlage importiert, dann muß man ja höllisch aufpassen,
daß da nicht Dinge den gleichen Namen haben.

Leider werden ja die Namen und alles was dazu gehört (Variablen, Keywörter, Bezeichnungen, Ereignisse an Objekten, im GBS und in Lua) nicht automatisch angepaßt beim Import.

Und was ist, wenn ihr ein Modul 2x importiert? Dann sind die Namen sowieso gleich!

Wie geht ihr damit um?
Vergebt ihr in jeder "Anlage", die man importieren könnte EINDEUTIGE Namen für ALLES was wichtig ist?
Habt ihr bessere Ideen?

Gruß
Thomas

Bearbeitet 1. Oktober 2020 von HaNNoveraNer

[Neo]

Hallo Thomas,

vor 20 Minuten schrieb HaNNoveraNer:

dann muß man ja höllisch aufpassen, daß da nicht Dinge den gleichen Namen haben.

warum? Dem Studio ist es egal, wie ein Objekt heißt, oder ob mehrere Objekte den gleichen Namen verwenden, solange deine EV die seit V5 gängige Praxis der direkten Objektreferenzierung verwendet. Wenn dann wäre das nur für deine Übersicht wichtig.

Viele Grüße,

Neo

[HaNNoveraNer]

Hallo Neo

Beispiel Lua Befehl:

$("Containerkran1").variables["Waggon_coupled"].couplers[1].enabled=true

Wenn es nun 2 Objekte mit dem Namen "Containerkran1" gibt, woher weiß er dann, wer gemeint ist?
Irgendwie sehe ich den Wald vor lauter Bäumen nicht...

Gruß
Thomas

Bearbeitet 1. Oktober 2020 von HaNNoveraNer

[Neo]

Hallo Thomas,

$("Containerkran1") ist ja eigentlich kein valider Lua-Code. Tatsächlich funktioniert dieser Code auch nur im Studio, weil beim Speichern des Lua-Codes dieser Befehl durch einen anderen ersetzt wird, der die Speicheradresse des genannten Objekts enthält. Das Studio selbst arbeitet somit also intern nicht mehr mit Namen, diese dienen nur der Anzeige.

Viele Grüße,

Neo

[Goetz]

vor 37 Minuten schrieb HaNNoveraNer:

Irgendwie sehe ich den Wald vor lauter Bäumen nicht...

Vielleicht verstehst du es mit folgendem Experiment besser.

Stell drei Fahrzeuge auf ein Gleis / eine Straße.
Gib allen drei Fahrzeugen identische Namen.
Gib in einem einzigen Event jedem der drei Fahrzeuge einen anderen Geschwindigkeitsbefehl

 

Wenn du später die Namen der Autos änderst, dann ändert sich auch ihr Name in der EV

 

und ebenso im Lua Skript:

 

 

Bearbeitet 1. Oktober 2020 von Goetz
erstes Beispiel durch zweites, besseres ersetzt

[HaNNoveraNer]

Ok, ich hatte vergessen, daß man ja ein Objekt auswählen muß und den Befehl nicht eintippt.
Das kommt, wenn man lange nichts gemacht hat :-)
Ich hatte da auch an getEntityByName gedacht. Das funktionert dann ja nicht mehr.

Jetzt muß ich mir nur noch überlegen, wie man so ein Objekt dann auf der Anlage schnell findet, ohne alle in der Stückliste durchzuprobieren.

Gruß
Thomas

[HaNNoveraNer]

Zur völligen Unübersichtlichkeit erzeugt Lua bei gleicher Namensvorhandenheit (was ein Wort) automatisch sowas:

$("rg1#2").text = zname.name

Obwohl das Objekt sauber aus der Objektliste ausgewählt wurde und dort immer noch nur "rg1" heißt.
 

Gruß
Thomas

[Goetz]

vor 9 Minuten schrieb HaNNoveraNer:

Zur völligen Unübersichtlichkeit

Es hilft dir, zwei Objekte gleichen Namens im Skript auseinanderzuhalten. Ohne diese Unterscheidung wüsstest du nicht, dass es sich einmal um Fahrzeug A und das andere Mal um Fahrzeug B handelt.

Sobald du die Objektnamen änderst, siehst du auch im Skript die geänderten Namen

[HaNNoveraNer]

Ihr findet auch immer eine scheinbar gute Erklärung

Wenn das analog auch im Selektionsfenster angezeigt/passieren würde, wäre es perfekt!
Dann könnte man das Objekt gut wiederfinden und den Namen auch von Hand eintippen.

Bearbeitet 2. Oktober 2020 von HaNNoveraNer

[Neo]

Hallo,

vor 7 Minuten schrieb HaNNoveraNer:

Ihr findet auch immer eine scheinbar gute Erklärung

du musst das von der anderen Seite betrachten. Angenommen, du schreibst ein Skript und referenzierst darin zwei Objekte, die den gleichen Namen besitzen (über die integrierte Auswahlliste). Ohne eine automatische Nummerierung würde das Skript so aussehen:

local vehicle1 = $("Meine Lok")
local vehicle2 = $("Meine Lok")

Wenn du jetzt speicherst, ist es für das Studio nicht mehr möglich, den Code auf deine ursprüngliche Objektauswahl zurückzuführen. Aus diesem Grund werden bei Objekten mit gleichem Namen im Skript temporär Nummerierungen eingeführt. Wichtig also für die dahinterstehende Logik, bringt dir natürlich keine verbesserte Übersicht, aber das Problem hast du vorher ja auch schon, wenn alle Objekte gleich heißen.

Was eigentlich wichtiger ist, ist das Loslösen von spezifischen Objektreferenzierungen. Benötigst du immer einen expliziten Zugriff auf ein konkretes Objekt, oder könnten Skripte nicht auch implizit auf Objekte zugreifen, z.B. durch ein auslösendes Fahrzeug in einem Ereignis? Wenn du generische Anlagen mit beliebigen Modulen planst, wirst du um generische und abstrakte Skripte/EV-Aktionen nicht herum kommen.

Viele Grüße,

Neo

[HaNNoveraNer]

Interessante Diskussion.

Generisch geht nur, wo es möglich ist.
Bei der Connection-Eigenschaft eines Fahrtreglers kann ich diesen nicht generisch adressieren.

Das Problem ist ja nur, daß wir die interne Objekt-ID nicht sehen.

>>> Wenn du jetzt speicherst, ist es für das Studio nicht mehr möglich, den Code auf deine ursprüngliche Objektauswahl zurückzuführen.  >>>
Ah, das wußte ich noch nicht. Da wird als NUR für Lua Scripte eine eindeutige Bezeichnung generiert, die dann beim Objekt abgelegt wird, um es zu identifizieren.

Was spricht denn dagegen, dies für ALLE Objekte grundsätzlich zu machen und auch im Selektionsfenster und im Eigenschaftsfenster anzuzeigen?

Gruß
Thomas

 

 

Bearbeitet 2. Oktober 2020 von HaNNoveraNer

[Neo]

Hallo,

vor 16 Minuten schrieb HaNNoveraNer:

Bei der Connection-Eigenschaft eines Fahrtreglers kann ich diesen nicht generisch adressieren.

hier könnte eine Erweiterung interessant sein, aktuell könntest du das Problem prototypisch über einen Timer lösen, der kontinuierlich die Werte des Drehreglers auf ein (generisches) Fahrzeug überträgt.

vor 21 Minuten schrieb HaNNoveraNer:

Das Problem ist ja nur, daß wir die interne Objekt-ID nicht sehen.

Das wäre keine Lösung, weil die internen IDs nicht statisch sind. Wenn du z.B. ein Modul in eine vorhandene Anlage einfügst, bekommen alle Objekte aus dem Modul eine neue ID, da es keine Kollisionen mit den IDs aus der Anlage geben darf. Du kannst dich bei diesen IDs daher nicht darauf verlassen, dass ein Objekt diese dauerhaft behält. Somit wäre es auch nicht clever, die IDs nach Außen hin anzuzeigen, weil du mit diesen Informationen wenig anfangen kannst.

vor 24 Minuten schrieb HaNNoveraNer:

Ah, das wußte ich noch nicht. Da wird als NUR für Lua Scripte eine eindeutige Bezeichnung generiert, die dann beim Objekt abgelegt wird, um es zu identifizieren.

Richtig, diese temporäre Nummerierung gibt es nur in Lua-Skripten, weil diese reine Textdateien sind und theoretisch auch über externe Editoren bearbeitet werden könnten, weshalb das Studio dort keine "internen" Daten speichern kann.

vor 26 Minuten schrieb HaNNoveraNer:

Was spricht denn dagegen, dies für ALLE Objekte grundsätzlich zu machen und auch im Selektionsfenster und im Eigenschaftsfenster anzuzeigen?

Geht es dir darum, dass das Studio selber Objekte umbenennt (nummeriert), wenn Objekte mit gleichem Namen bereits existieren, z.B. beim Einfügen aus dem Katalog oder aus einer anderen Anlage? Wäre sicherlich machbar, hätte bei mir aber keine hohe Priorität, weil "Dampflok" vs "Dampflok #2" eigentlich nichts an dem Problem ändert, dass man nicht weiß, welche Lok nun hinter welchem Namen steht.

Viele Grüße,

Neo

[HaNNoveraNer]

Genau darum geht es nun.
Klar hat das keine Priorität.

>>> weil "Dampflok" vs "Dampflok #2" eigentlich nichts an dem Problem ändert, dass man nicht weiß, welche Lok nun hinter welchem Namen steht  <<<
Doch, man könnte dann im Selektionsfenster die Lok schnell finden.
VIelleicht sogar mit Doppelclick auf den Namen im Script?

Aber Du hättest das gleiche Problem wie mit den ID's.
Es gibt sicherlich Fälle, in denen eine fortlaufende Numerierung nicht möglich wäre.
Es sei denn man läßt Lücken zu, wenn ganze Gruppen wieder gelöscht werden.

Gruß
Thomas

 

Bearbeitet 2. Oktober 2020 von HaNNoveraNer