Regel bei Zeitverzögerug wieder nutzbar machen.

Tag.
Ich habe eine Regel, welche man ingame nutzen kann, sie legt bei jeder Aktivierung eine Wompfbeere in das Inventar des Aufrufers der Regel. Nun möchte ich(Damit mache Spieler nicht dauernd Wompfbeerenim Inventar holen), eine Art Sperre herstellen. Sie soll nachdem man die Regel aktiviert hat, geschlossen werden, und nach 5000 Frames ca. wieder brauchbar gemacht werden. Das heisst alle 5000 Frames bekommt man die Erlaubnis eine Wompfbeere zu nehmen.
Schöner wäre es, wenn man dies per Kontexmenü hinbekommen könnte, was nicht sonderlich schwer ist, dies allein kann ich auch selbst machen...

Bitte postet nichts wie: "Versuch mal Funktion xy", denn dies bringt mich leider nicht weiter. Ich brauche am besten ein Beispiel.

Der script der Regel ist folgender:

Zitat :

#strict 2

protected func Activate(iByPlayer)
{
Log("%s hat sich eine {{WMPF}} gegönnt.", GetPlayerName(Par()));
CreateContents(WMPF, GetCursor(iByPlayer));
return true;
}

ich würd ein array mit der länge der spieleranzahl items nehmen und überall nullen reintun. wenn sich jemand eine wompfbeere nimmt, wird "seine" null auf eins gesetzt. dann halt noch bei jedem aufruf überprüfen ob dem aufrufer seine "null" nicht auf eins steht. mit schedule noch die eins nach 5000 frames wieder auf null machen.

Klingt gut, jedoch kennst du ein Scriptteil, wo soetwas ähnlich passiert?

Ich glaub d könntest das auch mit ner Bitmaske machen.
Heute Nachmittag mach ich n tut.

Wenn ich weiss, wie man angehen muss, ist das alles kein Problem.
Mit den Funktionen selbst kann ich ohne Probleme umgehen.

Höfi:
Mal sehen, wie es wird.

Dragonclonk schrieb:

Klingt gut, jedoch kennst du ein Scriptteil, wo soetwas ähnlich passiert?

nich direkt, aber hier mal meine version:

Code:

local Players;

func Initialize() { Players = CreateArray(GetPlayerCount()); }

func Activate(int iByPlayer) {
  if(Players[iByPlayer] == 1) return(Sound("Error*");
  CreateObject(WMPF, GetCursor(iByPlayer));
  Log("<c 00ff00>%s hat sich eine</c> {{WMPF}}<c 00ff00> gegönnt!", iByPlayer);
  Players[iByPlayer] == 1;
  ScheduleCall(0, "ResetWompfGetting", 5000, 0, iByPlayer);
}

func ResetWompfGetting(int iPlr) {
  Players[iPlr] = 0;
}

Ah... Ich werde es gleich mal ausprobieren.
Und Danke für die Mühe den Script gleich zu posten.

Merkwürdigerweise funktioniert der Script nicht.
Den Fehler konnte ich nicht entdecken.

Dieser Error wurde ausgegeben:

Zitat :

by: Activate() (obj Wompfbeere ins Inventar legen. #141) (MinorMeleeKI.c4s\Food.c4d\Script.c:7)
by: console script in MinorMeleeKI.c4s\Food.c4d\Script.c (obj Wompfbeere ins Inventar legen. #141)

Kannst du vlt. den komplettenscript posten?

Der ist vier Posts über mir. -_-

Aso, hätt ja sein können, dass du noch andere Zeilen drin hast.
edit;
wie z.b. #strict2

Das ich #strict 2 integriert habe, sollte wohl logisch sein. :/

Dann ist es doch nicht der komplette Script.

Wenn man #strict bzw. #strict2 hinzunimmt, was natürlich vorausgesetzt wird, dann doch.

Kannst du vlt. einfach deinen Script posten, die Zeilenangabe im Error richtig deuten kann.

OMG!
Ich habe doch gesagt, dass der Script der, der von Simsi ist! Siehe oben!

Der von Simsi hat aber kein #strict2

Dragonclonk schrieb:

OMG!
Ich habe doch gesagt, dass der Script der, der von Simsi ist! Siehe oben!

Wenn du Hilfe in anspruch nehmen willst, dann solltes du auch den helfern ein wenig entgegenkommen.

Außerdem ist #strict2 nicht logisch in jedem Script. Ich zb benutze nur #strict weil ich noch mit CE arbeite.

Deine Fehlermeldung ist übrigens zu kurz. Direkt eine Zeile vor deinem Auschnitt sollte eigentlich mehr über dein Fehler gesagt werden.

Zitat :

Wenn du Hilfe in anspruch nehmen willst, dann solltes du auch den helfern ein wenig entgegenkommen.

Höfi bietet keine Hilfe an, das merkt man an den Posts.

Zitat :

Außerdem ist #strict2 nicht logisch in jedem Script. Ich zb benutze nur #strict weil ich noch mit CE arbeite.

(Selten so gelacht. xD) Also: Es ist irrelevat, ob du CE nutzt oder nicht. Ich nutzte, aufgrund der Anpassung-> #strict 2.
Und es ist wohl überaus logisch, dass man #strict oder #strict 2 integriert, weil ein mittelmässiger Scripter weiss, dass ohne dies der Script nutzlos ist.

Zitat :

Deine Fehlermeldung ist übrigens zu kurz. Direkt eine Zeile vor deinem Auschnitt sollte eigentlich mehr über dein Fehler gesagt werden.

Sie ist nicht zu kurz! Sie sagt alles, was man zum entkäfern braucht.

Ok, wenn du meinst.
Dann kriegst du dein Problem auch aleine in den griff.

Also nur mal rein Interessehalber. Ich arbeite mit CR und benutze trotzdem am Anfang jedes Skriptes #strict . Was genau ist den der Unterschied, abgesehen davon, dass es eben neue Syntax ist und trotzdem funktioniert.

Zitat :

Also nur mal rein Interessehalber. Ich arbeite mit CR und benutze trotzdem am Anfang jedes Skriptes #strict . Was genau ist den der Unterschied, abgesehen davon, dass es eben neue Syntax ist und trotzdem funktioniert.

#strict 2 ist der neue Standart. #scrict wir nur noch als Abwärtskompatiblität akzeptiert.

Die Fehlermeldung ist wirklich zu kurz, es müsste noch etwas in richtung Array expected oder Target Is Zero dabei stehen. Guck nochmal genau nach.

Ansonsten sehe ich beim groben drüber sehen das das hier falsch ist:

Zitat :

Players[iByPlayer] == 1;//== vergleicht, = weißt zu

Anstatt das mit Schedule zu lösen würde ich es so in der Art machen (Ist performanter und so):

Zitat :

local LastWompfbeere;

func Initialize() { LastWompfbeere= []; }

protected func Activate(iByPlayer)
{
if (FrameCounter() < LastWompfbeere[iByPlayer] + 5000) return(1);
LastWompfbeere[iByPlayer] = FrameCounter();
Log("%s hat sich eine {{WMPF}} gegönnt!", iByPlayer);
CreateContents(WMPF, GetCursor(iByPlayer));
return true;
}

Ah, vielen Dank- Ich werde es gleich ausprobieren.

Dragonclonk schrieb:

Zitat :

Also nur mal rein Interessehalber. Ich arbeite mit CR und benutze trotzdem am Anfang jedes Skriptes #strict . Was genau ist den der Unterschied, abgesehen davon, dass es eben neue Syntax ist und trotzdem funktioniert.

#strict 2 ist der neue Standart. #scrict wir nur noch als Abwärtskompatiblität akzeptiert.

Aber nen wirklichen Nutzen hats nicht? So dass neue Funktionen nur mit #srict 2 funktionieren?