Beiträge von AndiS

Das mit der Mindestanforderung ist immer so eine Sache, bei allen Spielen. Ich habe KRS 2007 sogar auf einem Rechner knapp unter den Mindestanforderungen zum Laufen gebracht. Aber es hat ausgesehen wie MSTS. Also wozu die ganze Debatte. Für ein detailreiches 3D-Spiel braucht man 2-4 GB RAM und eine möglichst gute Grafikkarte, wobei "möglichst gut" einfach vom persönlichen Budget abhängt. Vernünftiger Prozessor und eine flotte, große Festplatte sind sowieso selbstverständlich.

Na das Zappeln wird uns noch eine Weile erhalten bleiben. Das kann man an Signalen auch "schön" beobachten. Wegen Grenzwert würde ich einmal 0,01 (m/s) annehmen, oder 0,02.

Na hoffentlich schaffen sie die doofe Eigenschaft nicht ab. Ist mir schon passiert, in der Vergangenheit. Nicht jeder Bug bleibt ewig bestehen.

Zitat von Maik

Muss hier nochal was zu sagen

Das ist meines "beschränkten" Wissens nicht möglich. Welcher Call im Lua soll das herrausfinden?

GetConsistType wäre das.
Kann jetzt natürlich sein, daß das in Engine Scripts nicht mag, aber GetConsistSpeed geht auch (und ist eine nette Alternative zum Geschwindigkeits-Controller, weil beim Rückwärtsfahren ein negativer Wert angegeben wird).

Zitat

ApplyToConsist weigert sich leider beständig zu funktionieren. Alles ausprobiert, da rührt sich nix. Ob mit oder ohne Messages.

Das ganze funktioniert also nur mit Wagen die ausgerüstet sind und eine ausgerüstete Lok vorn dran haben. Ich finde, dass schränkt ziemlich ein oder ?

"Interessant."

Ich hab das aber auch nicht als "muß morgen gehen, oder ich reg mich auf" gemeint, sondern eher als Vision für die Community Edition der Waggons.
Wenn das jetzt so ist, daß alle Waggons im Zug damit ausgerüstet sein müssen, dann muß man, wenn es so weit ist, auch mit unseren Nachbarn, z.B. in Italien, in Kontakt treten.

Zitat

Ich hab es jetzt grad eben genau so umgesetzt. Wenn eine lok dran hängt, die dem Cosist vermdeldet dass sie angekuppelt ist, dann checken die Wagons nach woe sie stehen und hängen bei bedarf die Tafel raus. Hängt man die Lok ab, gehen die Tafeln weg. Hängt man einen Fremdwagon dazwischen ist keine Tafel mehr da. Ich weis nich wie ich das sonst lösen soll mit den Einschränkungen im RW. Und ehrlich gesagt wollt ich mich nich 2 Monate mit den Tafeln aufhalten. Da sind wichtigere dinge wie die ZWS und ZZA.

Genau, es ist einfach ein Feature und vielen, und offensichtlich nicht ganz einfach, den Durchbruch zu schaffen.

Es gibt aber immer noch die Möglichkeit, eine Variante der Waggons mit Zugschluß zu schaffen, haben die Italiener schon lange so (heißt Coda für die italienische Variante bzw. Coda DB-CH-OBB für unsere). Das ist einfach ein Child Blueprint im Wagon Blueprint, das kann daher auch jemand dazufügen, der nicht den Source hat.

Natürlich ist die automatische Lösung viel eleganter, aber die Welt geht nicht unter ohne sie (oder mit einer halben Lösung).

Zitat

Was ich noch veruschen kann ist, das die Wagen erst mal grudsätzlich als letzte im Verband eine Tafel raushalten solange keine ausgerüstete Lok dran ist. Sobal die Lok ihr Dasein bekundet, schalten die Wagen um auf Message und reagieren entsprechend. Sendet die Lok eine Zeit lang nicht mehr, schalten sie zurück und hängen wieder am leeren Ende die Tafel raus. Mehr geht nicht.

Sowas würd ich nicht anstreben. Mir persönlich ist lieber, man muß hier und da einmal einen Zugschluß explizit definieren, als es haben alle abgestellten Garnituren auf beiden Enden einen Zugschluß. Das sind einfach wesentlich mehr Fehler. Annahme: 1 Spielerzug, 10 AI-Züge, 50 oder 100 abgestellte Wagengruppen (oder Einzelwaggons). Natürlich nimmt man den Spielerzug mehr wahr, aber deshalb an 50 abgestellten Gruppen einen falschen Zugschluß anschauen?

Was schon eher funktionieren könnte: Wenn die Tafel rausgehängt wird, sobald der Waggon fährt (und der letzte ist). Das deckt dann nämlich alle AI-Züge ab, während abgestellte Waggons korrekt ohne Zugschluß bleiben. Natürlich wird die Tafel in diesen Fällen nie mehr eingeholt, sonst verschwindet sie ja beim Stehen, und AI rangiert eh (noch) nicht, d.h. der Zugschluß soll ewig drauf bleiben.

Damit es dann beim Spielerzug anders ist, kann man ja (dann/später einmal) für den Spielerzug die aufwendigere Lösung versuchen. Dann ist vielleicht die Waggonauswahl eingeschränkt, und die Loks auch, aber dafür hat man da dann die maximale Funktionalität. Und für den bunten Eindruck reicht es, wenn die "sonstigen" Waggons in AI mitfahren, bei der es wiederum reicht, wenn der letzte Waggon "intelligent" ist.

Also bei der Gelegenheit möchte ich auch eine Stimme für konstruktiven Zugang zu Freeware aller Art einwerfen. Freeware kann auch in Tutorials bestehen und in Zuarbeit für andere.

Die englische Szene hat im Prinzip mit diese Route Building Challenges durchgestartet. Aber da waren natürlich schon Leute vorhanden, die sich auskannten. Und natürlich gab es für England im Default Content schon mehr, und fehlerärmer, als für Deutschland.

Insbesondere solange die Szene klein ist, wird sich die Payware-Debatte im Kreis drehen. Wie die anderen sagen, der Hersteller legt den Preis fest und der Kunde kauft oder nicht. Eine Unterschriftenliste "ich kaufe nur um 10 Euro" braucht man erst gar nicht auflegen, für die gibt es keinen Empfänger.

Auch diese Diskussion um die Euro/km hatten wir schon bei MSTS. Es gibt Schnellfahrstrecken, die müssen lang sein, damit man eine gewisse Zeit schnell fahren kann. Und es gibt Lokalbahnen und Industriegebiete, in denen man in derselben Zeit sehr wenige km zurücklegt. Die Anzahl der Objekte und die Produktionsdauer kann bei beiden durchaus gleich sein! Und daher auch der Preis.

Deshalb gibt es nur eine Alternative zum Warten auf tolle, billige Payware: Irgendwas für Freeware tun.

Ich fände es auch erfolgversprechend(er), wenn sie Leute zu Teams zusammenfinden. Man kann ja nicht alles können, aber jeder hat irgendwelche Stärken.

Nur wenn man es gescheit angeht, wird man mit "next generation simulations" (bzw. "this generation simulations") irgendwas zustande bringen. Die Computer sind leistungsstärker als vor 10 Jahren, die Erwartungen sind höher, die Möglichkeiten der Programme auch, darauf muß man sich einfach einstellen, anstatt von der Vergangenheit zu träumen.

Du verwendest Blender 2.5 (2.59 sagt der Screenshot). Der Exporter funktioniert nur mit Blender 2.49 (und 2.48). Später einmal soll es den Exporter (heißt Bigex und gibt es hier bei den Downloads) einmal mit 2.5 funktionieren, aber derzeit liegt das noch in der ungeplanten Zukunft. Daher solltest du parallel auch Blender 2.49 installieren, vielleicht auch ganz auf Version 2.49 umsteigen, falls es dir nichts ausmacht.

Jemand hat berichtet, daß die Texturen verloren gehen würden, wenn er von 2.5x nach 2.49 umsteigt. Ich selbst hab es noch nie ausprobiert, und würde auch zuerst einmal andere Wege (andere Formate) durchprobieren, bevor ich aufgeb. Aber du sparst dir jedenfalls viel an Nerven, wenn du zuerst einmal einen Weg für dich findest, den du immer wieder einmal durchtestest, wann immer du eine neue Funktion in Blender für deine Objekte verwendest.

1 Blender Unit = 1 m in RW. Da wird es kaum Überraschungen geben. Und dein Sockel geht schön unter 0, was beim Platzieren sicher Freude macht. Also alles im grünen Bereich, soweit ich das sehe.

Naja, aber luac.exe wird doch vom Blueprint Editor nur zum Syntaxcheck verwendet und nachher ladet erst recht die Source im Assets-Unterordner. Ich hab aber auch schon gehört, daß man kompilierten Lua-Code genauso in den Assets-Ordner stellen könnte.

Die Frage ist, ob es sich auszahlt, sich mit luac.exe zu spielen. Wegen den paar Include-Files bei Fahrzeugen würd ich mich nicht streßen.

Und bei den Signalen hab ich es vor langer Zeit schon so gelöst, daß alle dasselbe Skript verwenden und zur Laufzeit draufkommen, was sie eigentlich sind - durch Checks, welche Teile grad da sind. (getNearLocation gibt nil zurück, wenn das angesprochene Child nicht da ist.)

Das eigentliche Lua require (oder gibt's auch include?) hab ich nicht zum Funktionieren gebracht (anno dazumals bei der KRS Release, mit wenig positivem Denken). Stattdessen gibt es das --include statement (siehe Signale). Das wird vom Blueprint Editor implementiert, und zwar traurigstens.

Erstens checkt er Abhängigkeiten nicht, d.h. wenn du --include=X.lua in deinem Skript A.lua hast, und du änderst X.lua, dann mußt du danach auch noch einmal einen Blueprint, der A.lua verwendet, neu exportieren.

Zweitens ist es nicht gesichert, daß die File in der Reihenfolge der --include statements eingebunden werden. Bei
--include=A.lua
--include=B.lua
hab ich es auch schon erlebt, daß nach dem Ändern von A.lua dann A.lua als zweites im Endergebnis steht.

Daß drittens das Resultat der Aktion eine Codevervielfachung ist, bei der z.B. 50 Signalskripts je 70 KB fast identen Code enthalten kann schon fast als Feature angesehen werden. Immerhin sind ja selten viele Signale gleichzeitig im Hauptspeicher und die getrennten Filezugriffe für jedes require statement kosten auch Zeit.

Aber davon darf man sich nicht beirren lassen, wenn man was erreichen will. Bei den Loks ist die Situation ja viel weniger schlimm als bei den Signalen, weil es viel weniger Loks gibt.

Im Vordergrund steht da einfach die klare Dokumentation und Versionierung, so überschaubar wie die Community ist wäre es ja ein Witz, wenn man z.B. Message-Nummern doppelt vergeben würde.

Echt schade, wenn/daß der RW schon wieder durcheinander kommt, weil an sich wäre diese Funktionalität ja im Spiel implementiert. Kann es sein, daß es nur am Kuppeln zwischen den abgestellten Waggons scheitert? Ich selbst hab das noch nicht so untersucht.

Meine Ideen zur Luxusvariante wären diese:

1.) Statt daß jeder Waggon selbständig herausfindet, ob er der letzte/erste ist, sendet die Lok eine Message, und zwar am Spielbeginn und bei jedem Halt. Die Waggons leiten sie weiter und merken dabei (am Return Value), ob sie der Letzte sind.

2.) Natürlich funktioniert das nur mit speziellen Loks, aber die Notwendigkeit einer Community Edition für den Default Content wurde andernorts schon angedeutet.

3.) Damit beim Rangieren der Zugschluß unterbleibt, setzt man im Szenario den Consist Type auf Light Engine (Lokzug oder wie immer die das übersetzt haben), und unterbindet im Skript dann das Message senden für diesen ConsistType.

4.) Wenn jetzt einer kommt und "Nahgüterzug" sagt, dann macht man einen Controller, mithilfe dessen der Lokführer explizit den Zugschluß rauf und runter tut, in Vertretung des Schaffners/Zugführers oder wer auch immer das im Vorbild macht.

5.) Wenn dieser Befehl über einen Controller (apply to consist) kommt, dann können nicht ausgerüstete Waggons in der Mitte nicht dazwischen funken. Aber man braucht trotzdem ein Skript, das eine Message schickt, die in diesem Fall vom Empfänger ignoriert wird, weil man nur so feststellen kann, ob ein weiterer Waggon dranhängt oder nicht. D.h. Effizienzsteigerung bekommt man so keine. Aber wenn man es nur selten macht, dann stört es nicht die Flüssigkeit beim Fahren.

Zitat von Maik

ApplyToConsist ist offenbar ein Parameter mit Eigenleben und mißmutigem Willen. Manche Daten werden weitergereicht, manche nicht. Ein Muster gibt es da nicht. Wäre natürlich ein Versuch wert.

Naja, das mit dem Eigenleben stimmt sicher für die Controller, die das Spiel mit irgendwas verbindet. Hier geht es aber sicher nur um selbst definierte, und die sollten entweder ganz oder gar nicht gehen, wobei man auf "ganz" hoffen sollte.

Ok, jetzt ist das klar mit dem Containerkran. Klar, daß der dann einen anderen Blueprint (falls es geht) braucht, und daß wir dann wieder das Problem mit dem Default Content Tauschen haben. Aber es war ja auch die Rede vom schwarzen Staub im Kalkwerk (ist mir in 4 Jahren nicht aufgefallen). Da muß ja auch ein einfach Reskin her, falls einmal wer Zeit hat.

Ad Default Content ausblenden: Ist halt blöd, daß fast alles in Kuju/RailSimulator ist, vom Baum bis zum Brake Van. Hier etwas los zu werden, ohne daß dann irgendwo irgendwas fehlt, ist wirklich schwer, würde aber die Ladezeit verbessern.

Aber so eine Community Package, die parallel dazu existiert, ist problemlos zu installieren, und spätestens in RW4 werden sie hoffentlich diese Objektlisten irgendwie strukturieren. Bis dahin helfen nur Namenspräfixe.

Wenn du die Kommunikation über Controller machst und nicht über Messages, dann können einzelne nicht ausgerüstete Wagen in der Mitte nicht stören. Aber ich hab nie probiert, ob Wagons Controller setzen können, oder nur lesen. Oder weder-noch?? Ich hoff halt immer noch darauf, daß RSC uns verraten, was sie glauben, daß in Waggon Scripts funktionieren soll und was nicht.

Jedenfalls haben sie vor, daß in RW3 jede Lok ihre eigenen Antriebsparameter hat, sodaß das Ansteuern vom Steuerwagen aus leichter sein sollte.

Der Grund, warum nicht mehr passiert, liegt meiner Meinung nach daran, daß es praktisch keine Doku gibt und man bei allem zuerst einmal selbst draufkommen muß, was funktioniert und wie genau. Ist zwar spannend, braucht aber viel Zeit und Enthusiasmus.

Das mit BulkCargo hab ich mir nachher auch gedacht, nachdem die Aufstellung fertig war. Super, daß es funktioniert.

Das mit den Containern und Scenery versteh ich nicht ganz, der Containerkran ist doch auch ein Interactive oder ist der Scenery? Ich muß sagen, daß ich mit Containern überhaupt nichts am Hut hab und daher keine Ahnung. Ich find die Umsetzung auch nicht wirklich berauschend mit der Endlosschleife der einen Animation. In der Realität fährt der Kran den Zug entlang, aber das war halt zu aufwendig zu implementieren.

Ad wer ändert das alles um: Die Engländer haben grad ein Community Pack rausgebracht, das großteils aus Reskins von Default Content besteht, mit sanierten Physics. So etwas kann sich als Befreiungsschlag für die Community auswirken, weil RSC sicher nichts ändern am Default Content, weil sonst wieder irgendein Uralt-Scenario nicht mehr will.

Man müßte halt dann in die Doku klar reinschreiben, daß es nicht irrelevant ist, das "beladen"-Häkchen auch bei Tankwagen zu machen. Man könnten als Fracht-Shape einen Ölfleck definieren, damit der Scenario-Bauer eine Gedächtnisstütze hat, was jetzt die beladenen und was die leeren sind.

Zitat von Maik

Is da aber nicht in der Cargo-Definition ein Gewicht drin? Ich glaub ich hätte da was gesehen. Man muss ja dem Wagon ein Cargo-Element geben wenn er beladen werden kann. Und dieses hat ein Gewicht dass es mitbringt.

Also ich hab mich bei meinen Recherchen auf den Default Stock beschränkt, in der Hoffnung, das die Hersteller wohl den besten Draht zu den Wissensträgern haben.

Fall 1: Typ "Container": Es gibt nur einen Verweis auf das Ladegut, das draufsteht, ohne Gewicht. Z.B. 5-Plank Waggon, Cattle Truck, FSA, KBS, Ssylms.

Fall 2: Typ Schüttgut: Es gibt einen Bulk Cargo (Schüttgut) -Eintrag mit der Angabe von Capacity, z.B. 16 beim 16-t Mineral Waggon, was ich als Beweis anseh, daß hier wirklich Tonnen stehen sollen und nicht vielleicht Pfund oder so.
7-Plank Waggon gehört auch in diese Gruppe, genauso wie Eanos, HAA, HTA

Fall 3: Keine Ladung. Die CargoDef ist leer.
Beispiele: Kkt, Ktmm, Milchtanker, PCA, Shimmns, Standard Van, TTA.

Zitat von Maik

MIt 5 Silberlingen tut sie in ca. 12 sec. auf 100. Immer noch bissel schnell, aber das liegt wohl dann an den falschen Tonnagen der Wagons.

Bei den Silberlingen gibt es kein Problem. 34 t sind eingetragen, Wikipedia sagt 31-40 t, also alles im grünen Bereich.
Bei Personenwaggons ist es ja überhaupt nicht so ein Unterschied zwischen beladen und leer, 10% oder so.
Aber bei offenen Güterwaggons schaut das anders aus und bei Tankern sowieso.
Leider hat sich Kuju vor allem auf die optischen Effekte konzentriert. Du kannst festlegen, welcher Shape erscheint, wenn ein Waggon beladen ist, aber du kannst nicht festlegen, wie viel schwerer er ist.

Es gibt da mehrere Faktoren/Bugs, die zusammenkommen:

1.) Die Zugkraft (MaxForce) ist nicht in kN, sondern kilo-lbf (1000-Pfund) anzugeben. Der Umrechnungsfaktor ist 4,45, d.h. eine Lok, die da den Wert in kN stehen hat (wie es die Doku verlangt), ist 4,45 mal so stark, wie sie sein soll. Und beschleunigt daher 4,45 mal so schnell.
Fehlerhaft sind 101, 143 und 151. V200 und 294 sind ok.

2.) Die Streckenhöchstgeschwindigkeit, die in den Track Rules angegeben wird, wird von der AI als mph interpretiert. Daher fährt die AI grundsätzlich 1,6 mal so schnell, als man möchte. Betroffen sind natürlich nur Gleise, die kph statt mph als Einheit angegeben haben (in der Track Rule).
Abhilfe: Performance 59% (oder halt 60% gerundet) ergibt die Streckenhöchstgeschwindigkeit. Für Güterzüge nimmt man natürlich nur einen Teil davon. Beispiel: Vmax 120, Güterzug soll 60 km/h fahren, Performance = 60 / 2 = 30%.

3.) Bei manchen Güterwagons ist das Gewicht (Mass) nicht ganz das, was man vermuten würde. Ist unterschiedlich, aber bevor du 2000t-Zug sagst, schau einmal ins bin-File, was da unter Mass steht, und eventuell unten unter Capacity bei Schüttgutwagons, wobei ich nicht ganz sicher bin, ob/wie das berücksichtigt wird. Daß beladene Containerwagons so schwer sind wie leere halte ich für höchst wahrscheinlich. Abhilfe: Wie in MSTS je 1 Variante für leer und voll erstellen.