Vorschläge für nächste Version

[Zimond]

ja über so einer Beschränkung hab ich auch schon nachgedacht da im Regelfall eh keiner hingehen dürfte und ein Objekt größer als 512x512 drehen möchte. Aber auch das wird nicht mal eben eingebaut sein, ich habs aber notiert weil ichs selber ganz cool fände.

[UrsVomUranus]

Ich bitte dich nochmal über den hinterlegten Text nachzudenken (Rechteckiger, einfarbiger Hintergrund für Textausgaben) - wg besserer Lesbarkeit.

[Wuji]

was auch noch ganz schön wäre ist das man beim timerbefehl { } diese klammern dran hängen kann.
bis jetzt geht doch nur :

timer(3)
setobj(Ka;0)
timer(3)
setobj(Ka1;1)

ich wills aber so:

timer(3)
{
setobj(ka;0)
setobj(ka1;1)
}

[Schiman]

ich wills aber so:

timer(3)
{
setobj(ka;0)
setobj(ka1;1)
}

Nur so als Bekräftigung . Dieser Vorschlag ist auch ziemlich sinnvoll.

[sley43]

Hallo Zimond,

ich habe da ein Problem bei meinem Projekt und möchte daher Fragen ob du da eine kleine Erweiterung in das P&C DK einbauen könntest in einer zukünftigen Version.

Es geht darum das ich den beamto Befehl auch für Objekte bräuchte, da ich Nebenfiguren die nur stark begrenzt animiert sind auch in anderen Räumen herbeirufen möchte. Ich kann ja nicht das Objekt in jeden Raum kopieren nur weil er dann irgendwann vielleicht gebraucht wird. Ausserdem habe ich das Objekt mehrfach in wiederholenden Scripten mit dem Namen verewigt, eine Namensänderung des Objektes macht meine Scripte zunichte. Alle Nebenfiguren als Charaktere zu erstellen halte ich für keine gute alternative.

Hoffe mein Problem ausreichend erklärt zu haben, ich denke das ein beamto für Objekte für jedermann von interesse sein könnte.

MfG,

Christian

[Zimond]

Alle Nebenfiguren als Charaktere zu erstellen halte ich für keine gute alternative.

Ich halte das für überhaupt keine Alternative sondern den eigentlichen Weg wie man es macht. Was gibt es daran auszusetzen? Die Größe ist beinflussbar, es wird automatisch gesprochen und es wird automatisch Text generiert. Alles was bei einem Objekt simuliert werden müsste. Der einzige Vorteil eines Objektes könnte daran liegen das man 10 statt 4 konstante Zustände einstellen kann. (damit sind die 4 richtungen gemeint, wenn ein Char anders aussehen soll einfach per Lookto umändern ob stehen Rechts auch tatsächlich einen Charakter im Profil zeigt oder nicht spielt bei stehenden nicht laufenden Chars eh keine Rolle.

[sley43]

Hallo Zimond,

danke erstmal für die Antwort, nur beschränkt die sich extrem auf Charaktere und weniger auf die Aufhebung der Beschränkung das man nur besondere Objekte (Charaktere) beamen kann.

Jetzt mal etwas genauer auf mein Projekt bezogen brauche ich das in erster Linie für Gegner die hier und da mal auftauchen müßen und eben nicht groß spazieren gehen oder reden. Wenn ich die bewege als Objekt verändern die nicht den Zustand, sondern nur wenn ich das sage, Charaktere ändern aber automatisch ihre Zustände sobald eine Bewegung stattfindet.

Ein anderes Beispiel wären Spezialeffekte für Magieangriffe die ich ebenso hier und da nach Laune mal benutzen möchte unabhängig von einem Charakter, verfügbar für alle Charaktere an allen Orten. Soll ich da auch lustige Blitz, Feuer, Wasser, ... "Charakter Objekte" erzeugen wegen der Beschränkung für normale Objekte?

Workarounds sind ok wenn eine leichtere Alternative zu schwer zu integrieren ist in das Tool, aber ist das hier wirklich schwer einzubauen? Ich kann das nicht beurteilen aber es scheint hier nur eine Begrenzung zu sein für einen vorhandenen Befehl.

Es sollte klar sein das das Auflösen einer Beschränkung fast nie nur einen Vorteil bringt sondern viele noch nicht erkannte. Nachteile würde es garkeine bringen, nur neue Möglichkeiten eben.

Also sollte es ein simpler Eingriff sein, wäre ich weiterhin für diese Erweiterung ansonsten muß ich wohl gewisse Objekte (Element Gegner z.B.) als Charakter Objekt erstellen.

MfG,

Christian

[Baelavay]

Vorweg: Ich würde einen "BeamObjTo()"-Befehl auch gern sehen. "Nachteile würde es garkeine bringen, nur neue Möglichkeiten eben." - sehe ich genauso. Klar sollen nicht alle erdenklichen Befehle hinzugefügt werden, um die Skriptsprache übersichtlich zu halten, aber dies wäre ja im Grunde eine Erweiterung des "beamto()"-Befehls. Und praktisch obendrein.

Aber ja, es gibt wie immer Umwege, die zum Ziel führen. Anstatt die Objekte hin- und herzubeamen, kann man mehrere Instanzen in unterschiedlichen Räumen einfügen.

Übrigens, du sagtest, du verwendest Objekte als Charaktere, weil beim PaCDK die Charaktere beim Bewegen andere Zustände annehmen, also sich optisch verändern. Aber das liegt doch ganz bei dir! Eine Animation findet nur statt, wenn mehr als ein Frame eingefügt werden. Wenn die Charaktere also sowohl beim Stehen als auch beim Laufen gleich aussehen sollen, dann fügst du in den Status "Stehen" das gleiche Bild ein wie in den Status "Laufen".

[Schiman]

Und noch was: Wenn du einfach Effekte realisieren willst, kannst du das auch mit dem Überallraum und mit Objekten auf dem Überallraum. Die kannst du dann nach belieben verschieben, animieren usw.

[sley43]

Danke für die Tips. Klar gibt es Workarounds, nur sind diese eben aufwendiger und nicht gerade hoch motivierend.

Mit einem Subroom hatte ich z.B. große Probleme, da Positionen falsch waren wenn der eigentliche Raum andere Maße hatte wie der Subroom. Weiß nicht mehr genau was das war, aber ich konnte keine Harmonie zwischen den beiden Räumen kriegen (im Bezug auf Positionen), wegen verschiedenen Größen.

Das ich bei Charakteren natürlich selber bestimmen kann welche Bilder sichtbar werden wenn ich kreativ bin ist mir klar, aber ich finde das schon sehr extrem und werde das nur gezwungener Maßen nutzen, wenn die beam Objekt Integration abgelehnt wird, weil eine Änderung zu aufwendig ist im Verhältnis zum Nutzen des Befehls.

Man kann tatsächlich durch Workarounds ganz tolle Sachen machen die aber eben ganz normal nicht möglich sind und viele neue Nutzer abschreckt oder eben einfach nur einschränkt.

Ich kann also natürlich auch ohne den Befehl mit meinem Projekt weitermachen nur wird alles komplizierter und das kann ab einer bestimmten Größe und Umfang des Spiels fatal werden. Wie es zur Zeit aussieht bin ich eh am Zweifeln ob die ganzen Limits des Programms für mich ausreichen werden oder ich noch weiter kürzen werden muß.

Also für mein Projekt wäre der neue beam Befehl weiterhin von großem Vorteil, weil er eben vieles stark vereinfachen würde.

Christian

[Schiman]

Hm.. also mich hat bisher gar nix abgeschreckt. Ich bezweifle irgendwie, dass dein System komplexer ist, als der Stuboter z.B.. So ist es nunmal beim Scripten oder Programmieren, dass man immer etwas haben will, was nicht da ist. Das muss man sich halt selber basteln oder irgendwie umgehen. Damit muss man leben und gerade das macht die ganze Sache ja zu einer spannenden Herausforderung.

Gut, das soll jetzt nicht heißen, dass ich gegen so einen Befehl bin. Im Gegenteil, nur die Grundeinstellung sollte irgendwo vorhanden sein.

Glaubst du im AGS oder so ist das einfacher??

[sley43]

Hallo Schiman,

Leute sind verschieden für die einen ist es eine Herausforderung während der andere direkt kapituliert.

Ich arbeite an meinem Projekt in erster Linie aus Spaß am entwickeln und erschaffen, also ohne Drang das Spiel so schnell wie möglich zu veröffentlichen, daher habe ich das ganze recht grenzenlos geplant und muß nun diese aber nachträglich einbauen.

Als ich gesagt habe das ich nicht sicher bin ob die Prog Limits für mein Projekt ausreichen, habe ich nicht die Qualität eines Script Systems gemeint sondern einfach die Quantität von benötigten Elementen die allesamt begrenzt sind.

Ich bin mir sicher das du mit den Scripten viel besser klarkommst wie ich und dadurch auch die besseren Scripte schreibst, nur genau das heißt das ich eben durch simplere Scripte eine größere Anzahl brauche. Und alles was diese bereits hohe Anzahl noch weiter erhöht versuche ich zu vermeiden, daher mein Wunsch nach dem Objekt beam.

Ich versuche auch nicht komplexe Systeme zu erschaffen sondern möchte einfach nur eine Idee verwirklichen.

Wenn ich glauben würde das ein anderes Prog mein Projekt einfacher verwirklichen könnte, hätte ich schon lange gewechselt. Nein ich bin mit dem P&C DK sehr zufrieden und die Nutzung macht Spaß, aber wenn ich eben eine geschlossene Tür finde, dann frag ich zuerst nach einem Schlüssel, bevor ich einen alternativen Weg suche.

MfG,

Christian

[Wuji]

Ich weiss nich aber ich könnte einen schönen Befehl gebrauchen und der wäre hilfreich um das Strategiespielgenre in PACDK besser zu skripten.

Movechar([WalkMousex];[Walkmousey];0)

Mit Walkmousex meine ich festgelegte Variabeln Die Das Objekt immer an den Naheliegenden Punkt moven.
Wie der Kreis (Der mit den 3 Größen) der beim Kennzeichnen des Walmap an die Maus gebunden ist. Der Skript wäre der gleiche.
Movechar ist eher unwichtig. das kann man mit Linkobj umgehen

[Schiman]

Das kannst du doch locker berechnen. Dazu brauch man doch keine extra Variablen...

[Wuji]

ich weiss aber bei mir kommen auch manchmal Fehlermeldungen mit
bla bla bla ist kein Walkmap punkt

Aber sag mir wie du das machen würdest

[Schiman]

Noch ein kleiner Vorschlag:
Es ist ja möglich, dass man bei lookto auch Charakternamen eingeben kann, auf die dann gelookt wird.
Es wäre gut, wenn man auch Objektnamen eingeben könnte und dann in Richtung von Objekten looken könnte.

Ich habe zwar schon selbst eine Hilfsfunktion geschrieben, die das erledigt, aber es wäre einfach komfortabel^^.

Hier übrigens die Hilfsfunktion, falls das noch jemand braucht:

Code: Select all

setnum(ObjectX;[objx:Objektname])
  setnum(ObjectY;[objy:Objektname])
setnum(Yselbst;[chary:LeonMaske]-[ObjectY])
setnum(Xselbst;[charx:LeonMaske]-[ObjectX])
setnum(minus;0-1)
(*Quadrant links*)
 if_num(Xselbst;<[minus]*[Yselbst])
  if_num(Xselbst;<[Yselbst])
    {
     lookto(self;3)
     break()
    }

(*Quadrand rechts*)
 if_num(Xselbst;>[Yselbst])
  if_num(Xselbst;>[minus]*[Yselbst])
    {
     lookto(self;4)
     break()
    }
    
(*Quadrant unten*)
 if_num(Xselbst;>[minus]*[Yselbst])
  if_num(Xselbst;<[Yselbst])
    {
     lookto(self;2)
     break()
    }

(*Quadrant oben*)
 if_num(Xselbst;<[minus]*[Yselbst])
  if_num(Xselbst;>[Yselbst])
    {
     lookto(self;1)
     break()
    }
    
 if_num(Xselbst;>0)
  lookto(self;4)
 if_num(Xselbst;<1)
  lookto(self;3)

Det funzt^^.

[Scarabaea]

ich finde das bei einem objekt irgendwie unsinnig. ein charakter bewegt sich ja, aber bei einem objekt kann ich doch einfach die zahl angeben.

[Schiman]

nicht, wenn du dich drumherum bewegen kannst und bei einem Klick auf das Objekt draufschauen willst, ohne den Char auf eine feste Position zu bewegen.

Bei mir ist es zum Beispiel so, dass ich sogenannte "Statisten", also Chars, die keine Funktion haben, die nur einfach rumstehen, sitzen oder sonstwas machen, als Objekte realisiere. Als Chars will ich nicht, weil Chars so unhandlich sind und ich Objekte einfach aus und einblenden kann, wie es mir beliebt.

Und es ist so, dass man auf diese Person klickt und dabei schaut der Charakter auf die Person, läuft aber nicht hin, weil das bei Statisten ja sinnlos wäre. Wenn du dir eine Person im Geschäft anschaust, dann läufst du ja auch nicht direkt vor die Person und schaust sie dir dann an, sondern du betrachtest sie mehr aus der Ferne, unauffällig.
Deshalb ist die Funktion notwendig.

Es gibt noch zahlreiche andere Anwendungsbeispiele, bei beweglichen Objekten z.B.

MfG,
Schiman

[Scarabaea]

ok, das hat mich überzeugt^^

[Zimond]

mich aber nicht

Ich sehe da ein Problem. Ein Charakter ist eine geradelinige Sache (in der Regel meistens) mit einem Fusspunkt. Man kann also ca. bestimmen wohin man blicken muss um ihn anzuschauen. Ein Objekt hat Pixelkoordinaten und eine Größe aber wo dort im Objekt nun tatsächlich der Punkt ist den ein Char anschauen kann hängt doch von den verwendeten Grafiken ab. Wenn die z.B ihren eigenen Schatten mitbringen ist der tatsächliche Mittelpunkt weit weg von der Mitte.

Das Problem mit den beweglichen Objekten seh ich ein ändert aber nichts an der schweren bestimmbarkeit. Sinnvoll ließe sich das nur machen wenn Objekte einen Mittelpunkt zugewiesen bekämen und das geht dann über den Nutzen hinaus.

[Schiman]

Hm, da hast du wohl recht...
Ok, dann behelfe ich mir eben mit Hilfsfunktionen^^.

[sley43]

Hallo Zimond,

ich habe gerade angefangen "Ceville" zu spielen und mir sind dort auch die Ladescreens aufgefallen, die es ja in sehr vielen Spielen gibt. Ich habe recht lange Ladesequenzen in meinem Projekt und auch noch recht häufig, da wäre eine Option für das Einfügen von gezielten Ladescreen bei Raumwechseln von großem Vorteil. Dort koennte man Textinfos und Bilder einbauen die die Story erweitern oder kleine Tipps und Tricks erwaehnen. Um sicher zu gehen das das Bild nicht zu kurz eingeblendet wird bei kurzen Ladesequenzen koennte man optional eine Mindest-Zeit angeben fuer die Einblendung des Screens.

Mit einem z.B. set_loadscreen (RoomX;BildX;Zeit) im Startscript waere ich schon sehr zufrieden. Und da es sich hierbei nur um ein Standbild handelt wird es auch keine Probleme geben wie mit der Ladeanimation bei dem Mauszeiger.

Die Mauszeiger Animation die fuer Ladesequenzen zur Zeit nutzbar ist geht ja gar nicht richtig, da sie staendig einfriert oder ruckelt.

Ich denke das diese Idee fuer fast jedes Projekt von Vorteil waere. Wenn es diese Idee schon gab und abgelehnt wurde, kann man meinen Beitrag hier gerne loeschen.

MfG,

Christian

P.S. Und danke fuer die staendigen Verbesserungen des P&C DKs.

[Schiman]

Das halte ich für eine sinnvolle Idee. Dadurch kann man vielleicht diese Fehler beim Raumladen auch vermeiden.
Der Raum ist vielleicht noch gar nicht richtig geladen, aber die on(enter) skripte laufen schon und dann spricht der Char zu früh oder läuft schon rum, obwohl der Raum noch gar nicht angezeigt wird.
Ich muss bei großen Räumen auch immer einen wait in die on(enter) cutscenes einbauen, damit diese Fehler nicht auftreten.

Wenn das möglich ist, dann ist das doch was für die Version 3.0 . (Da gehört schließlich was revolutionär neues rein ).

[Zimond]

- Das ist technisch so nicht möglich. Das Laden der Grafiken führt zwangsläufig zu einem Freeze. Deswegen hängt da auch der Mauszeiger. Sowas läßt sich nur verhindern in dem man einen eigenen Thread programmiert der für das Laden zuständig ist, das hab ich auch schon probiert nur war das Ergebnis (obwohl generell erst mal funktionierend) sääähr bug anfällig was in der Natur von Thread Programmierung liegt wenn man diese nicht wirklich von Anfang an einplant.

Das heißt während des ladens kann nicht noch was anderes geladen und angezeigt werden!

Ihr könnt was an annäherndes per Umweg erreichen :

- Erstellt euren Ladescreen (nur statisches, animiertes würde stillstehen) innerhalb des Überall Raumes und gruppiert diesen mit group()
- In die Walkmapstelle wo eigentlich nur der Beamto Befehl reinkommt dann :

Code: Select all

setfocus(none)
setstring (laderaum ; hier der raumname zu dem es gehen soll)
beamto (charname ; [laderaum] ; x ; y ; look)
function (ladebild)

Der Fokus muss auf none stehen damit nach dem beamto nicht automatisch der neue Raum geladen wird, daher kann bei beamto auch kein self stehen. Bei mehreren Chars müsst ihr also mit if_ischar mehrere Beamto's benutzen.

Die Funktion dann :

Code: Select all

unloadroom ()
wait(1)
setobj (ladebild_gruppe ; 1)
wait(0,2)
loadroom ([laderaum])
setobj (ladebild_gruppe ; 0)
wait(0,1)
setfocus(last)

Die Funktion ist dann immer die gleiche nur die Walkmappunkte müssen einzeln gemacht werden (aber muss ja sowieso) Das wait(0,2) ist nötig damit der Freeze des Raumladens nicht schon eintritt bevor die Ladebildgruppe angezeigt werden konnte.


PS : Nur zur Info, Version 3.0 wird es niemals geben. Wenn Alühn 2 fertig ist mach ich aller höchstens noch alle Langpunkte der ToDo Liste weg was dann 2.9.9 wird. Und ab da gibts dann nur noch bei schwerwiegenden Fällen Bugfixes in Form von 2.9.9a usw. Weil, ich möchte danach einfach mal wieder was komplett anderes machen. Das ich mit dem Konzept von PaC-DK begonnen hab is nu fast schon fucking 5 Jahre her.

PPS : Fehler beim Raumladen? Das einzige was passieren kann ist das Chars nachgeladen werden und dann schon das on(enter) angefangen hat. Das läßt sich nur die Speicher Resistent Einstellung und einem loadchar vorweg vermeiden.

[sley43]

Hallo Zimond,

danke für die Antwort und die Workaround Idee.

Möchte aber nochmal fragen ob die beam Objekt Erweiterung nun auch sicher auf der "Nee du" Liste steht oder doch noch bis Version 2.99 reinkommt?

Dein Statement das es die Version 3.00 nie geben wird, fand ich jetzt aber etwas hart formuliert, da du damit ja das langsame zu Grabe tragen des P&C DKs ankündigst.

Finde das sehr schade, kann es aber auch etwas verstehen.

MfG,

Christian