Weiterentwicklung der Starterpacks (Allgemein)

[KhrisMUC]

So übel ist das gar nicht; Raum 8, Hotspot 7 ist das Geschlossene. Objekt 2 wird darüber gelegt, um es offen darzustellen.
Wenn man das Schema kennt, ist es relativ simpel.

Als ich das zum ersten Mal gesehen habe, war ich allerdings auch etwas entsetzt

[Kinkilla]

Als ich das zum ersten Mal gesehen habe, war ich allerdings auch etwas entsetzt

Dito.
War eher liebe auf dritten Blick.

[Kaktus]

Wenn man wirklich mal das GlobalScript umschreibt, könnte man sich überlegen, ob man die VariableExtensions z.B.
durch Properties ersetzt, dann könnte man z.B. einfach sowas machen wie:

Code: [Auswählen]

...
else if (UsedAction(eActClose))
{
if(oKlodeckel.Visible)
{
oKlodeckel.Visible = false;
hToilette.SetTextProperty("DefaultAction", "Open");
...

Wobei ich mit den VariableExtensions eigentlich ganz zufrieden bin.

[Cmdr]

Es ging mir auch nicht um das Verständnis der Codezeile als solche, sondern dass in diesem Fall ein Verhalten eines ganz bestimmten Objektes im GlobalScript definiert wird. Da gehört es definitiv nicht hin und solch ein Stil führt unweigerlich zu einem unlesbaren Spagetti-Code. Ins GlobalScript gehören mMn nur allgemeine Funktionalitäten - Anpassungen dieser für bestimmte Objekte gehören zu dem Objekt selbst (also z.B. in das Raum-Script).

Jemand, der sich mit dem Code nicht auskennt und sich die Funktionalität der Toilette anschauen möchte, würde erstmal genau dort beginnen zu lesen. Dass die Funktion inmitten der Wirren des GlobalScripts gesetzt wird, ist erstmal einfach null ersichtlich. Es würde eine ganze Zeit dauern (und Nerven kosten), diese Stelle überhaupt zu finden.

Aus diesem Grund plädiere ich stark zu Kaktus Vorschlag einer Funktion, die das Property ändert und an der Stelle aufgerufen wird, an der sie nunmal am meisten Sinn macht: In der Hotspot/Objekt-Funktion im Raum.

[KhrisMUC]

Grundsätzlich ist das natürlich zu befürworten; ich z.B. würde ein entsprechendes Setup in room_Load erwarten, das ein manuelles Handling von eActOpen/Close überflüssig macht (Stichwort Spaghetti-Code).

Allerdings wird VariableExtensions in der global rep_exe aufgerufen, um in Echtzeit die GUI-Buttons anzupassen. Man müsste also eine Datenstruktur erstellen, in der die Daten (Raum, Hotspot, Objekt, Verb) in room_Load gesetzt werden, damit sie für die global rep_exe verfügbar sind.

Oder man macht es wie LucasFan, als er mit AGS 2.62 Maniac Mansion nachgebaut hat, lange bevor die Rede von einsteigerfreundlichen MMM-Packs war, und erstellt einfach eine Funktion im GlobalScript, in der man alle Türen aufsetzt...

[Cone Arex]

Changelog:
* Variable Standardaktion für Toilette in Raum 8.
* Variable Standardaktion für Briefkasten in Raum 18.

In beiden Funktionen wurde außerdem ein Kommentar eingefügt, der darauf hinweist, dass sich der Code für die Standardaktion im GlobalScript befindet.

Off-Topic: 210 Commits dieses Jahr. Wuhu!

und erstellt einfach eine Funktion im GlobalScript, in der man alle Türen aufsetzt...

Wird ja nun genauso gemacht, nur dass die Funktion in ein eigenes Script ausgelagert wurde.

[KhrisMUC]

und erstellt einfach eine Funktion im GlobalScript, in der man alle Türen aufsetzt...

Wird ja nun genauso gemacht, nur dass die Funktion in ein eigenes Script ausgelagert wurde.

Jo, ich wollte nur darauf hinaus, dass es sich hier um ein Überbleibsel handelt, das ursprünglich durchaus sinnvoll umgesetzt wurde.

A propos neues Türenskript: die Funktionen sehen im Moment so aus:

Code: (ags) [Auswählen]

function hTuer01_AnyClick()
{
  if(Door[eTuerBernardsZimmer].Click()==0) Unhandled();
}Da ein Raum mit fünf Türen fünf dieser Funktionen hat, kommt Einiges zusammen; ich wäre stattdessen für

Code: [Auswählen]

void DoorType::ClickUnhandled() {
  if (this.Click() == 0) Unhandled();
}

// room script
function hTuer01_AnyClick()
{
  Door[eTuerBernardsZimmer].ClickUnhandled();
}

[Cmdr]

Changelog:
* Variable Standardaktion für Toilette in Raum 8.
* Variable Standardaktion für Briefkasten in Raum 18.

In beiden Funktionen wurde außerdem ein Kommentar eingefügt, der darauf hinweist, dass sich der Code für die Standardaktion im GlobalScript befindet.

Der Kommentar macht es nicht wirklich besser. Es bleibt weiterhin richtig schlechtes Software-Design.
Ich finde z.B. die Idee, die Standard-Aktion über einen Postfix im Namen zu definieren gar nicht so übel. Also warum nicht einfach den Namen von "Toilette>o" in "Toilette>c" ändern?

Ganz eigentlich resultieren unsere Probleme ja nur darin, dass AGS-Script einfach eine furchtbare "Sprache" ist und selbst die einfachsten objektorientierten Strukturen nicht unterstützt werden. Hach, was wäre das schön *träum*.

Da ein Raum mit fünf Türen fünf dieser Funktionen hat, kommt Einiges zusammen; ich wäre stattdessen für

Code: [Auswählen]

void DoorType::ClickUnhandled() {
  if (this.Click() == 0) Unhandled();
}

// room script
function hTuer01_AnyClick()
{
  Door[eTuerBernardsZimmer].ClickUnhandled();
}

Klingt gut und lässt sich auch besser lesen. Beim Ursprünglichen wundert man sich an der Stelle wirklich nur über die if-Abfrage.
Ich würde die Funktion aber stattdessen ClickOnDoor() oder ähnlich nennen.

[Kinkilla]

Hach, was wäre das schön *träum*.

Frust wird mittlerweile bei AGS mitgeliefert. Das gehört schon dazu.
Ich finde den Vorschlag von Cmdr auch am einfachsten. (Beide Vorschläge!)

[KhrisMUC]

Ganz eigentlich resultieren unsere Probleme ja nur darin, dass AGS-Script einfach eine furchtbare "Sprache" ist und selbst die einfachsten objektorientierten Strukturen nicht unterstützt werden. Hach, was wäre das schön *träum*.

AGS-Script kann natürlich nicht mit Java oder C++ mithalten, aber immerhin werden ja eigene structs unterstützt, was diese Aussage etwas seltsam wirken lässt. Oder was genau meinst Du mit "einfachsten objektorientierten Strukturen"?

Außerdem ist AGS eine Adventure-Engine, keine Programmiersprache, und dafür ist die Skript-Sprache enorm mächtig, wenn man sie z.B. mit GameMaker oder anderen Engines vergleicht, die keine externe Skriptsprache unterstützen.

Mir wäre auch ein JavaScript-API am liebsten, aber ich finde durchaus, das AGS sehr viel bietet.

Und warum "ClickOnDoor()", wenn es sich bereits um eine Methode des Door-structs handelt? Door[...].ClickOnDoor() oder wie?

[Kiwa]

Habe im neuen Jahr gleich mal was gutes getan und ein paar Bugs im Wendy SP rausgehauen. Da wäre:

1. Walkable Area im oberen Bereich der Bücherei angepasst, VORHER sah es so aus:




2. Drei Bugs den Fahrstuhl betreffend entfernt.
    2.1 Wenn man die Fahrstuhl Tür öffnete und dann den Raum verlassen und wieder betreten hat war es nicht mehr möglich den Fahrstuhl zu
          benutzen. Der Fahrstuhl stand offen und das Tastenfeld im Fahrstuhl hatte keinen Hotspot mehr
    2.2 Walkable Areas im Fahstuhl sowohl im Ersgeschoss als auch im ersten Stock angepasst, und
    2.3 Wenn man das Fahrstuhltastenfeld im Fahrstuhl benutzte war es nicht mehr möglich den Fahrstuhl im selben Stockwerk zu verlassen.
          Dafür habe ich die Option EXIT eingebaut, siehe Bild:




3. Die Proportionen im Badezimmer von WC und Waschbecken passen überhaupt nicht. Da habe ich noch nichts gemacht, da müsste mal ein Grafiker ran, so wie es jetzt ist sieht es jedenfalls viel zu groß aus und das Waschbecken hängt zu hoch, finde ich. Das WC ist deutlich zu breit. Was sagt ihr?




Noch eine Scriptfrage:
Die Tastenfunktionen vom Fahrstuhl (im inneren des Fahstuhls) sind mittels Dialog realisiert. Soweit so gut. Allerdings werden im Dialog Funktionen aufgerufen die ich nirgends, auch nicht im GlobalScript finden kann, siehe Markierung im Bild:



Wo sind diese Scripte und wäre es nicht einfacher den Code direkt in den Dialog zu schreiben? Dort kann man genauso gut Code reinschreiben und es funktioniert auch und man braucht nicht den Scripten hinterher suchen.

EDIT: Hier das neue SP zum Download (bitte auch in GitHup integrieren):
https://workupload.com/file/5yqAVuA

[Cmdr]

Ich vermute mal, dass die ein RoomScript aufrufen. ( Im Raum unter function on_call (int i) ).
Das ist sinnvoll, wenn Dinge des Raumes, wie Objects angesprochen werden. Ansonsten stimme ich dir zu, dass allgemeine Funktionalitäten, wie bspw ein Changeroom auch direkt im Dialog implementiert werden sollten. Das ging btw in alten AGS Versionen noch nicht, weshalb es wahrscheinlich so gemacht wurde.

[Kiwa]

Ich vermute mal, dass die ein RoomScript aufrufen. ( Im Raum unter function on_call (int i) ).

Im Raum Script (vom Raum in der auch der Fahrstuhl ist) ist eine derartige Funktion nicht vorhanden. Es wird aber eine Funktion Namens "aufz()" importiert. Wo die implementiert ist weiß ich aber auch nicht, die Suchfuktion hat im GlobalScript diese jedenfalls nicht gefunden.

... Ansonsten stimme ich dir zu, dass allgemeine Funktionalitäten, wie bspw ein Changeroom auch direkt im Dialog implementiert werden sollten. Das ging btw in alten AGS Versionen noch nicht, weshalb es wahrscheinlich so gemacht wurde.

Das würde erklären warum der Code nicht im Dialog steht. Die alten AGS Versionen (vor AGS 3.2.1) kenne ich nicht.

[Kaktus]

Bei run-script X im Dialogscript wird die Funktion dialog_request() (GlobalScript) aufgerufen und die Nummer dann als param übergeben. Ist umständlich, vor allem wenn man zich Funktionen hat, die über Dialog aufgerufen werden. Gut, dass man den Code jetzt direkt ins Dialogscript schreiben kann.

[Kiwa]

Bei run-script X im Dialogscript wird die Funktion dialog_request() (GlobalScript) aufgerufen und die Nummer dann als param übergeben.

Habe im GlobalScript folgendes gefunden:

Code: [Auswählen]

#sectionstart dialog_request  // DO NOT EDIT OR REMOVE THIS LINE
function dialog_request (int param)
{
}
#sectionend dialog_request  // DO NOT EDIT OR REMOVE THIS LINE

Und nun? Die Funktion ist komplett leer. Wie zum Geier funktioniert das? Hat AGS jetzt schon unsichtbaren Code?

Btw: Das überarbeitete Wendy-SP ist noch nicht auf Github. Wäre gut wenn das mal jemand der sich damit auskennt aktualisieren könnte.

EDIT: Sorry, war im falschen SP. Im Wendy-SP steht Code in der Funktion.