- Der Anregungs-Thread für das PaC-DK -

[Baelavay]

Es war mit der Grafik von DaGus also tatsächlich wie erwartet: Die weiße Fläche wird - im Gegensatz zur von mir gespeicherten Grafik - korrekt angezeigt! Damit wäre das Rätsel um die Weiß-Transparenz gelöst und das Problem von eurer Seite aus gelöst. Ich werde Objektgrafiken mit reinen Weiß-Tönen nun auf eine andere Weise speichern.
...und das PaC-DK war an der ganzen Sache unbeteiligt

[Zimond]

sehr schön

[Baelavay]

Könnte das Sprachtool dem User nicht auch eine Liste erstellen mit den Soundfiles, die man z.B. in playsound()-Befehlen angegeben hat? Also zusätzlich zu den speech()-Befehlen.

[Zimond]

gute idee, so brauch ich nicht beim Skripten von Alühn 2 dann alle Sounds immer aufzuschreiben

[Baelavay]

Es wäre eine Bereicherung, wenn das Sprachtool beim Erstellen von Textfiles, die in speech-Befehlen (bald auch anderen?) angegebenen Sounddateinamen beinhalten, unterscheiden würde zwischen

• Sounddateien, welche bereits in den Mediapool importiert wurden, d.h. bereits vorhanden/ erstellt sind, und
• Sounddateien, die noch nicht vorhanden sind.

Bei fortgeschrittener Projektphase wird es nämlich anders kaum noch deutlich, welche Speeches beispielsweise noch erstellt und importiert werden müssen.

Es wäre also ein großes Anliegen meinerseits, dass das Sprachtool beim Erstellen von Textfiles zwei verschiedene Typen erstellt, oder zumindest in den Textfiles die im Projekt noch nicht vorhandenen Soundfiles gesondert kennzeichnet.

[Baelavay]

...außerdem würde ich mir wünschen:

• einen Befehl "movetext(Nummer;x;y;Geschwindigkeit)", der für Textzeilen genauso funktioniert wie der "moveobj"-Befehl für Objekte
• einen Befehl, der an bestimmte Maps gebundene Textzeilen wieder löst und "everywhere" anzeigen lässt, also sozusagen das Gegenstück zum "bindtext"-Befehl, der seit Version 2.6.0 mit dabei ist

Wenn ich schon mal dabei bin, noch eine Frage: Wie komme ich selbst nach dem Erstellen eines fertigen Spiels an die erstellten Spieldateien, welche ja optional mit einem zufälligen (also unbekannten?) Passwort versehen sind? Klar hat man im Normalfall selbst noch den Projektordner, aus dem man die Dateien genommen hat, es betrifft mich auch nicht akut, es würde mich einfach mal interessieren - so nebenbei...

Habe übrigens vorhin zum ersten mal die Option im DEV-Mode getestet, die die Spielgeschwindigkeit erhöht. Einfach irre

[Zimond]

Wenn ich schon mal dabei bin, noch eine Frage: Wie komme ich selbst nach dem Erstellen eines fertigen Spiels an die erstellten Spieldateien, welche ja optional mit einem zufälligen (also unbekannten?) Passwort versehen sind? Klar hat man im Normalfall selbst noch den Projektordner, aus dem man die Dateien genommen hat, es betrifft mich auch nicht akut, es würde mich einfach mal interessieren - so nebenbei...

Wenn ich dir das verraten würde könntest du von allen Games die Dateien rausholen, da der.. nun nennen wir ihn mal Algorithmus... immer der gleiche ist
Wenn ich etwas gemacht hätte wie das der Spielersteller selber ein eigenes Passwort eintragen könnte, wäre jemand wie unser Schnüffler Elogy in der Lage das ganze in 10 Minuten zu knacken

Deine Vorschläge werden notiert.

[Elogy]

Ihr seid fies

[Baelavay]

Vorschlag:

Bezugspunkt des Charakters sollte bei deaktivierten "echten Linksanimationen" gleichsam wie die Charaktergrafik gespiegelt werden.

Erklärung:

Ich habe beispielsweise dieses Charakterfenster, Pickup-Zustand:


Die "echten Linksanimationen" sind deaktiviert. Mein Problem ist, dass der Charakter, wenn er nach links etwas aufhebt, für die Zeit des Pickup-Effekts immer kurz einen Satz nach links macht. D.h. er befindet sich während der Pickup-Animation zu weit links, weiter links als wenn er normal steht. Beim Pickup nach rechts tritt das nicht auf.

Ich kann mir das Problem nur folgendermaßen erklären:
Eigentlich müsste der Bezugspunkt des Charakters sich mit dem Charakter spiegeln, also so:


Er befindet sich bei der "nicht echten Linksanimation" aber an der selben Stelle wie bei der Rechtsanimation:


Sollte ich mit meiner Vermutung nicht richtig liegen, so wäre ich über einen Lösungsvorschlag äußerst dankbar

[Zimond]

ich bin mir ziemlich sicher das auch der Bezugspunkt immer mitgespiegelt wird, es würde mich wundern wenn mir das bisher alleine schon beim Machen von Alühn nicht aufgefallen wäre. Aber ich notier mir das dennoch mal auf die Liste um das noch mal nachzuschauen.

[Baelavay]

• Wäre es nicht besser, wenn sich das Coin-Menü schließen würde, wenn man auf den Bereich außerhalb des Coin-Menüs (Umgebung) klickt, so wie man es standardmäßig von den Windows-Menüs kennt? Zum einen wäre das die erste Möglichkeit, das Menü zu schließen (bisher blieb bei geöffnetem Coin nichts anderes übrig als einen Befehl auszuwählen), zum anderen würde verhindert, dass man den Charakter im Hintergrund bewegen kann und sich somit die Walkmapkoordinaten verändern.
• Lässt sich ein optionaler Kasten integrieren, der hinter einer Infotextzeile angezeigt wird?

[Zimond]

- erstell einfach ein Objekt das Bildschirmgröße hat ohne Grafiken setz es ins Coinmenu (in den passenden Raum) und klick mit der rechten maustaste darauf um es NACH HINTEN zu setzen. In das Objekt dann noch :

on (click)
command ()

und schon geht das.

- Um die Infotexte die neben der Maus erscheinen? säh doch pfui baba aus

[Baelavay]

• Ich habe deine Anweisungen mit dem Wegklicken des Coin-Menüs befolgt. Das hat aber leider nicht so geklappt wie erhofft. Da die Angelegenheit doch recht schwierig zu erklären ist, habe ich ein hoffentlich verständliches Bildchen angefügt:
  
  Wenn es so weiter geht, werde ich noch Rekordhalter im Bilder-Upload... das da im dritten Bild ist übrigens keine Werbung für einen bekannten Baumarkt, sondern soll ein Objekt darstellen - mir ist jetzt auf die Schnelle nichts besseres eingefallen
• Es gibt zwei Gründe, weshalb ich mir einen Kasten hinter der Infozeile wünsche: Erstens suche ich seit langem vergeblich in den Grundeinstellungen meines Spiels nach einem Farbton, der sich von jedem Hintergrund der Maps in meinem Projekt abhebt, gleichzeitig aber auch zum Design passt (also kein schweinchenrosa o.ä.), zweitens würde es nach meinem persönlichen Empfinden schlichtweg besser aussehen. Ich meine, jeder kennt doch die windows-typischen Quick-Infos, die erscheinen, verweilt man längere Zeit mit der Maus über einem Icon. Für mich war die "showinfo()"-Textzeile immer eine Art vereinfachte Quick-Info. Stell dir doch mal die System-Infozeile ohne den gelben Balken vor - das geht ja wohl mal gar nicht
  
  Ich will dich natürlich zu keinem neuen Feature drängen, hast ja schon viel für mich am PaC-DK verbessert. Kannst du dir aber vorstellen, einen optionalen (!) "Kontrastkasten" hinter den Infozeilen zu integrieren - oder wäre das überhaupt machbar? Hier noch zwei kleine Pics um dich von der Notwendigkeit zu überzeugen:
  
  
  Man kann sich wahrscheinlich vorstellen wir das auf dunklerem Untergrund aussehen würde (das stellt jetzt einfach mal ein Adventure-Objekt "Arbeitsplatz" dar ) - oder weiße/ graue Schrift auf hellem Untergrund...

[Zimond]

- Coin Menü :

Tausch den command() Befehl gegen return() aus.
Pack dein Coinmenü in die Mitte des Raums so hast du das Dummy Objekt dann komplett drumherum.

- Textrahmen :

Aber bei deinem Beispiel fehlen noch die OUtlines die du um den Text legen kannst, dann sieht das ja nich ganz so unscheinbar aus. Ich schau mal was man da Rahmen mäßig machen.

[Baelavay]

• Pack dein Coinmenü in die Mitte des Raums so hast du das Dummy Objekt dann komplett drumherum.

  Gute Idee, doch auch das ist problematisch: öffne ich das Coin-Menü nun also wenn sich der Mauszeiger genau in der Mitte des Bildschirms befindet, dann sollte es wohl funktionieren. Was aber, wenn sich das Coin-Menü am Rand des Bildschirms öffnet? Dann sieht es wieder genauso aus wie beim dritten Bild oben, d.h. der Bildschirm ist beispielsweise 800x600, und auch die maximale Objektgröße ist 800x600. Demzufolge gibt es bei nicht zentraler Position des Coin-Menüs einen Bereich, in dem kein Dummy-Objekt vorhanden ist und sich das Coin-Menü nicht schließen lässt.
  
  Um das zu verhindern, müsste man den Coin-Raum 3x3 Bildschirme groß machen, damit auch bei am Rand geöffnetem Coin überall ein Dummy-Objekt vorhanden ist - wobei 3x3 ja nicht geht. Ich weiß auch nicht, ob ohne Hintergrundgrafik größer als einfache Bildschirmgröße eine höhere Abmessung als 800x600 möglich ist und wie das in den Coin-Interface-Einstellungen der Grundeinstellungen aussieht.
  
  Möglicherweise irre ich mich auch völlig und es funktioniert auf deine beschriebene Weise - der Ansicht bin ich momentan aber noch nicht
  ...womit ich wieder auf meine Anfangsfrage zurückkomme: Wenn sich das Schließen des Coin-Menüs durch Klick auf die Umgebung nicht im Projekt realisieren lässt, wäre es dann direkt im PaC-DK möglich?

• bei deinem Beispiel fehlen noch die OUtlines die du um den Text legen kannst

  Du meinst man kann Outlines auch um die Infotextzeilen legen? Meines bisherigen Wissens war der Infotext kein durch das Textmenü definierter und somit bis auf die Farbe nicht einstellbar!?

[Zimond]

- stimmt.. joa, sollte sich von pac-dk seite auch lösen lassen
- Ich mein eigentlich die Outlines einer Schriftart, der Infotext benutzt standard mäßig die erste die du im Schriftarten fenster eintragst, und wenn dort Outlines an sind sollte auch der Infotext Outlines haben.

[Baelavay]

Gibt es bereits eine Möglichkeit, um im Spiel die Darstellung von Objekten im Raum (Vorne/ Mitte/ Hinten) zu verändern? Ich habe beispielsweise einen Zaun, der bei Aufruf eines Walkmapskripts nach vorne bzw. hinten gesetzt wird. Den Zaun als "mittleres" Objekt einzustellen macht in dem Fall keinen Sinn, da er quer über das Bild verläuft, d.h. die Linie, die man bei mittleren Objekten angibt, an dem der Charakter von "vor dem Objekt" zu "hinter dem Objekt" gelangt, ist nicht horizontal.
Die einzige Möglichkeit, die mir spontan einfällt, ist, zwei Objekte mit der selben Grafik und der selben Position im Raum zu erstellen, wobei das eine auf "vorne" und das andere auf "hinten" gesetzt ist. Im Walkmapskript müsste ich dann zwischen den beiden Objekten hin- und herschalten --> ein wenig unpraktisch.

Im günstigsten Fall könnte ich die Darstellung per Befehl verändern. Wäre so etwas in der Art machbar?

[Zimond]

Wäre schon machbar, ich bin nur immer ein bisschen zaghaft was das einfügen neuer Befehle angeht, weil je mehr verschiedene Befehle drin sind desto potentiell unübersichtlicher wirds.

Das Problem mit solchen quer liegenden Objekten kenn ich auch, aber sie kommen ja eher selten vor und da kann man doch ruhig mal die Methode anwenden die du beschreiben hast, oder? sei gnädig zu meiner ToDo list

Und bevor du wieder wegen der Profilinfo fragst : Ich mach das alles zusammen mit dem nächsten PaC-Dk Update, aber wann der kommt kann ich dir jetzt noch nich sagen.

[Baelavay]

Das Problem mit solchen quer liegenden Objekten kenn ich auch, aber sie kommen ja eher selten vor und da kann man doch ruhig mal die Methode anwenden die du beschreiben hast, oder?

No prob, ist an sich auch kein unentbehrlicher Verbesserungsvorschlag meinerseits.
Aber damit bestätigt sich mal wieder meine These: "Bei einfachem Rechteckauswahl/ -begrenzungssystem statt Polygonhotspots/ Direktkonturauswahl hat man mit Problemen zu rechnen, sobald man diagonale Objekte darzustellen und einzubinden hat." - Aber ich werde diesen Punkt weiterhin still übergehen

Und bevor du wieder wegen der Profilinfo fragst : Ich mach das alles zusammen mit dem nächsten PaC-Dk Update, aber wann der kommt kann ich dir jetzt noch nich sagen.

Heureka das ist doch schon mal was - ich nehme das einfach mal als verbindliche Zusage betreffend der erweiterten Profilinfo
Aber erlaube mir Interesse halber zu fragen, wie du es zu ermöglichen planst? Hat der gepostete Forenpatch funktioniert?

[Zimond]

ich habe Arbeitsmäßig grundsätzlich Scheuklappen auf, welche es mir ermöglichen lange Projekte überhaupt durchhalten zu können... soll heißen darüber mach ich mir Gedanken wenn ichs einfügen will

Wenn ich vorstelle ich würde mir bei Alühn 2 schon jetzt zu allem was ich machen muss den Kopf zerbrechen würde ich wirklich bald so aussehen wie auf deinem ToDo Liste Bild

[Baelavay]

Es stimmt schon, dass man besser den Überblick speziell über umfangreichere Projekte behalten kann, wenn man sich nähere Gedanken über die Realisierung einzelner Aufgaben erst macht, wenn sie umgesetzt werden sollen. Andererseits muss ich sagen, dass es leicht frustrierend sein kann, wenn man das gesamte Projekt einschließlich dem fraglichen Element konzipiert hat und erst bei der Konfrontation mit der Realisierung der Aufgabe bemerkt, dass man es gar nicht umsetzen kann. Das ist meine Einstellung zur allgemeinen Planung. Bei deiner Liste geht es natürlich um unterschiedliche Verbesserungen des PaCDKs bzw. des Forums - und nicht um mehrere Aufgaben innerhalb des selben Projekts, wie es beispielsweise bei Adventures der Fall ist. Und ist es das nicht, worauf du dich hiermit bezogen hast?:

darüber mach ich mir Gedanken wenn ichs einfügen will

welche es mir ermöglichen lange Projekte überhaupt durchhalten zu können

[Baelavay]

Dies ist die Liste aller verfügbaren Charakteraktionen:Ist es noch niemandem aufgefallen, dass einem bei im Charakterfenster angewählten "echten Linksanimationen" eine Aktion "Nehmen Links" fehlt? Bei asymmetrischen Charakteren sieht schließlich auch die Pickup-Aktion anders aus, je nach Blickposition Links/ Rechts. Oder ist 20 bereits die maximale Anzahl?

[Zimond]

jor.. fällt das wohl, aber da kann man ja noch selber etwas machen... nimm einfach eine Extra Animation benenn sie um zu "pickupleft" und bei Situationen wo im Spiel eine Links Nehmen Animation ausgeführt wird kommt dann anstatt pickup (self) : setchar (self ; pickupleft)

[Baelavay]

• zur Aktion "Nehmen Links": Sicher, eine Extraanimation für fehlende Standardanimationen zu verwenden ist eben die Notlösung
• Ich frage mich immer wieder, wieso Bools manuell eingetragen werden müssen, Nums/ Strings hingegen nicht. Ich schlage vor, dass das PaCDK bei der Spielerstellung während dem Skriptcheck auch selbst nach angegebenen Bools sucht und diese selbst in eine Liste aufnimmt. Das wäre doch bestimmt technisch möglich, oder?
• Mir ist ein ungünstiger Walkmapkachel-Pixel-Konflikt bei Charakteren aufgefallen: Beim Befehl „walkto()“, welcher sich auf Charakter auswirkt, werden Walkmapwerte angegeben (also bei einer Walkmapabmessung von 32x24 Kacheln 768 Möglichkeiten), im Raumfenster schiebt man seinen Charakter jedoch frei an eine Pixelstelle (das sind bei einer Auflösung von 800x600 unvorstellbare 480000 mögliche Positionen).
  Das Problem, das mir aufgefallen ist, möchte ich anhand eines Beispiels erklären: Stellen wir uns vor, wir möchten einen patrouillierenden Soldat integrieren, der von Punkt A nach B, wieder zurück läuft und das wiederholt. Wir setzen unseren Charakter also im Raumfenster an die gewünschte Anfangsposition der Strecke, die er ein einem „on(loop)“-Ereignis im Raumskript hin- und herlaufen muss (mit „walkto()“). Ich denke, es stellt sich als überaus schwierig dar, den Charakter nach der ersten Tour per „walkto()“-Befehl wieder genau an den Startpunkt laufen zu lassen, dessen Pixelwerte man ja zuvor im Raumfenster festgelegt hat. Der „walkto()“-Befehl akzeptiert aber nur Walkmapwerte.
  Mir sind dazu auch zwei (viel zu komplizierte!) Lösungsmöglichkeiten eingefallen: Die erste wäre eine Division der Pixelwerte des Startpunkts, um die zugehörigen Walkmapkoordinaten herauszufinden. Nachteil: Das Ergebnis ist nur ein Näherungswert, da der Bezugspunkt eines Charakters ebenfalls ein (winziger) Pixel ist und sich so ein Toleranzbereich der Koordinaten innerhalb einer Walkmapkachel ergibt. Soll heißen, wenn 1 Walkmapkachel bspw. 32 Pixel breit und 32 hoch ist (genauer Wert spielt jetzt keine Rolle), so wissen wir immer noch nicht, welcher der 1024 Pixel der einzelnen Kachel der Startpunkt ist.
  Zweite Möglichkeit: Den Charakter gleich bei Betreten des Raums an den gewünschten Startpunkt beamen, so weiß man genau wo er sich befindet, da man ihn selbst mit Walkmapangaben an eine Stelle gesetzt hat und da der „walkto()“-Befehl ebenfalls Walkmapwerte verlangt.
  Mein Wunsch ist anhand des Beispiels und der Tatsache, dass sich der Walkmap-Pixel-Konflikt bei den Charakteren nur derbst schwierig umgehen lässt bestimmt ersichtlich: Es würde für eine präzise Postierung der Charaktere im Raum(-fenster) ausreichen, wenn sich die Charaktere stufenweise, Walkmapkachel für Walkmapkachel, im Raum verschieben lassen würden.

[Zimond]

Ich frage mich immer wieder, wieso Bools manuell eingetragen werden müssen, Nums/ Strings hingegen nicht. Ich schlage vor, dass das PaCDK bei der Spielerstellung während dem Skriptcheck auch selbst nach angegebenen Bools sucht und diese selbst in eine Liste aufnimmt. Das wäre doch bestimmt technisch möglich, oder?

Mhh... joa.. kann man machen.

Zum dritten Punkt : Auf meiner ToDo Liste steht bereits der Punkt "Walkmap Snap-Option einbauen", eine Option im Setup die dafür sorgt das du die Chars nur auf die Walkmappoints bewegen kannst.

Noch mal kurz offiziell wegen dem nächsten Release :

Das kann noch ne Weile dauern weil ich im Moment recht gut mit den Räumen für Alühn 2 vorran komme und diese Strähne nicht unterbrechen möchte, weil, der Wechsel vom Grafikdesign rüber zur Programmierung braucht bei mir im Kopf immer so 2,3 Tage bis es völlig vollzogen ist. Aber meine ToDo Liste geht ja nicht verloren also bitte habt alle weiter Geduld.