Posts by red51

Quote from Deirdre

Ich habe Probleme mit Java-Blaupausen in denen die ID 15 (36 im Spiel direkt) durch meine Textur ersetzt wurde. Diese Textur wurde überhaupt nicht übernommen.

Naja, die ID 15 war ja eine der nicht verwendeten schwarzen "N/A" Texturen in der Java Version, d.h. in der Blaupause ist auch lediglich die Information "15" vorhanden, nicht mehr, und nicht weniger Wie gesagt, die Texturen selbst (also die Bilddaten) werden nicht in Blaupausen gespeichert, da dies die Blaupausen massiv aufblähen würde (und darüberhinaus auch einige Copyright-Fragen in den Raum stellen würde, wenn Blaupausen im Forum geteilt werden)^^

Quote from Deirdre

Ich hatte die Java-Blaupausen erwähnt, auf denen die Farbblöcke in der Unity-Version viel dunkler rüberkommen.

Beim Vergleich der Farbblöcke fällt das nicht auf, allerdings ist der Unterschied bei einem gebauten Teil gravierend. Siehe Screen. (das helle Fenster stammt aus der Java-Version).

Auf dem Bild fällt der Unterschied natürlich sehr extrem aus, da der Rahmen auf dem rechten Bild im Schatten liegt, während er auf dem linken Bild direkt von der Sonne angestrahlt wird (da es in der Java Version ja keine Schatten gab).

Es kann aber durchaus sein, dass einige Farbtöne, die wir als Ersatz definiert haben, noch nicht optimal sind. Ich gucke mir das nochmal genauer an

Quote from Deirdre

Es wurde bestimmt schon einmal irgendwo erwähnt, xD, aber wäre es irgendwann möglich die Texturen von Möbeln zu verändern, um eine gleichmäßigen

Farbverlauf der Umgebung zu gewährleisten?

Das ist generell ein heikles Thema, da Objekte nun - anders als in der Java Version - ihre eigenen Texturen bzw. ein ganz konkretes "UV Mapping" haben. Das muss man sich so vorstellen, dass Objekte in abgewickelter Form vorliegen und darauf dann eine Textur angepasst wird. Hier ist ein Bild (von der CryEngine, aber das Prinzip ist überall dasselbe), was das recht gut verdeutlicht (links ist die Textur zu sehen, rechts das zugehörige Objekt): https://docs.cryengine.com/dow…Date=1439377292000&api=v2

Würde man nun einfach eine der Bautexturen darauf legen, würde das leider in vielen Situationen nicht gut aussehen und teilweise verzerrt erscheinen.

Mal sehen, ob wir dafür eine andere Lösung finden, aber momentan kann ich dazu leider noch nicht viel sagen.

Quote from Yaromid

Wie sieht das dann eigentlich mit Wäldern in der neuen Weltgeneration aus, wird es da nochmal unterschiedliche Varianten geben?

Also auf unserer Agenda stehen momentan nur Laub- und Nadelbäume Die werden natürlich anders aussehen als in der Java Version.

Wir haben aber prinzipiell so viele Bäume vorbereitet, dass wir später auch mehr Abwechslung pro Biom haben können (also zB auch eigene Wälder fürs mediterrane Biom - während das in der Java Version ja recht überschaubar war [das war die Gegend mit den Pappeln, zwischen Graslandschaft und Savanne]).

Gibt es ansonsten noch eine bestimmte Waldsorte, an die du gedacht hast?

Quote from Deirdre

Ist es dann bereits möglich die Bäume oder Pflanzen so weit zu verkleinern, dass sie bequem in Blumentöpfe passen, ohne dass auf Konsolenbefehle

zurückgegriffen werden muss?

Daran wollen wir eigentlich nichts ändern. Denn die Bäume sind sehr detailreich (sprich haben viele Polygone), beim Kleinerskalieren jedoch ändert sich daran nichts (die sind also aus Performancesicht genauso "teuer") - der Unterschied ist allerdings, dass man bei Miniaturversionen viel eher dazu neigt, viele davon auf kleinem Raum zu platzieren. Wenn jetzt ein Spieler bspw. ein großes Beet dicht mit Miniaturbäumen bepflanzt, würde das einen verhältnismäßig großen Einfluss auf die Performance haben - und besonders im Multiplayer kann das kritisch werden.

Das freie Skalieren via Konsolenbefehl werden wir definitiv nicht einschränken, aber wenn es auch regulär möglich wäre, Bäume so klein zu machen, ist das quasi wie eine Art "Unbedenklichkeitsbescheinigung"

Mit dem Update werden aber auch allerlei kleinere Pflanzen reinkommen, die man entsprechend problemlos (also auch ohne Befehl) auf Blumentopf-Größe bekommen kann. Die sind in jedem Fall deutlich performanter.

Quote from Deirdre

Mir macht auch etwas Gedanken, dass ich zu viele Pflanzen zu Dekozwecken verwende und dann viele Bauteile und später noch NPCs hinzukommen und

es dann zu Performanceproblemen kommen kann

Pflanzen werden nicht mit NPCs interferieren, d.h. auch sehr viele Pflanzen werden sich hinsichtlich vieler NPCs nicht negativ auswirken. Da sind wiederum viele Bauteile (Blöcke) eher ausschlaggebend.

Hier muss aber betont werden, dass das in der neuen Version bei Weitem nicht so extrem ausfallen wird wie in der Java Version. Die Physikengine der Java Version ist mittlerweile ca. 13 Jahre alt, das hinterlässt irgendwo seine Spuren...

Quote from Deirdre

Oder sieht es mit der Performance bei bereits ins Spiel integrierten Blumentöpfen besser aus?

Kommt drauf an... wenn wir Blumentöpfe mitsamt Blumen anbieten, dann werden die sicherlich besser optimiert sein. Leere Blumentöpfe hingegen machen keinen Unterschied.

Aber wie gesagt, wenn du mit kleineren Pflanzen (die mit dem nächsten Update reinkommen werden) arbeitest, musst du dir da keine Gedanken bzgl. Performance machen. Nur wenn du viel mit Bäumen bzw. Miniaturbäumen arbeitest (also per Befehl klein skalierte Bäume), dann wird das die Performance natürlich beeinflussen (aber trotzdem nicht hinsichtlich NPCs).

Quote from Arakara

Würde es bei dieser Dauer eine Reduktion geben können, wenn die Blaupausen auf verschiedene Unterverzeichnisse verteilt sind? Könnte (rein theoretisch) nur dann geladen werden, was in dem gerade angewählten Subverzeichnis steht? Und wenn dann ein anderes Subverzeichnis gewählt wird, wird kurz jener Inhalt geladen?

Ich kann mir nicht vorstellen, dass alle 1000 BPs auf einmal benötigt werden, sondern z.B. nur die Zaun-BPs, später nur die Dach-BPs, etc.

Leider würde das nicht helfen Die neue Version zeigt ja sämtliche Blaupausen mitsamt Vorschaubild in der scrollbaren Liste an (nur durch einen jeweiligen ein-/ausklappbaren Header getrennt). In der Java Version hingegen musste man im Journal stattdessen explizit die Gruppe wählen, und dann wurden auch nur diese Blaupausen angezeigt. Die Java Version hatte auch den Vorteil, dass von Blaupausen nur der Name angezeigt wurde, und erst beim Draufklicken wurden mehr Infos sowie das Bild sichtbar. Jetzt hingegen müssen von jeder Blaupause zumindest das Vorschaubild und ein paar Metadaten geladen werden.

Das ist in der neuen Version aber trotzdem schon weitreichend optimiert, bspw. werden die Vorschaubilder erst beim Scrollen dynamisch geladen (sprich das Spiel lädt die Bilder nur für die Blaupausen, die in der Liste aktuell auch sichtbar sind, und sobald beim Scrollen mehr Blaupausen sichtbar werden, werden ihre Bilder entsprechend nachgeladen usw). Dennoch dauert alleine das Zusammenbauen der Liste ein wenig, wenn mehrere 1000 BPs vorhanden sind...

Aber wie gesagt, mit dem nächsten Update wird das zumindest insofern etwas entschärft, dass nur noch bei Änderungen des Ordners neu geladen werden muss

Quote from Deirdre

red51 du sprachst von einer gewollten Verzögerung beim Setzen von Blaupausen, warum ist sas gewollt? Wer aus Versehen eine Blaupause zu früh setzt, der kann ja den Unsobefehl benutzen

Ich denke für den Durchschnittsspieler ist die kleine Verzögerung durchaus sinnvoll um ein versehentliches Platzieren zu verhindern. Gerade bei größeren Blaupausen dauert das Platzieren an sich (und der Undobefehl entsprechend auch) ja ein wenig - also nicht die künstliche Verzögerung, sondern allein die Dauer, bis alle Bauteile auftauchen usw. Und im MP bedeutet sowas auch recht viel Last für den Server, da ist es besser, so ein Versehen von vornherein auszuschließen. Man kann sich währenddessen ja auch bewegen und umschauen, um sich selbst ggf. nochmal zu vergewissern, dass alles passt.

Man könnte natürlich darüber nachdenken, für kleine Blaupausen die Zeit evtl. herunterzusetzen (also wenn bspw. nur wenige Teile oder nur eine Lampe o.ä. darin vorhanden sind).... das müsste man sich mal überlegen

Ich schätze es ist aber einfacher, wenn wir eine Option dafür einbauen (vorläufig aber erstmal nur über die config einstellbar). Ab dem nächsten Update kannst du folgendes zur config.properties Datei hinzufügen: Game_BlueprintsPlaceDelay=0.5 (um die Verzögerung auf 0.5 herunterzusetzen) oder Game_BlueprintsPlaceDelay=0 (um die Verzögerung ganz auszuschalten).

Quote from Deirdre

Beim Setzen von Lampen, gefärbt und gedimmt, als Blaupausen in einem Riesenpool angebracht und richtig positioniert, vergeht im Schnitt eine halbe Stunde, mindestens

Aber die halbe Stunde kommt doch nicht wegen der kurzen Verzögerung zusammen?

Quote from Deirdre

Ich habe mittlerweile auch Blaupausen die nicht zu nutzen sind, da die eigene Textur aus der Java Version in der Unity Version nicht erkannt wird. WIrd das mit dem nächsten Update geändert?

Du meinst Texturen aus Texturepacks? Oder was meinst du genau? Blaupausen speichern keine Texturen selbst (sonst könnte eine BP schnell sehr groß werden), sondern nur die Textur-IDs. Wenn also das Bauwerk in der Blaupause bspw. Marmor mit der ID 58 enthält, dann speichert die Blaupause auch nur die "58" (ohne zu wissen, wie die Textur aussieht oder ob sie evtl. ersetzt wurde). Beim Laden in der neuen Version sieht das Spiel dann nur "58" ohne zusätzliche Infos.

Quote from Yaromid

Gibt es Neuigkeiten zum Update ?

Also momentan sind wir noch damit zugange, jede Menge Pflanzen und Bäume in die neue Version zu packen Und entsprechend auch einige zugehörige Items (zB Obst & Gemüse).

Was ein bisschen schade ist, dass der Unity-Bug, wodurch Windows 7 User das Spiel derzeit nicht spielen können, bisher immernoch nicht behoben wurde. Unity weiß seit Oktober darüber Bescheid und der Bug wurde auch mittlerweile in ihrer alten Version (2021.2) und ihrer aktuellen Alpha (2022.2) behoben, in der aktuellen Version (2022.1) - welche wir momentan verwenden - aber ist der Fix dafür seit 2 Monaten "In Review" Ich hatte eigentlich gehofft, dass das zeitig zu unserem Update fertig wird...

Angepeilt haben wir eigentlich, dass wir das Update diesen Monat rausbringen können (also noch nicht die volle Weltgenerierung & Wasser & Co, sondern nur der 1. Teil davon, nämlich Pflanzen und diverse Vorkehrungen). Wir haben aber in den letzten Wochen noch recht viel Zeit in die eigentliche Weltgenerierung gesteckt (damit der 2. Teil des Updates, welcher ohnehin viel wichtiger ist, nicht unendlich lange auf sich warten lassen muss), wodurch aber natürlich der 1. Teil etwas weiter nach hinten gerät... wir werden jetzt aber zusehen, dass das einigermaßen zeitnahe kommen kann

Quote from Avanar

red51 ich dachte bisher, dass die Verzögerung beim Setzen der bp eine Art Sicherheit darstellt, gegen versehentliches setzen und spammen.

Ja genau, allerdings bezog ich mich oben nicht auf diese Verzögerung beim Platzieren (die ja durchaus gewollt ist), sondern lediglich auf die "Ladezeit" beim Öffnen des Blaupausen-Menüs (also wenn man an den Blaupausentisch geht) Sorry, falls ich mich da irgendwie missverständlich ausgedrückt habe^^

Normalerweise ist beim Öffnen des Blaupausen-Menüs keine nennenswerte Ladezeit vorhanden, sprich das Menü erscheint eigentlich mehr oder weniger sofort. Je mehr Blaupausen man aber hat, desto länger dauert es. Wenn man extrem viele Blaupausen hat (zB über 1000), dann kann es durchaus einige Sekunden dauern, bis das Blaupausenmenü erscheint (weil das Spiel erst alle Blaupausendateien durchgeht und das Menü dazu generiert).

Quote from Avanar

Aber bei xxxx bp wird es echt schwierig mit der Zeit. Gibt es nicht einen Mittelweg? Also nur 1x am Anfang laden und dann einen manuellen refresh?

Wie ja im vorherigen Post beschrieben, wird das Spiel ab dem nächsten Update die Blaupausen standardmäßig nur noch dann neuladen, wenn eine Änderung im Ordner erkannt wurde (also irgendeine Datei im "Blueprints" Ordner dazukam, geändert oder gelöscht wurde)

Ich denke, dass das die optimale Lösung sein wird (und es dann eig auch keinen Bedarf mehr nach einem manuellen Refresh geben dürfte).

Du könntest die Auflösung sonst auch über die "config.properties" Datei im Spielverzeichnis (also im "_New Version" Ordner) entweder löschen (dann werden alle Einstellungen auf Standard zurückgesetzt) oder ansonsten mit einem Texteditor öffnen und die Werte Graphic_ResolutionX auf 1280 ändern und Graphic_ResolutionY auf 720 ändern, die Datei speichern, und das Spiel erneut starten. Besteht das Problem mit den Buttons danach weiterhin?

Basically this information is still accurate - once the new version becomes the "main game", the Java version will move to a separate beta branch on Steam (for the standalone, on the other hand, the Java version and new version use separate launchers anyway).

The only information that's slightly outdated is the part about blueprints: In fact blueprint support is already there and Java blueprints are compatible with the new version (at least when it comes to blocks and construction elements)

Quote from Deirdre

red51 Ich habe extrem viele Blaupausen, 1000 dürfte noch zu wenig sein. da dauert das Laden mittlerweile schon sehr lange. Das sofortige Einfügen von neuen Blaupausen ist zwar ein Pluspunkt, aber ich gehe davon aus, dass das nur das Einfügen von Java-Blaupausen oder Blueprints aus dem Forum betrifft oder? Die Option zum einmaligen Laden wäre schon mega.

Ja, das betrifft in erster Linie das Einfügen von heruntergeladenen Blaupausen aus dem Forum (oder auch Java-Blaupausen). Später allerdings auch über die Mod-Schnittstelle (Workshop bzw. mod.io) heruntergeladene Blaupausen.

Mit dem nächsten Update werden wir das auf jeden Fall etwas abändern und die Blaupausen standardmäßig nur dann neuladen, wenn sich der Ordnerinhalt geändert hat. Das sollte das Problem eigentlich schon entschärfen Ansonsten wird man aber per Option auch generell bestimmen können, dass Blaupausen nur einmalig geladen werden sollen.

Quote from Deirdre

Das Einfärben mit der Farbrolle wäre eine gute Option, leider lassen sich die Ersatz- Putzfarben, durch Übermalen nicht aufhellen und eine Texturänderung mit der Rolle funktioniert ja leider nicht.

Kommt darauf an, welche Textur verwendet wird. Wenn es eine dunkle Textur ist, wird man die natürlich nur eingeschränkt aufhellen können, wenn es aber durch eine Farbe zustande kommt, kannst du das natürlich komplett anpassen.

Wenn du dir nicht sicher bist, ob der Farbton von der Textur selber oder einer darüberliegenden Farbe stammt, kannst du die Farbe zB mit edit color 0 zurücksetzen - wenn es immernoch zu dunkel ist, dann ist es die Textur selber. Mit edit texture könntest du dann höchstens die Textur ändern.

Quote from Deirdre

Beim Ziehen von Blöcken ist mitunter die Anzahl der Blöcke nicht zu lesen, egal aus welchem Winkel man es betrachtet

Momentan wird der Text leider von soliden Objekten (zB anderen Blöcken) verdeckt, wodurch er - je nach Position - manchmal nicht sichtbar ist. Mit dem nächsten Update aber wird die Schrift immer sichtbar sein, also auch durch Wände bzw. Blöcke hindurch (wie in der Java Version)

Implementing physics or gravity for construction elements is a bit tricky unfortunately: The user can freely place them (so they're not bound to a grid, for example, which makes it computationally intensive to find connected elements) and there is also no limit about how many elements could be placed. Some buildings consists of tens of thousands or even hundreds of thousands of construction elements - calculating structural integrity for them would have a big impact on performance unfortunately

However, it's still something we may add in the long run

Quote from VIXLENCE

Fire system, wooden materials burn over time changing their texture on a burnt tree, also falling to the surface so that a mountain of static burned garbage remains from the house.

Fire is also planned, actually we did some experiments with that some time ago, but it's also a bit tricky to implement good looking fire (due to the number of construction elements a building could consist of, but also due to their size - if a user creates a big construction element [e.g. a block with a size of 5x5x5], it's getting tricky to render fire appropriately on that). But as mentioned, it's still planned

Could you elaborate on that?

Laut Screenshot ist eine 4:3 Auflösung eingestellt (1280x960), verwendest du wirklich einen Monitor im 4:3 Format bzw. ist das gewollt? Leider kommt die neue Version mit 4:3 Auflösungen noch nicht gut zurecht (lediglich mit 16:9, 21:9 und 32:9), das werden wir aber noch ändern^^

Du kannst das Problem lösen, indem du eine 16:9 Auflösung verwendest - die nächstgelegene Auflösung wäre in deinem Fall 1280x720 (also 720p)

Wir könnten das evtl. später einbauen, aber dafür müssten Blaupausen der neuen Version generell erstmal Terrain unterstützen

Bevor wir aber den Fokus darauf lenken können, müssen wir erst einige dringendere Dinge in der neuen Version fertigbekommen...

Quote from Deirdre

Das Laden von Blaupausen dauert bei mir sehr lange. Ich habe zwar einige Blaupausen in Ordnern, aber meiner Meinung nach ging das Öffnen in der Java-Version mit vielen Blaupausen schneller vonstatten.

An sich dauert das Laden von Blaupausen ungefähr genauso lange wie in der Java Version. Der Unterschied ist allerdings, dass die Java Version die Blaupausen einmalig beim Spielstart eingelesen hat. Die neue Version hingegen macht das jedes Mal beim Öffnen des Blaupausen-Menüs. Hintergrund ist der, dass der Spieler dadurch jederzeit neue Blaupausen ins Spiel einfügen kann, ohne neustarten zu müssen (während in der Java Version hingegen dazu ein Neustart nötig war). Normalerweise ist das auch kein großes Problem, bei extrem vielen Blaupausen (vor allem > 1000) kann das aber schon recht lange dauern...

Wir müssen mal schauen, ob wir das evtl. optimieren können. Ansonsten könnten wir ggf. eine Option hinzufügen, womit Blaupausen nur einmalig geladen werden sollen. Damit würde nur das erstmalige Öffnen des Menüs lange dauern. Nachteil wäre aber, dass neu eingefügte Blaupausen-Dateien erst nach einem Neustart erkannt würden.

Quote from Deirdre

Was mich interessieren würde red51, was wird aus den Farben und Texturen der Java-Blaupausen? Werden die allgemein sehr dunklen Farben/Texturen ersetzt? Ich habe mittlerweile eine ganze Stadt gebaut, allerdings sieht alles gleich dunkel aus und an einem Fachwerkhaus die Holztextur zu ersetzen, würde Jahre dauern. Die Texturen bzw. Farben werden angepasst. jedenfalls habe ich das irgendwo gelesen.

Was passiert mit den bereits in der Unity-Version aufgestellten Bauten und was ist mit den Java-Blaupausen im Ordner?

Ich nehme an, dass Unity Blaupausen (bereits gesetzte Java-Blaupausen) einen helleren Touch bekommen und Java-Blaupausen beim Setzen auch.

Das wären dreimal Farbänderungen. Neue Java Blaupausen, bereits gesetzte Java Blaupausen, also konvertierte und ganz neue Gebäude?

Ich glaube, diesen Punkt verstehe ich nicht ganz Was genau meinst du mit hellen und dunklen Farben? Meinst du damit, dass Ersatztexturen, die die neue Version für Java-Blaupausen wählt, teilweise zu dunkel sind? Wir nehmen da gerne Vorschläge entgegen, damit für künftige Java-Blaupausen evtl. treffendere Ersatztexturen bzw. -farben gewählt werden

Bestehende Blaupausen (die also bereits in der neuen Version geladen wurden) oder auch bestehende Gebäude werden sich aber nicht mehr verändern.

Quote from Deirdre

Avanar Dann wundert es mich, dass die neue Version nicht mehr Leute spielen wollen.

Ich denke, dass die Spielerzahlen vor allem deshalb so gering ausfallen, weil die neue Version noch nicht genug zu bieten hat. Die meisten werden wohl auf die kommende Weltgenerierung und ggf. auch Tiere / NPCs warten. Ich glaube nicht, dass es damit zusammenhängt, dass das Bauen anders als in der Java Version ist...

Zu allen anderen Punkten hinsichtlich Java vs. Unity wurde vmtl. schon genug gesagt... wir drehen uns da irgendwie im Kreis

Quote from Deirdre

Beim Fensterrahmen sind mir Unterschiede in der Anzeige aufgefallen. (siehe Screen).

Stimmt, das ist tatsächlich etwas suboptimal... links wird die tatsächliche Größe angezeigt, während sie in der Mitte aufgerundet wird, abhängig von der derzeitig eingestellten Skalierungspräzision (wenn zB eine Präzision von 0.1 eingestellt ist, wird die Anzeige auf 1 Nachkommastelle gerundet, wenn sie zB 0.01 beträgt, dann auf 2 Nachkommastellen usw).

Wir werden das mit dem nächsten Update ändern

Quote from Deirdre

Außerdem sieht man die weiße Schrift viel besser.

Welche weiße Schrift meinst du genau? Beziehst du dich evtl. darauf, dass die Größenangabe am linken Rand nur schlecht lesbar ist? Wenn ja, dann stimme ich zu - auch das können wir mit dem nächsten Update etwas anpassen

I think that mod.io would be a good solution for this, as mentioned by Minotorious We can integrate it directly into the game, so people can easily download new plugins/blueprints etc.

Having a custom solution for this would be indeed better (as it would give us full control over this), but unfortunately there would be a lot of work involved to set up a proper website, API etc. and to moderate it... so I guess it's easier to rely on mod.io for this.

There was a discussion about support for Steam Workshop, mod.io etc. in the past in our Steam forum: https://steamcommunity.com/app…ns/0/3123802224166721327/

Some people there would prefer support for Steam Workshop, but unfortunately that's not a perfect solution (as it wouldn't work for non-Steam versions of the game)... but apparently there was no real argument against mod.io either

Undo fürs Platzieren ist auf jeden Fall noch geplant

Die neue Version ist tatsächlich für jeden verfügbar, der bereits die Java-Version von Rising World besitzt

Das Code-Feld in Steam hingegen ist nur dafür da, um zusätzliche Einträge für versteckte Betas freizuschalten (was es bei RW so in der Form eh nicht gibt) Das ist zugegebenermaßen etwas irritierend in Steam umgesetzt... aber wie die Vorredner schon sagen, einfach unity - New Version Preview auswählen, das Code-Feld leer lassen und das Fenster schließen. Anschließend wie Deirdre sagt direkt über die Steam-Bibliothek starten und "New Version" auswählen, um die neue Version zu starten.

In singleplayer, the time speed value in the config.properties file is relevant: It's game_time_speed there. The default value is 1.75, please have a look if this is maybe set to a higher value in your file (in this case, just change it back to 1.75 or another value)

Quote from Kryssi_79

Support for Unity Assets/Prefabs and FBX files would be really great

Then theoretically I can also work with C#

Well, unfortunately it won't be possible to load custom C# scripts this way We're using IL2CPP, so there is no Mono runtime which could load C# assemblies...

Support for Unity prefabs / asset bundles would only cover models and materials / shaders (which need to be HDRP compatible)

Unfortunately there is indeed a bug which causes trouble when entering/leaving a tent (like falling through the ground)... We're working on a fix!

Quote from Popeye57

Thx for replying so all the rest of it has to do with the simplecar plugin?

Yes, it's solely caused by the SimpleCar plugin The long message you're seeing is a so called "stack trace", which is basically a list of methods which were called when the error occurred. The game called the "update" method of the internal plugin manager, which then invoked a method in the SimpleCar plugin - and inside this method, the plugin tried to reference something that does not exist, resulting in this "NullPointerException"^^