Fehlermeldungen wenn man AGS 3.2.1 Spiele mit AGS 3.4 starten will [GELÖST]

[Cone Arex]

AGS sagt mir auch nichts von Strg + H sondern Strg + Umschalt + E.

Exakt. Das ist der Fehler. AGS legt die Funktion auf irgendwelche zufällig gewählte Tastenkombination, anstelle von dem korrekten Strg+H, so das sie kein Schwein findet und gezwungen ist, die einzelne Replace-Funktion zu verwenden.

Und versuche bitte durchgängig deutsch zu sprechen, es ist zwar toll das du der englischen Sprache mächtig bist, aber das hilft mir nichts.

Das ich da nur geflucht habe, sollte auch für jemanden ohne Englisch-Kenntnisse ersichtllich sein.

Aber jetzt zu deinem Fehler:
AGS hat jede Instanz von eDirection durch CharacterDirection ersetzt, auch FaceDirection. Für die zukunft lässt sich vermeiden, in dem man nach " eDirection" (mit Leerzeichen vorne dran) sucht durch " CharacterDirection" (auch mit Leerzeichen) ersetzen lässt. Übrig gebliebene Instanzen von eDirection ändert man dann manuell. (Sollten weniger als 4 sein und können gefunden werden, in dem man das Spiel testweise kompiliert.)

Da noch ein Problem mit den Türen anstehen soll fürchte ich das es nie aufhört.

Das Problem mit den Türen sind <= 10 Zeilen Quellcode.

Wenn nun erstmal tagelang kompatibilitäts Probleme behoben werden müssen dann neige ich eher dazu bei einer älteren AGS Version zu bleiben (mit alten SPs).

Wenn man weiß, was behoben werden muss und es richtig macht, ist das pro Projekt in unter 10 Minuten erledigt.

[Cmdr]

Das ist auch so, nur hat die AGS-Funktion eine andere Bezeichnung. Also solltest du diese nun auch überall ändern.

Wenn du mir jetzt noch genau sagst wie die alte und wie die neue heist so das man es direkt in die Maske vom AGS Editor eingeben kann...

Das weiß ich nicht auswendig, kannst du aber über die Autovervollständigung finden.
Gebe z.b ein "cDave." und such dir die Funktion aus der Liste. Wenn keine Liste kommt probier mal Strg+Leertaste.

[Kiwa]

Das ist der Fehler. AGS legt die Funktion auf irgendwelche zufällig gewählte Tastenkombination, anstelle von dem korrekten Strg+H, so das sie kein Schwein findet und gezwungen ist, die einzelne Replace-Funktion zu verwenden.

Wieso Fehler? Weil AGS die Tastenkombination nicht so belegt wie du es haben willst? Jetzt sag mir bitte nicht das du die zig hundert Änderungen in den SPs einzeln geändert hast?

Ich habe nun die eDirection, die EnterRoom und die 4 Richtungsangaben (z.B. eDirDown zu eDirectionDown usw.) entsprechend abgeändert.
Wenn man nun die EXE erstellen will kommt die Meldung:

Flashlight.asc(189): Error (line 189): undefined symbol 'eEventChangeRoomBeforeFadein'

Also habe ich kurzerhand die Zeile Code im Flashlight Script ausgeschaltet, dann geht es aber so weiter mit dieser Meldung:

GlobalScript.asc(2470): Error (line 2470): undefined symbol 'eEventChangeRoomBeforeFadein'

Da bisweilen von einer solchen Funktion nicht die Rede war, hier nochmal die Frage wie es weiter geht? Gehört das schon zum Türenproblem oder ist das was anderes? Wenn ConeArex schon all das gefixt hat dann wäre es vielleicht hilfreich wenn hier mal jemand den Link dazu postet. Sicher auch gut für alle anderen die das selbe Problem (früher oder später) haben werden.
Konnte durch die Suchfunktion im Forum es nicht finden.

[Cone Arex]

Weil AGS die Tastenkombination nicht so belegt wie du es haben willst?

Nicht wie ICH es haben will, sondern wie es betriebsystemübergreifend STANDARD ist.

Jetzt sag mir bitte nicht das du die zig hundert Änderungen in den SPs einzeln geändert hast?

Doch. Durch genervtes durchklicken.

Wenn man nun die EXE erstellen will kommt die Meldung:...

Dieser Fehler ist mir nicht bekannt. Als ich das Mansion-SP upgedatet habe, ist etwas derartiges nicht aufgetreten.

[Cone Arex]

Sorry für den Doppelpost, aber sonst geht die Änderung unter.

Der Fehler wurde erneut durch die ReplaceAll-Funktion verursacht. "eEventChangeRoomBeforeFadein" muss eigentlich eEventEnterRoomBeforeFadein" heißen.

[Kiwa]

Jetzt sag mir bitte nicht das du die zig hundert Änderungen in den SPs einzeln geändert hast?

Doch. Durch genervtes durchklicken.

Jetzt verstehe ich langsam warum du so genervt bist. Das muss STUNDEN gedauert haben sich durch ALLE SPs durchzuklicken. Wenn ich überlege das (AGS zeigt immer die Anzahl der Treffer an) es sich alleine bei dem einen SP schon um ca. 1000 Treffer handelte (was ich bis jetzt so grob in Summe in Erinnerung habe) dann muss einem dabei doch irgendwann der Finger abfallen beim durchklicken.
Oh Cone, jetzt tust du mir schon (fast) ein wenig leid, aber mal bei einer neuen Version auf die Einträge der Menüleiste zu klicken um zu schauen was sich da so verändert hat ist aber auch nicht unüblich. Tja, jetzt hast du auch mal einen Bock geschossen, sowas passiert.

Der Fehler wurde erneut durch die ReplaceAll-Funktion verursacht. "eEventChangeRoomBeforeFadein" muss eigentlich eEventEnterRoomBeforeFadein" heißen.

Danke für den Hinweis. Das ist natürlich ein Nachteil dieser Funktion. AGS erkennt den String "EnterRoom" und ändert diesen dann auch wenn dieser innerhalb anderer Zeichenketten vorkommt. Ärgerlich. Schreib doch mal einen Hinweis an das AGS Team das man solche Probleme umgehen kann, für Groß/Kleinschreibung gibt es schließlich auch eine Einstellung bei der Such- und Ersetzfunktion. Warum du dennen schreiben sollst und nicht ich? Weil dein englisch besser ist als meins.

Nur nochmal der Vollständigkeit halber:
1. Die Datei playerExtends in AGS komplett löschen
2. Dann die Funktionsnamen von eDirection, eDirUp usw, und EnterRoom auf die neuen ändern
3. Türproblem beheben (von dem ich noch nicht weiß wie das Problem aussieht und wie es behoben wird).

Richtig so oder fehlt noch was? Nochmal die Bitte den Link zum Update hier posten, das vergrößert die Chanche das auch andere es finden.

[Cone Arex]

Das muss STUNDEN gedauert haben sich durch ALLE SPs durchzuklicken.

Nö. Ein paar Minuten für alles. Was aber an der repetitiven Arbeit, die sich bei mir in physischen Beschwerden äußert, nichts ändert.

aber mal bei einer neuen Version auf die Einträge der Menüleiste zu klicken um zu schauen was sich da so verändert hat ist aber auch nicht unüblich.

Ich lese die Changelogs, um heraus zu finden was es neues gibt. Und da wurde es nie aufgeführt. Strg+H geht nicht und die Suchfunktion hat zusätzlich eine Replace-Funktion (was auch nicht standardkonform ist). Also habe ich angenommen, dass die Replace-All-Funktion einfach nicht implementiert ist. Würde zu AGS passen.
BTW: Die Menüleiste beachte ich gar nicht mehr, als ich sie nur selten brauche (Build EXE und Make Template). Die Zeiten der Menüleiste ist ohnehin schon lange vorbei.

Das ist natürlich ein Nachteil dieser Funktion.

Das lässt sich umgehen, in dem man nicht nach "EnterRoom" sondern nach ".EnterRoom" suchen lässt.

Schreib doch mal einen Hinweis an das AGS Team das man solche Probleme umgehen kann

Das ist kein Bug, sondern genauso vorgesehen.

Nur nochmal der Vollständigkeit halber: [...]

Im Prinzip ja. Es fehlt noch ProcessClick, aber das ist vernachlässigbar. Außerdem sind in machen SPs (und vermutlich noch viel Episoden) noch veraltete Befehle aus 2.62-Zeiten vorhanden, wie die alten Formen von FaceDirection und EnterRoom die von der Suche wegen der anderen Syntax nicht gefunden werden. Aber das sollten so wenige sein, das sie von Hand entsorgt werden können. (Und wenn nicht, einfach die Suche ändern.)

3. Türproblem beheben (von dem ich noch nicht weiß wie das Problem aussieht und wie es behoben wird).

Für jede Tür sind nur zwei Richtungen angegeben, obwohl vier benötigt werden. Z.B. die Haustür der Bernoullis: Angegeben sind nur eDirLeft (Spieler schaut vom Flur auf die Tür) und eDirUp (Spieler schaut von draußen auf die Tür). Wenn man aber durch die Tür durchgeht, schaut der Spieler aber nach eDirRight (wenn von der Haustür in den Flur gegangen wurde) und eDirDown (vom Flur nach draußen gegangen). Diese beiden Richtungen wurden aber nicht explizit angegeben. Stattdessen werden die angegebenen Richtungen irgendwie "umgedreht".
Das ganze hat mit dem selbstdefinierten eDirection funktioniert (weil es ja dafür geschrieben wurde), mit dem AGS-internen Datentyp CharacterDirection funktioniert das nicht mehr. (Hier sei anzumerken, dass das keine Fehlermeldung erzeugt. Das Spiel kompiliert widerstandslos. Stattdessen führt es zum fehlerhaften Verhalten, dass der Spieler in die falsche Richtung schaut.) Ich habe nicht herausgefunden, wie das "Umdrehen" der Richtungen funktioniert. Ich verstehe die beiden Zeilen einfach nicht.
Mein schmutziger Lösungsansatz dafür war, eine Funktion zu schreiben die eine Richtung entgegen nimmt und die entgegengesetzte Richtung zurück gibt. Im Türen-Skript werden dann die Variablen mit der Rückgabe-Wert der Funktion befüllt.
Ein Beispiel dafür ist hier im Mansion-SP: https://raw.githubusercontent.com/ManiacMansionMania/Mansion-SP/master/GlobalScript.asc
Nach "reverseDirection" suchen, die Funktion kopieren und die Variablen l_Direction und l_NewDirection damit füttern. Und die alten Zeilen auskommentieren. (Einfach drei mal nach reverseDirection suchen und anschließend nach "// I have no idea what these lines are supposed to do.")

[Kiwa]

Danke für die Hinweise.

Was die zwei Zeilen angeht,

//l_Direction       = (l_Direction+2)%4;
//l_NewDirection    = (l_NewDirection+2)%4;

so gehe ich mal davon aus du diese deaktiviert hast. Falls diese schon ausgeschaltet waren dann ist das wohl nur ein Rest aus einer alten Vorversion des Scriptes.
l_direction und l_NewDirection ist wohl ein Integer, den sonst könnte man damit nicht rechnen und die Funktion ClickSpecial gibt auch einen Zahlenwert (int) zurück. Der % Operator ist der Rest-Operator in AGS, so steht es hier:
http://www.adventuregamestudio.co.uk/wiki/Script_language_keywords

Sowas benutzt man oft wenn man Zahlen auf gerade oder ungerade prüfen will, wobei man dann eher durch 2 teilt. Mmh, mysteriös diese Zeilen 
Man müsste genau wissen wie das mit der Blickrichtung funktioniert, wahrscheinlich werden die 4 Blickrichtungen durch Zahlenwerte dargestellt.
Aber wenn ich das richtig verstehe funktioniert das Spiel auch ohne die 2 Zeilen, bzw. es ist egal ob diese Zeilen an oder aus sind, es funktioniert in beiden Fällen nicht!?

[Cone Arex]

Erstmal heißt nicht "deaktiviert" sondern "auskommentiert".
Ich weiß selbstverständlich das es Integer sind und was der Rest-Operator ist.

wahrscheinlich werden die 4 Blickrichtungen durch Zahlenwerte dargestellt.

Ja, werden sie. Siehe die Definiton im playerExtends: https://github.com/ManiacMansionMania/Mansion-SP/blob/05c6ab2f6f431f152815c3400d424c52b5bdcb87/playerExtends.ash

Aber wenn ich das richtig verstehe funktioniert das Spiel auch ohne die 2 Zeilen

, bzw. es ist egal ob diese Zeilen an oder aus sind, es funktioniert in beiden Fällen nicht!?[/quote]
Ja, tut es. Weil die Variablen schon Werte haben. Es sind aber halt nicht die Richtigen ergo der Spieler schaut in die falsche Richtung.

bzw. es ist egal ob diese Zeilen an oder aus sind, es funktioniert in beiden Fällen nicht!?

Mit dem neuem Datentyp (CharacterDirection) funktioniert es in beiden Fällen nicht.

EDIT: Ich habe das ganze nochmal untersucht. Ich verstehe jetzt, wie die Richtungen errechnet werden (ich hatte einen Denkfehler drin). Allerdings funktioniert es dennoch nicht mit dem neuen Datentyp. Obwohl (!) die Zahlenwerte die gleichen sind.

EDIT²: Ich habe mich vertan. Die Zahlenwerte sind nicht die gleichen. Das ist das Problem.

[Kiwa]

Ich hab die Gleichung bzw. Zuweisung (den eine Gleichung ist es nicht) l_Direction = (l_Direction+2)%4 mal für die 4 Fälle durchgerechnet:

(0 + 2) / 4 = Rest 0 

(1 + 2) / 4 = Rest 0

(2 + 2) / 4 = Rest 0

(3 + 2) / 4 = Rest 1

Der Rest-Operator gibt immer nur den Rest zurück der bei einer Division übrigbleibt, wenn der Zähler kleiner gleich dem Nenner ist müsste also der Rest Null sein. Oder?

Man kann also mit der Zeile Code jeweils prüfen ob der Spieler nach rechts schaut, denn dann ist Rest = 1, nach dieser Definition:

#define DIR_UP    0 
#define DIR_LEFT  1
#define DIR_DOWN  2 
#define DIR_RIGHT 3

Wozu sollte man das brauchen? Es bleibt rätselhaft 

[Cone Arex]

wenn der Zähler kleiner gleich dem Nenner ist müsste also der Rest Null sein. Oder?

Eben nicht. Das war mein Denkfehler. Ist der Divident kleiner als der Divisor gibt der modulo den Dividenten zurück. Nicht 0. (Für mich als Informatiker ist so ein Fauxpas oberpeinlich.)

Entsprechend:
(0 + 2) %4 = 2

(1 + 2) %4 = 3

(2 + 2) % 4 = 0

(3 + 2) %4 = 1

Die Zahlenwerte von CharacterDirection sind:
Down: 0
Left: 1
Right: 2
Up: 3

Jetzt finde jemand eine mathematische Abhängigkeit.

#define DIR_UP    0
#define DIR_LEFT  1
#define DIR_DOWN  2
#define DIR_RIGHT 3

Den Kram kannst du ignorieren. Das ist Legacy-Code aus 2.62-Zeiten.

[Kiwa]

Entsprechend:
(0 + 2) %4 = 2

(1 + 2) %4 = 3

(2 + 2) % 4 = 0

(3 + 2) %4 = 1

Die Zahlenwerte von CharacterDirection sind:
Down: 0
Left: 1
Right: 2
Up: 3

Jetzt finde jemand eine mathematische Abhängigkeit.

Ich geh das mal in gedanken durch, vielleicht kommen wir dann auf die Lösung:
1. Der Spieler dreht sich von 0 (Down, blick uns an) nach 2 (rechts) -> Spieler dreht sich nach links
2. Spieler dreht sich von 1 Left nach 3 Up (Blickt von uns weg) -> Spieler dreht sich nach rechts
3. von 2 (rechts) nach 0 Down -> Spieler dreht sich nach rechts
4. von 3 (Up) nach 1 Left -> Spieler dreht sich nach rechts links

Der Spieler kann sich also mittels dieser Zuweisung 3 mal nach rechts und einmal nach links drehen, oder hab ich jetzt einen Drehwurm?
Schlauer werd ich daraus auch nicht aber vielleicht fängt das irgendeinen Sonderfall ab, zu erkennen ist das nur einmal eine Linksdrehung vorkommt. Oder hab ich mich mal vertan?

EDIT: Ich hatte einen Fehler, er dreht sich zweimal nach rechts und zweimal nach links.

EDIT2: Jetzt komm ich gerade ganz durcheinander, je nachdem aus welcher Perspektive man das sieht. Aus der Sicht des Menschen der vor dem PC sitzt oder aus Sicht der Spielfigur im Spiel. Down müsste doch heißen, Spieler schaut uns an und Up Spieler schaut von uns weg, also zum Objekt z.B. tür. Hab schon länger nix in AGS gescriptet.

[Cmdr]

Interessante Diskussion, die ihr hier mitten in der Nacht führt.
Aber wo liegt das Problem?
Es wird einfach der Zahlenwert der Direction genommen, +2 gerechnet und modulo 4 genommen, um im 4er Zahlenbereich zu bleiben. Das Ergebnis ist bei der definierten Reihenfolge der Richtungen immer die umgekehrte Richtung.

AGS definiert die Reihenfolge dagegen so, wie sie auch in den Views verwendet wird, deshalb geht diese schicke Richtung nicht mehr auf.
Ich habe mir deshalb eine Funktion geschrieben, die einfach ganz stumpf die momentane Richtung abfragt und durch die Gegenrichtung ersetzt. Diese Lösung ist zwar nicht so schön elegant wie die alte, aber die funktioniert.

Code: [Auswählen]

CharacterDirection invertDir(CharacterDirection dir)
{
  if(dir==eDirectionDown)
  {
    return eDirectionUp;
  }
  else if(dir==eDirectionUp)
  {
    return eDirectionDown;
  }
  else if(dir==eDirectionLeft)
  {
    return eDirectionRight;
  }
  else if(dir==eDirectionRight)
  {
    return eDirectionLeft;
  }
  else return eDirectionDown;
}
Der Aufruf der Funktion kommt dann an die Stelle der alten Rechnungen und ist:

l_Direction       = invertDir(l_Direction);
l_NewDirection    = invertDir(l_NewDirection);

Edit: Ich verwende noch die alten MMM-Directions, die ich wie oben beschrieben umgebogen habe. Habe die Codezeilen hier auf die neuen AGS-Funktionen umgeändert. Da ich das jetzt nicht überprüfen kann, gebe ich keine Garantie auf korrekte Syntax.

[Kaktus]

Code: [Auswählen]

//l_Direction       = -(l_Direction-3)%4;

[Cmdr]

Code: [Auswählen]

//l_Direction       = -(l_Direction-3)%4;

Genial!  Danke!