[Tutorial] Papyrus Beispielskripte

wenn es da keine Aussage von einem Entwickler dazu gibt, ist es eh nur geschwätz sorry.
mal die 10'000 scripts anschauen die dabei liegen ist auch keine schlechte Idee

na toll, da gibt es ein paar forums einträge, quali der Leute unbekannt, absolut keine fakten, ihr tragt es ins Wiki ein und so wird es zur in Stein gemeisselter Wahrheit ... erschreckend :shock::huh:

@Xgf
einerseits hast du ja recht, aber es wurden ja schon verschiedene tests gemacht und dies ist schön länger im gespräch^^.
Und außerdem machen die Entwickler auch nicht immer alles richtig, meiner erfahrung nach ist es eigentlich eher das gegenteil, da sie nicht soviel zeit haben wie ein modder und daher ihre scripts nicht zu 100% optimieren und es geht eher um zeitgewinn. Ich mein Dawnguard.esm hat 602 ITM, 82 UDR records^^ auch nicht gerade das was ich optimiert nenne^^. Und die GetActorReference() funktion besteht einfach nur aus: GetReference() as Actor (welche auch wesentlich schneller ist.)
Ich denke das wurde auch einfach nur aus zeitgewinn eingebaut.


Edit: Ich will jetzt nicht die entwickler schlecht wirken lassen, ich denke einfach das das normal ist für spieleentwickler, denn sie wollen ja auch irgendwann fertig werden und nicht wie Duke Nuken Forever 14 jahre für die Entwicklung brauchen . Einer von Bethesdas mottos ist ja auch: "We can do anything, but we can't do everything."

Papyrus ist nachweislich (!) von der Technik her ziemlicher Müll. Nicht einmal ein Garbage-Collector ist vorhanden. Und wenn Du es nicht glauben willst, Xgf, ist das Deine Sache, aber wenn es durch Zeitmessungen bewiesen wurde (ein Beispiel habe ich als Quelle im CK-Wiki eingetragen), dass Game.getPlayer() so langsam ist, und man es dann trotzdem nicht glaubt, finde ich ein wenig lächerlich. Die Zeitmessungen wurden übrigens mit der getCurrentRealTime()-Function durchgeführt, die komischerweise von Bethesda programmiert wurde.
Diesen Thread durchzulesen ist dazu auch sehr empfehlenswert.

Kahmul schrieb:

Papyrus ist nachweislich (!) von der Technik her ziemlicher Müll. Nicht einmal ein Garbage-Collector ist vorhanden.

Zum Vergrößern anklicken....

*sign*

@Xgf:
Da braucht man keinen Entwickler fragen und eigentlich auch keine Zeitmessungen durchführen. Es ist immer schneller auf ein Objekt im Cache zuzugreifen, als eine Funktion aufzurufen, die das Objekt irgendwie ermittelt. Das hat gar nichts mit Game.GetPlayer() zu tun, das ist bei jeder Funktion so.

Kahmul schrieb:

Papyrus ist nachweislich (!) von der Technik her ziemlicher Müll.

Zum Vergrößern anklicken....

das habe ich nicht gelesen.. sonst übersäuere ich noch

Kahmul schrieb:

Nicht einmal ein Garbage-Collector ist vorhanden. Und wenn Du es nicht glauben willst, Xgf, ist das Deine Sache, aber wenn es durch Zeitmessungen bewiesen wurde (ein Beispiel habe ich als Quelle im CK-Wiki eingetragen), dass Game.getPlayer() so langsam ist, und man es dann trotzdem nicht glaubt, finde ich ein wenig lächerlich. Die Zeitmessungen wurden übrigens mit der getCurrentRealTime()-Function durchgeführt, die komischerweise von Bethesda programmiert wurde.
Diesen Thread durchzulesen ist dazu auch sehr empfehlenswert.

Zum Vergrößern anklicken....

Es geht nicht darum ob die Info wahr oder falsch ist. Sie ist nicht qualifiziert!

Ich arbeite seit über 20 Jahren in der IT und schreibe vor allem komplexe scripte.
In meiner Mod gibt es ca 3000 Zeilen Code. Der macht immer genau das was ich will. Die laufen einwandfrei. Darauf kommt es an. Ich habe auch keine Performance Probleme.
Was für mich ganz neu war die Tatsache, dass da eine Physikengine am Werk ist und nicht immer alles so ist wie es scheint.

Ich musste viel mit Waits arbeiten.Der Engine zeit geben, in der Welt zu machen was ich will... sowas macht man normal nicht.... performace.. waits.. klingelingeling..
Vielemale musste ich auch nach anderen Wegen suchen, weil eingeschlagener nur zu 95% zuverlässig funktionierte.
Es kommt z.B. nach mehreren Stunden Testen -- einwandfrei -- plötzlich eine Game.FindClosestReferenceOfType Anfrage leer zurück, obwol das Object da steht. Oder sie kommt abgefüllt obwohl das object weg ist... das z.B. sind für mich wichtige Themen

apropos: ich finds toll ein solches Thema. Die Moder machen viel zuviel geheimnisse um ihre scripts. Meine Source liegt bei.
Es gibt nichts zu schützen an einem Script, nur etwas zu verbergen!

Quad2Core schrieb:

@Kahmul
jo stimmt mein fehler wird berichtigt. Ich hatte schon mal davon gehört das Game.getPlayer() nicht so gut sein soll, aber das es so langsam ist oO. Danke für die information, man lernt nie aus

Edit:
wen es interessiert: Ich hab gerade einen post auf Gameskyrim.com gefunden, welcher sogar besagt, dass die version über den property bis zu 1.000 x schneller ist (ja eintausend).
Hier die source (englisch)

Zum Vergrößern anklicken....

Wisst ihr eigentlich, dass dieses Gameskyrim.com eine unverschämte 1:1 Kopie vom offiziellen Bethesda Forum ist?
Hier bitte, der Original-Post von deinem Zitat:
http://forums.bethsoft.com/topic/1421159-gamegetplayer-or-actor-playerref-auto/

http://www.creationkit.com/Persistence_(Papyrus)
Persistence is the act of making an Object Reference stick around in the game and not be unloaded. This applies to all references in the game, including things like actor references. Because they continue to stick around, they consume processor time and memory when other references in the same area will have disappeared and unloaded.

When a script property is pointed at a reference in the editor, the target reference will be flagged as "permanently persistent". In other words, nothing you do during runtime will unload the object. This means that, if possible, you should not use properties to point at references directly. If you can, pull references in from events or other locations to avoid permanently keeping them around. Even if you reassign a value to your property while the game is running, the original reference will stick around.

So there are a few things to keep in mind when trying to keep things from sticking around too long:
- Avoid long-running functions
- Avoid properties to references if possible
- Variables to references should only be pointing at a reference for as long as they need to
- Only register for updates for as long as you need them


Ich denke nicht, dass ich etwas falsch mache, wenn ich mir eine Variable abfülle mit Game.GetPlayer und dann konsequent mit dieser arbeite.