Neue Schalterfunktion mit einheitlichen Namen

[Cafépause]

vor 2 Stunden schrieb Goetz:

Weil man z.B. praktisch nur entweder einen Blinker oder die Warnblinkanlage einschalten kann.

Das stimmt so aber auch nur bedingt. Betätige ich im Auto den Blinker (Seite egal) und den Warnblinker, den blinken alle Blinker am Fahrzeug. Die Warnblinkfunktion überschreibt den Blinker nur, nimmt ihn aber nicht zurück.

Schalte ich am realen Fahrzeug den Warnblinker aus, wird der gesetzte Blinker weiter funktionieren.

Habe ich eine Verkaufsstelle mit Tag,- und Nachtbeleuchtung, nimmt auch hier die gleichzeitig gesetzte Schaltmöglichkeit Tag (alles an) und Nacht (Sparbeleuchtung / Putzbeleuchtung) keine Veränderung an der jeweils anderen Schaltmöglichkeit vor.

Es sind "or"-Schaltungen. Ist bei der Verkaufsfläche Tag- oder Nachtbetrieb gesetzt, Beleuchtung an. Ist der Blinker gesetzt oder der Warnblinker eingeschaltet, dann blinkt es.

Ich betrachte dies als normales Betriebsverhalten. 

VG, Cafépause 

[prinz]

vor 4 Stunden schrieb gmd:

Ich habe einen weg gebaut die animationsmoeglichkeiten der einzelnen fahrzeuge automatisch zu ermitteln

Nach einer Idee von @EASY hatte ich das auch schon mal gemacht (s. Anlage "Animationen für Bahnfahrzeuge" ID: 4879AD06-54F0-4533-B9A3-A1B96EBAB35D ). Mittlerweile gibt es dasselbe Verfahren für Straßenfahrzeuge (Blinker, Fahrlicht, etc.). Dies bezog sich damals noch auf die Animationsnamen. Es kann aber leicht auf integrierte Schalter umgebaut werden.

Allerdings:

1. Wenn mehrere Animationen in einem erweiterten Schalter zusammengefasst werden (z.B. Blinker/Warnblinker), funktioniert das Verfahren nicht mehr.
2. Die Ermittlung und Pflege der Animations-/Schalternamen ist sehr aufwändig. Neue Modelle müssen in diese Listen eingearbeitet werden.

Da nach der initialen Erzeugung der Schalternamen (1:1 zu Animationen) ist die Wahrscheinlichkeit hoch (wie auch die Diskussion hier zeigt), dass immer mehr
erweiterte Schalterfunktionen eingesetzt werden. Hierzu müssten die Parameterlisten und Schalterermittlung um diese Daten ergänzt werden. Das möchte ich mir
dann doch nicht zumuten

In diesem Sinne, viele Grüße
    Wolfgang

[streit_ross]

Wenn man statt Vielem sogar alles realitätsnah haben möchte, kann es auch nach hinten losgehen;

Gruß

streit_ross

 

[Goetz]

@streit_ross   

[gmd]

6 hours ago, prinz said:

Nach einer Idee von EASY hatte ich das auch schon mal gemacht (s. Anlage "Animationen für Bahnfahrzeuge" ID: 4879AD06-54F0-4533-B9A3-A1B96EBAB35D ). Mittlerweile gibt es dasselbe Verfahren für Straßenfahrzeuge (Blinker, Fahrlicht, etc.). Dies bezog sich damals noch auf die Animationsnamen. Es kann aber leicht auf integrierte Schalter umgebaut werden.

Allerdings:

1. Wenn mehrere Animationen in einem erweiterten Schalter zusammengefasst werden (z.B. Blinker/Warnblinker), funktioniert das Verfahren nicht mehr.
2. Die Ermittlung und Pflege der Animations-/Schalternamen ist sehr aufwändig. Neue Modelle müssen in diese Listen eingearbeitet werden.

Da nach der initialen Erzeugung der Schalternamen (1:1 zu Animationen) ist die Wahrscheinlichkeit hoch (wie auch die Diskussion hier zeigt), dass immer mehr
erweiterte Schalterfunktionen eingesetzt werden. Hierzu müssten die Parameterlisten und Schalterermittlung um diese Daten ergänzt werden. Das möchte ich mir
dann doch nicht zumuten

In diesem Sinne, viele Grüße
    Wolfgang

Das erkennen und das pflegen ist aufwending, wenn man nicht externe hilfe in anspruch nimmt(damit meine ich die schnittstelle). Das Mbs kennt ja alle schalternamen fuer jedes objekt, die koennte Neo ja zugaenglich machen, bleibt aber die konsolidierung der namen zu einheitlichen funktionen. Da gibt es natuerlich viele funktionen die nicht fuer viele modelle vorhanden sind aber das kann man auch regeln.
Also hier die beschreibung meines vogehens:
Ich erzeuge meine objekt seitenbilder in meiner app auf aehnliche weise, daher kommt die idee. Meine App hat den katalog aller modelle und kann sie automatisch auf einer testanlage plazieren und einzel selektieren. Das fuehrt dazu dass die schalter im  steuerungsfenster angezeigt werden. Das steuerungsfenster wird an einer bestimmten stelle des bildschirms positioniert und es wird ein screenshot gemacht und unter dem modellnamen abgespeichert. Das geht vollautomatisch. Dann lade ich die benannten files in badges in den AI und der macht fuer mich die listen.

Hier ein einzelner dialog, das habe ich weiter automatisiert. Damit erhalte ich listen wie diese:

('DH 500 Ca')
['01 Dach ausblenden']
['02 Spitzenlicht vorne']
['03 Spitzenlicht hinten']
['04 Schlusslicht vorne']
['05 Schlusslicht hinten']
['06 Führerstandsbeleuchtung']
['07 Tür rechts']
['08 Tür links']

('MAK1202-1205')
['Kabinenbeleuchtung']
['Lifter']
['Rotlicht-hinten']
['Rotlicht-vorne']
['Spitzenlicht-hinten']
['Spitzenlicht-vorne']

('V200')
['Frontlicht_rot']
['Frontlicht_weiss']
['Kabinenbeleuchtung hinten']
['Kabinenbeleuchtung vorne']
['Maschinenbelüftung']
['Maschinenraum_Beleuchtung']
['Rücklicht_rot']
['Rücklicht_weiss']
['x- Info']

Die wird in die Db geladen. Das habe ich als vorbereitung fuer mein konzept getestet, habe die anforderungen und das konzept beschrieben und wollte anfangen zu programmieren, habe aber zuerst den post gemacht der dann in diesem thread gelandet ist. 
Der naechste schritt ist eine groessere schnittmenge an animationen zu ermitteln, die standardisierte liste zu erstellen und dann die animationen zuzuordnen. Das geschieht mit hilfe eines grids. Der AI erkennt die zusammenhaenge recht gut und liefert 90%-95% der zuordnungen. Das programm speichert diese und in dem grid kann man das kontrollieren,. Ich habe auch eine testfunktion geplant in der man ein objekt auswaehlt(in meinem katalog), das wird auf der anlage positioniert und die animationen werden automatisch durchgespielt.
Alles das ist nur ueber die schnittstelle sinnvoll zu loesen und funktioniert nicht im Mbs direkt, dazu sind einfach nicht genuegend funktionen vorhanden und das uebersteigt auch die zielsetzung, da persistenz (datenspeicherung) gebraucht wird und wesentlich mehr funktionalitaet (user interface) als Lua breitstellt. Viele funktionen werden immer nur sinnvoll ueber externe programme machbar sein. 
Hier noch ein beispiel:
Ich habe mich ein paar stunden mit fahrstrassen beschaeftigt, aber auch hier sind ausgefeilte steuerungen nur extern machbar. Fahrstrassen sind eine gute idee und ein sehr effizientes konzept fuer die EV schnell, komplexere strecken zu schalten, aber blocksicherung und effektive nutzung eines verzweigten netzes sind muehsam. Je laenger die fahrstrasse, um so mehr wird blockiert. Ich kann halt eine fahrstrasse bestehend aus 5 bloecken nicht von 3 zuegen befahren lassen. Eine komplexe steuerung ist auch hier nur extern moeglich, deshalb schreibe ich ja mein programm.
Gruss
Gmd

 

 

Bearbeitet Sonntag um 23:13 Uhr von gmd

[prinz]

Hallo @gmd,

Zunächst einmal: Klasse Verfahren. Das gefällt mir sehr gut. Wie immer, ist auch ein Aber dabei:

Wenn die Zuordnung von Steuerungsnamen, die ja keiner Normierung unterliegen, zu "neutralen" Steuerungsnamen weitestgehend die AI übernimmt, ist das schon ein Riesenschritt zu einer Lösung. Wie willst Du aber aus einem statischen Screenshot die Unterfunktionen erkennen? Hier ein Beispiel (war hier im Thread schon mal aufgeführt):

Das halte ich zumindest für schwer.

Trotzdem:

Viele Grüße,
    Wolfgang

 

[gmd]

t seems my environment for processing the image has reset, and I don't have access to the necessary language data files for Tesseract. Let me fix this and retrieve the text for you.

Here is the extracted text from the image in the requested format:

plaintext

CopyEdit

['Steuerung'] ['Maschinen-Abgase links'] ['Maschinen-Abgase rechts'] ['Maschinen-Lüfter'] ['Beleuchtung hinten'] ['0- aus'] ['Beleuchtung vorn'] ['Licht hinten'] ['0- aus'] ['Licht vorn'] ['0- aus'] ['O'] ['Antrieb einschalten']

Let me know if you need any corrections or further assistance!

ich habe nur das image in meinen chat gepostet, habe einen batch fuer sowas

gruss
Gmd

PS: und mit besseren instruktionen kann man dann auch nur die wirklich relevanten teile filtern .. bin dabai das alles zu implementieren, gib mit 2-3 tage

 

Bearbeitet Montag um 09:30 Uhr von gmd

[gmd]

und hier der screenshot vom chat.
gruss

Gmd

[gmd]

nur zur illustration. Ich habe begonnen das zu implementieren, habe die db tabellen definiert und eine kurze anforderungsbeschreibung mit den db tabellen fuer den ai gemacht und das bekam ich zurueck:

you have created these lists from images ['01 Dach ausblenden'] ['02 Spitzenlicht vorne'] ['03 Spitzenlicht hinten'] ['04 Schlusslicht vorne'] ['05 Schlusslicht hinten'] ['06 Führerstandsbeleuchtung'] ['07 Tür rechts'] ['08 Tür links'] I want to store them in this table public partial class Vehicleanimation { public ulong Id { get; set; } public string Name { get; set; } public ulong? TypeId { get; set; } public string Description { get; set; } public ulong? FollowedBy { get; set; } public ulong? AnimationOwnerId { get; set; } public virtual Objektreferenz AnimationOwner { get; set; } public virtual Vehicleanimation FollowedByNavigation { get; set; } public virtual ICollection<Vehicleanimation> InverseFollowedByNavigation { get; set; } = new List<Vehicleanimation>(); public virtual Vehicleanimationtype Type { get; set; } public virtual ICollection<Vehicleanimationparameter> Vehicleanimationparameters { get; set; } = new List<Vehicleanimationparameter>(); } I want to link them individually to a type public partial class Vehicleanimationtype { public ulong Id { get; set; } public string TypeName { get; set; } public string Description { get; set; } public virtual ICollection<Vehicleanimationparameter> Vehicleanimationparameters { get; set; } = new List<Vehicleanimationparameter>(); public virtual ICollection<Vehicleanimation> Vehicleanimations { get; set; } = new List<Vehicleanimation>(); } and each animation can have properties(parameters) public partial class Vehicleanimationparameter { public ulong Id { get; set; } public ulong? TypeId { get; set; } public ulong? AnimationId { get; set; } public float? Duration { get; set; } public sbyte? IsLoop { get; set; } public sbyte? IsNight { get; set; } public sbyte? IsDay { get; set; } public sbyte? HasSound { get; set; } public sbyte? HasRepeat { get; set; } public float? Interval { get; set; } public sbyte? MovingOnly { get; set; } public sbyte? StoppedOnly { get; set; } public sbyte? CompleteBeforeMoving { get; set; } public sbyte? StartAfterEngineOff { get; set; } public virtual Vehicleanimation Animation { get; set; } public virtual Vehicleanimationtype Type { get; set; } } thiese parameters can be used as a preset for a type (template for the animation parameters) and for each individual animation Animations are linked with vehicles via the table ObjectReference Thast part of the prject, Now lets start with an edit funktion for the types with the ability to enter presets for each type Best is to use a syncfusion data grid and NOTE most parameters are TINYINTS with -1 not applicable 1 = true 0 = false do you need anything else ? I want the View in xaml UserControl and the Viewmodel which I load into a dockingmanager

ChatGPT said:

ChatGPT

To create an edit functionality for Vehicleanimationtype that includes presets for animation parameters using a Syncfusion DataGrid, we will need the following:

1. ViewModel: A VehicleanimationtypeEditViewModel with properties to manage Vehicleanimationtype and its associated Vehicleanimationparameter entries.
2. UserControl: A XAML view for editing types and entering presets using a Syncfusion DataGrid.
3. Command Logic: Commands for adding, saving, and deleting entries.
4. Data Binding: Bindings between the ViewModel and the DataGrid for CRUD operations.

Implementation Plan

1. ViewModel: VehicleanimationtypeEditViewModel

csharp

CopyEdit

using CommunityToolkit.Mvvm.ComponentModel; using CommunityToolkit.Mvvm.Input; using Syncfusion.Data.Extensions; using System.Collections.ObjectModel; public class VehicleanimationtypeEditViewModel : ObservableObject { private readonly DBContextManager _dbContextManager; public VehicleanimationtypeEditViewModel(DBContextManager dbContextManager) { _dbContextManager = dbContextManager; LoadTypes(); LoadParameters(); } public ObservableCollection<Vehicleanimationtype> VehicleanimationTypes { get; set; } = new(); public ObservableCollection<Vehicleanimationparameter> AnimationParameters { get; set; } = new(); private Vehicleanimationtype _selectedType; public Vehicleanimationtype SelectedType { get => _selectedType; set { SetProperty(ref _selectedType, value); LoadParametersForType(value); } } private void LoadTypes() { var types = _dbContextManager.DbContext.Vehicleanimationtypes.ToList(); VehicleanimationTypes = new ObservableCollection<Vehicleanimationtype>(types); } private void LoadParameters() { var parameters = _dbContextManager.DbContext.Vehicleanimationparameters.ToList(); AnimationParameters = new ObservableCollection<Vehicleanimationparameter>(parameters); } private void LoadParametersForType(Vehicleanimationtype type) { if (type != null) { var parameters = _dbContextManager.DbContext.Vehicleanimationparameters .Where(p => p.TypeId == type.Id) .ToList(); AnimationParameters = new ObservableCollection<Vehicleanimationparameter>(parameters); } } [RelayCommand] private void SaveType() { _dbContextManager.DbContext.SaveChanges(); LoadTypes(); } [RelayCommand] private void AddType() { var newType = new Vehicleanimationtype { TypeName = "New Type" }; VehicleanimationTypes.Add(newType); _dbContextManager.DbContext.Vehicleanimationtypes.Add(newType); } [RelayCommand] private void DeleteType() { if (SelectedType != null) { _dbContextManager.DbContext.Vehicleanimationtypes.Remove(SelectedType); VehicleanimationTypes.Remove(SelectedType); SelectedType = null; } } }

2. XAML: VehicleanimationtypeEditView.xaml

xml

CopyEdit

<UserControl x:Class="YourNamespace.Views.VehicleanimationtypeEditView" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:syncfusion="http://schemas.syncfusion.com/wpf" mc:Ignorable="d"> <DockPanel> <StackPanel Orientation="Horizontal" DockPanel.Dock="Top" Margin="5"> <Button Content="Add Type" Command="{Binding AddTypeCommand}" Margin="5"/> <Button Content="Save" Command="{Binding SaveTypeCommand}" Margin="5"/> <Button Content="Delete" Command="{Binding DeleteTypeCommand}" Margin="5"/> </StackPanel> <syncfusion:SfDataGrid x:Name="TypeGrid" AutoGenerateColumns="False" ItemsSource="{Binding VehicleanimationTypes}" SelectedItem="{Binding SelectedType, Mode=TwoWay}" Margin="5"> <syncfusion:SfDataGrid.Columns> <syncfusion:GridTextColumn HeaderText="ID" MappingName="Id" IsReadOnly="True"/> <syncfusion:GridTextColumn HeaderText="Type Name" MappingName="TypeName"/> <syncfusion:GridTextColumn HeaderText="Description" MappingName="Description"/> </syncfusion:SfDataGrid.Columns> </syncfusion:SfDataGrid> <TextBlock Text="Presets for Selected Type:" Margin="5"/> <syncfusion:SfDataGrid x:Name="ParameterGrid" AutoGenerateColumns="False" ItemsSource="{Binding AnimationParameters}" Margin="5"> <syncfusion:SfDataGrid.Columns> <syncfusion:GridTextColumn HeaderText="ID" MappingName="Id" IsReadOnly="True"/> <syncfusion:GridNumericColumn HeaderText="Duration" MappingName="Duration" /> <syncfusion:GridCheckBoxColumn HeaderText="IsLoop" MappingName="IsLoop" /> <syncfusion:GridCheckBoxColumn HeaderText="IsNight" MappingName="IsNight" /> <syncfusion:GridCheckBoxColumn HeaderText="IsDay" MappingName="IsDay" /> <syncfusion:GridCheckBoxColumn HeaderText="HasSound" MappingName="HasSound" /> <syncfusion:GridCheckBoxColumn HeaderText="HasRepeat" MappingName="HasRepeat" /> </syncfusion:SfDataGrid.Columns> </syncfusion:SfDataGrid> </DockPanel> </UserControl>

3. Docking Manager Setup

Load the VehicleanimationtypeEditViewModel into a docking manager using your existing infrastructure.

For example:

csharp

CopyEdit

var editView = new VehicleanimationtypeEditView { DataContext = new VehicleanimationtypeEditViewModel(dbContextManager) }; dockingManager.Children.Add(editView);

Das ist fertig lauffaehiger code, nicht immer correct aber mit ein paar korrekturen spart man jede menge tipparbeit und bekommt den optimierten code.

Meine produktivitaet mit dem AI ist faktor 10 wenn nicht mehr. Wenn das zuviel ist hier dann bitte sagen und ich loesche den post.
gruss
Gmd


 

[Neo]

vor 17 Minuten schrieb gmd:

Meine produktivitaet mit dem AI ist faktor 10 wenn nicht mehr. Wenn das zuviel ist hier dann bitte sagen und ich loesche den post.

Das Extrahieren von Schalternamen per Screenshot und einer KI halte ich für übertrieben, die Daten kann ich euch ohne Fehleranfälligkeit auch im Studio bereitstellen.

[gmd]

Neo,

danke, Ich hatte das ja bereits erwaehnt war aber nicht sicher ob du dazu bereit bist.
Natuerlich ist das die beste loesung , frage ist nur in welcher form.

Warte auf die liste und mal schauen was ich daraus machen kann.
Gruss
Gmd

 

[Neo]

Hallo,

folgendes Archiv enthält eine sortierte Liste aller Schalternamen aller Modelle im Online-Katalog (inkl. Archiv):
Schalter.zip

Es wird schnell klar, dass die fehlende Standardisierung zu einem Wildwuchs von Schalternamen geführt hat. Wenn wir aus der vorhandenen Liste "Standardnamen" extrahieren können, kann ich diese als Vorlagen direkt in das Studio einbauen, sodass Modellbauer beim Erstellen neuer Aktionen sofort auf bekannte Namen zurückgreifen können. Diese Vorlagen hätten den Vorteil, dass sie übersetzbar wären (so wie die Weichen- und Signalstellungen). Zusätzlich zu den Standardnamen müsste man sich aber auch entscheiden, ob es sich um einen einfachen oder um einen erweiterten Schalter handelt (um z.B. Abblend- und Fernlichter zusammenzufassen). Mit den Schaltern ab V9 möchte ich ja weg von der Einzelansteuerung der Modellanimationen, hin zu generischen Modellfunktionen.

Wenn die Standardisierung funktioniert, würde ich eine Kompatibilitätsfunktion einbauen, um Bestandsmodelle an das neue System anzupassen.

Viele Grüße,

Neo

[prinz]

Hallo @Neo,

Das ist schon eine tolle Hilfe. Wie ich der Liste entnehme, sind die erweiterten Schalter noch nicht enthalten. Wenn Du das noch ergänzend könntest. Ein Vorschlag für Erweiterten Schalter "Beleuchtung hinten" bei E-Lok Modell BR 285:

Beleuchtung hinten|0 - aus|1 - Führerkabine|2 - Führerstand|3 - Führerkabine und Führerstand

Wobei das Pipe-Zeichen (|) als Trennzeichen dient und nicht in den Schalternamen vorkommen sollte.

Für alle Steuerungen wird wohl keine Normierung notwendig sein (z.B. Segel reffen vorn). Aber für bestimmte, oft in der EV benötigte Steuerungen sollten Standard-Steuerungsnamen festgelegt werden. Ein erster Vorschlag wäre:

Bahnfahrzeuge:

Tueren|0 - links|1 - rechts
Fahrlicht|0 - vorn|1 - hinten
Fernlicht|0 - vorn|1 - hinten
Schlusslicht|0 - vorn|1 - hinten
Innenbeleuchtung
Pantograf|0 - vorn|1 - hinten

Straßenfahrzeuge:

Blinker|0 - links|1 - rechts
Bremslicht
Fahrlicht
Tueren|0 - links|1 - rechts
 

Lichtobjekte (Laternen etc.)

Licht

Wie weit man mit anderen Modellen (z.B. beleuchtete Häuser) verfahren möchte, sollte diskutiert werden, besonders bei Häusern, die mehrere Beleuchtungsmöglichkeiten anbieten. Da sind wohl die Geschmäcker verschieden.

Noch eine Anmerkung: Ist bei einer Standardfunktion (z.B. Fahrlicht) bei einem Modell nur eine Steuerung für "0 - vorn" vorhanden, müsste für "1 - hinten" eine Dummy-Funktion eingerichtet werden.

Viele Grüße,
    Wolfgang

 

 

Bearbeitet Montag um 11:38 Uhr von prinz
Dummy ergänzt

[gmd]

Neo,

zunaechst einmal danke, ABER .. lol die liste ist ja keine zuordnung von schalter zu modellen und das ist ja das entscheidende.

Ich bin dabei  eine datenstruktur aufzubauen und animationen zu typisieren und mit eigenchaften zu versehen, die dann als steuerungsparameter verwendet werden koennen.
Bin gerne bereit hier input zu erhalten. Animationen koennen eigenschaften haben, was noch fehlt sind richtungsbedingungen, ich betrachte zunaechst einmal nur fahrzeuge.
Typen dienen zur schnelleren definition von eigenschaften und steuerfunktionen.
Mal sehen was daraus wird, werde regelmaessig berichten und du kannst ja deinen input dazu geben, happy to oblige.
Nun was machen wir mit dem problem der fahrzeugzuordnung, wieder zurueck zum AI ? klingt schlimmer als es ist und die fehlerquote ist gering.
Gruss
Gmd

 

[Phrontistes]

vor 1 Minute schrieb gmd:

was noch fehlt sind richtungsbedingungen

Eigentlich nicht. Solange die Modellbauer die Begriffe "rechts" bzw. "links" als in Fahrtrichtung rechts/links definiert haben (was soweit ersichtlich durchweg der Fall ist) ist es einfach per EV die "richtigen" Türen anzusprechen weil man die Fahrtrichtung des Verbandes kennt und weil man die Orientierung jedes einzelnen Fahrzeuges feststellen kann (und weil man weiß, ob der Bahnsteig links oder rechts ist).

Für die mehrwertigen Schalter musst Du beachten, dass zwei Informationen gebraucht werden: Schaltername (text) und Schalterstellung (number). Für Türen in einem mehrwertigen Schalter eines (noch nicht veröffentlichten)  V9-Fahrzeuges (Name: "Türen"; 0 = Alle Türen zu, 1 = Türen rechts, 2 = Türen links, 3 = Alle Türen auf) mache ich das so nachdem ich in die Fahrzeugvariable (Liste mit zwei Einträgen) "9 Doors R open" "Türen" und "2" hineingeschrieben habe.

if Vehicle.variables["9 Doors R open"] ~= nil then
  Vehicle.actions[Vehicle.variables["9 Doors R open"]["1"]].state = Vehicle.variables["9 Doors R open"]["2"]
  Vehicle.actions[Vehicle.variables["9 Doors R open"]["1"]].autoMode = ""

Die mehrwertigen Schalter müssen anders behandelt werden als bisher. Der Code geht für die bisherigen Animationen wie folgt weiter:

else
  if Vehicle.variables["Doors at right side"] ~= nil then
    if Vehicle.variables["Door speed"] ~= nil then
      Vehicle.animations[Vehicle.variables["Doors at right side"]]:play(-1, 1, -1, -1, Vehicle.variables["Door speed"])
    else
      Vehicle.animations[Vehicle.variables["Doors at right side"]]:play(-1, 1)
    end
  end

Die Animationsgeschwindigkeit kann man übrigens mit den neuen V9-Schaltern (noch) nicht verändern, das will @Neo aber noch implementieren.

vor 53 Minuten schrieb Neo:

Mit den Schaltern ab V9 möchte ich ja weg von der Einzelansteuerung der Modellanimationen, hin zu generischen Modellfunktionen.

Das musst Du manchem Modellbauer aber noch deutlicher rüberbringen, sonst setzen diese die alte Logik fort und bauen Schalterbänke wie hier.

Beste Grüße

Phrontistes

[Neo]

vor 39 Minuten schrieb prinz:

Wie ich der Liste entnehme, sind die erweiterten Schalter noch nicht enthalten.

Ich habe die Liste ersetzt, nun enthält sie auch die Zustandsnamen der erweiterten Schalter.

vor 35 Minuten schrieb gmd:

die liste ist ja keine zuordnung von schalter zu modellen und das ist ja das entscheidende.

Im Moment nicht, so eine Zuordnung wird erst dann wichtig, wenn wir uns für einen Standard entschieden haben und die Bestandsmodelle anpassen möchten. Lass uns zunächst bei einem Thema bleiben und einen Standard evaluieren.

vor 8 Minuten schrieb Phrontistes:

Für Türen in einem mehrwertigen Schalter

Ein erweiterter/mehrwertiger Schalter sollte nur für exklusive Zustände genutzt werden, nicht für alle möglichen Kombinationen, die auch einzeln ansteuerbar sind. Türen würde ich daher auch in Zukunft über einen linken und rechten Schalter getrennt ansteuern. Ein mehrwertiger Schalter bietet sich bei der Beleuchtung an, wo z.B. ein Abblendlicht und ein Fernlicht sich gegenseitig ausschließen.

Das Einführen von Standardschaltern wird nur ein erster Schritt sein und nicht alle Probleme lösen. Es wird langfristig auch eine Erweiterung des Automatikmodus geben, um z.B. Blinker oder Türen automatisch zu steuern (damit der Nutzer für Standardaktionen nicht immer wieder die gleiche EV schreiben muss).

Meine Empfehlung ist daher, mit den Vorlagen von Standardschaltern zu beginnen und die Bestandsmodelle auf das einheitliche System umzustellen. Damit werden schon viele Bereiche vereinfacht werden (mit dem Zusatz, dass die Standardschalter später maschinell bearbeitet werden können, falls sich Standards ändern).

Viele Grüße,

Neo

[gmd]

12 minutes ago, Phrontistes said:

Eigentlich nicht. Solange die Modellbauer die Begriffe "rechts" bzw. "links" als in Fahrtrichtung rechts/links definiert haben (was soweit ersichtlich durchweg der Fall ist) ist es einfach per EV die "richtigen" Türen anzusprechen weil man die Fahrtrichtung des Verbandes kennt und weil man die Orientierung jedes einzelnen Fahrzeuges feststellen kann (und weil man weiß, ob der Bahnsteig links oder rechts ist).

 

Das hast du misverstanden, ich meine nur ob eine animation richtungsabhaengig ist, pantograf, tueren, stirnlicht usw. aber nicht rauch, abgase, kabinenlicht etc ..
bei der typisierung geht is um eigenschaftstypen.
Gruss
Gmd

 

[gmd]

2 minutes ago, Neo said:

 

Im Moment nicht, so eine Zuordnung wird erst dann wichtig, wenn wir uns für einen Standard entschieden haben und die Bestandsmodelle anpassen möchten. Lass uns zunächst bei einem Thema bleiben und einen Standard evaluieren.

Das ist mir nicht genug, sorry. Ich verwende liebe komplette daten auch wenn sie nicht standardisiert sind, und werde daraus einen standard fuer mich ableiten.  Ich bin ja auch nicht auf einfach oder mehrfachschalter angewiesen und es ist fuer mich auch nicht wichtig ob ein modell alle funktionen hat, ich muss einfach nur wissen ob eine funktion vorhanden ist und wie sie heist. Wenn daraus etwas allgemein verwendbares entsteht, oder zumindest anregungen gibt, dann ok, aber ich warte nicht bis eine solche diskussion abgeschlossen ist. Es kostet mich nicht mehr als ein paar stunden die liste zu erstellen die ich brauche als sample. Muessen ja nicht alle sein, und wenn das zu einem brauchbaren ergenis fuehrt koenen wir weiter diskutieren. Wenn ich die fahrzeug zuordnung habe kann ich die animationen typisieren und wenn ich sie typisiert habe kann ich einen moeglichen standard ableiten. Das ist meine normal vorgehensweise.
gruss
Gmd

 

[Phrontistes]

Hallo @Neo,

vor 2 Stunden schrieb Neo:

vor 3 Stunden schrieb gmd:

die liste ist ja keine zuordnung von schalter zu modellen und das ist ja das entscheidende.

Im Moment nicht, so eine Zuordnung wird erst dann wichtig, wenn wir uns für einen Standard entschieden haben und die Bestandsmodelle anpassen möchten.

Es wäre unabhängig von @gmds Programmierung schon immer schön gewesen, wenn man sich für jedes Modell die Animationsnamen (bzw. in V9 auch die Schalternamen) als Text greifen könnte. Bisher muss man den Text nämlich fehlerträchtig abtippen um seine eigene standardisierte Variable zu füllen. Ich wäre froh, hätte ich ein txt in dem ich für jedes Modell dessen Animations- und Schalternamen finden könnte.

Noch eleganter wäre, ich könnte aus den Animationsnamen des Modells im Variablenfenster mit der rechten Maustaste einen auswählen und so eine (vorher von mir angelegte) Textvariable füllen.

Ich habe mal die ganze Liste fotografiert damit Du siehst, was ich so alles an standardisierten Variablen in meinen Fahrzeugen habe. Vielleicht nimmst Du das als Feature-Wunsch auf.

Beste Grüße

Phrontistes

[Goetz]

vor 19 Minuten schrieb Phrontistes:

wenn man sich für jedes Modell die Animationsnamen (bzw. in V9 auch die Schalternamen) als Text greifen könnte. Bisher muss man den Text nämlich fehlerträchtig abtippen

Dafür nutze ich die grafische EV.
Dort gebe ich ein konkretes Modell an, wähle aus der Liste den richtigen Achsennamen und wechsle dann beim Objekt zu etwas generischem wie "Auslöser" oder "Wiederholung". Und wandle zum Schluss diese Zeile (bei Bedarf) in Lua. Sind ein paar Klicks, aber zur Fehlervermeidung gönne ich mir die.

[Neo]

vor einer Stunde schrieb Phrontistes:

Noch eleganter wäre, ich könnte aus den Animationsnamen des Modells im Variablenfenster mit der rechten Maustaste einen auswählen

Das Ziel ist ja, solche Variablenlisten zu vermeiden. Sinnvoller erscheint mir da eher die Erweiterung der EV, um alle Animations-/Schalternamen zu enumerieren. Auch der Zugriff auf die Content-ID eines Modells erscheint sinnvoll, um "klassenbasiert" arbeiten zu können.

[Phrontistes]

vor 13 Minuten schrieb Neo:

solche Variablenlisten

wird es noch sehr lange geben, jedenfalls bei mir. Schau mal die obige Liste genauer an, da sind auch einige Objekte dabei (Kamera vorn und hinten [das geht von Haus aus ja auch nicht], Fahrer [das haben die meisten Fahrzeuge nicht], Rauch/Dieselabgase [das haben viele Fahrzeuge nicht], Zielanzeige [die ist nicht immer ein label] oder Lichtscheiben (beim Regio Shuttle oben nicht, aber bei Fahrzeugen, die keine oder keine korrekten Spitzen und Zugschlusssignale haben). Nur mit solchen Listen bin ich in der Lage, bei jeden beliebigen Zug (auch Wendezug) mit der jeweils gleichen EV-Anweisung alles richtig einzustellen, z.B. den Licht- und Fahrerwechsel am jeweils letzten Fahrzeug des Verbandes - und zwar unabhängig davon, ob (z.B.) der Fahrer ein von mir eingesetztes Objekt oder eine Animation oder ein Schalter ist.

vor einer Stunde schrieb Goetz:

Dafür nutze ich die grafische EV.

nutzt

vor 1 Stunde schrieb Phrontistes:

im Variablenfenster

nichts also muss ich weiter abtippen  es sei denn, Du stellst wenigstens

vor 1 Stunde schrieb Phrontistes:

ein txt in dem ich für jedes Modell dessen Animations- und Schalternamen finden könnte

zur Verfügung, dann ginge es immerhin über das Clipboard.

vor 38 Minuten schrieb Neo:

Zugriff auf die Content-ID eines Modells erscheint sinnvoll

[prinz]

Ein Vorschlag:

Ich habe aus @Neos Liste der Steuerungsnamen sowie den von mir (einst mühsam) erstellten Zuordnung zu globaleren Namen (in Variablen gespeichert) mal einen Abgleich gemacht. Daraus resultiert eine XLS-Datei (Wahlweise auch als .CSV mit "|" als Spaltentrennzeichen), die in der ersten Tabelle drei Spalten beinhaltet:

Spalte A: Steuerungsnamen lt. Neos Liste
Spalte B: Allgemeiner Name für einen Schalter bei Matching mit irgendeinem Modell der Bahnfahrzeuge (bzw. #NV bei Excel: nicht gefunden)
Spalte C: Allgemeiner Name für einen Schalter bei Matching mit irgendeinem Modell der Straßenfahrzeuge (bzw. #NV bei Excel: nicht gefunden)

In der Excel-Datei findet ihr auch die Tabellen "Bahn" und "Auto" mit den Steuerungsnamen, mit denen ich bisher abgeglichen habe.

Mit dem Ergebnis könnte Neo (wenn er möchte) schon einmal für die Modelle, die einen Treffer bei einem Steuerungsnamen mit einem Wert in Bahn oder Auto haben, diesen neutralen Aktionsnamen zu generieren. Damit wäre für die geprüften Steuerungen schon mal eine Basis vorhanden.

Alternativ könnte @gmd die AI eine vergleichbare Liste "ausspucken" lassen, die auch noch das Modell enthält.

Steuerungsnamen.zip

Viele Grüße,
    Wolfgang

[gmd]

5 hours ago, prinz said:

Alternativ könnte gmd die AI eine vergleichbare Liste "ausspucken" lassen, die auch noch das Modell enthält.

Steuerungsnamen.zip 108.42 kB · 3 downloads

Viele Grüße,
    Wolfgang

das ist doch schon mal ein anfang .. I habe meine typisierung fast fertig, dh eigenschaften fuer jede animation, wie tag,nacht, intervall, dauer und etliche weitere eigenschaften. Warted einfach mal ab was ichdamit mache.
Die liste is ein einfang und eine vorlage. Ich werde meine animation/fahrzeug liste erstellen und dann damit abgleichen, ds bedeutet hinter jeder animation mit deinen eintraegen den name eine modells, welches zutrifft. Was daruas entsteht ist eine vergleichsliste weleche animationen gleiches tun aber anders heissen, damit kann ich besser steuern und die modellbauer oder wer auch immer will kann das vereinheitlichen. Die typen wuerden ja eine erste standardisierung liefern. Mal sehen wie weit ich komme, habe noch andere dinge zu erledigen zur zeit, aber trotzdem noch genug zeit mich damit zu beschaeftigen.
Gruss
Gmd

[gmd]

7 hours ago, Phrontistes said:

 

Ist schon mal eine idee fuer typen, gemeinsam sollte da doch eine brauchbare liste rauskommen.
Gruss
Gmd