Beiträge von Maik Goltz

Sorry Leute aber der ICE1 ist grad wirklich kein Thema. Der basiert auf einem ganz anderen Scriptansatz und da kann man nicht mal eben die PZB reinfummlen ohne den ganzen Rest umbauen zu müssen. So ein kompletter Umbau war ja angedacht für das Script der 120EL was der ICE dann bekommen hätte. Aber da die ganzen Dinge nicht so funktionieren wie gewünscht, gibt es da auch momentan kein Ergebnis was einbaubar wäre. Punkt.

Tja, da kollidieren eben auch diverse Ansprüche. Die beiden implementierten Funktionen im TS sind ja bekannt, und auch halbwegs was sie können und eben auch nicht. Also eigentlich ist genau bekannt was der TS kann und was nicht. Das ist also kein "auf das Programm Geschiebe". Mit LUA hat das auch wenig zu tun. LUA ist hier nur das Werkzeug, das durchaus vollständig beherrscht wird. Der TS bietet aber einfach nicht die notwendigen Funktionen um viele Dinge umzusetzen. Die LZB Funktion wird durch einfache Signalabfragen realisiert. Das ist eben nur ein Workaround aber keine richtige Umsetzung. Da muss man an den Signalen rumtricksen damit damit es geht. Damit ist dann eben der Mischbetrieb, den wir aber für Strecken wie Berlin-Wittenberg benötigen, komplett unmachbar. Wenn ich einfach sagen könnte "fragen genau nur diesen Signaltyp ab der ein eingeschränktes Signalbild zeigt" ab, dann könnte man die LZB Blöcke wunderbar abbilden und diese eben auch zusätzlich zu anderen Signalen setzen. Aber genau das geht eben nicht. Es wirde einfach jedes beliebige nächste einschränkende Signal zurückgemeldet, egal ob das für LZB wichtig ist oder nicht. Also was macht man, man geht her und stellt die normalen Signale in so großen Abständen auf wie auf Muc-Aug. Das geht auf der Rennpiste da, aber nicht auf anderen Mischbertiebstrecken. RSC ist das Wurst, weil die Fahrzeuge quasi an die Strecke gebunden sind. Die hätten das selbe Problem wenn sie zB die Rollbahn von HB nach Münster bauen müssten. Dort stehen eben die Signale in 1000m Abständen und dann funktioniert deren LZB nicht mehr. Möglicherweise ändern sie genau dann die Möglichkeiten des Abfragens und erweitern diese, aber eben nicht jetzt wo wir es brauchen. Somit ist eine LZB nach RSC Maßstäben bisher nur auf Muc-Aug benutzbar und nicht auf anderen Strecken die normale Signalabstände benutzen.

Ich merke aber leider eh dass ich die Problematik hier nicht darlegen kann, ohne dicke Romane zu schreiben. Dazu sind die Leute einfach nicht tief genug drin in der Materie. Von außen sieht immer alles einfach aus. Deswegen stelle ich die Rechtfertigungsversuche jetzt ein und widme die gesparte Zeit den neuerlichen Versuchen herauszufinden wie es nun machbar wäre oder eben auch nicht. Die Ergebnisse oder eben Nichtergebnisse werdet ihr dann in den Produkten erkennen. Wem diese dann nicht zusagen, der braucht sie nicht zu kaufen. Wir können auch nur mit Wasser kochen.

ice, du musst das leider etwas genauer und tiefer betrachten. RSC hat die vorgetäuschte LZB Funktion für bisher genau eine Strecke und die beigepackten Fahrzeuge gebaut. Unsere Fahrzeuge müssen aber auch auf anderen Strecken funktionieren. Diese Nachhaltigkeit wäre nicht gegeben mit deren, nach wie vor undokumentieren Umsetzung. Es ist auch sehrwohl wichtig wie weit die Funktion nach vorn schauen kann. Schliesslich handelt es sich um unsere EL Produkte und diese stellen auch an uns erhöhte Erwartungen von Seiten des Kunden. Auf Muc-Aug kann die LZB nur funktionieren weil die Trasse dafür speziell prepariert ist. Wie genau, das erschliesst sich mir bisher nicht. Ich habe da einen Verdacht und auch eine Idee, aber mehr auch nicht. Und so probiere ich eben Tag ein Tag aus immer wieder neu und komme nicht weiter. Das hält auf und kostet letztlich viel Geld.

Ganz davon ab war mir von anfang an klar, dass diese Aussagen wie "na RSC kanns doch auch" irgendwann in dem Bezug kommen. Aber das ist kein Argunment. VW und Audi und andere solche Hersteller können auch Autos bauen weil sie wissen wie sie gebaut werden müssen. Ich weis es aber deswegen noch nicht wenn sie es mir nicht sagen (was nicht ganz stimmt, das ist also ein fiktives Beispiel ... ich habe schon ein Auto komplett zerlegt und wieder zusammengebaut und das war irgendwie einfacher als ne LZB für den TS zu coden, bzw hat weniger Frustfaktoren weil man zum Ergebnis kommt am Ende).

Das sollen auch alles keine Ausreden sein. Ich will genauso LZB wie viele Andere. Aber ich möchte auch genausogut keinen Murks dem Kunden anbieten müssen. Der TS ist leider nun mal ein sehr eingeschränktes Arbeitsumfeld wenn es um solche technischen Aspekte geht. Er ist einfach nicht "offen" genug um neue Funktionen schnell und ordentlich zu implementieren. Da gibt es deutlich bessere Simulatoren am Markt die sowas viel besser drauf haben. Es wäre für RSC und einen ordentlich bezahlten Coder sicher kein Problem in den TS mal eine ordentliche API einzubauen, aber denen ist das nicht wichtig. Dort ist nur Show angesagt. Und die LZB von denen ist eine reine Show.

Zur LZB, und warum diese nur schwer zu implementieren ist, habe ich bereits ausfühlich geschrieben hier im Forum. RSC hält mit Informationen hinterm Berg, die HRQ Umsetzung ist nicht die selbe wie die von RSC und arbeitet noch schlechter. Der Vesuch das in die 120 einzubauen ist bisher gescheitert, da die Lok bei 200km/h und 11 Wagen keinen so massiven Anker hat wie sie bräuchte. Das bedeutet die AFB funktioniert nicht mit der pseudo LZB weil die Bremswege auf normalen Streken (die nicht extra für die pseudo LZB gebaut wurden wie Muc-Aug) zu lang sind und die Leute einem dann aufs Dach steigen weil die AFB nicht richtig bremst. Das manuelle Bremsen betrifft das ebenfalls. Auf Berlin-Wittenberg würde die gar nicht erst funktionieren. Das sind nur einige der Schwierigkeiten bei der Sache. Dass die Funktionen komplett undokumentiert sind ist eine weitere. Klar kann man durch Reingeneering und viel investierter Zeit eniges rausfinden, aber durch die vorkompilierten Scripte der Signale sind zB die "Sonderfunktionen", die RSC in die Signale gebaut hat damit deren LZB funktioniert, nicht einsehbar. Und ich rate ungern rum. Das führt zu keinem Ergebnis. Die Scripte im Klartext hat Ulf vor einiger Zeit bereits angefragt bei RSC, aber da kommt wie gewöhnlich nichts ausser kühle Luft.

Die 120 wurde in die Ecke gestellt wegen dieser under andere Unzulänglichkeiten des TS. Die 103 wird jetzt auf der alten Basis gebaut und da diese keine AFB und andere regeltechnische Vorgänge im bezug auf LZB benötigt, könnte es sein, dass diese mit dieser halb funktionierenden pseudo LZB kommt. Das wird momentan in vielen Stunden kleinlicher Probierei ausgelotet. Wenns aber nicht geht, dann kommt es auch nicht rein.

Zitat von Reviersprinter

Nanu die bauen wir ja schon

Tja, da hat RSC einen klaren Vorteil. Die müssen Niemandem sagen was sie tun und die bauen so eine Strecke in 8-12 Wochen. Da kann die Community und der kleine Entwickler nicht gegen ankommen. Da kann man nur mit deutlich besserer Qualität punkten, wenn man eine gleiche oder ähnliche Strecke an den Mann bringen will. Aber auch das wird dann schwer.

Hat jemand schon das Magazin irgendwo im Onlinehandel (DL) entdeckt. Albo-Medien ist offenbar nicht in der Lage das eigene Produkt in den Verkauf zu stellen. Wozu auch, ist ja nur ein Hobbymagazin das kein Geld abwirft und das keiner kauft und Albo braucht scheinbar das Geld auch nicht

Eben, ihr müsst immer auch davon ausgehen, dass es Menschen gibt, die diese Lok noch nicht haben. Ein so altes AddOn würde ich zB nicht mehr kaufen wenn ich die Lok noch nicht hätte. Also macht man sie jetzt neu, und bringt sie eben auch neu an den Mann. Die machen das nicht weil es Spass macht, sondern weil es genau so und gut funktioniert. Die 3 Leute die sich aufregen sind RSC total egal. Der Stellenwert der meckernden Kommunity ist sehr gering, vor allem bei RSC. Die haben eine fest Linie und von dieser weichen die nicht ab weil sie es nicht müssen. Ganz einfache Rechnung.

Die Grenzen sind wirklich etwas realitätsfern. Ich hab die Tage die ganzen Kommentare die so umherschwirren zu dem Thema verfolgt und die Meinungen gehen weit auseinander. Aber viele von den Leuten die sagen "das reicht doch aus" benutzen den Internetzugang nicht wirklich zeitgemäß. 75Gb sind überhaupt nichts heutzutage, auch nicht mit einer eher langsamen Leitung (ich Zahle für 16 und hab nur 12, allerdings nicht Telekom). Was ich hier allein am Tag rauf und runterlade geht da locker drüber und das ganz ohne Videos (mal ab von Youtubes Pixelpampe). Dazu kommt dass hier zB kein VDSL geht. Selbst wenn ich also mehr zahlen wollte weil ich mehr Traffic benötige, dann geht das nicht. Ich erinnere mich noch an 2000-2004. In der Zeit habe ich krampfhaft versucht DSL zu bekommen, wohlgemerkt mitten in Berlin. Ich hatte damals nur ISDN und keine Flatrate (die wurde ja schnell wieder eingestellt). Das waren kosten von 150-200DM im Monat. Ein DSL Anschluss kostet weit weniger und ich hätte auch die 200 dafür gezahlt. Aber die Infrastuktur gab es einfach nicht her. Und genau das ist jetzt auch wieder. Man zieht den schwarzen Peter weil die Infrastuktur fehlt, man selbst aber gern auch draufzahlen würde um weiter wie gewohnt mit dem Netz arbeiten zu können (ob nun privat oder beruflich ist egal, das verschwimmt hier total). Jetz kommt noch der Satz "dann bestell einen Businessanschluss". Klar, aber das ist für den Kleinunternehmer dann sein komplettes Monatseinkommen dass dafür drauf geht und schneller ist der Anschluss bei dem was man sich noch leisten könnte auch nicht. Die Telekom macht mit ihrem Vorstoß hier die Zukinft der Internetnutzung in Deutschland kaputt. Die Leute werden sich dermaßen einschränken, dass die Gewinne bei den Firmen die große Datenmengen liefern/verwalten/vorhalten stark zurückgehen und diese Firmen zugrunde gehen. Dadurch wieder fallen unersetzlich diverse Dienste weg die ihren Wert haben. Das ist also ein risen Rückschritt und das alles nur mit einer großen Engpasslüge. Denn das Netzt itself hat mit den Datenmengen gar kein Problem, lediglich die Telekom Finanzabteilung hat eins.

Das geht sicher ein bisschen weit aber ich hatte eine ähnliche Idee bereits im Kopf. Ich wollte mal versuchen einen Kilometerzähler einzubauen und die Lok muss dann nach einer bestimmten Laufleistung ins BW (eine kleine extra Aufgabe beigepackt). Idee gut, Umsetzung weniger. Ich muss den Wert des Kilometerstandes ja irgendwo über die Szenarien hinausretten, also speichern. Und genau da liegt das Problem so ein bisschen. Da es kein OnSzenarioEnd() Event gibt, muss ich ständig den Stand abspeichern, und da dies nur in einer Datei möglich ist, weil wir hier keine Datenbanken zur Verfügung haben im TS, wäre das eine weitere große Fehlerquelle die man sich damit einbaut.

Lässt sich sicher machen. Screenshots müssen eh immer angefertigt werden.

Das neue OL System hat übrigens das gleiche Problem mit der Fahrdrahthöhe und den nicht variablen Pantographen. Schaut ma auf London-Faversham genu hin. Da ist der Panto auch eher selten am Draht. Aber man sitzt ja auch nicht auf dem Dach sindern vorn aufm Bock. Schön wären sich bewegen Pantos ja, würde deutlich mehr Realität ins Auge geben, aber das geht eben nicht. Gibt halt keinerlei Möglichkeit die Collisionsdaten abzufragen und zu reagieren. Nicht mal relative Abstände kann man abfragen, nur einen Abstand eines Fahrzeuginternen Nodes mit der 0 der aktuell befahrenden Kachel. Das hilft aber nicht weiter da der Fahrdraht da keine Rolle hat.

Die Stromabnehmer sollten eigentlich alle auf der selben Höhe sein, bei allen Loks. Denn der TS2013 gibt die mehr oder weniger vor. Wer OL selber zieht, der muss eben auf die korrekte Höhe achten. Collisionsabfragen werden wir nicht erwarten dürfen also bleibt es dabei. Alternative ist nur die OL Masten als Signale zu bauen und mathematisch an die Sache ran zu gehen damit sich der Panto dem Tatsächlichen Höhenverlauf der OL anpasst. Das ist aber nur Theorie und im TS quasi auch nicht machbar.

Dann ist es missverständlich formuliert. Da steht nur sinngemäß dass kein rotes Dreieck dort sein darf, nicht wo es nicht sein darf. Eine Weiche hat mindestens 3 Trennung zu haben damit sie funktioniert. Natürlich ausserhalb der Innenkonstruktion, also Zugen und Herzstück.

Warum fällt keinem auf, dass die Anleitung mit der Weiche da oben falsch ist? Warum soll da keine Trennung hin? Da MUSS eine Trennung hin damit die Signale funktionieren.

Pssssscht!! .. nicht doch so laut. Zu so später Stunde weckt ihr doch die ganzen Nachbarn auf

Die Wagen sind über das Wagonnummernfeld konfigurierbar. Einfach "Skin01-" bis "Skin04-" vor die Nummer schreiben, dann wird das entsprechende Aussehen erzwungen nach dem Start. Steht auch in der Anleitung.

Ja keine Ahnung. Ist nur eine Vermutung da die Motoren ja in der Lage wären auch als Wiederstand zu dienen. Bei den schweren Güterzügen aber warscheinlich ohne jedwede Wirkung.

Ein Güterwagen als Bremse hat dann aber eine sehr zackige Kennline. Und die Lok ist dann ein Fall für den Altmetallhändler wie dieses Schätzchen hier http://img250.imageshack.us/img250/9854/120111azo5.jpg

Bei ner V200 ist dann eben eine Sand-Wiederstandsbremse. Einfach das Kieselgut ins Getriebe schütten, das wird schon irgendwie bremsen ohne dass man die Bremsbacken bemühen muss...

Ah stop... welche V200? Die Trommel war/ist diesel-elektrisch und hat wohl auch teilweise eine E-Bremse

Die Ami-Diesel sind diesel-elektrisch. Da geht das. Bei den diesel-mechanical und diesel-hydraulic BPs geht das nicht. Man kann die zwar eintragen aber sie tut nichts. Ist ja auch klar. Es ist eine E-Bremse und keine hydrodynamische Bremse. Letztere kennt der TS nicht genauso wenig wie eben ein Wandlergetriebe. Das hydraulic BP ist voller bugs und kaum verwendbar, oder einfach nur schlecht dokumentiert, wer weis.

Und was wenn für die meisten Güterwagen eben keine anstehen? Dann passiert es eben auch nie. Du musst hier immer paketbezogen den Aufwand berechnen. Es geht nicht schneller wenn man 30 Palkete auf einmal updatet oder sowas. Bei den nächsten Güterwagen werde ich das veruschen einzubauen, und wenn jemand einen Rangierer spendet, bauen wir den auch ein. Personen bauen ist nicht so toll und kostet viel Zeit (auch wenn da nun wieder andere Stimmen aufkommen, aber hier muss priorisiert werden).

Polygone sind gar nicht mal das Problem im TS2013. Bau dir ein Objekt aus 50k Poly aber bepinsel es mit einer 1x1px Textur. Da kannst du 500 von hinstellen, da passiert nicht viel. Man hat sicher keine Framerage von 200fps mehr aber 30 sind noch drin. Es sind die Texturen die in TS2013 die Performance zerstören. Das ist aber nicht die Schuld der Objektbauer sondern der Mangel an der Gameengine selbst. Die rendert die megatexturen auch in 2km noch. Zumindest FrustumCulling scheint die Engine aber zu beherrschen, sonst gäbs warscheinlich ein Desaster. Jetzt brauchs nur noch OcclusionCulling damit auch nur das gerendert wird was auch zu sehen ist. Bisher wird ein Haus mit einer 4k Textur auch hinter einer Wand aus anderen größeren Häusern gerendert und das kostet sinnlos Performance. Besten Beispiel für die Auswirkungen dessen ist KöDü. Es braucht also wirklich Objekte die an den Aufstellort gebunden sind mit ihrer Detailtreue. Ich weis nicht ob LODs da was bewirklen, aber das wäre auch eine Option da ordenlich die 10 LOD Slots zu nutzen. Leider werden die LODs nicht überbeldnet sondern hart umgeschaltet. Sieht dann bissel doof aus wenn die Hauswand 200m vor einem erst scharf aufpoppt statt langsam zu überblenden.