Beiträge von Maik Goltz

Zitat von Berliner079

Diese Erklärung leite mal an VR weiter, und nicht an mich, denn ich habe diesen begriff aus dem entsprechenden handbuch entnommen,
virtual-railroads.de/baureihe-…sto-mint-expert-line.html

In dieser Anleitung ist kein Hinweis auf eine "Zwei Wege Steuerung" zu finden. Die Begrifflichkeiten wurden korrekt, wie von @MarcoL397 erwähnt, in die Anleitung übertragen. Bitte informiere dich zukünftig genau, wenn du solche Behauptungen in den Raum stellst. Auch viele andere Dinge die du im Bezug auf unsere Produkte hier vom Besten gibst, sind nicht ganz korrekt. Denke bitte daran, dass die Userschaft, die das alles liest, das für bahre Münze nimmt und wir dann die Support-Arbeit ableisten müssen, aufgrund vieler getätigter Falschaussagen hier im Forum. Wenn du es nicht genau weist, dann bitte spekulieren nicht, sonder frage vorher nach und schreibe erst dann die korrekten Informationen hier hin. Da wären wir dir sehr dankbar für.

Zitat von kiter

Ich persönlich finde es schade, das vR sich nicht dazu entschließen kann beide Versionen so anzubieten, dass sie den selben Dateipfad haben.

Das bestimmen nicht die Drittanbieter, sondern DTG.

Der Shop kann nicht einfach offline genommen werden, dann kommt nämlich auch kein neuer mehr Der Angriffspunkt, auf den die seit Monaten laufenden Angriffe auf den Shopserver (x-mal pro Sekunde von diversen russischen Servern) aus sind, wurde entfernt. Der Code für den Miner muss schon deutlich länger im Shop gewesen sein, wurde aber erst passend zum 24.12. als Geschenk aktiviert. Über diesen Weg ist es nun nicht mehr möglich Code in den Shop einzuschleusen. Aber es ist natürlich möglich, dass es auch andere Wege gibt. Auf diesen Verdacht hin wird aber nicht der Shop zugemacht. Sonst müssten ja alle Online-Shop dicht machen die es gibt, denn keiner ist vor Angriffen sicher.

Der Miner wurde vorerst Dank eines Hinweises entfernt. Fragt sich halt nur wie lange das so bleibt. Wir arbeiten weiter an einem neuen Shopsystem. Das dauert bekanntlich etwas. Genauere Infos dazu gibt es später von offizieller Seite per Newsletter.

Das Problem ist bekannt. Es wird mit Hochdruck an der Erstellung eines neuen Shopsystems gearbeitet. Der von Russen eingeschleuste Miner ist nicht lokalisierbar. Ich habe meine ganzen Weihnachtsfeiertage damit verbracht das Ding zu suchen. Der Miner wird Client seitig injiziert. Wie, das erschließt sich mir leider nicht. Der Server liefern Miner freien Code aus. Das schein eine neue perfide Methodik zu sein. Der Shop ist somit am A. Der Miner ist aber ungefährlich. Er lastet nur die CPU aus, richtet aber sonst nichts an. Der Shop funktioniert genauso wie vorher. Mehr gibt es dazu momentan nicht zu sagen.

Man bekommt aber über die Styles den Weichspüler nicht weg. Es geht also nur, wenn man Steam aus der Skalierung raus nimmt. Wer weis was das noch alles für Effekte mit sich bringt. Wie gesagt, ist das bei vielerlei Software ein Problem unter Windows. Habe ich ständig mit zu kämpfen. Und da sind vor allem viele Helferlein dabei, die noch auf alten GUI Elementen aufbauen. Der BPE des TS ist da übrigens auch so ein Kandidat. Trotz dem er in .NET relativ modern geschrieben wurden, unterstützt er die Skalierung nicht. Das macht es quasi unmöglich, länger als 5 Minuten mit dem Ding auf 32" 4k zu arbeiten. Da drehen sich einem die Augen aus den Höhlen. Angeblich hat MS in der nächsten Windows Version da einige Verbesserungen erschaffen. Aber wirklich glauben tue ich daran nicht.

Zitat von moritz.hoefner

@Maik Goltz naja es sind 125% empfohlen von Windows und wenn ichves auf 100% unstelle (was ich schon versucht habe) wird alles betroffene zwar schärfer aber fast unlesbar klein. Gibts vielleicht noch andere Möglichkeiten?

Wirklich viel andere Möglichkeiten gibt es da nicht, außer was @Dayjay erwähnt, was aber dann eben den Steam-Client aus der Skalierung wirft. Da du scheinbar keinen 4k Monitor betreibst, halte ich die Skalierung für unnötig. Das sieht auf deinen Screenshot alles doch viel zu groß aus. Wenn das Display natürlich nur 12-14 Zoll aufweist, dann wird alles wieder klein. Deswegen ist ein Laptop mit solchen Displaygrößen auch eher was für Emails und Surfen im Web, aber nicht für lange Produktive Arbeit, da die Schriften eben doch schon zu klein sein können. Sowas löst das MacOS deutlich besser auf den Retina Displays, aber wir haben nun mal Windows hier Da muss man dann eben mit leben. Ich kenne die Die Probleme nur zu gut, da ich seit Jahren auf dem Pfad der Erleuchtung zum perfekten Monitor-Arbeitsplatz ständig in den Abgrund rutsche. Es gibt leider kaum Perfekte Darstellung, nicht auf 12", 27" WQHD, 32" 4k oder gar 55" 4k, wie ich es aktuell habe. Man muss immer Kompromisse eingehen, da nicht jede Software hier mitspielt.

Nein Safter, er hat schon recht. Die Schriften sind weich gezeichnet. Scharf sieht anders aus. Das Problem hier ist wahrscheinlich eine Skalierung der GUI-Elemente von Windows. Nicht jede Software reagiert da gut drauf und Steam gehört leider dazu. Schau mal unter "Anzeigeeinstellungen -> Skalierung & Anordnung -> Größe von Text, Apps und anderen Elementen ändern". Da sollte 100% stehen. Wenn nicht liegt es daran.

Seht nett aus, technisch gesehen, aber wird garantiert genauso proprietär wie Run8 werden. Das dürfte keine Konkurrenz zum TSW darstellen, maximal eine Alternative für Technik-Fetischisten in Sachen Eisenbahn. Ich schau es mir mal an. Die paar Öcken ist es definitiv wert.

"Professionell" lassen wir mal dahingestellt, aber eines sind sie, viele. Da sind etwa 100 Leute für den TSW am werkeln und man kann mit 100 Mann keine Strecke bauen, also bauen die mehrere gleichzeitig. Nur das würde auch Sinn ergeben. Man wird garantiert an dem vorhandenen Konzept festhalten, viel, einfach und schnell zu bauen.

Ich halte mich offensichtlich zu selten im TS auf, um sowas nicht zu bemerken

Die Betreiber der ungarischen Seite scheren sich eh einen Kehricht um die Belange von Herstellern. Was du am Ende auf deiner Platte machst ist dir überlassen. Es ist aber halt nicht abgesegnet das Repaint und das wohl aus gutem Grund, es funktioniert ja scheinbar nur schlecht. Deswegen gibt es ja die Regeln und die Abnahme, damit keine Probleme entstehen.

SimuGraph ist rein CPU basiert und nicht auf PhysX oder sowas. Und über CUDA kannst sowas nicht lösen in einem Spiel. Die Graka ist und bleibt im TS reine Polyschleuder. Und wenn du meintest die Nvidia PhysX über die GPU laufen zu lassen, da ist doch bereits bekannt, dass da jede CPU schneller ist. Es gibt nur 2 oder 3 Spiele die wirklich die GPU bei PhysX nutzen. Eines davon ist Metro. Aber wenn man das dann einschaltet, merkt man sofort, dass es nichts bringt. Ein TS (als Spiel) wird immer CPU basiert sein müssen. Zumindest mit der aktuell vorhandenen Architektur an Hardware. Es braucht einfach ganz neue Dinge um sowas zu lösen. Im Prinzip so etwas wie Apple jetzt mit der KI macht. Einen Chip der nur KI macht mit einer speziellen API. Klar, PhysX ist auch sowas, aber siehst ja selbst wie es verkümmert. Keiner kauft extra eine Graka extra zum hohen Preis um PhysX zu beschleunigen. Und eine einzelne hat zu wenig Power. Zwei geht aber auch nicht, da im SLI die 2. Karte kein PhysX extra berechnen kann. Da fehlt es eben wieder an der API. Kannst drehen wie du möchtest, es bleibt alles Käs. Das dauert noch 20 Jahre bis das mal wirklich toll läuft.

Dann müsste das aber mit normalen Wagen auch passieren, denn da gibt es keinen Unterschied. Auch die Sdggmrss sind normale Wagen, aber halt 2 je Einheit. Kannste aber auch 2 Eanos zusammenkuppeln und hast das selbe, nur andere Optik. Also ich hatte das noch nie und ich habe wahrlich schon einige Wagen aufgegleist.

Was meint ihr mit verdrehen? Ich hatte noch nie Probleme mit den Wagen beim Kuppel oder Zusammenstellen. Da dreht sich kein Wagen von allein einfach um. Wenn man die in einem Szenario korrekt platziert und kuppelt, sollten die dann auch so stehen beim Start. Mehrteilige Wagen sind nichts anderes als mehrere Wagen in bestimmter Reihenfolge aneinander gekuppelt. Die Jakobsdrehgestelle sind nur ein optischer Trick. Jeder Wagenteil hat 2 Drehgestelle. Eines davon ist unsichtbar.

Das sehe ich nicht so. Oder machst du das an der Ghz-Zahl fest? Die ist nicht relevant. Relevant ist, was der Prozessor in einem Takzyklus zu leisten vermag. Eine moderne CPU ist erheblich leistungsfähiger auf einem Kern als eine 3 Generationen zurück liegende CPU mit deutlich mehr Kerntakt. Die Ghz sind nur Marketingzahlen fürs Kaufvieh. Echte Leistung misst man anders.

Dann haben die möglicherweise ein Flag gesetzt, dass das Cooking verhindert. Das würde dann auch die schlechte Peformance erklären. Hab mich mit dem Fernbus nicht beschäftigt, ist mir zu hässlich

Würde ich so sagen ja, hatte ich auch schon öfter mal erwähnt ^^. Wer was bauen will muss auch alles was er braucht selbst bauen (Assets), oder eben sich mit anderen Leuten zusammen tun. Ich denke mal schon, dass DTG beim Launch des Editors eine Art Grundstock an Material mitgeben wird, aber garantiert keine ganzen Strecken. Die fertigen Strecken kannst du so nicht mehr verwendet weil die eben gekocht sind. Rückentwicklung ausgeschlossen. Auch wird es interessant werden wie das mit der Flora läuft, auch für Drittanbieter die Strecken bauen. Die Speedtree Lizenz ist stets Projekt bezogen. Laut deren Definition ist ein AddON für die UE auch ein eigenes Projekt. Heist im Klartext, dass ein Streckenbauer, der die SpeedTrees verwenden möchte, schon mal satte 7000€ netto berappen muss nur für die Nutzung der Flora. Da sind aber noch keine Modelle bei. Das kostet dann nochmal paar Tausender für die eigentlichen Bäume. Oder man setzt sich hin und baut eigene. Das wird alles nicht wirklich einfacher und besser werden im TSW

Zitat von Interplayer

Die .uassets sind die Dateien die die UE4 nimmt wenn du ein Spiel baust. Du könntest also die dateien in deinem eigenen UE4 Spiel benutzen. Ich kann schon verstehen das alles in .pak gepackt wird, damit ein anderer Entwickler sie eben nicht klaut.(Nach eigenem Wissen geschrieben)

Die .uasset im Deployment sind nicht das Selbe, wie die .uasset die man im UE4 Editor verwendet. Nur die Endung ist gleich. Der UE4 Editor erkennt zwar den Typ der Datei aber laden kann man diese nicht mehr. Die UE "kocht" alles wenn man das Spiel oder Addon final erzeugt. Das Kochen beinhaltet viele Dinge wie zB. Performanceoptimierungen ala DynamicBatch oder Bakings. So ein Cooking kann auch schon mal richtig lang dauern. Die erzugten Dateien sind eigentlich nicht mehr bearbeitbar. Es gibt ein paar Werkzeuge die aus den gekochten Texturen und Sounds wieder die Originale herstellen können. Das funktioniert aber nur marginal und nur mit bestimmten Texturtypen. So ein "im Asset gebaue" wie jetzt im TS kann man in der UE vergessen. Entweder man hat Source oder man hat Pech.

RSSLO ist hier offenbar auch davon ausgegangen, dass die User immer mit vollem Tank losfahren und hat den Tankinhalt deswegen fest im Script verankert. Sollte man möglichst nicht machen. Gerade bei Dieselloks bietet sich ja an, auch mal mit leerem Tank zu starten. Dann passt aber das was RSSLO da gescriptet hat nicht mehr. Und das hätte man auch besser machen können, denn nach kurzer Überlegung und etwas in dem Blueprintgewusel des TS geschaut, ist es sehr einfach möglich, den aktuellen Tankinhalt normalisiert auszulesen und auszuwerten. Aber bei der Lok hat man einfach wieder den Fehler gemacht, statt Gallonen eben Liter einzutragen. Klar, steht wie immer im BPE nicht dran welcher Einheit der Wert entsprechen soll, aber ein Blick in die Docs hätte Klarheit geschafft.