Ergebnis 1 bis 20 von 23

Thema: Sks

Baum-Darstellung

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

    "Vibration of Nature" - It's a long story
    stars_mod
    Zitat Zitat von übelster Held
    jetzt zu deinen cods schwächen:
    - bei einen fall der geschwindigkeitsänderzung kann man deinen code in die
    tonne treten: XD
    nehmen wir mal an monster 3 ist als erster dran... am ende wird die
    tempgeschw. auf null gesetzt
    danach hero 2 der ein monster angreift...
    nach ihn kommt hero 3 dran, der
    einen geschwindigkeits zauber einsetzt der die geschw aller helden um
    20 erhöht...
    und hier ist der hacken... man könnte jetzt die ganzen betroffenen agilitätswerte um 20 erhöhen, müsste dann aber auch die
    temporären agilitätswerte angleichen... aber da ja schon bei einen
    helden die temp agi werte auf null sind, müsst man seine tempwerte auslassen... denn sonst kommt der held am ende des kampfes noch einmal
    dran, da der code ja erst aufhört wenn der höchste wert null ist...
    mann könnte sichs aber auch viel einfacher machen und das einbauen
    auf was du bei deinen code verzichtest hast: switches wer schon drann war
    und wer noch nicht...
    Wo ist da genau das Problem? Ich sehe es nicht.
    Man muss nur eine zusätzliche Fork bei dem Skript hinsetzen, dass die Geschwindigkeit eines Kampfteilnehmers ändert. Das Skript ist einfach nur:
    1. Aktualisiere Geschwindigkeit von Kampfteilnehmer
    2. Wenn Temporäre Geschwindigkeit von Kampfteilnehmer NICHT 0 ist: Aktualisiere AUCH die Temporäre Geschwindigkeit.

    Natürlich macht es speziell dieses Skript etwas aufwändiger für den Rechner, aber stellen wir mal deine Methode hinsichtlich des Rechnen-Aufwandes gegebenüber:
    Wenn man Switches verwendet, werden diese Switches IMMER in der Berechnung der Aktions-Reihenfolge abgefragt. Das heisst grob gesehen (zumindest im Schlimmsten) DOPPELTEN Umfang an Fork-Konditions.
    Nun bedenke das dieses Skript JEDE RUNDE kommt, undzwar für jeden Kampfteilnehmer EINMAL.

    Bei meiner Methode ist das Skript, dass die Geschwindigkeit eines Kampfteilnehmer während der laufenen Runde ändert, etwas rechenaufwändiger (um eine Fork, bzw. 4 Forks, wenn es 4 Kampfteilnehmer sind), aber wie oft kommt dieses Skript schon?
    Bestimmt nicht jede Runde mehrmals, weshalb es seltener kommt als das Reihenfolge-Berechnen-Skript. :P

    Edit: Ansonsten ist, soweit ich das sehe, eher dein Skript umständlich wenn es darum geht, das während des Kampfes eine Geschwindigkeit verändert wird.
    Bei dir muss man nämlich in so einer Situation alles vorberechnete komplett hinschmeissen. Alles was man zu den Kampfteilnehmern berechnet hat, die noch nicht dran waren, wird verschmissen und neu errechnet.

    Bei mir wiederum muss die Rechnen zur Reihenfolgenbestimmung immer nur einmal vor jeder ausgeführten Aktion durchzogen werden. Wenn die Geschwindigkeit verändert wird, wird nicht mehr gerechnet, als sonst.
    Alles was man tun muss, ist zu beachten, dass, wenn die temporäre Geschwindikeit eines Kampfteilnehmers 0 ist, sie auch wirklich 0 bleibt und alles müsste richtig laufen.

    Aber ansonsten muss ich mich bei dir entschuldigen:

    Dein Skript ist wirklich in etwa wie das, was ich hier beschrieben habe.
    Toll finde ich sogar, dass du Variable-Pointer-Verwendet hast (V[V[x]]=y), auf sowas bin ich gar nicht eingegangen.

    Und hättest du den Beitrag nicht gelöscht hätte ich mich schon in meinem vorherigen Post entschuldigt o_ô

    Dennoch bringen die Switches als Abfrage nur Nachteile. So kann man mein Skript sehr stark komprimieren, indem man eine Schleife mit einem Variablen-Pointer macht, die so oft durchlaufen wird, wie es Kampfteilnehmer gibt. Angenommen die Temporären Speedwerte würden auf den Variable 51-60 liegen, dann könnte man es einfach so regeln:

    VPointer=50
    Top-Wert=0
    Top-Nummer=0
    Label 1
    VPointer=VPointer+1
    Speed=V[VPointer]
    If Speed > Top-Wert
    Top-Wert=Speed
    Top-Nummer=VPointer
    Top-Nummer=Top-Nummer-50
    End Case
    If VPointer < 60
    Goto Label 1
    End Case

    Sowas geht leider in keinem Fall mit Switches, weil man Switches zwar per VPointer verändern, sie aber leider nicht auf diese Art abfragen kann, weil man Switchwerte generell nicht auf so einfache Art übertragen kann.

    Wie auch immer, mein Kommentar in meinem ersten Beitrag war etwas unüberlegt, tut mird Leid deswegen.

    Wir sollten am besten das Kriegsbeil bekraben oO

    C ya

    Lachsen

    Edit: Ups, ja, hab mich verschrieben, richtig XD
    BEi dern Fork muss Top-Wert stehen, nicht Top-Nummer

    Geändert von Lachsen (05.06.2005 um 01:24 Uhr)

Berechtigungen

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