Posts by moevenbaer

    oder auf eine Straße stellen oder

    Dann gibt es also solche waagrechten "Ebenen" ja schon. Schön.

    Hm. Aber die Container sacken durch die Straße durch. Also doch keine "höhere Standebene" für Container (auch nicht für DK1_Cont ST-S40 ).
    Vielleicht sind das spezielle Fahrbahnen?

    Das steht noch auf der Todo-Liste.

    Aus meiner Sicht sind Haltetafeln eigentlich auch nichts anderes als Signale. Oder habe ich Unterschiede (bis auf das 2D-Bild) nur noch nicht bemerkt?


    Leider alles immer noch ohne den hinreichenden Spaßfaktor, Schade.



    Und noch eine Frage: Kann man per Lua zwei Modelle austauschen? Gedanke für ein Containerlager/Containerterminal ist, vor dem "Abhaken" vom Kran ein identisches Immo-Modell an die gleiche Position bringen und das Goods-Modell verschwindenlassen. Oder vor dem Anhaken das Goods-Modell an die gleiche Position setzen und das Immo-Modell verschwinden lassen.


    LG aus dem Randboulettenland

    Ekkehard (moevenbaer)

    oder auf eine Straße stellen

    Das wusste ich nicht. Reagieren auch andere (alle?) Güter/Container so?

    Das sind ‘waagerechte und stabile Standorte‘,

    Dann gibt es also solche waagrechten "Ebenen" ja schon. Schön.

    ‘Drückt‘ man den Container mittels Gismo unter die ‘Lagerfläche‘ und lässt los, bewegt sich der Container abwärts bis auf ca. -100 m. Hat man ihn dort wiedergefunden und gibt in den Objekteigenschaften als Abs. Höhe den Wert 0 ein, steht er wieder am ursprünglichen Standort.

    Ist das ein Test zur Bestätigung? Werde ich nachher mal probieren.

    In beiden Fällen kommt es zu dem unschönen ‘Rütteln‘ der Container.

    Meinst du damit das Wackeln am Hook? Oder dieses komische Hüpfen eines Containerstapels, ohne erkennbaren Grund und Zeitplan.

    Die Kran-Fahrt lässt sich z.B. über eine oder mehrere Halttafeln kontrollieren.

    Das steht noch auf der Todo-Liste. Mit Weichen und kurzen Abzweigstümpfen habe ich es schonmal auf ca 2-3 cm genau hinbekommen. Da bin ixch aber noch am Werkeln für das Anpassen der Gleislängen an die Containerslots.


    LG aus dem Randboulettenland

    Ekkehard Skirl (moevenbaer)

    sind auch glatte Flächen nötig, auf denen Güter rutschen können.

    Version 1.0: Ebene Fläche Waagerecht

    Version 2.0: Rutschebenen mit Reibungsfaktor

    Version 3.0: ???


    PhysX und Skalieren ==> zur Zeit noch nicht möglich, also sind verschiedene Modelle je nach Anwendungsfall notwendig

    Ich würde für meine Ideen und zum Herumtesten erstmal eine unsichtbare Platte X19mxY68m (V1.0) benötigen als waagerechte Standfläche ohne rutschen. Aber eigentlich ist die Dimension auch egal. Dann werden diese Flächen eben gekachelt, was etwas aufwändiger ist. Solche "Klebe/Montagepunkte" wären natürlich auch schon mal schick für das rastern.


    es werden sichtbare Bestandteile zur exakten und schnellen Positionierung

    Dazu gibt es dann doch das Gismo und die 2D-Symbole, welche EEP bereitstellt?

    Und vielleicht ist eine Skalierungsachse für eine sichtbare Fläche (analog zum Fahrere?), zum sehen der Dimension, möglich.

    Ein erstes Modell existiert bereits auf meiner Festplatte

    wie solch ein System möglichst ohne Probleme und störende Auswirkungen auf andere Modelle

    Eigentlich bräuchte man doch zuerst einmal blos eine unsichtbare Platte mit skalierbarer Größe, die dann "über" das andere Modell (z.B. Betonflächen, Bahnsteige etc.) gelegt wird, stelle ich mir vor für eine erste Grundversion und zum Erforschen der Querwirkungen, als Beta-Modell so zu sagen.


    Aber unter Umständen führt das dazu, dass man zwischen einer Gelände-Positions-Höhe und eine EEP-Physik-Höhe unterscheiden muss. Oder es gibt sowas wie Viskosität bereits in der EEP-Physik, mit der man den Oberflächen-Widerstand gegen die Erdanziehung in einem Modell bzw. besser noch in einem Modell-Objekt regeln kann?


    P.S. So eine Viskositätsachse für Modell-Teil-Objekte von 0-100 könnte auch zu spannenden Effekten/Modellen führen.

    Um mal etwas auf die Euphoriebremse zu treten

    Nachdem ich nun mal ein paar Tage exprimentiert habe, bin ich auf ein paar Dinge gestoßen, die gebremst haben.


    Deshalb hier mal die Gedanken mit der Frage, ob es das sein kann:

    1. Auch im 3D_Editmodus hüpfen Containerstapel in unregelmäßigen Abständen.
    2. Die Transformationsdaten werden nicht beim Speichern oder Laden "verfälscht"
    3. Die "Ungenauigkeiten" treten zum ersten mal auf beim Wechsel in den 3D-Modus.
    4. Die "Ungenauigkeiten" sind bei Immos nicht aufgetreten.
    5. Positionierungen von Fahrzeugen per Signal, Haltetafel, Gleisende, Endgleis sind

    Daraus ergeben sich auch ein paar Fragen für mich:

    • zu 1.: Meine Idee dazu ist, dass hier die Physik ihren Anteil hat.
      Und ergänzend dann:
      • Vieleicht sind die Container zu leicht?
      • Vielleicht ist auch der Standard-Rasen-Boden "uneben", was dann mit der Physik zusammenwirkt?
    • zu 4.: Kann es sein, dass Immos nicht von der Physik behandelt werden?

    Da mir 4. aufgefallen ist, verstärkt sich meine Idee, Verschiebebühnen-Technik als Immobilie mit Kranobjekt (ohne Fahrzeugfunktion) zu verwenden. Da hier keine Gleise angebunden werden müssen, könnte man mit einer weiteren Achse, zusätzlich zu den Kranachsen, die Veschiebung des Kranes im Sinne von hin- und herfahren simulieren. Das ist wohl mal wieder ein weiteres Prototypprojekt.


    Weitere Frage: Gibt es eine "Bodenplatte", die eben ist, z.b. Betonfläche, die aber auch die "fallenden" Güter aufhält vor dem Durchfallen?


    LG aus dem Randboulettenland

    Ekkehard (moevenbaer)

    Gleisobjekt + Kran + Container

    Na ja bei meinen Gedanken ist dann schon mal eine Ungenauigkeit raus, denn das Verhältnis Kran zu Gleisobjekt soll ja konstant sein und ist es wohl auch, weil ja das Kranobjekt (hier mit seinen 19m) auf einem genau 19m Gleis stehen soll. Aber das mit dem Laden und Speichern könnte ein Problem sein bzw. werden.


    Eine Frage steht da also auch noch: Wie entstehen diese "Ungenauigkeiten" bzw. warum werden unterschiedliche Werte gespeichert?

    Vermutliche Antwort ist, dass nicht alle rationalen Zahlen ein IEE-Gleitkomma-Ident haben?


    Vielleicht hilf da, dass alle Positionen und Maße so gewählt werden, dass solche Idents bestehen? Vielleicht gibt es da eine Möglichkeit. Wieder was zum Nachdenken.

    Weiß jemand, mit wie vielen Ziffern Genauigkeit EEP arbeitet und speichert?

    Also für mich zeichnet sich jetzt ein Bild ab:


    Ich müsste ein Modell bauen, dass aus einer unsichtbareine en Linie besteht, die die Länge des CTerm vorgibt unhd einem 19m langen unsichtbaren Gleis, dass an eine Manuelle-Transformationsachse gebunden wird und an die dann die Verschiebung des Gleises.

    19m weil der Containerkran halt 19m lang ist und dann nicht "wackelt" bei der Positionierung. Die beiden Längen könnten vielleicht an einer Skalierungsachse hängen, um sie auf verschiedene Kranlängen einzustellen. Und wenn ich das richtig sehe, muss das ein Gleisobjekt werden.

    Die Krangleise weden dann als Beiwerk hinzugefügt (oder auch ins Objekt?)


    Soweit mein bisheriger Gedankengang.

    Und im Schlaf ist mir dann die Idee vom Einsatz einer Schiebebühne gekommen, auf der der Kran steht. Die können ja sehr genau auf Gleispositionen schrittweise gesetzt werden. Das Krangleis muss dann eben 90° gedrehr von der sonst üblichen Richtung stehen. Damit kann man vielleicht die Slots präziser ansteuern. Da kommen dann die von mir "nicht so geliebten" :ae_1: unsichtbaren Gleise zum Einsatz als Kopplungstellen.

    Oder auch nicht (?), denn ich vermute mal, dass die Schritt-Verschiebung über eine Manuelle-Transformations-Achse gekoppelt werfen kann.

    Und die Positionierung an einem Gleisende führt EEP sehr präzise aus. Mal schauen, ob ich so einen Prototyp zusammen bekomme.

    Dreh den Spiess um.

    Aber wenn in einem CTerminal Container stehen, dann muss ich doch dahin recht genau, damit die Container nicht schif herumbaumeln bzw. rumhüpfen.


    Halt-Tafeln

    Sind Halt-Tafeln sowas wie Signale? Habe die immer als passiv betrachtet. Muss ich mal in der Signalgruppe nach sowas suchen.

    Die Fahrtrichtung des Container-Krans wird über den Steuerdialog vorgegeben.

    Da man das ja auch per Scriptfunktion auslösen kann, passt das als Gedankenstupser super.


    Meine (zugegebner Maßen "wahnsinnige") Idee ist es, ein CT über Container-Transport-Aufträge automatisch zu steuern. Es soll eine Auftragsliste geben, die abgearbeitet werden soll. Und mein erster "Meilenstein" soll das gezielte Umsetzen sein von einem platz auf den anderen.

    Nach dem Neuladen des Lua-Scriptes in EEP

    Genau das war nicht der Fall bei mir, aber ich war eben auch noch nicht im 3D-Modus, weil ja da erst das Script ausgeführt wird. Vorher ist es nur geladen, habe ich jetzt verstanden.

    Die einfachere Möglichkeit dürfte aber sein, darauf zu verzichten und stattdessen nach dem Laden der Anlage einmal kurz in den 3D-Modus zu schalten, sodass das Skript (inklusive der eingebundenen Unterdateien) einmal ausgeführt wird (und dabei alle irgendwo definierten Funktionen global bekannt gemacht werden).

    Das ist noch bequemer und genau richtig für mich. Dankeschön.

    Mich beschäftigt das Thema Containerterminal. Dabei bin ich auf ein kleines (großes) Problemgestoßen, dass eine genaue Positionierung des CK erfordert. Es soll Containerslots (grüne bzw. braune Gruppe) und Containerstacks (grüne bzw. braune Felder) geben. Hier geht es um die Positionierung vor Slots. Die gelingt mir nicht präzise genug.

    So komme ich auf die Idee (Auslöser waren die Experimente von „Gärtner (MH3)“ zu „Modellversuche zum Thema Gütertransport“), die Slots „beweglich“ zu gestalten. Beim Herabsenken des Geschirrs wird die Slotebene mit der Containerstackgruppe im Script „gekoppelt“ und sanft an die „ungenaue“ Positionierung des Containerkranes angepasst. Diese Slotebenen sind vielleicht dimensionslos unsichtbar und haben im Idealfall "Verschiebeachsen".


    Hat jemand eine Idee, was man da als Verschiebefläche verwenden kann oder wie man sowas baut?

    Bei dieser Methode ist ein kleines Problem aufgetaucht, das das gedachte Prinzip etwas aushebelt.

    In meiner Version von EEP (16 + 1-4) kann ein Kontakt die Funktion nicht finden, wenn sie nicht im Hauptscript steht.

    Das ist für mich logisch, weil LUA ja nur eine ID für eine Funktion speichert und nicht den Funktionsnamen, wenn es in den Bytecode übersetzt wurde.

    Und EEP hat erstmal keine Ahnung von den weiteren per require eingebundenen Script-Daten.

    Ein getesteter Workaround ist der, dass (so ähnlich wie in Headerdateien von C oder C++) der Name "definiert" wird und dann im NACHFOLGEND importierten Script "neu geschrieben" wird.


    Im Hauptscript: function FUNKTIONSNAME() end

    Im "require"-Script: FUNKTIONSNAME = function() ... end

    was mich erstaunt ist es, dass es keine BugFixes gibt

    Sarkastisch formuliert: Ja dazu ist doch der Bugtracker da!


    Eher sachlich: Auch ich kaufe immer die neuen Versionen, im zweisinnigen Hintergedanken, als Bugfix und Upgrade. :aa_1:


    P.S. Mir ist auch bewusst, dass ich vermutlich mehr Mittel dazu zur Verfügung habe als andere. Ich bin auch gerne bereit, mich an einem fairen Fond zu beteiligen, der es EEP-Nutzern ermöglicht, denen es nicht so leicht fällt, regelmäßig neue Versionen zu erwerben.

    Vielleicht kann der Trend Verlag sich auf Spendenbasis mit daran beteiligen.

    Vielleicht gibt es sogar eine Förderstrecke der Länder oder des Bundes, die Jugendclubs oder schulische AGs mitfördert, passende Technik und Software zu erwerben. Aber dazu muss sich, glaube ich der Trend Verlag als offizelles Unternehmen bewerben.

    Weil es für mich einfacher ist.

    Ich habe eine Liste an interessanten Features, die ich hier aus diesem Faden herausgezogen habe. das habe ich auch weiter so vor.

    Hm. Ist das nicht ein wenig kurz geschossen, dafür dass da ein riesiger Rucksack mitgeschleppt wird? Ich weiß ja nicht, wie du deine Liste organisierst, aber es kann sich doch nur um die Links hinter den #-Nummern der Beiträge als Quelle handeln, die neben einer Notiz gemerkt wird in der Liste. Die alten Links gehen doch nicht verloren, wenn man in einem anderen Thread neue Wünsche erfasst.


    Aber egal. Ich muss den Rucksack ja nicht umherschleppen. :aa_1:


    Machen wir einfach so weiter wie immer ...


    Und eines ist jetzt offengelegt und festgestellt: Es kümmert sich tatsächlich jemand um Wünsche ... und es gibt eine Featureliste :bp_1:

    ---

    P.S. Jeder Beitrag bekommt im WoltLab-Forum eine eigene ID. Und die Forumsoftware kommt auch ohne Thread-Titel klar:

    Beispiel (#3.995)

    Vollständiger Link: Wünsche für EEP18 und folgende Versionen

    Hinreichender Link: https://www.eepforum.de/forum/…?postID=499500#post499500

    Vielleicht ist es hilfreich :aq_1:

    Was soll man sich für die 18-Version wühnschen, wenn man nicht mal weisst, was in der 17 bereits enthalten ist?

    Doppelt wünschen hält besser. Und man kann ja in den nicht mehr aktuellen Wunsch im neuen Thread (z.B. EEP19) vermerken, dass die Erfüllung in der vorherigen Version (z.B. EEP18) erfüllt wurde.

    vor kurzem stand ich noch bei den Wünschen für EEP 17, die eigentlich langsam fällig wäre. Plötzlich (für mich) gibt es den Thread Wünsche für EEP 18.

    Das bringt mich auf einen threadorganisatorischen Wunsch:


    Macht es nicht doch mehr Sinn, für jede Version einen eigenen Thread auf zu machen und die alten zu schließen?


    Und wenn das nur deshalb passiert, damit "alte Wünsche nicht verloren gehen", dann halte ich dagegen: Wer liest schon mehr als 3000 Beiträge nochmal?


    Der neue Thread hat dagenen den Vorteil, dass "nur" (immer noch) aktuelle "neu" Wünsche aufscheinen. Und wenn jemand seinen wunsch wirklich vermisst, dann kann er (und muss) ihn wieder einstellen, und dabei kann er sogar die Formulierung unter Einbeziehung der Beiträge dazu präzisieren bzw. anpassen.

    Hintergrund: im Westen gibt es die Möglichkeit die Signalgeschwindigkeit an einem Signal, mit einem Buchfahrplaneintrag zu ändern.

    Das ist jetzt wohl eher eine Verständnisfrage allgemeiner zum Eisenbahnverkehr:

    Nach meinem Verständnis werden doch Höchstgeschwindigkeiten an Signalen deshalb gesetzt, damit für den nachfolgenden Fahrweg nicht zu schnell gefahren wird. Warum soll ich also eine Signalhöchstgeschwindigkeit überschreiben, wenn der Fahrweg dahinter es nicht zulässt? Und sollte die Strecke dahinter ausgebaut worden sein, warum ändert man dann nicht die Signalgeschwindigkeiten?

    mit ein paar Links ist das eben nicht getan.

    Damit meinte ich ich die Stellen im Forum, an denen sowas schon mal diskutoert wurde, wenn ich das richtig erinnere. Habe ich aber nicht mehr gefunden oder mit falschen Suchkriterien gesucht.


    Aber wie ich sehe, ist das, was du meinst, wohl ziemlich genau das, was ich in

    Regelmäßige Funktionsaufrufe im EEPMain-Takt - Funktionsliste und Zeittaktsteuerung

    mit euch zusammen schon für mich herausgefunden habe. Danke.


    Das Prinzip ist also schon sehr alt, aber immer noch wirkungsvoll: Irgendwo wird ein Flag gesetzt oder entsteht eine Bedingung, dass woanders (ggf. regelmäßig im Spiel-Haupt-Zyklus) abgefragt wird und auf dass dann ggf. reagiert wird.


    Ist eigentlich einfacher, als es sich für EEP immer anhört. :aa_1: Dann ist das ja auch schon geklärt. Danke.


    P.S. @Administration: Wenn keine Einwände bestehen, kann der Thread sicherlich geschlossen werden.