Timed Props aus bestehenden Props erstellen

[nekseb]

Hallo,
ich möchte aus einem bestehenden Prop, von denen ich sowohl die .desc und die .model Datei habe verschiedene timed props erstellen, z.B. wie die Eisenbahnprops von Kenworth & Royal.

Nun habe ich versucht, die .desc und .model mittels Reader in einer Dat zusammenzufassen und die Exemplar property in RTK4 zu ändern. Hierzu habe ich die Werte eines entsprechenden Props aus den Eisenbahnprops kopiert und den Namen geändert.

Das Prop wird mir aber im LE nicht zur Auswahl angeboten.....

Muss ich die ID des Props ändern und wenn ja - wie?

Wie kann ich mehrere "timed" Versionen eines Props (z.B. von 07 bis 10 und von 18 bis 22 Uhr) erstellen?

Dank im Voraus

 

[Andreas]

Wenn Du zeitgesteuerte Props erstellen willst, brauchst Du auf jeden Fall eine neue ID, ansonsten löst Du die Prop Pox damit aus. In welcher Datei die einzelnen files liegen, ist unerheblich, es kommt allein auf die Properties im Prop Exemplar file an. Wenn Du Props für mehrere Zeitspannen benötigst, erstelle einfach mehrere Exemplar files mit dem gleichen Modell. Neben RTK4 brauchst Du noch weitere Properties, schaue Dir dazu am besten bestehende zeitgesteuerte Props genau an. Auf SC4D gibt's glaube ich auch irgendwo ein Tutorial, aber eigentlich reicht es beim Modding meist, sich die bereits existierenden Sachen nur genau genug angucken und die Einstellungen zu replizieren.

 

[nekseb]

Hallo Andreas,
danke für die Antwort, die Info's bzgl. timed props vom SC4D habe ich schon studiert.

Und wie vergebe ich eine neue ID - wenn du ein Tutorial empfehlen kannst, gerne.

Wenn ich dich richtig verstehe, ändere / ergänze ich nur die .desc Datei und füge innerhalb dieser Datei mehrere Exeplar Files ein (für jede Zeitspanne eine)?

(Die Geister, die ich rief...)

 

[Fluggi]

Oben im Reader ist ein Button, der heißt "File Info". Da auf "Edit" klicken und Du kannst neue TGI-IDs vergeben, in Deinem Fall reicht es, die Instance ID zu ändern.

Alternativ tut es auch ein Rechtsklick auf das File und eine Auswahl von "Generate new Instance", dann schmeißt der Reader seinen Zufallsgenerator an und vergibt eine zufällige neue ID.

 

[logan123]

Zufallsgenerator

Erstellt dieser nach "gut Dünk" eine neue ID?
Kann diese dann zufällig schon bestehen?
Ist dort die Ursache einer Prop Box zu finden?

 

[nekseb]

Erstellt dieser nach "gut Dünk" eine neue ID?
Kann diese dann zufällig schon bestehen?
Ist dort die Ursache einer Prop Box zu finden?

Soweit ich das mitbekommen habe, heißt das "Prop Pox" und die "zufällige" ID ist nicht die Ursache des PP - irgendwie weiß dieses Teil, welche ID noch frei ist (wahrscheinlich über sein GlobalWLAN ).

Schau dir mal den Thread auf SC4D an, dort ist man der Ursache schon etwas nähergekommen.

PS: Danke Fluggi - machmal sollte man rechtsklicken...

 

[Fluggi]

Naja, die zwei PIMs erstellen auch nach Gutdünken IDs, genau wie das BAT. Irgendwo hier im Forum war doch einer, der Parisgebäude anstelle von Bäumen auf seinen Grundstücken hatte.
Soweit ich weiß ist aber die Group ID auch zufällig bei Lots etc., also is da die Wahrscheinlichkeit recht gering.

Anders ist das bei Texturen und Propfamilien, wo man sich beim BSC erstmal einen ID-Bereich registrieren muss, damit es keine ID-Konflikte gibt. Der Parkweg soll schon der Parkweg bleiben.

Bei der Masse an Zeugs, die so herumschwirrt, allein schon auf dem STEX, frage ich mich eigentlich schon länger, warum da keine Konflikte auftreten.
Aber die können ja auch nur auftreten, wenn man zwei Plugins mit der selben TGI hat ... und die Wahrscheinlichkeit ist ja schon recht gering ...

 

[krechlok]

Erstellt dieser nach "gut Dünk" eine neue ID?
Kann diese dann zufällig schon bestehen?

Ist dort die Ursache einer Prop Box zu finden?

Schau an, schau an, DAS könnte doch möglich sein...

 

[logan123]

heißt das "Prop Pox"

Uuups....sorry,verlesen

Und danke Euch,wieder was gelernt.

 

[Fluggi]

Schau an, schau an, DAS könnte doch möglich sein...

Hm, naja. Es gibt ja zuhauf irgendwelche Ersetzungsmod, die herumschwirren, sei es, um die Laterne von der Fußgängerzone zu entfernen oder um die Maxislots am Wachsen zu hindern.

Wenn dem so wäre, dann würden der Maxisblocker und viele andere Ersetzungsmods, die darauf basieren, dass ein modifiziertes Plugin mit exakt der selben TGI nach dem ursprünglichen Plugin geladen wird und dieses somit überschreibt, unweigerlich die Pox auslösen.

Problematisch wird's, wie Andreas schon schrieb, wenn jemand per Ersetzung aus einem normalen Prop ein zeitgesteuertes Prop machen möchte. Das ist der Auslöser der Prop Pox.
Da a) das mittlerweile bekannt ist und ein großer Teil der Modder das weiß und b) das recht sinnlos ist, da man ja einfach ein neues Prop basteln kann und nichts ersetzen muss (mir fällt spontan keine Situation ein, die es sinnvoll macht, aus einem statischen Prop ein zeitgesteuertes zu machen), tritt das nicht so häufig auf.

 

[logan123]

(mir fällt spontan keine Situation ein, die es sinnvoll macht, aus einem statischen Prop ein zeitgesteuertes zu machen)

Tore(habe ich z.B. auf meiner Müllverbrennungsanlage drauf),
geschlossene/geöffnete Rollo's/Fensterläden,...z.B.

 

[Andreas]

Was die IDs angeht: Diese werden - zumindest bei korrekter Implementierung - nach dem Datum vergeben, so daß zumindest theoretisch keine ID-Konflikte auftreten können, es sei denn, es würden zwei IDs exakt zum gleichen Zeitpunkt erstellt. Das gilt für die Instance ID, weiterhin hat auch jeder, der das BAT benutzt, eine einmalige Group ID, die für die gerenderten Modelle verwendet wird.

Meistens ist es kein Problem, wenn man "zufällig" nach eigenem Gutdünken" eine ID vergibt, aber gerade, wenn man hier irgendwelche bevorzugten Buchstaben- und Zahlenkombinationen verwendet, kann es eben doch leichter zu Überschneidungen kommen. Daher gibt es zumindest für Texturen und Propfamilien einen Index, weil die in der Regel am häufigsten gebraucht und eben nicht automatisch generiert werden.

Die Prop Pox wird - nach aktuellem Kenntnisstand - hauptsächlich deshalb ausgelöst, wenn einem bestehenden Prop Exemplar file neue Properties für ein zeitlich gesteuertes Verhalten hinzugefügt werden, ohne die ID zu ändern. Beim Bau einer Stadt werden alle Prop Exemplar files mit in der Stadt-Datei gespeichert, da das Spiel ja ansonsten nicht wissen kann, welches Prop einer Propfamilie beim Bau des Lots ausgewählt wurde. Und wenn man eine Abhängigkeit nicht installiert hat, fehlt dieses Prop auf bestehenden Lots auch, nachdem man die fehlende Datei nachinstalliert hat.

Hat nun das Prop Exemplar file nach Hinzufügen der Properties eine andere Dateigröße, beißt sich das mit den in der Stadt gespeicherten Werten, und der Bug wird ausgelöst. Das kennt man ja auch von nachträglich veränderten monatlichen Kosten und dergleichen, die plötzlich die Budgetregler verrückt spielen lassen, weil die Werte in der Datei nicht mehr mit denen des Savegames übereinstimmen.

 

[nekseb]

Danke Andreas - wieder was gelernt!

Obwohl mich die Bezeichnungen (ID, Exemplar File, TGI, etc.) immer noch ganz Karusell im Kopp machen

Aber ich mache das so, wie Mensch lernt: etwas Try & Error, ein bißchen nachlesen und manchmal Fragen...

Und RESPEKT vor allen Moddern, Lotern, Batern hier und bei SC4D (und überall auf der Welt), die ein eigentlich "veraltetes" Spiel in Ihrer Freizeit auf"pim"pen und immer neue, wunderbare Sachen veröffentlichen!

DANKE!

 

[nekseb]

Nochmal eine Nachfrage:

Nachdem ich entsprechend den Tipps hier 3 neue Desc-Files erstellt habe und die RTK4 Werte angepasst habe, funzt das Ganze.

Kopfzerbrechen bereitet mir aber noch die Prop-Pox-Geschichte....

Jeder der 3 Desc-File hat eine eigene Kennung, bestehend aus dem Name und den TGI-Werten. Die ersten beiden Werte sind gleich, der letzte variiert.

Beispiel:
Prop1-0x653428a-0xb13c093e-0x741547d7.desc
Prop2-0x653428a-0xb13c093e-0x891738d4.desc
Prop3-0x653428a-0xb13c093e-0x906787d9.desc

Damit hat doch jedes "Prop" eine eigene ID - oder?

 

[Andreas]

Ja, ausschlaggebend ist die Instance ID (der dritte Wert).

 

[nekseb]

Danke