Ergebnis 1 bis 12 von 12

Thema: Renn-Script Optimierung?

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1

    Renn-Script Optimierung?

    Hallo allerseits!
    Da ich seit Ewigkeiten nicht mehr wirklich gemakert habe und mich eben aber doch die Lust überfiel, mal wieder rumzuspielen, habe ich mich mal an einem Rennscript versucht.
    (Mindest-)Anforderungen dabei waren:

    • Der Charakter soll beim Rennen ein anderes Charset verwenden
    • Der Charakter soll wenn er steht wieder zum normale Charset wechseln
    • Nicht passierbare Tiles und Events lassen ihn ebenfalls zurückwechseln
    • Es soll "sumpfige" Tiles geben, in denen ein Char zwar gehen, aber nicht rennen kann
    • Das Ganze soll mit der SHIFT-Taste funktionieren, da ich für ENTER noch andere Ideen habe


    Das habe ich soweit auch alles umgesetzt bekommen, wüsste jetzt aber - rein aus Neugier/perfektionismus - ob es eventuell effizientere Wege gibt als meinen:

    Zitat Zitat von EasyEventExporter
    - SCRIPT -
    <> Change Variable: [22-27] = 0
    <> Change Variable: [28] = 1
    <> Comment: __________________________________________________
    <> Comment:
    <> Comment: SHIFT gedrückt?
    <> Comment: __________________________________________________
    <> Comment:
    <> Key Input Processing: Var. [22], Keys: Shift
    <> Fork Condition: If Variable [22] == 7 then ...
    . <> Comment: __________________________________________________
    . <> Comment:
    . <> Comment: Richtungstaste gedrückt?
    . <> Comment: __________________________________________________
    . <> Comment:
    . <> Key Input Processing: Var. [23], Keys: Down, Left, Right, Up
    . <> Fork Condition: If Variable [23] > 0 then ...
    . . <> Fork Condition: If Variable [23] <= 4 then ...
    . . . <> Comment: __________________________________________________
    . . . <> Comment:
    . . . <> Comment: Nächstes Tile?
    . . . <> Comment: __________________________________________________
    . . . <> Comment:
    . . . <> Change Variable: [24] = X position on map (tiles) of hero
    . . . <> Change Variable: [25] = Y position on map (tiles) of hero
    . . . <> Fork Condition: If Variable [23] == 1 then ...
    . . . . <> Change Variable: [25] += 1
    . . . . <>
    . . . : Else ...
    . . . . <> Fork Condition: If Variable [23] == 2 then ...
    . . . . . <> Change Variable: [24] -= 1
    . . . . . <>
    . . . . : Else ...
    . . . . . <> Fork Condition: If Variable [23] == 3 then ...
    . . . . . . <> Change Variable: [24] += 1
    . . . . . . <>
    . . . . . : Else ...
    . . . . . . <> Fork Condition: If Variable [23] == 4 then ...
    . . . . . . . <> Change Variable: [25] -= 1
    . . . . . . . <>
    . . . . . . : End of fork
    . . . . . . <>
    . . . . . : End of fork
    . . . . . <>
    . . . . : End of fork
    . . . . <>
    . . . : End of fork
    . . . <> Comment: __________________________________________________
    . . . <> Comment:
    . . . <> Comment: Blockierendes Event?
    . . . <> Comment: __________________________________________________
    . . . <> Comment:
    . . . <> Get Event ID: (V[24], V[25]), Store in var. [27]
    . . . <> Fork Condition: If Variable [27] > 0 then ...
    . . . . <> Call Event: Map Event V[27], Page V[28]
    . . . . <> Fork Condition: If Variable [27] == 9999 then ...
    . . . . . <> Comment: Event ist nicht passierbar
    . . . . . <> Jump To Label: 1
    . . . . . <>
    . . . . : End of fork
    . . . . <>
    . . . : End of fork
    . . . <> Comment: __________________________________________________
    . . . <> Comment:
    . . . <> Comment: Terrain?
    . . . <> Comment: __________________________________________________
    . . . <> Comment:
    . . . <> Get Terrain ID: (V[24], V[25]), Store in var. [26]
    . . . <> Fork Condition: If Variable [26] == 1 then ...
    . . . . <> Comment: Passierbar
    . . . . <> Change Hero Graphic: Hero #1 -> Rem_new #1
    . . . . <> Move Event: Hero, Frq 8, Pattern: Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Inc spd, Inc spd, Inc spd
    . . . . <>
    . . . : Else ...
    . . . . <> Comment: Geblockt
    . . . . <> Jump To Label: 1
    . . . . <>
    . . . : End of fork
    . . . <>
    . . : Else ...
    . . . <> Jump To Label: 1
    . . . <>
    . . : End of fork
    . . <>
    . : Else ...
    . . <> Jump To Label: 1
    . . <>
    . : End of fork
    . <>
    : Else ...
    . <> Jump To Label: 1
    . <>
    : End of fork
    <> Jump To Label: 2
    <> Label: 1
    <> Change Hero Graphic: Hero #1 -> Rem_new #0
    <> Move Event: Hero, Frq 8, Pattern: Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Inc spd, Inc spd
    <> Label: 2

    Zunächst wird abgefragt, ob SHIFT gedrückt ist (ohne wait until key is pressed), dann, ob eine Pfeiltaste gedrückt ist (ebenfalls ohne wait until key is pressed). Dann wird geschaut,wo sich der Charakter denn hinbewegt und ob sich dort ein Event befindet. Wenn ja, wird das Event auf Seite 1 gecallt, wenn die ID 9999 zurückkommt, ist es nicht passierbar, d.h. der Charakter wird dagegenstoßen und das Charset muss gewechselt werden. Andernfalls wird das Zeilterrain abgefragt. 1 heißt passierbar (oder genauer gesagt: "Es kann gerannt werden") und das Charset wird gewechselt und die Geschwindigkeit hochgedreht, bei allem anderen sowie im Fall, dass irgendwo vorher eine Abfrage negativ ausfällt, wird der Teil am Ende des Scripts aufgerufen, der Ursprungscharset wiederherstellt und die Geschwindigkeit aufs normale setzt.

    Klappt soweit alles wunderbar. Ist ein Tile zwar vom Chipset aus passierbar, vom Script her aber nicht, tritt der Sumpf-Effekt ein und der Char ist gezwungen in normalem Tempo über das Tile zu gehen. Die Sache mit den Events stört mich allerdings etwas, da das voraussetzt, dass alle Events eine entweder leere Seite 1 haben (passierbar) oder die Variable Event ID auf 9999 setzen. Ist jetzt nicht der größte Aufwand, aber lästig auf Dauer. Mir fällt aber auch keine elegantere Lösung, ohne riesige Umwege über extra Map-Events zu machen, die Listen beinhalten, was passierbar ist und was nicht und dann abgeglichen werden müssen.
    Theoretisch sollte sich das Ding auch mit recht wenig Aufwand für Fälle erweitern lassen wie ein anderes Charset bei alter Geschwindigkeit oder umgekehrt, da könnte es jedoch aufgrund eines mini-Bugs Probleme geben: Im Falle von sumpfigen Gelände wechselt der Char verfrüht die Charsets. Scheinbar nimmt der Maker bereits an, dass der Char auf dem nächsten Feld ist, auch wenn der Sprite noch hinterherhinkt. Würde etwa bei einem extra Charset fürs durch-Match-waten dazu führen, dass der Char noch ein paar Pixel lang im Boden hängt. Hat jemand dazu eine Idee? ._.

  2. #2
    Hab mal dein Skript ein klein wenig auseinander genommen und verstehe nun im Ansatz was du mit den einzelnen Befehlen vor hast..
    Es sieht für mich aber etwas kompliziert aus, kann auch daran liegen, dass ich das Skript nicht erstellt habe, sondern du ._.

    Ich habe mich daher mal probehalber an diesem Skript versucht, nur eben auf meine Art. Das Ergebnis wird aber voraussichtlich erst morgen fertig sein, da ich noch ein paar kleine Bugs fixen muss.
    Wenn es dann fertig ist könnte ich dir den Code dann schicken, vielleicht löst der ja dein Problem.

    Aber wie gesagt, da müsstest du noch bis morgen warten.. (Falls du trotzdem schon einen kleinen Blick hineinwerfen willst, gib einfach Bescheid, dann editiere ich den Post)

  3. #3
    Ich frage für mein Footstep-Script ab, ob der Held sich bewegt hat, weils einfacher ist, ob abzufragen ob er sich bewegen könnte.

  4. #4
    Zitat Zitat
    Scheinbar nimmt der Maker bereits an, dass der Char auf dem nächsten Feld ist, auch wenn der Sprite noch hinterherhinkt.
    Das stimmt, soweit ich weiß, werden die neuen Koordinaten schon vor der Bewegung gesetzt.

  5. #5
    Pixelposition nehmen = Win.

  6. #6
    Zitat Zitat von Corti Beitrag anzeigen
    Ich frage für mein Footstep-Script ab, ob der Held sich bewegt hat, weils einfacher ist, ob abzufragen ob er sich bewegen könnte.
    Also praktisch auf Tastendruck hin abfragen, ob die Pixelposition von vor 0.0 Sekunden mit der aktuellen noch übereinstimmt?

    Das teste ich direkt mal, das würde im Idealfall die ganze Terrain-Sache weitestegehend umgehen und die Event-Notlösung völlig aushebeln.


    @aleksy:
    Kein Thema, kein Stress. Würde mich freuen zu sehen, wie du das Ganze umsetzt!


    EDIT:
    Ich hab das mit der Bewegungsabfrage mal probehalber ausprobiert, allerdings noch ohne so Zusatzzeugs wie sumpfiges Gelände:

    Zitat Zitat von EasyEventExporter
    - SCRIPT -
    <> Change Variable: [22] = 0
    <> Change Variable: [24] = X position on screen (pixels) of hero
    <> Change Variable: [25] = Y position on screen (pixels) of hero
    <> Comment: __________________________________________________
    <> Comment:
    <> Comment: SHIFT gedrückt?
    <> Comment: __________________________________________________
    <> Comment:
    <> Key Input Processing: Var. [22], Keys: Shift
    <> Fork Condition: If Variable [22] == 7 then ...
    . <> Comment: __________________________________________________
    . <> Comment:
    . <> Comment: Bewegt sich der Char?
    . <> Comment: __________________________________________________
    . <> Comment:
    . <> Wait: 0,0 sec.
    . <> Change Variable: [24] -= X position on screen (pixels) of hero
    . <> Change Variable: [25] -= Y position on screen (pixels) of hero
    . <> Fork Condition: If Variable [24] != 0 then ...
    . . <> Comment: Bewegt sich
    . . <> Move Event: Hero, Frq 8, Pattern: Chg graphic to Rem_new #1, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Inc spd, Inc spd, Inc spd
    . . <>
    . : Else ...
    . . <> Fork Condition: If Variable [25] != 0 then ...
    . . . <> Comment: Bewegt sich
    . . . <> Move Event: Hero, Frq 8, Pattern: Chg graphic to Rem_new #1, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Inc spd, Inc spd, Inc spd
    . . . <>
    . . : Else ...
    . . . <> Comment: Bewegt sich nicht
    . . . <> Jump To Label: 1
    . . . <>
    . . : End of fork
    . . <>
    . : End of fork
    . <>
    : Else ...
    . <> Jump To Label: 1
    . <>
    : End of fork
    <> Jump To Label: 2
    <> Label: 1
    <> Move Event: Hero, Frq 8, Pattern: Chg graphic to Rem_new #0, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Inc spd, Inc spd
    <> Label: 2
    An und für sich funktioniert es gut und ist schon viel simpler. Wie ich schon befürchtet habe sorgt der 0.0 Wait aber dafür, dass der Held jetzt aus dem Stand heraus etwas zögerlich losrennt. Ohne den Wait liegen die verglichenen Pixelpositionen allerdings zu nah beieinander, sodass keine Bewegung erkannt wird. :/ Oder habe ich einfach einen Denkfehler?

    Geändert von BDraw (09.10.2014 um 11:42 Uhr)

  7. #7
    Zitat Zitat von BDraw Beitrag anzeigen
    Scheinbar nimmt der Maker bereits an, dass der Char auf dem nächsten Feld ist, auch wenn der Sprite noch hinterherhinkt.
    Genau so passiert das auch. Das neue Feld für das Event wird gesetzt und die Grafik bekommt einen Offsetwert zugewiesen,
    wie weit weg sie sich gegen die Laufrichtung vom Eventblock befindet, der wird dann Frame für Frame so lange automatisch
    runtergeregelt und immer näher zum Zielpunkt nachgezogen, bis wieder 0 erreicht ist, danach kann es sich wieder bewegen.

    Wenn man per Erweiterungen Zugriff darauf bekommt, lassen sich damit einige nette Dinge anstellen, wie das Rein- oder
    Rauslaufen am Rand einer Map, die auf anderem Weg sehr mühsam wären.


    Eine Rennmechanik für das Spieler-"Event" mit verändertem CharSet wäre am Einfachsten, wenn du lesen kannst, ob sich
    entweder die Pixelpos der Eventgrafik ändert oder der Bildschirm auf der Map verschiebt (und letzteres dürfte ein bisschen
    schwieriger werden), denn während das passiert, weisst du ganz genau, dass Bewegung im Gange ist, natürlich müsstest
    du das immer dann deaktivieren, wenn gescriptet über die Map gefahren werden soll.

  8. #8
    Zitat Zitat von MagicMaker Beitrag anzeigen
    Genau so passiert das auch. Das neue Feld für das Event wird gesetzt und die Grafik bekommt einen Offsetwert zugewiesen,
    wie weit weg sie sich gegen die Laufrichtung vom Eventblock befindet, der wird dann Frame für Frame so lange automatisch
    runtergeregelt und immer näher zum Zielpunkt nachgezogen, bis wieder 0 erreicht ist, danach kann es sich wieder bewegen.

    Wenn man per Erweiterungen Zugriff darauf bekommt, lassen sich damit einige nette Dinge anstellen, wie das Rein- oder
    Rauslaufen am Rand einer Map, die auf anderem Weg sehr mühsam wären.


    Eine Rennmechanik für das Spieler-"Event" mit verändertem CharSet wäre am Einfachsten, wenn du lesen kannst, ob sich
    entweder die Pixelpos der Eventgrafik ändert oder der Bildschirm auf der Map verschiebt (und letzteres dürfte ein bisschen
    schwieriger werden), denn während das passiert, weisst du ganz genau, dass Bewegung im Gange ist, natürlich müsstest
    du das immer dann deaktivieren, wenn gescriptet über die Map gefahren werden soll.
    Mh, die Scrollposition wäre wohl einerseits recht umständlich hierfür zu verwenden, zum anderen bei 20x15 Maps nicht sehr effektiv. Wie eben beschrieben habe ich eben die Sache mit der Pixelposition ausprobiert, bekomme das zeitlich aber noch nicht fein genug hin. 0.0 ist eben leider immer noch gerade lang genug, dass man die Verzögerung merkt, wenn man aus dem Stand losrennen will.

    EDIT:
    Mir fällt gerade auf, dass der ganze Ansatz mit der Bewegung eigentlich einen Denkfehler haben müsste: Ich will ja, dass der Charakter (wenn Bewegung möglich ist) sofort losrennt. Wenn ich aber abfrage, ob er sich bewegt hat, geht er ja bereits und rennt nicht, was für den Spieler auch schon sichtbar ist. Die Verzögerung habe ich also so oder so in dem Ansatz, egal, wie fein ich die Abfrage hinbekomme. Ich müsste also wissen, ob Bewegung im gange ist, noch bevor der Maker das Charset bewegt, was aber mit Pixelabfragen wiederum (meines Wissens nach) nicht machbar ist.
    Wenn ich nicht irgendetwas übersehen habe ist die Lösung damit leider vorerst für meine Zwecke raus. Schade, dabei war die deutlich übersichtlicher und kürzer.

    Geändert von BDraw (09.10.2014 um 11:55 Uhr)

  9. #9
    Was hier alles so diskutiert wird erscheint mir irgendwie ganz merkwürdig, vielleicht überfliege ich die Posts einfach zu stark um sie komplett zu verstehen ^^'
    Aus dem Skript ist gestern leider doch nichts mehr geworden, bin irgendwann aus Müdigkeit einfach eingeschlafen (um 2 Uhr Nachts einschlafen um morgens um 6 aufzustehen ist wohl keine gute Idee..).

    Ich denke aber du kannst dann von heute bis spätestens Ende der Woche mit einem Ergebnis rechnen, genug Ideen für Bugfixing liefert die Community scheinbar ja xD

    EDIT:
    Das Skript sträubt sich leider massiv dagegen, korrekt zu funktionieren.. ständig gibt es irgendwelche Probleme mit Kollisionsabfragen, Tastenabfragen, Schaltern, Reihenfolgen etc.. Wenn ich ein Problem behebe taucht daraus wiederum ein neues auf.
    Es kann also ein kleines Weilchen dauern, bis irgendwas halbwegs funktionsfähiges entsteht. Ich hoffe du wirst aber bis dahin nicht zu lange auf eine funktionierende (andere) Lösung warten müssen.

    Geändert von aleksy (11.10.2014 um 20:48 Uhr)

  10. #10
    Du kannst sonst auch gerne einfach mal posten, was du hast. Vielleicht bringt mich dein Ansatz ja schon weiter.

    Ich habe meinerseits gestern noch etwas gewerkelt. Kann es sein, dass Pixelkoordinaten leicht buggy werden, wenn sie nicht an ein (fixes) Map-Event gekoppelt sind? Ich hatte die Koordinaten des Helden genommen, kurz gewartet, und die aktuellen Koordinaten subtrahiert. Ist die Map aber größer als 20x15 bleibt der Held in der Mitte des Bildschirms und hat laut Maker selbst beim Bewegen die selben Pixelkoordinaten wie 5 Schritte zuvor.
    Ich hab das Rennevent dann als Mapevent platziert und stattdessen die Koordianten des (stationären) Events mit denen des Helden abgeglichen. Das funktioniert, auch wenn es im Script nicht schön aussieht (hilft mir bloß immer noch nicht bei der Verzögerung beim Losrennen).

    Parallel hatte ich mich erinnert, dass Lachsens Rennscript aus Velsarbor genau das tut, was ich umzusetzen versuche... Aber ganz ehrlich, ich steige noch nicht wirklich durch das Script durch, bei der Menge an Labels und Variablen, deren Funktion sich mir nicht ganz erschließt xD

  11. #11
    Kleines Update, mein Script läuft.

    Zuerst hatte ich versucht, das Velsarbor-Script nachzuscripten. Das klappt zwar wunderbar und ich habe eine grobe Idee, wie es funktioniert, ist mir aber einfach zu unübersichtlich und ich bin kein Freund davon, fremde Scripte zu übernehmen - vor allem, wenn ich stellenweise raten muss, wie was jetzt funktioniert. Aber ich habe dabei festgestellt, dass es dieses "nachhängen" in dort zwar auch existiert, aber dadurch kaschiert wird, dass der Held bereits vor dem Wechsel des Charsets schneller wird. Damit geht es jetzt tatsächlich auf.
    Lachsen fragt das zwar völlig anders ab als ich und hat es geschafft, die Abfrage mit Mapkoordinaten anstatt Pixeln flüssig zu bekommen, aber was soll's. Für's erste bin ich auch mit einer Lösung als Map-Event glücklich.

    Zitat Zitat von EasyEventExporter
    - SCRIPT -
    <> Change Variable: [22-26] = 0
    <> Change Variable: [28-29] = 0
    <> Comment: __________________________________________________
    <> Comment:
    <> Comment: SHIFT gedrückt?
    <> Comment: __________________________________________________
    <> Comment:
    <> Key Input Processing: Var. [22], Keys: Shift
    <> Fork Condition: If Variable [22] == 7 then ...
    . <> Comment: __________________________________________________
    . <> Comment:
    . <> Comment: Richtungstaste gedrückt?
    . <> Comment: __________________________________________________
    . <> Comment:
    . <> Key Input Processing: Var. [23], Keys: Down, Left, Right, Up
    . <> Fork Condition: If Variable [23] > 0 then ...
    . . <> Fork Condition: If Variable [23] <= 4 then ...
    . . . <> Comment: Rennt der Char bereits?
    . . . <> Fork Condition: If Variable [27] == 0 then ...
    . . . . <> Move Event: Hero, Frq 8, Pattern: Chg graphic to Rem_new #0, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Inc spd, Inc spd, Inc spd
    . . . . <> Change Variable: [27] = 1
    . . . . <>
    . . . : End of fork
    . . . <> Comment: __________________________________________________
    . . . <> Comment:
    . . . <> Comment: Terrain?
    . . . <> Comment: __________________________________________________
    . . . <> Comment:
    . . . <> Change Variable: [24] = X position on map (tiles) of hero
    . . . <> Change Variable: [25] = Y position on map (tiles) of hero
    . . . <> Get Terrain ID: (V[24], V[25]), Store in var. [26]
    . . . <> Fork Condition: If Variable [26] == 3 then ...
    . . . . <> Comment: Sumpf
    . . . . <> Jump To Label: 1
    . . . . <>
    . . . : End of fork
    . . . <> Comment: __________________________________________________
    . . . <> Comment:
    . . . <> Comment: Stehst du?
    . . . <> Comment: __________________________________________________
    . . . <> Comment:
    . . . <> Change Variable: [28] = X position on screen (pixels) of this event
    . . . <> Change Variable: [29] = Y position on screen (pixels) of this event
    . . . <> Change Variable: [28] += X position on screen (pixels) of hero
    . . . <> Change Variable: [29] += Y position on screen (pixels) of hero
    . . . <> Change Variable: [24] = V[28]
    . . . <> Change Variable: [25] = V[29]
    . . . <> Wait: 0,0 sec.
    . . . <> Change Variable: [28] = X position on screen (pixels) of this event
    . . . <> Change Variable: [29] = Y position on screen (pixels) of this event
    . . . <> Change Variable: [28] += X position on screen (pixels) of hero
    . . . <> Change Variable: [29] += Y position on screen (pixels) of hero
    . . . <> Change Variable: [24] -= V[28]
    . . . <> Change Variable: [25] -= V[29]
    . . . <> Fork Condition: If Variable [24] == 0 then ...
    . . . . <> Fork Condition: If Variable [25] == 0 then ...
    . . . . . <> Comment: JA!
    . . . . . <> Jump To Label: 1
    . . . . . <>
    . . . . : End of fork
    . . . . <>
    . . . : End of fork
    . . . <> Comment: __________________________________________________
    . . . <> Comment:
    . . . <> Comment: Rennen!
    . . . <> Comment: __________________________________________________
    . . . <> Comment:
    . . . <> Move Event: Hero, Frq 8, Pattern: Chg graphic to Rem_new #2, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Inc spd, Inc spd, Inc spd
    . . . <> Change Variable: [27] = 2
    . . . <>
    . . : Else ...
    . . . <> Jump To Label: 1
    . . . <>
    . . : End of fork
    . . <>
    . : Else ...
    . . <> Jump To Label: 1
    . . <>
    . : End of fork
    . <>
    : Else ...
    . <> Jump To Label: 1
    . <>
    : End of fork
    <> Jump To Label: 2
    <> Label: 1
    <> Comment: __________________________________________________
    <> Comment:
    <> Comment: Gehen
    <> Comment: __________________________________________________
    <> Comment:
    <> Move Event: Hero, Frq 8, Pattern: Chg graphic to Rem_new #0, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Dec spd, Inc spd, Inc spd
    <> Change Variable: [27] = 0
    <> Label: 2
    Damit brauche ich mir auch endlich keinen Kopf mehr um die Passierbarkeit von Events zu machen UND habe muss die Passierbarkeit nicht per Terrain ID einstellen. @_@

    @aleksy:
    Über deinen Ansatz würde ich mich natürlich immer noch freuen!

    Geändert von BDraw (12.10.2014 um 16:18 Uhr)

  12. #12
    Na, bis mein Skript auch läuft wird es wahrscheinlich noch 'ne Weile dauern. Ich bekomme es einfach nicht dazu richtig zu funktionieren..
    Aber da du ja schon eine funktionierende Lösung hast, kann ich mir vielleicht noch ein wenig Inspiration davon holen, halbwegs verstehen kann ich es ja.
    Dann mache ich mich später nochmal an die Arbeit, habe ich Moment noch einiges zu tun

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •