Technik - Was ist machbar?

[Macros]

hab ich ja gesagt sie greift nur gegner im sichtradius an

...

Eben das ist sehr umständlich im 2k zu scripten. Im xp könnte man das glaube ich mit RGSS machen, kenne mich mit Ruby aber leider net aus.

Ist es eigentlich möglich jede Taste des Keyboards in den RPG-Maker XP einzubeziehen?
(Hab gedacht passt ganz gut zum Thema...)

...

Nein das passt eigendlich nicht ins thema, das hättest du wenn du dir den Thread durchgelehsen hättest auch bemerkt. Sollte dies aber nicht um Dauerzustand werden, ist das aber net so schlimm.
So viel ich weis, kannst du, ohne RGSS folgende Tasten belegen:
Enter, space, esc, Num0, Shift, A, S, D, Q, W, Z. X, B, V, C.
Die konfiguration kannst du im Spiel, wenn du F1 drückst vornehmen.
Benutzt wird dies dann mit einem Tasteneingabe ereigniss, was das in eine Variabele speicher, die du in einer Bedingung abfragst.

[Nevius]

So ein sichtradius is wirklich easy...

Du vergleichst einfach die Kordinaten der Einheit und von den Gegnern, ist der unterschied 10 oder weniger (wenn der sichtradius jetzt 10 wäre) -> Gegner im Sichtradius

[Phönix Tear]

Hmm, wie du auf 3200 kommst weiß ich nicht so genau. Wollen wir nun einen Sichtradius der tatsächlich ein Sichtradius ist, oder ein Kasten der um die Einheit verläuft? Ein Sichtradius befände sich natürlich nur da wo der Gegner gerade hinschaut, der Kasten eben auf allen Seiten. Aber auch bei dieser Abfrage komme ich gerade mal auf 6 Variablen. Hier das Beispiel (Die Variablen "Gegnerdurchlauf 1/2" ist am Anfang natürlich auf 0):

Code:

<>Lable 1
<>Fork Variable "Gegnerdurchlauf 1", 0 same
<><>Change Variable "Angreifer X" [Armee 1 X-Pos]
<><>Change Variable "Angreifer Y" [Armee 1 Y-Pos]
<>Else:
<>Fork Variable "Gegnerdurchlauf 1", 1 same
<><>Change Variable "Angreifer X" [Armee 2 X-Pos]
<><>Change Variable "Angreifer Y" [Armee 2 Y-Pos]
<>Else:
<>Fork Variable "Gegnerdurchlauf 1", 2 same
<><>Change Variable "Angreifer X" [Armee 3 X-Pos]
<><>Change Variable "Angreifer Y" [Armee 3 Y-Pos]
<>Else:
<>...
<>So jetzt weiter für alle Armeen
<>...
<>End:

<>Fork Variable "Gegnerdurchlauf 2", 0 same
<><>Change Variable "Verteidiger X" [Gegner 1 X-Pos]
<><>Change Variable "Verteidiger Y" [Gegner 1 Y-Pos]
<>Else:
<>Fork Variable "Gegnerdurchlauf 2", 1 same
<><>Change Variable "Verteidiger X" [Gegner 2 X-Pos]
<><>Change Variable "Verteidiger Y" [Gegner 2 Y-Pos]
<>Else:
<>Fork Variable "Gegnerdurchlauf 2", 2 same
<><>Change Variable "Verteidiger X" [Gegner 3 X-Pos]
<><>Change Variable "Verteidiger Y" [Gegner 3 Y-Pos]
<>Else:
<>...
<>So jetzt weiter für alle Feinde
<>...
<>End:

<>Change Variable "Angreifer X" - "Verteidiger X"
<>Change Variable "Angreifer Y" - "Verteidiger Y"

<>Fork Variable "Anrgeifer X" < 0
<><>Change Variable "Angreifer X" * (-1)
<>End:
<>Fork Variable "Anrgeifer Y" < 0
<><>Change Variable "Angreifer Y" * (-1)
<>End:

<>Fork Variable "Angreifer X" < "Sichtradius"
<><>Fork Variable "Angreifer Y" < "Sichtradius"
<><><>Fork Variable "Gegnerdurchlauf 1", 0 same
<><><><>Change Variable "Gegnerdurchlauf 2" + 1
<><><><>Change Variable "Armee 1 Ziel" = "Gegnerdurchlauf 2"
<><><><>Change Variable "Gegnerdurchlauf 2" - 1
<><><>Else:
<><><>Fork Variable "Gegnerdurchlauf 1", 1 same
<><><><>Change Variable "Gegnerdurchlauf 2" + 1
<><><><>Change Variable "Armee 2 Ziel" = "Gegnerdurchlauf 2"
<><><><>Change Variable "Gegnerdurchlauf 2" - 1
<><><>Else:
<><><>Fork Variable "Gegnerdurchlauf 1", 2 same
<><><>...
<><><>So jetzt weiter für alle Armeen
<><><>...
<><><>End:
<><>End:

<>Fork Variable "Gegnerdurchlauf 2" < "Feinde auf dem Feld"
<><>Change Variable "Gegnerdurchlauf 2" + 1
<><>Goto Lable 1
<>Else:
<><>Fork Variable "Gegnerdurchlauf 1" < "Freunde auf dem Feld"
<><><>Change Variable "Gegnerdurchauf 1" +1
<><><>Goto Lable 1
<><>End:
<>End:

So, ich hoffe ich habe nichts vergessen ^^°. Je nachdem auf welcher Seite man schaut muss man nun einfach die Variablen von Freund und Feind vertauschen. Das sollte dann nicht so das Problem sein. Von dem kleinen Wörtchen "Gegnerdurchlauf" sollte man sich nicht verwirren lassen, es gibt beim ersten mal ("Gegnerdurchlauf 1") lediglich an von welcher eigenen Armee man nun die X bzw. Y Werte braucht. "Gegnerdurchlauf 2" beschreibt dann aber tatsächlich, welcher Gegner abgefragt wird.
Einziges Problem an dieser Taktik ist, das so nun (sollten alle Gegner in Reichweite sein) immer nur der letzte angegriffen wird. Eine direkte Abfrage wer nun näher ist, ist also nicht enthalten...
Ich hoffe mal Leute wie Lachsen lesen diesen Thread, denn die finden immer noch so einiges was man vereinfachen kann

mfg
Phönix Tear

[Macros]

So ein sichtradius is wirklich easy...
Du vergleichst einfach die Kordinaten der Einheit und von den Gegnern, ist der unterschied 10 oder weniger (wenn der sichtradius jetzt 10 wäre) -> Gegner im Sichtradius

...

Dann müsstest du aber, wenn jeder 20 Einheiten hat 20x20 also 400 Variabelen berechnungen machen.
Wenn der Sichtradius 10 ist, musst du noch abfragen, ob der der da steht im Umfeld mehr/gleich 1 liegt und gleichzeitig weniger/mehr als 10.
Also alles mahl 2. Nun sind wir bei 800.
Für jede Himmelsrichtug 3200 Berechnungen.

[dadie]

Man brauch exakt 3 Variablen für ein Sichtradius

Hero X , Hero Y , Event Seiten ID bei in sichtfeld

nun prüft man ein script ob irgentein event mit einer ID über X auf einer passenden Koordinate ist , und sätz diese dann das Event auf seite 2 wo dann Alarm drin sein könnte.

Das ganze bräuchte am ende also nur 3 bzw. wenn man es über Temp. Vars lösen will 5 Variablen.Es sind insgesammt 10*10 also 100 Abfragen aber damit müsste ein guter rechner klarkommen.Ich habe ein Sichtfeld script so mit 5*5 gelöst und es ist Super flexibel.

Achja warum ID über X ? Wir haben nicht nur gegner als events im game

[Macros]

Ich verstehe es nicht. Der Hero ist die Maus.
Also weis ich dann, nach dadie ob Einer unter meiner Maus steht
Oder meinst du mit , oder meinst du mit Hero y/x eine Einheit.
Dann weis ich das in der Nähe eines meiner Einheiten ein Gegner is, aber dann weis ich immer noch net genau wo. (welche Himmelsrichtung, welcher abstand).

Kannst du mir das bitte noch mal erklären. Ich weis nämlich nicht wie du auf drei Variabelen kommst. Mit fünf kann ichs noch nachvollziehen.

[dadie]

Code:

<>Var.Set:0001 Hero X : hero X 
<>Var.Set:0002 Hero Y : Hero Y 
<>Var.Set:0003 View_Side : 2 
<>Var.Set:0004 Temp_X_View : 5 
<>Var.Set:0005 Temp_Y_View : 5 
<>Var.Set:0008 Temp_X : 0001 - 0004 
<>Var.Set:0009 Temp_Y : 0002 - 0005 
<>Var.Set:0010 Temp_X2 : 0
<>Var.Set:0011 Temp_Y2 : 0
<>Var.Set:0007 Ene_Event : 5 

<>Cycle



<><>Event.-ID  V[0008] V[0009] V[0006:Event-ID] 

<><><>Fork.Varb[V0007:Ene_Event] < V[0006:Event-ID] 
<><><><>Event.Call V[0006:Event-ID] V[0003:View_Side] 
<><><>END.Fork

<><>Var.Set V[0008:Temp_X] : V[0008:Temp_X] + 1
<><>Var.Set V[0010:Temp_X2] : V[0010:Temp_X2] + 1

<><><>Fork.Varb[V0010:Temp_X2] = V[0004:Temp_X_View] 
<><><><>Var.Set V[0008:Temp_X] : V[0008:Temp_X] - V[0004:Temp_X_View] 
<><><><>Var.Set V[0009:Temp_Y] :  V[0009:Temp_Y] + 1
<><><><>Var.Set V[0011:Temp_Y2] :  V[0011:Temp_Y2] + 1
<><><>END.Fork

<><><>Fork.Varb[V0011:Temp_Y2] = V[0004:Temp_Y_View] 
<><><><>Cycle.Stopp
<><><>END.Fork

<>Cycle.END

So siht in etwa da Code aus für eine abfrage um den Hero ob ein gegner da ist.Wenn ein gegner da ist wird überprüft ob es ein gegner ist mit hilfe der Event ID alle Events mit einer ID über 4 sind gegner.Nun wird dieses gegner event in den zweiten Modus gestartet über die Event seite die wir über :
<>Var.Set:0003 View_Side : 2 bestimmen.

Tja so einfach geht es

[Gekiganger]

Sicher ist ein Nachteil von Phönix Tears System, dass jede Einheit separat behandelt werden muss und der Code so mit jeder zusätzlichen Einheit anschwillt.

Da sieht dadies System dann doch viel übersichtlicher aus. Allerdings wird bei seinem System, bei einem 5x5 Felder großen Sichtfeld, ständig eine Fläche von 121 Felder durchgegangen, ohne dass sich darauf eine gegnerische Einheit befinden muss (die [0/x],[x/0],[0/0] Felder nicht vergessen!!).
(BTW dadie, schau mal die temporären Zähler an, die würden, so wie du es im Code angegeben hast, nach der 2. Zeile unendlich nach rechts wandern)

Hier werden wiederum bei Phönix's System nur die Einheiten, die auch wirklich existieren, berücksichtigt, was es, obwohl das Skript größer ist, gegenüber dadie's, performanter macht.
Und Performanz ist das, was man bei einem solchen Projekt am meisten beachten sollte.


Da beide Systeme ihre Vor- und Nachteile haben, schlage ich einen Mix aus beidem vor.
Es werden nicht die Felder, auf denen sich ein Event möglicherweiße befinden könnte abgefragt, sondern die Positionen der Einheiten direkt. Allerdings werden diese nicht statisch im Code angegeben, sondern auf sie wird verpointert.

Das ganze könnte so aussehen: <Parallel Process oder Autostart Event>
(wem es zu unübersichtlich ist, sollte die Kommentare herauslöschen)

Code:

//setzen: Eventbereich (Etart/Ende) der Einheiten
<>Variable Oper: [0001:$_fUnits startIndex] Set, 2
<>Variable Oper: [0002:$_fUnits endIndex] Set, 3
<>Variable Oper: [0003:$_eUnits startIndex] Set, 4
<>Variable Oper: [0004:$_eUnits endIndex] Set, 5
//setzen: Startpointer auf Einheitenkoordinaten
<>Variable Oper: [0012:$_fUnits Pointer] Set, 7
<>Variable Oper: [0013:$_eUnits Pointer] Set, 9
setzen: Koordinaten-Eventseite auf Einheiten
<>Variable Oper: [0014:$_units Coords Page] Set, 2
//setzen: sichtradius (quadratisch um Einheit)
<>Variable Oper: [0015:$_units Vision Size] Set, 5
//Zähler mit Startwerten initialisieren
<>Variable Oper: [0005:&_friendly index] Set, Var [0001:$_fUnits startIndex]'s Value
<>Variable Oper: [0006:&_enemy index] Set, Var [0003:$_eUnits startIndex]'s Value
//Zählschleife durch eigene Einheiten
<>Loop
  //Zählschleife durch gegnerische Einheiten
  <>Loop
  	//Pointer auf Koordinaten der eigenen Einheiten setzen
	<>Variable Oper: [0011:%_units KoordsPointr] Set, Var [0012:$_fUnits Pointer]'s Value
	//Koordinaten von eigener Einheit in Variablen, auf die Pointer referenziert, speichern
	<>Call Event: V[0005:&_friendly index][V[0014:$_units Coords Page]]
	//Pointer auf Koordinaten der gegnerischen Einheiten setzen
	<>Variable Oper: [0011:%_units KoordsPointr] Set, Var [0013:$_eUnits Pointer]'s Value
	//Koordinaten von gegnerischer Einheit in Variablen, auf die Pointer referenziert, speichern
	<>Call Event: V[0006:&_enemy index][V[0014:$_units Coords Page]]
	//Koordinaten gegnerischer Einheiten von Koordinaten eigener Einheiten abziehen, um Abstand zu ermitteln
	<>Variable Oper: [0007:fUnit X] -, Var [0009:eUnit X]'s Value
	<>Variable Oper: [0008:fUnit Y] -, Var [0010:eUnitY]'s Value
	//negative Werte unerwünscht, daher auf absoluten Wert umwandeln
	<>Branch if Var [0007:fUnit X] is 0 Less
	  <>Variable Oper: [0007:fUnit X] *, -1
	: End
	<>Branch if Var [0008:fUnit Y] is 0 Less
	  <>Variable Oper: [0008:fUnit Y] *, -1
	: End
	//prüfen, ob gegnerische Einheit im Sichtradius der eigenen Einheit liegt (==> ermittelter Abstand muss <= Sichtradius sein)
	<>Branch if Var [0007:fUnit X] is V[0015:$_units Vision Size] Less/Equal
    	  <>Branch if Var [0008:fUnit Y] is V[0015:$_units Vision Size] Less/Equal
      	    //gegnerische Einheit wurde gesichtet
	    Message: Friend \v[5] (Event ID) spots Enemy \v[6] (Event ID)
	  : End
	: End
	//gegnerische Einheiten Zähler um 1 erhöhen
	<>Variable Oper: [0006:&_enemy index] +, 1
	//prüfen, ob gegnerische Einheiten Zähler letzten Gegner durchlaufen hat
	<>Branch if Var [0006:&_enemy index] is V[0004:$_eUnits endIndex] Greater
    	  //gegnerische Einheiten Zähler auf Startwert resetten und Zählschleife durch gegnerische Einheiten beenden
	  <>Variable Oper: [0006:&_enemy index] Set, Var [0003:$_eUnits startIndex]'s Value
	  <>Break Loop
	: End
  : End Loop
  //eigene Einheiten Zähler um 1 erhöhen
  <>Variable Oper: [0005:&_friendly index] +, 1
  //prüfen, ob eigene Einheiten Zähler letzte eigene Einheit durchlaufen hat
  <>Branch if Var [0005:&_friendly index] is V[0002:$_fUnits endIndex] Greater
    //Zählschleife durch eigene Einheiten beenden
    <>Break Loop
  : End
: End Loop

Aufmerksame Leser werden sich nun fragen, woher denn die Koordinaten zu den Einheiten kommen.
Nun, diese werden im Event der Einheit direkt gesetzt.
Dazu wird im Event der Einheit eine neue Seite erstellt. Diese wird durch einen Switch gesperrt. Da dieser Switch nur zum Sperren dient und im Spiel NIEMALS angeschaltet wird, kann er ebenso für alle weiteren Eventseiten in anderen Events, die gesperrt bleiben sollen, verwendet werden.

Diese Seite enthält folgenden Code: <Push Key>

Code:

<>Variable Oper: [V[0011:%_units KoordsPointr]] Set, This Event X Coord.
<>Variable Oper: [0011:%_units KoordsPointr] +, 1
<>Variable Oper: [V[0011:%_units KoordsPointr]] Set, This Event Y coord.

So hat man sogar einen kleinen, objektorientierten Ansatz mit eingebracht, auch wenn das wohl eher eine Vergewaltigung des Begriffes ist. ^^'


Noch ein paar Erklärungen zu den Variablen:

Code:

0001:$_fUnits startIndex		//Bereich eigener Einheiten (Index beschreibt Event ID) -> Startindex
0002:$_fUnits endIndex			//Bereich eigener Einheiten (Index beschreibt Event ID) -> Endindex
0003:$_eUnits startIndex		//Bereich gegnerischer Einheiten (Index beschreibt Event ID) -> Startindex
0004:$_eUnits endIndex			//Bereich gegnerischer Einheiten (Index beschreibt Event ID) -> Endindex
0005:&_friendly index			//Iterator, zählt von 0001:$_fUnits startIndex bis 0002:$_fUnits endIndex
0006:&_enemy index			//Iterator, zählt von 0003:$_eUnits startIndex bis 0004:$_eUnits endIndex
0007:fUnit X				//X Koordinate einer eigenen Einheit (in ihr wird auch Abstand zwischen eigener und gegnerischer Einheit gespeichert)
0008:fUnit Y				//Y Koordinate einer eigenen Einheit (in ihr wird auch Abstand zwischen eigener und gegnerischer Einheit gespeichert)
0009:eUnit X				//X Koordinate einer gegnerischen Einheit
0010:eUnitY				//Y Koordinate einer gegnerischen Einheit
0011:%_units KoordsPointr		//Pointer, über dessen Wert die Koordinaten der Einheiten in die jeweiligen Variablen geschrieben werden
0012:$_fUnits Pointer			//Pointerstartbereich für die Koordinaten der eigenen Einheiten (0007:fUnit X)
0013:$_eUnits Pointer			//Pointerstartbereich für die Koordinaten der gegnerischen Einheiten (0009:eUnit X)
0014:$_units Coords Page		//Nummer der Eventseite in den Einheiten, in denen sich der Code zum setzen der Koordinaten befindet
0015:$_units Vision Size		//quadratisch angegebene Größe des Sichtbereichs der Einheiten in Felder

Vorangestellte Zeichen:

$ = statisch (werden zur Laufzeit nicht mehr verändert)
% = Pointer/Zeiger
& = Index/Zähler/Iterator

[Nevius]

Hat sich ja viel getan seit ich das letztemal in den Thread geguckt habe 8)

Mit sichtradius ist natürlich ein Kasten gemeint, also das die Einheit sozusagen auch nach hinten sieht, wäre ja Blöd wenn eine Einheit nicht regiert nur weil der Gegner hinte rihr ist

Da ja schon einige Scripte für einen Sichtradius gepostet worden sind, ist dieses Prolbem nun auch gelöst!

Wie findet ihr denn meinen Vorschlag für das KS den ich weiter oben schon gepostet habe? Also mit Pathfinding zu gegnerischen einheit -> angriff.

Wäre natürlich aufm XP besser umsetzbar!

[Phönix Tear]

Spontan falen mir 6 Gründe ein, warum wir eine Einheitenbegrenzung brauchen:

- Wir verwenden als Einheit jeweils ein Event, welche wir vorher haben müssen und nicht nach belieben erstellen können
- Pathfinding ist so schon recht komplex, wenn zu viele Einheiten auftauchen wird es sehr, sehr schwer werden
- Kämpfe dürften im normalen Bildschirm mit vielen Einheiten sehr schwer zu machen sein, sowie auch recht unübersichtlich und schwer zu steuern
- Es wirkt zwar so als wäre der Bildschirm recht groß, trotzdem lässt er sich sehr leicht mit einzelnen Einheiten überfüllen was die Übersichtlichkeit einschränkt
- Viele Einheiten brauchen unglaublich viele Variablen die wir alle einzeln einstellen müssen (außer wenn wir sie per Nummer zuweisen)
- Mit ergänzenden Scripten wie z.B. für die Rahmen kann das sehr Ressourcen fressen werden (denkt ans KS)
- Mehr fällt mir jetzt nicht ein

Den ein oder anderen könnte man umgehen. Das Problem mit den Variablen z.B. mit Zuweisungen per Variablen Nummer, trotzdem können wir so nicht unendlich viele Einheiten aufstellen, da sonst die Abfrage zu kompliziert wird (Rahmen und KS). Der ein oder andere Punkt spricht auch noch dafür, das wir garnicht so viele Einheiten haben wollen. Ich wäre bei sowas immer noch dafür ein eigenes KS aufzubaun. Die Frage ist nur wie wir das verbinden. Ein echtzeit Strategiespiel basiert ja auch darauf das man seine Einheiten umher schickt und diese dann angreifen können, ohne das man einen extra Kampfmodus braucht (sonst hätten wir ja sowas wie bei "Heros of Might and Magic"). Wir sollten uns (imo) eher damit beschäftigen wie wir ein ordentliches KS mit wenig Einheiten umsetzen, anstatt uns darüber den Kopf zu zerbrechen wie viele wir einbringen können.
Es muss ja nicht immer nur durch weitere Events geregelt werden. Auch Regeln im Spiel können da abhelfen (automatische Zustellung neuer Truppen zu einer bestehenden Armee, etc.). Am Ende sollte nur etwas zustande kommen, dass einem Spaß macht, es zu spielen. Natürlich ist (momentan) unser Augenmerk erstmal darauf gerichtet, wie man neue technische Probleme am besten mit dem Maker löst, aber einige haben ja angesprochen das da am Ende was gutes bei rauskommen soll, also müssen wir uns früher oder später auch um die Wünsche der Spieler kümmern. Aber wie gesagt: Alles zu seiner Zeit
Ich würde im Moment gerne von euch hören wie ihr überhaupt gedenkt das KS umzusetzen... Jetzt nicht direkt das Problem mit dem Pathfinding, eher wie es generell laufen soll...

mfg
Phönix Tear

[Macros]

Zitat von: Nevius
So hab nun mal n kleines script für den Rahmen im 2k geschrieben.

...

Ich habs getstet und ich denke, dass das wohl die beste Methode ist. Habe jedenfalls keine Mängel festgestellt.
Tolle Arbeit.

ich glaub wir diskutierne nur aber ich fänds cool wenn was dabei rauskäm

...

Jo, irgendwie fände ichs auch cool. Es wollte ja mal Jemand ein Echtzeitstrategiespiel machen, aber ich denke es liegt auf Eis.
Es könnte ja zum Schluss in einem Reisenproject, wie Metropolis enden.
Also das jeder der will, nach dem was im Thread steht etwas scriptet und wir das dann zusammenfügen.
Is natürlich nur eine Idee nebenbei.

[Macros]

Ich habe mir das Script im Maker noch nicht angeschaut, aber die Fehler die auftreten, hängen doch damit zusammen dass man momentan nur ein Feld von 3x3 tiles ziehen kann. Dieses Script war wohl auch mehr zur demonstration gemacht. Wenn es so ausgereift ist, dass man den Ganzen Screen ausfüllen kann, scriptet man einfach noch dazu, dass man nicht weiter raus kann, solange mann einen Rahmen zieht.

Zur unvollständigeit des Scripts und dessen Zweck der Veranschaulichung zitiere ich folgendes von Nevius:

Linke Maustaste drücken und man kann einen Rahmen ziehen. Der Rahmen darf nur 3x3 Tiles gross sein, sonst verschiebt er sich (das verschieben kann man auch wegmachen). 3x3 maximal ist es weil ich zu faul war um mehr zu scripten (is ja auch nur ne demonstration), ginge Problemlos auch nen Rahmen der den ganzen Screen ausfüllt. (wäre halt bissel aufwendig, aber wenn ihrs braucht für n game mach ichs gern) Script dürf ihr gerne erweitern oder verbessern (postet es dann mal hier).

...

Ausserdem braucht man bei deiner Methode vier Pics, hier nur eins. Man müsste sehen wie deine Version aussieht, jedoch stelle ich mir das etwas unkonfortabler vor.

[Nevius]

Macros hat eigentlich schon alles gesagt, ich möchte es aber noch gerne bestätigen:

Mein Rahmen-Script ist nur für einen Rahmen von 3x3 gedacht, nur zur demonstration... Es funktioniert problemlos denn ich habe es la nge genug getestet... Wie Makros gesagt hat müsste man dann einfach das Scrollen unterbinden und das Rahmenscript auf 20x15 erweitern... (wäre halt n bischen arbeit aber in 2 tagen hat man das auch... wenn nicht weniger!)

Direktes vermeiden von Fehlern -> Find ich gut, sollten wir so machen!

Dein Rahmen -> Mach doch mal ne demo, kann mir net so vorstellen wie du das scripten willst... wäre wahrscheinlich noch umstänlicher als meins!