[Gelöst] Befehl "soll nicht für Hazardclonk gelten"

Ich hab durch die Einbindung des Epic-packs ja eingefügt, dass normale Clonks Gegenstände die sie dabei haben nun in der Hand halten.
Dadurch haben sie die neuen Aktionen "HoldWalk" und "HoldJump" bekommen, weshalb z.b der Bausatz und das Bauen der Lehmbrücke in einem appendto an diese neuen Aktionen angepasst werden mussten.

Dummerweise baut der Hazardclonk auf dem normalen Clonk auf, was sehr unglücklich ist, da selten Änderungen am Clonk auch so beim Hazardclonk funktionieren. So auch in diesem Fall. Bisher konnte ich nur erkennen, dass getragene Waffen nicht mehr sichtbar sind, aber wer weiß was da noch alles an Fehlern passiert.

Nun sehe ich folgende Möglichkeiten:
1. Das Hazardclonkskript umschreiben, sodass es nicht mehr auf dem normalen Clonk basieren muss. Das wäre sicherlich das vernünftigste, aber leider nicht wirklich machbar, da ich mich dazu zu wenig auskenne, wie die ganzen inherited Funktionen mit den verschiedenen Parametern funktionieren, welche ich dann ja ersetzen müsste. Diese Option fällt also eig schon weg.
2. Die Waffen des Hazardclonks an die neuen Aktionen anpassen. Das wäre denkbar, könnte aber auch kompliziert werden. Außerdem kann ich so nur die Dinge behandeln, die mir bisher aufgefallen sind. Es können also noch zahlreiche weitere unvorhergesehende Fehler auftauchen. Deswegen schließe ich das auch aus.
3. In den Funktionen, welche die neuen Aktionen einführen eine Ausnahme Formulieren, dass sie nicht ausgeführt werden, wenn es sich um einen Hazardclonk handelt (oder wahlweise, dass sie nur ausgeführt werden, wenn es sich um einen normalen Clonk handelt). Diese Option erscheint mir am einfachsten und sinnvollsten.

Also wie kann ich Option 3 umsetzen? Reicht es da am anfang jeder der neuen Funktionen einen if Befehl zu schreiben? Und wie müsste dieser aussehen?  Es ist dort ja nirgends ein target oder obj odersonstwas definiert, deswegen wüsste ich gerade nicht, was im if Befehl als Ziel angegeben werden müsste.

Option 3 macht am meisten Sinn, ja. Ich denke, es müsste reichen, auf die ID zu überprüfen, also in etwa if (GetID() == CLNK) return; - natürlich mit der richtigen ID des Hazardclonks. Evtl. musst du bei einigen Funktionen auch inherited verwenden.

okay, also es sind nur 2 Funktionen in dem Aktions appendto drin. Die erste ist eine Initalize und die zweite ist ein Effekt welcher durhc Initalize aufgerufen wird. Demnach sollte es reichen, wenn ich nur bei Initialize die Bedingungen davor setze.

Das Original:

protected func Initialize()
{
  AddEffect("InventarCheck", this, 1, 1, this);
  return(_inherited());
}


Habe es jetzt so gemacht:

protected func Initialize()
{
  if (GetID() == CLNK){ AddEffect("InventarCheck", this, 1, 1, this);}
  else {return(_inherited());}

  return(_inherited());
}


Leider wird dadurch auch dem normalen Clonk die Aktion genommen… Ich vermute ich muss in den if Befehl noch das "return(_inherited())" unterbringen? Weiß aber nicht, wie ich da 2 Dinge unterbringe… muss ich die durch ein Komma trennen? Oder ein &&?   Selbst wenn das nicht der Grund, wie könnte ich 2 Folgen machen, wenn der if Befehl erfüllt ist?

> wie könnte ich 2 Folgen machen, wenn der if Befehl erfüllt ist?


Alles was in dem folgenden Block { ... } steht, wird ausgeführt. Das hatten wir irgendwann schonmal bei einer for-Schleife:

if (1 == 2)
{
    Log("1 ist 2!");
    GetCursor(0)->Explode(100);
    GameOver(9000);
}

^- Dieses Script logt eine Nachricht, sprengt den Spieler und beendet das Spiel wenn 1 gleich 2 ist.

Das ist aber jetzt hier in deinem Fall nicht die Ursache, weil alles nach dem Block (ausser das im else-Zweig) auch noch ausgeführt wird. In deinem Fall wird das return inherited() auf jeden Fall ausgeführt! Du könntest dir sogar den else-Zweig ganz sparen.

>Alles was in dem folgenden Block { ... } steht, wird ausgeführt.


ah okay, also Semikolon. Ich war mir nicht sicher, wie ich es trennen müsste ;)

Also sagst du, dass es so eigentlich funktionieren müsste?  Dann ists ja komisch, warum der normale Clonk ebenfalls die Aktion verliert... hm...

Ich teste Änderungen immer in abgespeckten kopierten Packs, weil Änderungen in einer vollständigen Kopie immer ewig dauern (20 sekunden pro winzige Änderung, auch wenn es nur ein buchstabe in einer textdatei ist…). 
Jedenfalls hab ich es gerade mal in eine vollständige Version gepackt und jetzt klappt alles einwandfrei. Hatte wohl irgendeine Datei gefehlt, weshalb die normalen Clonks die Aktion verloren hatten.

>Ich teste Änderungen immer in abgespeckten kopierten Packs, weil Änderungen in einer vollständigen Kopie immer ewig dauern (20 sekunden pro winzige Änderung, auch wenn es nur ein buchstabe in einer textdatei ist...).


Du solltest eh nur in entpackten Daten arbeiten.

Die Objektpakete sind ja ZIP-Archive um Platz zu sparen. Du kannst die im Editor mir Rechtsklick->Zerlegen komplett entpacken und arbeitest dann nur auf echten Ordnern & Dateien. Bevor du sie hochlädst musst du die dann wieder mit Rechtsklick->Packen in Archivform bringen.
Ich empfehle jetzt beim ersten Mal entpacken vorher eine Sicherungskopie zu machen. Mir ist zwar dadurch schon lange nichts mehr kaputt gegangen, aber ich erinnere mich dass das mal passiert ist.

Wenn du auf gepackten Dateien arbeitest, wird bei jeder kleinen Änderung alles komplett entpackt und neu gepackt. Deshalb die 20 Sekunden

ja, ich hab schon gemerkt, dass es alles schneller geht, wenn man entpackt und die Dateien im Explorer bearbeitet, anstatt mit dem Editor.
Aber das entpacken verursacht mehr Fehler als es nutzt. Bisher ist jedesmal irgendein Fehler aufgetreten. Natürlich hatte ich vorher immer eine Sicherung gemacht.
Aber es war jedesmal so, dass nach dem entpacken die Engie viele Fehlermeldungen ausspuckte, die vorher nicht da waren und ich konnte sie nicht lösen, außer wieder die Sicherung zu verwenden und sie gepackt zu lassen…
Ich tippe darauf, dass es an der Größe des Packs liegt.

>ja, ich hab schon gemerkt, dass es alles schneller geht, wenn man entpackt und die Dateien im Explorer bearbeitet, anstatt mit dem Editor.


Du kannst die Dateien dann auch ganz normal im Editor bearbeiten

>Aber es war jedesmal so, dass nach dem entpacken die Engie viele Fehlermeldungen ausspuckte, die vorher nicht da waren und ich konnte sie nicht lösen, außer wieder die Sicherung zu verwenden und sie gepackt zu lassen...


Denk aber dran, dass du jetzt bei jeder kleinen Änderung alles komplett entpackst und neu packst. Ich würde sagen, das ist noch viel fehleranfälliger

>Denk aber dran, dass du jetzt bei jeder kleinen Änderung alles komplett entpackst und neu packst. Ich würde sagen, das ist noch viel fehleranfälliger


nur ist mir dabei bisher noch kein Fehler untergekommen ;)
Ich hab einfach keine Lust, dass ich mit einem entpackten Pack arbeite, da viele Änderungen mache und danach beim testen merke, dass ein haufen Fehler auftreten. Denn dann verbringe ich wieder stunden damit, rauszufinden, wo der Fehler herkommt, um dann letzlich endlich zu merken, dass ich den Fehler nicht verursacht habe, sondern er durch das entpacken entstand. In dem Fall war dann die ganze Arbeit umsonst, da ich mit der verpackten Sicherungsdatei weiterarbeiten muss, wo ich meine neu erstellten Inhalte nicht einfach reinkopieren kann, weil sie verpackt ist, es dauert also letzlich trotzdem ewig.
Habe ich jetzt schon 2 mal hinter mir , das stundenlange suchen nach einem Fehler den ich nicht finden kann :D

Meine Erfahrung ist eher andersrum:
Bei mir ist es öfters passiert, dass Änderungen einfach nicht übernommen wurden, wenn ich im gepackten Ordner gearbeitet habe.
Mittlerweile arbeite ich von vorneherein immer NUR entpackt und packe dann (eine Kopie davon) nur zum Hochladen

>Bei mir ist es öfters passiert, dass Änderungen einfach nicht übernommen wurden, wenn ich im gepackten Ordner gearbeitet habe.


könnte mir vorstellen, dass du den Effekt meinst, der oft eintritt, wenn man Dinge dupliziert , bzw kopiert. Wenn man dann in der einen Datei etwas verändert, wird das nicht korrekt angezeigt, wenn man das Script dazu dann öffnet. Man muss den Editor dann immer mit F5 aktualisieren...  hab mich mittlerweile dran gewöhnt.

>Mittlerweile arbeite ich von vorneherein immer NUR entpackt


ich denke ich hätte auch damit anfangen müssen.  kleinere Pakete entpacken sich meistens problemlos und ohne Fehler.   Vllt versuch ichs demnächst mal, mein Objektpack in  kleineren Happen zu entpacken und teste dann gleich, ob noch alles geht...   ich befürchte halt nur, dass sich dann ein Fehler einschleicht, der sich erst bemerkbar macht, wenn eine bestimmte Situation eintritt, weshalb ich ihn dann erst bemerke, wenn schon viel zuviel neues dabei ist... naja.. mal schauen...

hast du zufällig Ideen zu meinen bisher noch ungelösten Threads?  Gibts hier im Forum einen Marker [Gelöst] für Threads die abgehackt sind?
edit: ich schreib einfach mal manuell in die Threadtitel [gelöst] wenn sie gelöst sind ;)

>könnte mir vorstellen, dass du den Effekt meinst, der oft eintritt, wenn man Dinge dupliziert , bzw kopiert


Das waren bei mir wirklich Packfehler.
Symptom dafür sind ganz viele Dateien im Clonkordner mit der Endung ".001" usw

Ich dachte die .001 - Dateien sind Backups, die gemacht werden, wenn die Engine läuft, während man die Änderung macht. Ich entwickle in der Regel auch im gepackten Zustand und kriege die nur, wenn ich was verändere, während die Engine läuft und darauf zugreift.
Die gerade geöffnete Szenariendatei bleibt, wie sie ist, aber die Änderungen sind in den Backup-Dateien gesichert.