[Tutorial] Papyrus Beispielskripte

Dieses Thema im Forum "[Skyrim] Creation Kit" wurde erstellt von Ehemaliger Benutzer, 13. Januar 2013.

  1. Xgf

    Xgf Bürger

    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 :eek::shock::huh:
     
  2. Quad2Core

    Quad2Core Abenteurer

    @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."
     
    Zuletzt bearbeitet: 14. Januar 2013
  3. Kahmul

    Kahmul Angehöriger

    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.
     
  4. azraelb

    azraelb Abenteurer

    *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.
     
    Zuletzt bearbeitet: 14. Januar 2013
  5. Die Optimierung meiner Skripte durch den Einsatz der Actor Property hat einen sehr deutlich spürbaren Temposchub bewirkt. Ich nehme dies als Hinweis in den Startpost auf.
     
  6. Xgf

    Xgf Bürger

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

    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!
     
    Zuletzt bearbeitet: 15. Januar 2013
    doritis und Ysolda gefällt das.
  7. Dass oft die Sourcen nicht beiliegen liegt daran, dass es viele Pluginfrickler da draussen gibt, die sich einfach an der Arbeit Anderer ohne zu Fragen bedienen. Die wissen meist nicht mal was das Skript da überhaupt aufführt. Ich habe keine Lust für diese Support zu leisten, nur weil sie mein Skript 1:1 bei sich einbauen und es dann im Zusammenhang mit meiner Mod und deren Bytemist im Spiel der User Amok läuft.
    Ich bin immer darum bemüht, dass meine Skripte nur exakt dass tun was sie sollen und bei unerwarteten (Rückgabe) Werten sich sofort selbst stoppen.
     
  8. Tamira

    Tamira Reisender

    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/
     
  9. Xgf

    Xgf Bürger

    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.
     
    old_men gefällt das.
  10. Werbung (Nur für Gäste)
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden