Eindeutigkeit der Objektvariationen und bilder fuer die Variationen

[gmd]

Neo,

in meinem verwaltungsprogramm bin ich jetzt etwas weiter und an einem punkt wo ich mehr informationen brauche. 

Ueber das api bekomme ich ja die thumb images aber nicht die variationen, da sie die gleiche guid haben. 
Was ist die URI fuer die variations images (thumbs).

Desweiteren waere es toll wenn das MBS die namen der variationen automatisch uebernehmen koennte statt immer
nur den namen der grundversion einzusetzen. 

Um die variationen zu identifizieren brauche ich mehr als nur die guid. Ueber info have ich die anzahl der polygone, die fuer variationen unterschiedlich ist.
Komme ich ueber LUA and diese info ? Kann ich uber LUA den variationsnamen abfragen ? Dann kann ich das in eine variable stellen und abholen.

Waere toll wenn du mir da auf die spruenge helfen koenntest.

Danke

Gmd

 

 

[Neo]

Hallo Gmd,

du kannst dem API-Aufruf noch einen Index-Parameter mitgeben:

https://api.3d-modellbahn.de/catalog/assets/{CONTENT-ID}?type=thumb&index=0

Es werden allerdings nur maximal 4 Vorschaubilder pro Asset generiert und im Online-Katalog gespeichert, d.h. du wirst nicht pro Variation ein Vorschaubild anfordern können.

vor 19 Stunden schrieb gmd:

Desweiteren waere es toll wenn das MBS die namen der variationen automatisch uebernehmen koennte statt immer
nur den namen der grundversion einzusetzen.

Was meinst du damit?

Per Lua kommst du nicht an statistische Informationen oder an Variationsnamen, die EV dient allein der Steuerung der Anlage. Was möchtest du mit den Variationsdaten anfangen?

Viele Grüße,

Neo

[gmd]

Zunaechst mal danke fuer die Antwort.
Ich bin weiter an meinem Verwaltungs/Betriebsplanung/Steuerungsprogramm. Habe einiges ueberarbeitet. Ziel ist es eine sehr grosse anlage in allen aspekten verwalten zu koennen. Ich brauche dazu nicht viele grundfunktionen, muss nur darauf achten dass alle namen eindeutig sind. Ich kann damit verschiedene dinge erreichen, z.b. ganze anlagenteile austauschen, wenn sie "genau passen", anlagenteile ausblenden um auf verdeckte teile zuzugreifen und vieles mehr. 

Man koennte ja mit layern arbeiten wirst du sagen fuer diese beispiele, aber das erfordert dass man total konsequent mit der plazierung ist und die eindimensionale layerliste hat eben grenzen fuer komplexe anlagen. Ich habe die moeglichkeit objektreferenzen aufzubauen und sie eigenen layern und layergruppen zuzuordnen, die wiederum an gebiete und segmente gehaengt werden. Ich habe die moeglichkeit vorhandene anlage automatisch zu strukturieren und alle objekte aufzuteilen. Das geht alles prima mit den vorhandenen kommandos bis zu dem punkt dass ich information verliere (variationen), wenn ich objekte nur ueber guid und einen namen ansprechen kann, aber das objekt nicht mit einer variation plazieren kann oder erkennen kann dass es eine variation ist. Dies kann ich verhindern wenn ich manuell variationen den variationsnamen vergebe (im MBS) und selbst eine liste pflege mit guid und variationsnamen. Mehrere objekte des gleichen namens machen mir dabei keine probleme.

Der erste schritt ist den manuellen aufwand im MBS zu verringern wenn die variationsbezeichnungen als name eingetragen werden. Das spart aufwand. Der zweite punkt ist es ein objekt als variation ueber schnittstelle erzeugen zu koennen oder als variation zu identifizieren, dann brauche ich keine zuordnungsliste zu pflegen. Das gilt auch fuer zugkonfigurationen mit vielen wagenvariationen. 

Diese punkte sind weder eilig noch extrem wichtig, es behindert mich nicht in meinem vorhaben, waere aber schoen wenn ich dann doch eine vollstaendige loesung hinbekomme. Ist eine anregung fuer die zukunft. 

Manche werden sich fragen was das ziel ist: Eine sehr grosse anlage automatisiert zu analysieren, vorgefertigte ablaufe anzuwenden und einen fahrplanbetrieb zu ermoeglichen und irgendwann vielleicht multiplayer. Was mich am meisten antreibt ist das ziel einen zug manuell in einer vollautomatisierten anlage zu fahren. Alle ablaefe muessen dynamisch korrigierbar sein, vielleicht (wahrscheinlich) regelbasiert und nicht algoriythmisch.

Du hattest ja angedeutet die schnittstelle zu veraendern/erweitern/verbreitern (was auch immer), damit werden natuerlich meine moeglichkeiten verbessert, aber derzeit bin ich noch mit grundfunktionen beschaeftigt. 

Eine schoene funktion ware eine tauschtextur spezifizieren zu koennen zur temporaeren visualisierung bestimmter abschnitte, ich behelfe mir derzeit aber mit beschriftungsobjekten die ich automatisch plaziere und dann ein und ausblenden kann. 

Mein derzeitiger stand ist:

Ich kann bloecke mit allen komponenten automatisch erkennen durch abfahren mit einem benannten fahrzeug. Gilt fuer schienen und strassen.
Kann signal, kontakt, weichen und gleiszustaende fuer mehrer bloecke optisch anzeigen zur betriebskontrolle (wird dann das stellpult treiben). 
Ich kann signale und kontakte automatisch plazieren wenn in einer abgefahrenen strecke keine erkannt wurden, die strecke aber gesichert werden soll. 
Ich kann Fahrwege (bloecke mit geschalteten weichen) zu fahrstrassen kombinieren. Das beinhaltet rangierwege etc. Fahrstrassen koennen zu routen kombiniert werden, fuer die dann ein fahrplan erstellt werden kann.  
Ich kann Wagen/Zug konfigurationen erstellen und automatisch auf startgleise positionieren (hier schlaegt das variationsproblem zu).
Fuer jeden erkannten block generiere ich automatisch einen schaltpultzweig (ausserhalb MBS) den ich in ein gesamtbild oder teilbild einsetzen und anpassen kann. (das ist noch nicht ganz fertig). Schaltpulte sind nach segmenten unterteilbar. 
Bei allem genannten natuerlich automatische eindeutige benennung aller teile.

Depotverwaltung, fahrplaene und steuerungsablauf kommen dann. Wird etwa so laufen wie meine blockdemo mit generischen, vorgefertigten scripts die manuell eingebracht werden und dann ueber variablen von extern gesteuert werden. 

Es ist eine andere art von Rockrail mit tieferer integration mit dem MBS. 

Das programm hat sehr viele "Hilfsfunktionen" und ich war in letzter zeit beschaeftigt einen neuen rahmen fuer die programme zu schaffen und besser zu dokumentieren, da ich ja immer wieder pausen mache und leichter wieder reinfinden moechte. 

Die vorige version hat eine zweistufige struktur (Gebiet,Block) unterstuetzt, das habe ich erweitert auf (Gebiet, Segment und Block).

Das nur mal als ueberblick.

Gruss

Gmd

 

 

 

 

 

 

 

 

[gmd]

Neo,

habe weiter getestet und die info mit dem index hat geholfen, dass ich zumindest erkenne das ein objekt variationen hat. 
Ich teste einmal ob mehrere bilder vorhanden sind und merke mir das mit dem Objekt. Ich habe auch einen weg gefunden die variationen zu plazieren. 

Das funktioniert bis 4 wie du ja gesagt hast. Ist fuer viele faelle schon ausreichend. Wenn es mehr als 4 sind mache ich das einmal manuell. 

Ich muss eben einmal fuer eine anlage die verwendeten variationen benennen und dann kann ich durch duplizieren neue variationen anlegen und positionieren. Nur wenn eine variation noch nicht vorhanden ist kann ich sie nicht automatisch plazieren. Das ist aber nicht so wichtig da ich ja die anlagen nicht baue sondern nur vorhandene analysiere und verwalte.

Ich kann auch durch einen bildvergleich fuer alle guid mit mehreren thumbs feststellen welche variation vorliegt und das objekt entsprechend benennen.

Ich habe ja ohnehin alle images auch von der seite fuer meinen zug designer und kann dann durch farbvergleich die variation ermitteln. 

Ist schon wieder ein stueck weiter  .. 

gruss

gmd

 

PS: Inzwischen ist mir die Idee gekommen, dass ich ja eine platte vorbereiten kann die alle variationen die ich haben will enthaelt, mit den richtigen namen und dann kann ich diese ja einfach "reinziehen" fuer die identifikation. Ist die anlage dann identifiziert kann man diese platte ja wieder loeschen. Das ist ausreichend fuer eine weile. 

Bearbeitet 21. März 2023 von gmd