Ich möchte nur ein Piratenschiff damit scripten indem ich XYZ bei projectile die position angebe (was ich nicht weiß wie)
Die Position des Piratenschiffes...? Kriegst du per
- $x=getx("self");
- $y=gety("self");
- $z=getz("self");
im Skript des Schiffes (beim entsprechenden Event... je nachdem).
dann stein verschießen per Id 23 dann ein bischen mit den parametern geschw., angriff und Drag rumspielen dann mit 4 angeben das ich abgeschoßen werden soll und zu guter letzt beim abfeuern eine Msg Boom am rand erscheint und Explosionsgeräusche zu hören sind(das kreig ich glaube ich noch hin aberdann versage ich damit es in das schussscript richtig einzubinden.
Ich würde das zwar hinkriegen... aber beim entsprechenden Skript würde ich auch erst noch einmal mit den ganzen Parametern erstma herumexperimentieren müssen.
Wie Quester schon sagte... einfach die vierte (oder fünfte?) Karte des Abenteuers mal in den Editor laden. Bei den Bambustürmen müssten so ein paar Fähnchen (Infoobjekte) in der Nähe sein wo so ein beispielhaftes Skript drinsteht. Da mal gucken und ein bisschen experimentieren.
Oh und bitte bis zum 12.10 antwoeten ab dann ist wieder schicht und mein Pc ist weg.
Dies soll weder drohung noch unterdrucksetzen sein nur muß ich nur um eure antwort zu lesen elendig lange warten. :cry_fox:
Uff... bin
relativ selten im Netz... *sry*
Äääh Division? Wie geht Division in Stranded scripts eigentlich? Im Tutorial von Unrealsoftware steht da nix davon ^^u
per "/", also bspw.
ja das mit dem durch 100.0 teilen statt durch 100 kam mir dann auch... da hat man mal in seiner jugend angefangen mit delphi und kriegt das einfach nicht in seinen schädel, dass es in C dann eine integerdivision ist, statt gleitkomma...^^ mit gleitkommadivision siehts dann auch schon n stück besser aus...
Unabhängig von der Notation ("100 oder 100.0") sollte eigentlich stets in float (fließkommazahl...) gerechnet werden. Normalerweise wird sowas ja bei der Deklaration von Variablen entschieden, bei Stranded (allgemein Skriptsprachen?) gibt es das nicht.
wenn mans genau nimmt, wäre ne gauss funktion besser geeignet als ne umgekehrte parabel 
^^. wegen tangentialem abschluss zum ebenem boden statt schnittpunkte... aber das sind wohl details... 
Stimmt! Daran hatte ich gar nicht gedacht... :roll:
was anderes: hab mir n script gebastelt das einen jahreszeitenwechseln einfügt. eigentlich macht es auch genau das was es soll: jahreszeiten wechseln, im winter gehen früchte und getreide kaputt. und palmen erleiden aufgrund des klimas schaden (wobei ich bei dem feature nicht sicher bin ob ichs drin lassen soll). das ganze passiert beim on:changeday
Na... ich schaue es mir mal an (falls ich Zeit dafür finde
).
nach einigen jahreszeitenwechseln wird das script beim on:changeday plötzlich zwei mal aufgerufen! (in der konsole sichtbar) das hat zur folge dass natürlich auf einmal winter is und einem die ganzen früchte usw kaputt gehen. ausserdem gehen dann natürlich auch die palmen eher kaputt, weil sie ja jetzt 2 mal am tag schaden bekommen und der sommer (zur regeneration) ja auch viel kürzer ausfällt. wie kann das sein? vor allem dass es zu beginn eines spiels ja funktioniert und nur einmal aufgerufen wird...
Hm... Muss ich schauen.
die zerstörung der früchte bzw. palmen ist für jeden objekt typ extra gelooped. ich hatte zuerst einen loop über alle objekte und dann den typ ermittelt, aber dadurch ging der tageswechseln doch etwas lange. deshalb aus performancegründen alles extra.
Ja, solche Skripte können sich unter Umständen extrem auf die Performance ausüben... damit hatte ich auch schon recht oft Probleme (aktuell beim Terrainzeugs erst wieder, s.u.)
Ja, genau... Terrainzeugs... Cool, dass ich den Beitrag schon zu Hause geschrieben hatte und jetzt nur noch einfügen brauche... *zack* (nur noch kurz die Vorschaufunktion... ok)
So... ich habe mal das Problem mit dem Terrain etwas genauer unter die Lupe genommen. Dein Skript ist nebenbei eher ein 'Berggenerator für Arme'... Abgesehen von den falschen Kommentarzeichen ('\' statt '//'). Nix für ungut.
Alles in allem ist es etwas schwieriger als hier anfangs dargestellt und man kommt um ein paar mathematische und numerische Grundlagen nicht drumherum. Mit etwas Gespür für Mathematik sollten aber die Grundkenntnisse aus der Schule zum Verständnis genügen.
Im Prinzip geht es darum, jeder x,z-Koordinate in der Terrainmatrix eine neue Höhe zuzuordnen. Nebenbei betragen die Abstände innerhalb der Terrainmatrix 64 und nicht 50. Etwas mathematischer und abstrakter formuliert ist also eine Funktion in zwei Variablen gesucht, welche eine zweidimensionale Fläche im dreidimensionalen Raum beschreibt und zwei Punkten eine Höhe zuordnet.
Zur Vereinfachung kann man erst einmal den eindimensionalen Fall betrachten. Bspw. beschreibt die Funktion f(x)=100-x^2 (eine an der x-Achse gespiegelte und um 100 Einheiten in y-Richtung verschobene Parabel) einen "Berg" im kartesischen Koordinatensystem.
Im zweidimensionalen Fall ist so eine Funktion ebenfalls leicht gefunden. Diese sollte außerdem noch zwei Anforderungen erfüllen: An den Randpunkten soll y=0 sein - der Rand unseres Berges. Und für x=z=0 nimmt sie gerade ihr Maximum an - die Spitze des Berges.
Offensichtlich wird das bspw. durch die Funktion f(x,z)=[r^2-(x^2+z^2)]*(y_max/r^2) realisiert, wie man leicht nachrechnet. Die Bedingung x^2+z^2=r^2 beschreibt anschaulich einen Kreis in der x-z-Ebene mit dem Radius r und für diesen Fall ist f(x,z)=0. Sind x=z=0 so nimmt f(x,z) gerade ihr Maximum bei y_max an.
Soweit zur Theorie. Auf mögliche Transformationen wie Strecken, Dehnen, Stauchen o.ä. will ich jetzt nicht weiter eingehen. Außerdem fehlt noch eine Zufallskomponente für die Variation, da so ein Berg ja nicht perfekt symmetrisch ist. Solche Spielereien kann man ggf. auch nachträglich noch einbauen.
Nun zu Implementierung. Wir kennen die Abstände in der Terrainmatrix, geben Höhe und Radius des Berges vor, und beschreiben ihn durch obige Funktion. Außerdem setzen wir zur Vereinfachung eine Ebene voraus, d.h. die Höhe der Karte sei überall gleich. Ebenso soll unser Berg erst einmal genau in der Mitte der Karte sitzen - die Translation kann man ebenfalls nachträglich noch einbauen.
Im Prinzip geht man nun alle Punkte in der Terrainmatrix durch und ändert entsprechend unserer Funktion dort die Höhe. Zwischen diesen Punkten wird bereits intern interpoliert, so dass wir uns darum nicht kümmern brauchen. Das Problem geschachtelter Schleifen wird einfach per Timer/Event umgangen und sollte auch kein Problem sein (ich habe mich erstmal für den Timer entschieden womit sich das "wachsen" des Berges beobachten lässt).
Außerdem wird hier teilweise mit recht hohen Zahlen operiert, weshalb man wegen evtl. auftretender Überlauf- oder Auslöschungsphänomenen wieder auf die Kondition der Funktion achten muss.
Folgendes Skript wäre ein guter Ansatz für eine Implementierung welcher allerdings hinsichtlich der obigen Probleme und Parameter auf jeden Fall noch optimiert werden müsste. Alles in allem ist die Laufzeit auch recht hoch, weshalb so ein Skript eher Spielerei und weniger für die Anwendung gedacht sein dürfte...
-> Editor -> leere Karte (64x64 oder so) -> komplett abflachen -> Info-Objekt mit folgendem Skript
- on:start {
- event "init";
- }
-
- on:init {
- //Höhe des Berges (Vielfaches von 64...!)
- $y_max=256.0;
-
- //Radius des Berges (Vielfaches von 64...!)
- $radius=256.0;
-
- //Starte bei Koordinate... x,z -> -256
- $x=-$radius;
- $z=-$radius;
-
- //Schrittweite... cnt -> 8
- $cnt=($radius/32);
-
- timer "self",500,$cnt,"loop_z";
-
- timer "self",(500*$cnt),1,"blubber";
- }
-
- on:blubber {
- terraintexture "generate";
- }
-
- on:loop_z {
- // $y_max=($radius*$radius);
- $x=-$radius;
- loop("count",$cnt) {
- //unsere Funktion...
- // $y=((($radius*$radius)-(($x*$x)+($z*$z)))*($y_max/($radius*$radius)));
- //...besser konditioniert...!
- $y=($y_max-(((($x*$x)+($z*$z))/$radius)*($y_max/$radius)));
- //an terrain-fkt. anpassen...
- $y=($y/32.0);
- //Senkpunkte werden ignoriert...
- if ((terrain($x,$z,0)-50)<=$y) { terrain $x,$z,2,$y; }
- //paar Infos für die Konsolenausgabe...
- $coord_x=terrain($x,$z,3);
- $coord_z=terrain($x,$z,4);
- echo "$x, $y, $z ($coord_x,$coord_z)";
- //nächste x-Koordinate in der Terrainmatrix
- $x+=64;
- }
- //nächste z-Koordinate in der Terrainmatrix
- $z+=64;
- }
-
Noch ein kleines Beispiel zum Problem der Kondition (F10->Execute Script->Copy'n'Paste->Ausführen)...
- $radius=1024.0;
- $x=0;
- $z=448;
- $y_max=512.0;
- $tmp1=((($radius*$radius)-(($x*$x)+($z*$z)))*($y_max/($radius*$radius)));
- $tmp2=($y_max-(((($x*$x)+($z*$z))*$y_max)/($radius*$radius)));
- $tmp3=($y_max-(((($x*$x)+($z*$z))/$radius)*($y_max/$radius)));
- msg "$tmp1 $tmp2 $tmp3";
-
Die Funktionsgleichungen für $tmp1,$tmp2,$tmp3 sind alle die gleichen, nur etwas umgestellt. Intern unterscheidet sich lediglich die Reihenfolge der Rechenoperation was zu den angesprochenen Problemen (Überlauf, Auslöschung...) und im Endeffekt zu falschen Ergebnissen (und somit Fehler bei der Terraingenerierung) führen kann.
Außerdem hat da DC intern irgendwie noch etwas Unsinn verzapft (vermutlich um Fehler wie 'Division durch 0' etc. zu vermeiden). Siehe
- $tmp1=(500.0/1000000.0);
- $tmp2=(500.0/100000.0);
- msg "$tmp1 $tmp2";
-
mit der Ausgabe "1.0 0.005"...
Nachtrag: Schaffe ich es noch meine Testkarte hochzuladen? Ja, das schaffe ich noch, moment... *swoosh*
