Beiträge von KBS198


Abonniere unseren Kanal auf WhatsApp (klicke hier zum abonnieren).

  • Münster-Warstein WLE (Projekt Bier)

    bisher wird die Rotationsgeschwindigkeit fest in Blender vorgegeben (über die IPO-Keys),
    mit Szenario-fähigen Objekten habe ich mich noch nicht befasst, kann also noch nicht
    sagen ob da was möglich ist, ich denke aber dazu werden sich bestimmt noch weitere
    Objektbauer zu Wort melden.


    Wenn man es hinbekommt die Werte aus dem Flyout in ein Script zu laden, wäre es sicherlich
    möglich Windrichtung und Rotationsgeschwindigkeit zu regeln, sowas habe ich aber noch nie
    gemacht, daher wage ich es hier nicht irgendwelche Zusagen zu machen die ich möglicherweise
    nicht halten kann.


    Gruß Stefan

  • TDR1909 Objekt- und Download-Thread

    im Skript startet der Öffnungsvorgang bei 360m, das sollte für Züge die nicht schneller als 40kmh fahren reichen.


    Das Skript ist nicht verschlüsselt sondern vom BPE compiliert (was auf das gleiche Hinaus läuft).


    Gruß Stefan

  • TDR1909 Objekt- und Download-Thread

    Klamüsern wir das doch mal aus einander.

    • was StS auf seinem Bild zeigt ist das Set vom 10.12.
    • bei diesem Set hat Schmiddi zwar geschrieben das 2 Tore drinnen wären,
      gepackt hat er aber nur eins, nämlich das Nicht-Animierte (deshalb Scenery-BP)
    • beim heutigen Set hat er hingegen die BluePrints von 2 Toren gepackt,
      aber nur die GeoPcDx von einem Tor.

    @TrailDogRunner1909: nochmal machen! (wie diverse Lehrer in meiner Schulzeit/Studium zu mir sagten :ugly: )


    @StS: die Animierten Tore verwenden LevelCrossing-BluePrints, da wie TSC schon sagte ein Tracklink benötigt wird.
    LC-BPs haben die Eigenschaft das ihr SceneryComponent-Objekt nur im Editor sichtbar ist, ist hier keine Geometrie eingetragen (igs-Datei),
    kann man im Editor nicht den ganzen BÜ verschieben sondern nur die einzelnen Child-Objekte relativ zum Ursprung des LC-BP.
    Da die animierten Sachen sowieso als AnimScenery-Objekte im Child-Abschnitt (des LC-BP) eingetragen werden, benötigt man
    eine zusätzliche Geometrie (den Editor-Würfel), die Bahnübergänge von Kuju und SAD verwenden aus den gleichen Gründen die gleiche Taktik.


    Gruß Stefan

  • Musik durch Strom/Elektrizität?

    das Kreischen liegt ja nicht an den ggf. nassen Schienen, sondern dass das Rad an der Reibwert-Grenze betrieben wird, um die Beschleunigung des Zuges zu maximieren.
    Nasse Schienen verschieben nur diese Grenze, ändern aber nicht das Verhalten der Regelung.


    Verhalten der Regelung:

    • Drehmoment wird auf Motor gegeben
    • Drehmoment überschreitet Reibwert-Grenze
    • Regelung reduziert Drehmoment unter Reibwert,
    • sobald das Rad nicht mehr durchdreht erhöht die Regelung das Drehmoment wieder
    • Gehe zu 1. :ugly:

    Dieser ganze Vorgang läuft im (Milli-)Sekunden-Takt ab, daher kommt es zum Kreischen, somit kann man
    eigentlich fast Sagen dass das Kreischen für mehr Beschleunigung in Kauf genommen wird,
    schließlich soll der Zug möglichst schnell auf seine Soll-Geschwindigkeit gebracht werden.

  • Musik durch Strom/Elektrizität?

    @bernd_NdeM & @Roland,


    nun werft ihr aber das "Singen" der Umrichter und das "Kreischen" der Schlupfregelung durcheinander :ugly:


    Ersteres kommt daher dass diese Asynchron-Motoren mit Drehstrom betrieben werden dessen Frequenz immer passend zur (Soll-)Drehzahl erzeugt wird.
    Hierbei tritt das Singen auf, da diese Frequenzen im Hörbaren Frequenzspektrum sind. "Singen" an sich tun hier die Umrichter (die machen aus Gleichstrom Drehstrom).
    Ein ähnlicher Effekt ist im Bereich der Grafikkarten als "Spulen-Kreischen" bekannt, er tritt auf wenn Grafikkarten sehr hohe Framerate berechnen (fps > 800).


    Beim "Kreischen" dreht das Rad kurzzeitig durch (bis die Regelung reagiert).


    Gruß Stefan

  • Helfende Hand für Signalscripten gesucht

    Zitat von StS

    Der Modellbau sollte schon so sein, daß vorhandene Skripte passend gemacht werden können, damit die Signale ins Gesamtkonzept passen. Und offenlegen ist nicht,

    Eben dafür (Objekt passend zu Skript) müssten Schuster&Signalteam zumindest die Namen der Nodes offenlegen, sonst müsste man bei jedem Signal das Skript anpassen.
    Zur Erläuterung: die Namen der Nodes müssen schon in Blender vergeben werden, erfährt man diese erst nach Kontaktierung des Signalteams, so muss man den ganzen
    Workflow von Blender über den BluePrintEditor und alle eigenen Skripts wiederholen.


    Hilfreich währe folgende Möglichkeiten:

    • Eine Art "Lastenheft" für Signalobjekte bzw. -Projekte mit denen man Schuster und das Signalteam kontaktieren will, wo dann zBsp. drinnen steht was das Signal
      an diesem Punkt können muss (LoD, über Nodes ansteuerbare Lampen, BluePrints u.v.m.), auch ließe sich hier auf andere Sachen verweißen die der
      Objektbauer gelesen haben sollte bevor er Schuster kontaktiert, sonst müsste Schuster jedes mal wenn er irgendwo helfen möchte von vorne beginnen.
    • ein Extrem abgespecktes Signalskript (compiliert wie alle anderen) für Eigenbauten, bei dem dann die Nodes offengelegt würden, so währe es möglich
      für den Eigenbedarf Signale zu bauen die vllt, anderst aussehen (Dreck usw.) aber funktionsmäßig mit den Schuster'schen Signalen zusammen arbeiten.

    Zum Gesamtkonzept muss man leider sagen dass es in der Natur der Sache liegt das Schuster & Co. niemals alle Varianten von Signalen die es irgendwann mal
    irgendwo gab oder gibt für den TS umsetzen werden können, daher ist es ja sehr löblich das Andreas(TSC) den Leuten beibringen will wie sie sich ihre eigenen
    Signale bauen können. Ich denke dass dabei vermutlich keine mit den Schuster'schen Signalen konkurrierende Systeme entstehen werden, sondern eher Varianten
    die zum Beispiel auf Nebenbahnen das Portfolio abrunden.


    Gruß Stefan