Immer aktuelle News: StarTrade - aktuelle Beta: 12.06.05

Gehe zu Seite Zurück 1, 2, 3 ... 10, 11, 12, 13, 14, 15 Weiter

Deine Meinung zu StarTrade ?

G-e-n-i-a-l :D	20%	38 Stimmen
Super :)	36%	67 Stimmen
Nicht gut, aber auch nicht schlecht	24%	46 Stimmen
Schlecht	3%	6 Stimmen
Absolut bekloppt	15%	28 Stimmen

Insgesamt 185 Stimmen

	Fetze	So, Jan 29, 2006 0:40 Antworten mit Zitat
Ich arbeite dran. Da ich mir noch nicht ganz sicher bin, ab welchem Entwicklungsstand ich die erste Version rausgeben werde, kann ich das nicht genau sagen, aber ich würde mal auf ein paar Monate tippen, wenn ihr funktionstüchtige Waffen und ne ausgereifte KampfKI drin haben wollt.

Fetze

So, Jan 29, 2006 0:40
Antworten mit Zitat

Ich arbeite dran. Da ich mir noch nicht ganz sicher bin, ab welchem Entwicklungsstand ich die erste Version rausgeben werde, kann ich das nicht genau sagen, aber ich würde mal auf ein paar Monate tippen, wenn ihr funktionstüchtige Waffen und ne ausgereifte KampfKI drin haben wollt.

	Fetze	Fr, Feb 24, 2006 19:32 Antworten mit Zitat
http://www.fetzenet.de/neust8.png Die Waffenauswahl ist fertig ^^ Unter der eigentlichen Auswahl sowie Waffenenergie-Anzeige werden nun alle unter diese Kategorie fallenden Waffen, die am Schiff installiert wurden, aufgelistet und deren Status angezeigt. Gut beobachten kann man im Screenshot die beiden Ladebalken hinter der Waffe, die anzeigen, wann die Waffe den nächsten Schuss abfeuern kann. Auf Ini-Wunsch wird ebenfalls angezeigt, wie viele Schüsse die Waffe noch feuern kann, bis ihr Munition und/oder Energie ausgehen. Als nächstes sind nun Projektile dran. Bisher kann man die Waffen schon abfeuern, es wird Energie verbraucht und sie laden nen Moment lang wieder auf, aber es wird eben noch kein Projektil erstellt.

Fetze

Fr, Feb 24, 2006 19:32
Antworten mit Zitat

http://www.fetzenet.de/neust8.png

Die Waffenauswahl ist fertig ^^
Unter der eigentlichen Auswahl sowie Waffenenergie-Anzeige werden nun alle unter diese Kategorie fallenden Waffen, die am Schiff installiert wurden, aufgelistet und deren Status angezeigt. Gut beobachten kann man im Screenshot die beiden Ladebalken hinter der Waffe, die anzeigen, wann die Waffe den nächsten Schuss abfeuern kann. Auf Ini-Wunsch wird ebenfalls angezeigt, wie viele Schüsse die Waffe noch feuern kann, bis ihr Munition und/oder Energie ausgehen.

Als nächstes sind nun Projektile dran. Bisher kann man die Waffen schon abfeuern, es wird Energie verbraucht und sie laden nen Moment lang wieder auf, aber es wird eben noch kein Projektil erstellt.

	Ava Gast	Fr, Feb 24, 2006 20:19 Antworten mit Zitat
Ich will den Screen gucken! aber er ist nicht da...

Ava

Gast

Fr, Feb 24, 2006 20:19
Antworten mit Zitat

Ich will den Screen gucken! aber er ist nicht da... Crying or Very sad

	HW	Fr, Feb 24, 2006 20:32 Antworten mit Zitat
Also der Link selbst funktioniert. Ich habe nämlich keine Probleme damit.

HW

Fr, Feb 24, 2006 20:32
Antworten mit Zitat

Also der Link selbst funktioniert. Ich habe nämlich keine Probleme damit.

	Ava Gast	Fr, Feb 24, 2006 21:29 Antworten mit Zitat
Ja, nun klappt's bei mir auch!

Ava

Gast

Fr, Feb 24, 2006 21:29
Antworten mit Zitat

Ja, nun klappt's bei mir auch! Smile

	Fetze	So, Feb 26, 2006 20:34 Antworten mit Zitat
So, mal ne kleine Modder-News: Die ActionSteps funktionieren nun vollständig. ActionSteps sind Schritte in der Ausführung im Verhalten eines Items. Zum Beispiel könnte ein Item damit erst einmal 5 Sekunden lange das Schiff heilen, dann 2 Sekunden lange Pause machen und dann wieder von vorne beginnen. Es wäre auch eine Waffe möglich, die, je länger man die Feuertaste gedrückt hält, immer schneller feuert, bis sie einen Maximalwert erreicht hat. Kein Problem, ActionSteps amchen es möglich. Das ganze funktioniert folgendermaßen: Jedes Frame, in dem das Item aktiviert ist - für Waffen bedeutet das: Jedes Frame, in dem man die Feuertaste drückt - läuft ein Timer vorwärts. Hat der Timer des aktuellen ActionStep dessen ActionStepDelay erreicht, wird zu dem ActionStep gewechselt, der bei NextActionStep angegeben ist, wobei der Timer genullt wird. Dieser nächste ActionStep kann einen eigenen ActionStepDelay haben. Hat der Timer diesen erreicht, wird wiederum zum nächsten ActionStep, wenn vorhanden, gewechselt, usw. Was passiert, wenn das Item nicht aktiviert ist / Man die Feuertaste der Waffe nicht drückt, wird mit ActionStepDelayType angegeben. Ist ActionStepDelayType = 0, wird das Item auf seinen Start-ActionStep zurückgeworfen, der Timer genullt. Sofortiger Ausgangszustand sozusagen. Ist ActionStepDelayType = 1, bleibt einfach alles, wie gehabt. Bei ActionStepDelay = 2 läuft der Timer auch weiter, wenn man gar nicht feuert (Also grundsätzlich immer, da er auch weiterläuft, WENN man feuert) und für ActionStepDelayType = 3 gilt: Der Timer läuft rückwärts, wenn man nicht drückt. Nimmt der Timer des aktuellen ActionSteps einen Wert unter 0 an, wird zu dem ActionStep gewechselt, der bei "LastActionStep" angegeben ist und der Timer auf dessen Maximaldelay gesetzt. Damit lassen sich tolle Sachen anstellen, beispielsweise eine Waffenüberhitzung, eine Gatlin-Gun, die immer schneller feuert, je länger man gedrückt hält oder sonstwas. Auch wäre das ein alternativer Weg, das Disruptorverhalten zu simulieren. Wir fassen anhand eines Beispiels noch einmal zusammen. Erstellen wir uns eine Schnellfeuerwaffe, die überhitzt. Wir betrachten im Beispiel nur den UseMode-Abschnitt der Waffe. So sieht beispielsweise momentan die SFG160 aus: Zitat: UseMode=New ActivateType=2 WeaponSelectionAmmoDisplayMode=-1 ActionStep=New EnergyDec=10 EnergyDecDelay=150 ActionDelay=150 ActionStep=End UseMode=End Die werden wir im folgenden bearbeiten. Dass es in der derzeitigen ST-Version noch gar nicht möglich ist, zu schießen, ist auch der Grund, warum sich dort bisher keine Einträge mit Bezug auf das zu feuernde Projektil finden. Hier mal das ganze mit Erklärung: Zitat: UseMode=New ;UseMode. Eine Möglichkeit, dieses Item zu benutzen. Die meisten haben insgesamt nur einen. ActivateType=2 ;Aktivierung durch Auswahl in der Waffenauswahl und Druck der Feuertaste WeaponSelectionAmmoDisplayMode=-1 ;In der Waffenauswahl findet sich keine Anzeige für die Restmunition. Hat ja keine. ActionStep=New ;Ein ActionStep, ein Schritt der Aktion des Items. EnergyDecDelay=150 ;Alle 150 Millisekunden EnergyDec=10 ;verbraucht die Waffe 10 Energie ActionDelay=150 ;Und alle 150 Millisekunden führt sie ihre Aktion aus (feuert). ActionStep=End ;Ende des ActionSteps UseMode=End ;Ende des UseModes Zunächst brauchen wir einen zweiten ActionStep. Er repräsentiert den Waffenstatus "Überhitzt", die Waffe wird dann langsamer feuern. Zitat: UseMode=New ActivateType=2 WeaponSelectionAmmoDisplayMode=-1 ActionStep=New ;Normal, Nr. 1 EnergyDec=10 EnergyDecDelay=150 ActionDelay=150 ActionStep=End ActionStep=New ;Überhitzt, Nr. 2 EnergyDec=10 EnergyDecDelay=300 ActionDelay=300 ActionStep=End UseMode=End So. Im Überhitzten Zustand wird die Waffe nurnoch halb so schnell feuern. Jetzt stellen wir eine Verbindung zwischen den beiden ActionSteps her. Zitat: UseMode=New ActivateType=2 WeaponSelectionAmmoDisplayMode=-1 ActionStep=New ;Normal, Nr. 1 EnergyDec=10 EnergyDecDelay=150 ActionDelay=150 ActionStepDelay=5000 ;Nach 5 Sekunden Dauerfeuer NextActionStep=2 ;wechselt die Waffe in den Überhitzten Zustand über. ActionStepDelayType=3 ;Je länger man nicht feuert, desto weiter kühlt sich die Waffe wieder ab. ActionStep=End ActionStep=New ;Überhitzt, Nr. 2 EnergyDec=10 EnergyDecDelay=300 ActionDelay=300 ActionStepDelay=3000 ;Feuert der Spieler trotz überhitzung weiter, dauert es später maximal 3 Sekunden, bis sich die Waffe wieder so weit abgekühlt hat, dass sie wieder schneller feuert. LastActionStep=1 ;...weil sie nämlich dann zurück in den nicht überhitzten Zustand wechselt. ActionStepDelayType=3 ;s.o. ActionStep=End UseMode=End So. Fertig. Gar nicht mal schwer, oder? ^^

Fetze

So, Feb 26, 2006 20:34
Antworten mit Zitat

So, mal ne kleine Modder-News:
Die ActionSteps funktionieren nun vollständig.

ActionSteps sind Schritte in der Ausführung im Verhalten eines Items. Zum Beispiel könnte ein Item damit erst einmal 5 Sekunden lange das Schiff heilen, dann 2 Sekunden lange Pause machen und dann wieder von vorne beginnen. Es wäre auch eine Waffe möglich, die, je länger man die Feuertaste gedrückt hält, immer schneller feuert, bis sie einen Maximalwert erreicht hat. Kein Problem, ActionSteps amchen es möglich.

Das ganze funktioniert folgendermaßen: Jedes Frame, in dem das Item aktiviert ist - für Waffen bedeutet das: Jedes Frame, in dem man die Feuertaste drückt - läuft ein Timer vorwärts. Hat der Timer des aktuellen ActionStep dessen ActionStepDelay erreicht, wird zu dem ActionStep gewechselt, der bei NextActionStep angegeben ist, wobei der Timer genullt wird. Dieser nächste ActionStep kann einen eigenen ActionStepDelay haben. Hat der Timer diesen erreicht, wird wiederum zum nächsten ActionStep, wenn vorhanden, gewechselt, usw.
Was passiert, wenn das Item nicht aktiviert ist / Man die Feuertaste der Waffe nicht drückt, wird mit ActionStepDelayType angegeben. Ist ActionStepDelayType = 0, wird das Item auf seinen Start-ActionStep zurückgeworfen, der Timer genullt. Sofortiger Ausgangszustand sozusagen. Ist ActionStepDelayType = 1, bleibt einfach alles, wie gehabt. Bei ActionStepDelay = 2 läuft der Timer auch weiter, wenn man gar nicht feuert (Also grundsätzlich immer, da er auch weiterläuft, WENN man feuert) und für ActionStepDelayType = 3 gilt: Der Timer läuft rückwärts, wenn man nicht drückt. Nimmt der Timer des aktuellen ActionSteps einen Wert unter 0 an, wird zu dem ActionStep gewechselt, der bei "LastActionStep" angegeben ist und der Timer auf dessen Maximaldelay gesetzt.
Damit lassen sich tolle Sachen anstellen, beispielsweise eine Waffenüberhitzung, eine Gatlin-Gun, die immer schneller feuert, je länger man gedrückt hält oder sonstwas. Auch wäre das ein alternativer Weg, das Disruptorverhalten zu simulieren.

Wir fassen anhand eines Beispiels noch einmal zusammen. Erstellen wir uns eine Schnellfeuerwaffe, die überhitzt. Wir betrachten im Beispiel nur den UseMode-Abschnitt der Waffe.
So sieht beispielsweise momentan die SFG160 aus:
Zitat:

UseMode=New
ActivateType=2
WeaponSelectionAmmoDisplayMode=-1
ActionStep=New
EnergyDec=10
EnergyDecDelay=150
ActionDelay=150
ActionStep=End
UseMode=End

Die werden wir im folgenden bearbeiten. Dass es in der derzeitigen ST-Version noch gar nicht möglich ist, zu schießen, ist auch der Grund, warum sich dort bisher keine Einträge mit Bezug auf das zu feuernde Projektil finden. Hier mal das ganze mit Erklärung:
Zitat:

UseMode=New ;UseMode. Eine Möglichkeit, dieses Item zu benutzen. Die meisten haben insgesamt nur einen.
ActivateType=2 ;Aktivierung durch Auswahl in der Waffenauswahl und Druck der Feuertaste
WeaponSelectionAmmoDisplayMode=-1 ;In der Waffenauswahl findet sich keine Anzeige für die Restmunition. Hat ja keine.
ActionStep=New ;Ein ActionStep, ein Schritt der Aktion des Items.
EnergyDecDelay=150 ;Alle 150 Millisekunden
EnergyDec=10 ;verbraucht die Waffe 10 Energie
ActionDelay=150 ;Und alle 150 Millisekunden führt sie ihre Aktion aus (feuert).
ActionStep=End ;Ende des ActionSteps
UseMode=End ;Ende des UseModes

Zunächst brauchen wir einen zweiten ActionStep. Er repräsentiert den Waffenstatus "Überhitzt", die Waffe wird dann langsamer feuern.
Zitat:

UseMode=New
ActivateType=2
WeaponSelectionAmmoDisplayMode=-1
ActionStep=New ;Normal, Nr. 1
EnergyDec=10
EnergyDecDelay=150
ActionDelay=150
ActionStep=End

ActionStep=New ;Überhitzt, Nr. 2
EnergyDec=10
EnergyDecDelay=300
ActionDelay=300
ActionStep=End

UseMode=End

So. Im Überhitzten Zustand wird die Waffe nurnoch halb so schnell feuern. Jetzt stellen wir eine Verbindung zwischen den beiden ActionSteps her.
Zitat:

UseMode=New
ActivateType=2
WeaponSelectionAmmoDisplayMode=-1
ActionStep=New ;Normal, Nr. 1
EnergyDec=10
EnergyDecDelay=150
ActionDelay=150

ActionStepDelay=5000 ;Nach 5 Sekunden Dauerfeuer
NextActionStep=2 ;wechselt die Waffe in den Überhitzten Zustand über.
ActionStepDelayType=3 ;Je länger man nicht feuert, desto weiter kühlt sich die Waffe wieder ab.

ActionStep=End
ActionStep=New ;Überhitzt, Nr. 2
EnergyDec=10
EnergyDecDelay=300
ActionDelay=300

ActionStepDelay=3000 ;Feuert der Spieler trotz überhitzung weiter, dauert es später maximal 3 Sekunden, bis sich die Waffe wieder so weit abgekühlt hat, dass sie wieder schneller feuert.
LastActionStep=1 ;...weil sie nämlich dann zurück in den nicht überhitzten Zustand wechselt.
ActionStepDelayType=3 ;s.o.

ActionStep=End
UseMode=End

So. Fertig. Gar nicht mal schwer, oder? ^^

	Ava Gast	So, Feb 26, 2006 23:57 Antworten mit Zitat
Und klingt ziemlich gut und interessant!

Ava

Gast

So, Feb 26, 2006 23:57
Antworten mit Zitat

Und klingt ziemlich gut und interessant! Smile

	TACITUS	Do, März 02, 2006 16:43 Antworten mit Zitat
Wieso gibt's beim Drehen der Raumschiffe oder zumindest bei der Andromeda so wenig zwischenschritte, das ist böhz böhze ansonste phat, das spiel
AMD Athlon 64 X2 4200+ Dual Core Prozessor _ 1024 MB Dual Channel DDR RAM _ GeForce 7800 GT PCI Express 256 MB GDDR3 RAM _ Festplatte 410 GB _ DirectX 9.0c User posted image

TACITUS

Do, März 02, 2006 16:43
Antworten mit Zitat

Wieso gibt's beim Drehen der Raumschiffe oder zumindest bei der
Andromeda so wenig zwischenschritte, das ist böhz böhze

ansonste phat, das spiel Wink

AMD Athlon 64 X2 4200+ Dual Core Prozessor _ 1024 MB Dual Channel DDR RAM _ GeForce 7800 GT PCI Express 256 MB GDDR3 RAM _ Festplatte 410 GB _ DirectX 9.0c
User posted image

	Fetze	Do, März 02, 2006 17:27 Antworten mit Zitat
Solltest dir mal die "großen Weihnachtsnews" vom 24.Dez anschauen, ein paar Posts vorher. Wie ich dort bekannt gegeben habe, arbeite ich zur Zeit an einer völlig neuen ST-Version die neben anderen neuen Features auch stufenlose Drehung und einen kaum merklichen Ladevorgang mitbringt

Fetze

Do, März 02, 2006 17:27
Antworten mit Zitat

Solltest dir mal die "großen Weihnachtsnews" vom 24.Dez anschauen, ein paar Posts vorher. Wie ich dort bekannt gegeben habe, arbeite ich zur Zeit an einer völlig neuen ST-Version die neben anderen neuen Features auch stufenlose Drehung und einen kaum merklichen Ladevorgang mitbringt Wink

	TACITUS	Do, März 02, 2006 18:01 Antworten mit Zitat
Ich hatte nicht wirklich Lust die restlichen 206 Posts durchzulesen, ich habe nur schnell das Spiel "bewertet" PS: Dann is ja gut, wenn du daran arbeitest pöp
AMD Athlon 64 X2 4200+ Dual Core Prozessor _ 1024 MB Dual Channel DDR RAM _ GeForce 7800 GT PCI Express 256 MB GDDR3 RAM _ Festplatte 410 GB _ DirectX 9.0c User posted image

TACITUS

Do, März 02, 2006 18:01
Antworten mit Zitat

Ich hatte nicht wirklich Lust die restlichen 206 Posts durchzulesen, ich habe
nur schnell das Spiel "bewertet" Wink

PS: Dann is ja gut, wenn du daran arbeitest pöp

AMD Athlon 64 X2 4200+ Dual Core Prozessor _ 1024 MB Dual Channel DDR RAM _ GeForce 7800 GT PCI Express 256 MB GDDR3 RAM _ Festplatte 410 GB _ DirectX 9.0c
User posted image

	Fetze	Sa, März 18, 2006 14:13 Antworten mit Zitat
So, hab das Grundgerüst der Projektile jetzt fertig eingebaut. http://www.fetzenet.de/neust10.png Bisher fliegen sie allerdings nur schön herum, bis sie sich nach Ablauf ihrer Lebenszeit selbst löschen. Kollision gibts bisher noch nicht. Vielleicht interessiert es den einen oder anderen, wie das jetzt Ini-Mäßig mit den Waffen aussieht. Hier, nehmen wir mal die LLG als Beispiel. Ich habe die für euch neuen Stellen mal kommentiert: Hier erst einmal der für die Waffe zuständige Teil der Ware "LLG": Zitat: UseMode=New WeaponSelectionThumbImage=wstllg.png ActivateType=2 WeaponSelectionAmmoDisplayMode=-1 ActionStep=New EnergyDec=15 EnergyDecDelay=300 ActionDelay=300 ActiveSound=schuss4.wav ;Sound, der beim Abfeuern der Waffe gespielt wird ActiveSoundMode=0 ;Sound wird global gespielt, nicht nur für das abfeuernde Schiff hörbar ActiveSoundVol=1.0 ActiveSoundPitch=1.0 ActiveSoundRange=150 EmitProjectile=PROJ_LLG ;Hier wird das Projektil erzeugt. ActionStep=End UseMode=End Und hier das Projektil: Zitat: [PROJTYPE=PROJ_LLG] ;Typbezeichnung und eröffnung des Ini-Leseblocks, wie gehabt. Name=LLG-Projektil ;Name des Projektils. Hat bisher keine Verwendung im Spiel. Image=projllg.png ;Bild des Projektils StartSpeed=6.5 ;Startgeschwindigkeit des Projektils RelativeSpeedMult=1.0 ;Multiplikator für die Geschwindigkeit, die das Projektil vom feuernden Objekt übernimmt LifeTime=5080 ;Lebenszeit in Millisekunden LifeTimeRandom=165 ;Zufallsfaktor der Lebenszeit ins negative und positive. Die Zufallsvarianz beträgt also 2 * 165 = 330 Millisekunden. [/PROJTYPE]

Fetze

Sa, März 18, 2006 14:13
Antworten mit Zitat

So, hab das Grundgerüst der Projektile jetzt fertig eingebaut.
http://www.fetzenet.de/neust10.png

Bisher fliegen sie allerdings nur schön herum, bis sie sich nach Ablauf ihrer Lebenszeit selbst löschen. Kollision gibts bisher noch nicht. Vielleicht interessiert es den einen oder anderen, wie das jetzt Ini-Mäßig mit den Waffen aussieht. Hier, nehmen wir mal die LLG als Beispiel. Ich habe die für euch neuen Stellen mal kommentiert:

Hier erst einmal der für die Waffe zuständige Teil der Ware "LLG":
Zitat:

UseMode=New
WeaponSelectionThumbImage=wstllg.png
ActivateType=2
WeaponSelectionAmmoDisplayMode=-1
ActionStep=New
EnergyDec=15
EnergyDecDelay=300
ActionDelay=300
ActiveSound=schuss4.wav ;Sound, der beim Abfeuern der Waffe gespielt wird
ActiveSoundMode=0 ;Sound wird global gespielt, nicht nur für das abfeuernde Schiff hörbar
ActiveSoundVol=1.0
ActiveSoundPitch=1.0
ActiveSoundRange=150
EmitProjectile=PROJ_LLG ;Hier wird das Projektil erzeugt.
ActionStep=End
UseMode=End

Und hier das Projektil:
Zitat:

[PROJTYPE=PROJ_LLG] ;Typbezeichnung und eröffnung des Ini-Leseblocks, wie gehabt.
Name=LLG-Projektil ;Name des Projektils. Hat bisher keine Verwendung im Spiel.
Image=projllg.png ;Bild des Projektils
StartSpeed=6.5 ;Startgeschwindigkeit des Projektils
RelativeSpeedMult=1.0 ;Multiplikator für die Geschwindigkeit, die das Projektil vom feuernden Objekt übernimmt
LifeTime=5080 ;Lebenszeit in Millisekunden
LifeTimeRandom=165 ;Zufallsfaktor der Lebenszeit ins negative und positive. Die Zufallsvarianz beträgt also 2 * 165 = 330 Millisekunden.
[/PROJTYPE]

	ke^kx	Sa, März 18, 2006 14:29 Antworten mit Zitat
Hm hm... Mal ne Frage: Wie verwaltest du das ganze innerhalb des Spiels? Klar, erst lädst du die Dateien und dein Programm parst das ganze in eine Bank oder einen Type. Und dann? Ist das "alles" was du machst? Also, dass du statt der "normalen" Vorgehensweise, die Waffen fest einzucoden, das ganze flexibel machst? Jiriki
http://i3u8.blogspot.com Asus Striker II Intel Core2Quad Q9300 @ 2,5 GHz (aber nur zwei Kerne aktiv aufgrund der Instabilität -.-) Geforce 9800 GTX 2GB RAM

ke^kx

Sa, März 18, 2006 14:29
Antworten mit Zitat

Hm hm... Mal ne Frage: Wie verwaltest du das ganze innerhalb des Spiels? Klar, erst lädst du die Dateien und dein Programm parst das ganze in eine Bank oder einen Type. Und dann? Ist das "alles" was du machst? Also, dass du statt der "normalen" Vorgehensweise, die Waffen fest einzucoden, das ganze flexibel machst?

Jiriki

http://i3u8.blogspot.com
Asus Striker II
Intel Core2Quad Q9300 @ 2,5 GHz (aber nur zwei Kerne aktiv aufgrund der Instabilität -.-)
Geforce 9800 GTX
2GB RAM

	Fetze	Sa, März 18, 2006 15:22 Antworten mit Zitat
Zuerst lasse ich das StarTrade-Hauptverzeichnis und den Unterordner nach Mods scannen. Im Hauptverzeichnis deswegen, weil auch das SPiel selbst intern als Mod gehandhabt wird. Einen Mod erkenne ich an seiner Hauptdatei modinfo.ini, in der steht, in welchen Unterverzeichnissen sich was befindet. Nachdem ich eine Liste erstellt habe, in der drin steht, was also alles für Mods zur Verfügung stehen, prüfe ich auf Kommandozeilenparameter, die Informationen darüber enthalten können, welcher Mod zu starten ist. Ist keiner angegeben oder gar kein Kommandozeilenparameter vorhanden, wird einfach der "Standard-Mod" im Hauptverzeichnis, das Hauptspiel geladen. Der erste Schritt des eigentlichen Ladevorgangs: Ab in das in der modinfo.ini angegebene GameData-Verzeichnis und die gamedata.ini öffnen, die sämtliche Spieldaten enthält (Es ist aber auch via "Ini-Include" möglich, Teile davon in andere Dateien auszulagern). Zunächst wird einmal drübergelesen und nach Typ-Definitionen gesucht. In StarTrade ist alles Typbasiert, es gibt Schifftypen, Stationstypen, Projektiltypen, etc.. Zunächst muss ich eine Liste aller Typen jeder Sorte erstellen, die ich später beim eigentlichen Einladen für die Definition verschiedener Variablen benötige. Beispielsweise zur Prüfung von Verweisen auf bestimmte Typen. Sind nun alle Typdefinitionen gefunden und registriert worden, wird die Datei nochmal gelesen: Wird nun eine Typdefinition gefunden, wird der Typ aus dem Register heraus gesucht und die folgenden Einträge auf diesen Typ bezogen und deren Werte gespeichert. Für jeden Typen habe ein eine Klasse mit einer Reihe von globalen Arrays, jeder Typ wird durch einen Array-Index repräsentiert, seine Typnummer. Beispielsweise will ich eine Information zur Waffe "LLG200" hreausfinden, dann gebe ich ihr Ini-Kürzel "LLG" an eine Function weiter, die mir dessen Typnummer zurückliefert und setze diese Typnummer dann in die Arrays dieser Klasse ein. Hier, etwas anschaulicher: Eine Waffe gilt übrigens intern als Commodity, als Handelsware/Item. Mit der folgenden Zeile finde ich beispielsweise den Namen der Waffe mit dem Ini-Kürzel LLG heraus: Commodity.sName[Commodity.ID2Type("LLG")] Insgesamt habe ich alle Typen in folgende Klassen gegliedert, die gleichzeitig dann auch die Klassen der InGame-Objekte sind: -> Ship -> Station -> Commodity -> Projectile Da kommen noch ein paar mehr, aber das hier sind die "Hauptklassen". So, was nun die flexibilität angeht: Man muss einfach "allgemeiner" coden und jede Möglichkeit, die sich aus den Ini-Einträgen ergibt mit einbeziehen. Neben den Parameter-Einträgen, die nur einen fest gecodeten Wert ersetzen gibt es nämlich auch noch die Spielmechanik-Einträge, die das grundsätzliche Verhalten eines Objekts bestimmen. Hier muss man zum Beispiel darauf achten, dass man per Ini kein Objekt erschaffen kann, das sich gegenseitig ausschließende Verhaltensweisen verfolgt, gleichzeitig muss man auch darauf achten, dass möglichst alle anderen Verhaltensweisen beliebig kombinierbar sind. Der Grund dafür, dass ich mir diese Arbeit mache ist, dass es so auch Leuten ohne Programmierkenntnisse ermöglicht wird, StarTrade zu modden und damit zu verändern oder zu erweitern. Wer will, kann auch ne Total Conversion basteln und die "StarTrade-Engine" so verwenden, um sich sein "eigenes" Spiel zu basteln. Das macht nicht nur dem Modder Spaß, sondern auch den Spielern, die seinen Mod ausprobieren und verlängert so die "Lebensdauer" des Spiels, was man an Titeln wie "Half Life" oder "Command & COnquer" beobachten kann. Da ich mir nicht sicher bin, deine Frage richtig verstanden zu haben, hab ich jetzt einfach mal ein bischen mehr geschrieben. Hoffe, die Antwort auf deine Frage steckt da irgendwo drin

Fetze

Sa, März 18, 2006 15:22
Antworten mit Zitat

Zuerst lasse ich das StarTrade-Hauptverzeichnis und den Unterordner nach Mods scannen. Im Hauptverzeichnis deswegen, weil auch das SPiel selbst intern als Mod gehandhabt wird. Einen Mod erkenne ich an seiner Hauptdatei modinfo.ini, in der steht, in welchen Unterverzeichnissen sich was befindet.

Nachdem ich eine Liste erstellt habe, in der drin steht, was also alles für Mods zur Verfügung stehen, prüfe ich auf Kommandozeilenparameter, die Informationen darüber enthalten können, welcher Mod zu starten ist. Ist keiner angegeben oder gar kein Kommandozeilenparameter vorhanden, wird einfach der "Standard-Mod" im Hauptverzeichnis, das Hauptspiel geladen.

Der erste Schritt des eigentlichen Ladevorgangs: Ab in das in der modinfo.ini angegebene GameData-Verzeichnis und die gamedata.ini öffnen, die sämtliche Spieldaten enthält (Es ist aber auch via "Ini-Include" möglich, Teile davon in andere Dateien auszulagern). Zunächst wird einmal drübergelesen und nach Typ-Definitionen gesucht.
In StarTrade ist alles Typbasiert, es gibt Schifftypen, Stationstypen, Projektiltypen, etc.. Zunächst muss ich eine Liste aller Typen jeder Sorte erstellen, die ich später beim eigentlichen Einladen für die Definition verschiedener Variablen benötige. Beispielsweise zur Prüfung von Verweisen auf bestimmte Typen.

Sind nun alle Typdefinitionen gefunden und registriert worden, wird die Datei nochmal gelesen: Wird nun eine Typdefinition gefunden, wird der Typ aus dem Register heraus gesucht und die folgenden Einträge auf diesen Typ bezogen und deren Werte gespeichert.
Für jeden Typen habe ein eine Klasse mit einer Reihe von globalen Arrays, jeder Typ wird durch einen Array-Index repräsentiert, seine Typnummer. Beispielsweise will ich eine Information zur Waffe "LLG200" hreausfinden, dann gebe ich ihr Ini-Kürzel "LLG" an eine Function weiter, die mir dessen Typnummer zurückliefert und setze diese Typnummer dann in die Arrays dieser Klasse ein. Hier, etwas anschaulicher:

Eine Waffe gilt übrigens intern als Commodity, als Handelsware/Item. Mit der folgenden Zeile finde ich beispielsweise den Namen der Waffe mit dem Ini-Kürzel LLG heraus:
Commodity.sName[Commodity.ID2Type("LLG")]

Insgesamt habe ich alle Typen in folgende Klassen gegliedert, die gleichzeitig dann auch die Klassen der InGame-Objekte sind:
-> Ship
-> Station
-> Commodity
-> Projectile
Da kommen noch ein paar mehr, aber das hier sind die "Hauptklassen".

So, was nun die flexibilität angeht: Man muss einfach "allgemeiner" coden und jede Möglichkeit, die sich aus den Ini-Einträgen ergibt mit einbeziehen.
Neben den Parameter-Einträgen, die nur einen fest gecodeten Wert ersetzen gibt es nämlich auch noch die Spielmechanik-Einträge, die das grundsätzliche Verhalten eines Objekts bestimmen. Hier muss man zum Beispiel darauf achten, dass man per Ini kein Objekt erschaffen kann, das sich gegenseitig ausschließende Verhaltensweisen verfolgt, gleichzeitig muss man auch darauf achten, dass möglichst alle anderen Verhaltensweisen beliebig kombinierbar sind.

Der Grund dafür, dass ich mir diese Arbeit mache ist, dass es so auch Leuten ohne Programmierkenntnisse ermöglicht wird, StarTrade zu modden und damit zu verändern oder zu erweitern. Wer will, kann auch ne Total Conversion basteln und die "StarTrade-Engine" so verwenden, um sich sein "eigenes" Spiel zu basteln. Das macht nicht nur dem Modder Spaß, sondern auch den Spielern, die seinen Mod ausprobieren und verlängert so die "Lebensdauer" des Spiels, was man an Titeln wie "Half Life" oder "Command & COnquer" beobachten kann.

Da ich mir nicht sicher bin, deine Frage richtig verstanden zu haben, hab ich jetzt einfach mal ein bischen mehr geschrieben. Hoffe, die Antwort auf deine Frage steckt da irgendwo drin Wink

Zuletzt bearbeitet von Fetze am Sa, März 18, 2006 15:27, insgesamt einmal bearbeitet

	Sung Gast	Sa, März 18, 2006 15:27 Antworten mit Zitat
Star Trade gerade das erste mal heruntergeladen und ausprobiert. Klasse gemacht!

Sung

Gast

Sa, März 18, 2006 15:27
Antworten mit Zitat

Star Trade gerade das erste mal heruntergeladen und ausprobiert. Klasse gemacht! Very Happy

	Fetze	Sa, März 18, 2006 16:00 Antworten mit Zitat
Für "Neueinsteiger" sollte ich dazu sagen: Die aktuelle Downloadversion ist momentan noch AltST, bietet also noch nicht die vor ein paar Posts gelisteten Features und die News gehören auch nicht dazu. Das bezieht sich alels auf die Version, an der ich momentan arbeite und die ich hoffentlich bald releasen werde.

Fetze

Sa, März 18, 2006 16:00
Antworten mit Zitat

Für "Neueinsteiger" sollte ich dazu sagen: Die aktuelle Downloadversion ist momentan noch AltST, bietet also noch nicht die vor ein paar Posts gelisteten Features und die News gehören auch nicht dazu. Das bezieht sich alels auf die Version, an der ich momentan arbeite und die ich hoffentlich bald releasen werde.

	ke^kx	Sa, März 18, 2006 16:06 Antworten mit Zitat
Ah, dann verstehe ich... Danke Mal schaun in wie fern ich mir daran ein Beispiel nehmen kann Jiriki
http://i3u8.blogspot.com Asus Striker II Intel Core2Quad Q9300 @ 2,5 GHz (aber nur zwei Kerne aktiv aufgrund der Instabilität -.-) Geforce 9800 GTX 2GB RAM

ke^kx

Sa, März 18, 2006 16:06
Antworten mit Zitat

Ah, dann verstehe ich... Danke Smile

Mal schaun in wie fern ich mir daran ein Beispiel nehmen kann Wink

Jiriki

http://i3u8.blogspot.com
Asus Striker II
Intel Core2Quad Q9300 @ 2,5 GHz (aber nur zwei Kerne aktiv aufgrund der Instabilität -.-)
Geforce 9800 GTX
2GB RAM

	Fetze	Do, März 23, 2006 19:54 Antworten mit Zitat
So, ich habe gerade nach rund einer halben Woche harter Arbeit (Es gibt Zeugen! ) endlich das neue Kollisionssystem fertiggestellt, das es Schiffen erlaubt, einigermaßen physikalisch korrekt zu kollidieren, ist meienr Meinung nach wirklich gelungen aber das kann man leider auf Screenshots nicht wirklich erkennen Standardmäßig wird die Schiff-Schiff-Kollision deaktiviert sein, genauergesagt nur die Kollision mit anderen Schiffen. Möglicherweise werde ich in der finalen Version auch Asteroidenfelder drin haben und mit Asteroiden - sie gelten intern auch als Schiffe - kann man natürlich kollidieren. Anders als in AltST kann man als Modder nun für jeden Schifftyp einzeln festlegen, ob er mit anderen Schiffen kollidieren kann. Bei der Kollisionsprüfung zweier Schiffe reicht es aus, wenn einer der beiden Schifftypen beim entsprechenden Eintrag eine "1" stehen hat. Da ich das nun abgeschlossen und somit auch den Grundstein für tolle Nicht-Weltraum-Total-Conversions gelegt habe, werde ich mich in nächster Zeit wieder den Waffen widmen. Umherfliegende Projektile und funktionstüchtige Waffen sind ja ganz schön, aber etwas witzlos, wenn sie durch die Schiffe hindurch fliegen ^^

Fetze

Do, März 23, 2006 19:54
Antworten mit Zitat

So, ich habe gerade nach rund einer halben Woche harter Arbeit (Es gibt Zeugen! Laughing

) endlich das neue Kollisionssystem fertiggestellt, das es Schiffen erlaubt, einigermaßen physikalisch korrekt zu kollidieren, ist meienr Meinung nach wirklich gelungen aber das kann man leider auf Screenshots nicht wirklich erkennen Rolling Eyes

Standardmäßig wird die Schiff-Schiff-Kollision deaktiviert sein, genauergesagt nur die Kollision mit anderen Schiffen. Möglicherweise werde ich in der finalen Version auch Asteroidenfelder drin haben und mit Asteroiden - sie gelten intern auch als Schiffe - kann man natürlich kollidieren. Anders als in AltST kann man als Modder nun für jeden Schifftyp einzeln festlegen, ob er mit anderen Schiffen kollidieren kann. Bei der Kollisionsprüfung zweier Schiffe reicht es aus, wenn einer der beiden Schifftypen beim entsprechenden Eintrag eine "1" stehen hat.

Da ich das nun abgeschlossen und somit auch den Grundstein für tolle Nicht-Weltraum-Total-Conversions gelegt habe, werde ich mich in nächster Zeit wieder den Waffen widmen. Umherfliegende Projektile und funktionstüchtige Waffen sind ja ganz schön, aber etwas witzlos, wenn sie durch die Schiffe hindurch fliegen ^^

	Fetze	Mo, Apr 17, 2006 16:38 Antworten mit Zitat
Partikel und Partikelemitter sind nun endlich komplett fertig und implementiert. Hier ein Beweisfoto: www.fetzenet.de/neust13.png Grafisch ist das ganze bewusst auf dem Stand von AltST geblieben, aber die durch Partikelemitter theoretisch realisierbaren Effekte sollten sich in ihrer Anzahl etwa verdoppelt haben. Was unterscheidet die alten Partikelemitter nun von den neuen? Was die alten konnten, will ich hier nicht aufführen, aber ich lasse mich mal auf einen kleinen Exkurs zu den Möglichkeiten der neuen ein: Das ist der Partikelemitter eines Antriebsstrahls: Zitat: [PEMTYPE=PEM_ENGINE_RED_1X4] LifeTime=-1 ZPosition=0 EmitStep=New EmitType=New Delay=16 DelayPhase=16 ParticleType=PAR_ENGINE_RED Number=1 Direction=180 Speed=0.1,0.2 SpreadX=2 SpreadY=0 InitialRelativeSpeedMult=0.0 DurationRelativeSpeedMult=0.5 EmitType=End EmitStep=End [/PEMTYPE] Dieser Partikelemitter ist nicht sehr spektakulär. Er lebt unbegrenzt lange (LifeTime), befindet sich hinter jedem Objekt, an dem er dranhängen kann (ZPosition). Alle 16 Millisekunden (Delay), sein Timer beginnt nach der Aktivierung direkt bei 16 (DelayPhase), erstellt der Partikelemitter einen (Number) Partikel des Typs "PAR_ENGINE_RED" (ParticleType) mit einer zufälligen X-Verschiebung relativ zur Position des Partikelemitters von -2 bis 2 (SpreadX) und schickt ihn mit einer Geschwindigkeit von 0.1 bis 0.2 (Speed) nach hinten (Direction). Dieser Partikel übernimmt während dem Flug 50% (DurationRelativeSpeedMult) der Geschwindigkeit des Partikelemitters / Schiffs, an dem der Partikelemitter sitzt, erhält dafür aber bei seiner Emission keine (InitialRelativeSpeedMult) zusätzliche Geschwindigkeit von ihm. Das zu realisieren war auch in AltST kein Problem. Was aber hier bereits neu ist: EmitTypes und EmitSteps. Hierzu eine kleine Erklärung: Jeder Partikelemitter hat beliebig viele EmitSteps. Er beginnt mit dem ersten EmitStep und verhält sich so, wie darin beschrieben wird. Nach Ablauf einer dort angegebenen Zeitspanne wechselt er in den nächsten EmitStep, bis er beim letzten ankommt und von dort aus wieder in den ersten wechselt. Es wird immer nur EIN EmitStep gleichzeitig ausgeführt, während die anderen, gerade inaktiven völlig ignoriert werden. Innerhalb jedes EmitSteps können beliebig viele EmitTypes stehen. Ein EmitType steht stellvertretend für einen Partikeltyp, der emittiert wird. EmitTypes laufen während ihr EmitStep aktiv ist alle gleichzeitig ab, können aber alle eigene Verzögerungen, Austrittswinkel, etc. besitzen. Soger eine eigene Austrittsposition relativ zur Position des eigentlichen Emitters ist möglich. Abgesehen davon können Emittierte Partikel eine Drehung erhalten und die wichtigsten Parameter (Speed, Direction, Spin) unterstützen sowohl einen Zufallswert zwischen zwei Grenzwerten als auch eine gleichmäßige Verteilung zwischen diesen beiden Werten. Konkret: Bei 0,9 und gleichmäßiger Verteilung würde bei 10 Partikeln folgendes zustande kommen: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. Ein Partikelemitter kann also schon ein recht komplexes Verhalten an den Tag legen, aber das oben beschriebene reicht für einige sehr aufwändige Effekte noch nicht aus. Deswegen ist es auch möglich, dass ein Partikelemitter neben Partikeln auch noch Partikelemitter emittiert, was eigentlich so ziemlich jede beliebige Emissionsform oder -struktur ermöglichen sollte, denn auch emittierte PartikelEmitter gehorchen denselben Parametern wie die Partikel. Kommen wir nun zu den Partikeln. Hier ist mal einer: Zitat: [PARTICLETYPE=PAR_ENGINE_RED] LifeTime=300,450 SlowDownMult=1.0 SpinSlowDownMult=1.0 GfxStep=new Duration=100.0,1 StartColor=225,160,45,255 \| 185,105,5,255 EndColor=0,0,0,255 Image=standardparticle.png GfxStep=End [/PARTICLETYPE] (Es ist übrigens der, den der oben gezeigte Partikelemitter verwendet) Dieser Partikel lebt 300 bis 450 Millisekunden (LifeTime), wird nicht langsamer (SlowDownMult) und behält auch seine eventuelle Rotation völlig bei (SpinSlowDownMult). Er besitzt einen GfxStep. Ein GfxStep, was ist das? Jeder Partikel besitzt mindestens einen davon und es verhält sich hier ähnlich wie mit den EmitSteps der Partikelemitter: Es ist immer nur einer aktiv und alle werden von vorne bis hinten durchgegangen, bevor das ganze wieder von vorne losgeht. Ein GfxStep enthält alle Informationen im Bezug auf die Optik des Partikels und dauert immer eine bestimmte Zeit. Die Dauer eines GfxSteps kann entweder relativ zur tatsächlichen lebenszeit des Partikels (Remember: Zufallswert zwischen 2 Grenzwerten!) oder in einer absoluten Zeitspanne angegeben werden. Aber nun zurück zu unserem Beispielpartikel: Sein einziger GfxStep dauert 100% seiner Lebenszeit (Duration), bei Beginn dieses GfxSteps wird seine Farbe 8Alphawert inklusive) auf einen Zufallswert zwischen 225,160,45,255 und 185,105,5,255 gesetzt (StartColor) und während der Dauer dieses GfxSteps wechselt die Farbe dann zu 0,0,0,255 (EndColor). Während dieses GfxSteps hat der Partikel das Bildchen "standardparticle.png" aus dem Gfx-ordner. Auch Partikel können mehr, als man hier sehen kann. Nicht nur bei StartColor sondern auch bei EndColor lassen sich 2 Werte angeben, die eine nBereich bilden. Selbiges gilt für StartSize und EndSize, die die Größe des Partikels verändern können. Optional kann man auch, damit keine Farb- oder Größensprünge entstehen die StartColor weglassen, was dazu führt, dass einfach die Farbe beim Wechsel des GfxSteps als StartColor verwendet wird. Partikel können auf Wunsch auch Additiv gezeichnet werden, was für Lichteffekte toll ist und für einige Partikel ist es auch sinnvoll, den Verhaltensmodus von "Sprite" auf "Spark" umzuschalten, was dazu führt, dass die Grafik mithilfe der letzten Position des Partikels wie ein umherfliegender Funke gedreht und skaliert wird. Es ist fast schade, dass ich vieles davon (Additives Zeichnen, ALpha, Größenvariation,...) in NeuST nicht verwenden werde, aber ich hab nunmal einen Grafikstyle zu bewahren ...solche Spielereien überlasse ich den Moddern g

Fetze

Mo, Apr 17, 2006 16:38
Antworten mit Zitat

Partikel und Partikelemitter sind nun endlich komplett fertig und implementiert. Hier ein Beweisfoto: www.fetzenet.de/neust13.png

Grafisch ist das ganze bewusst auf dem Stand von AltST geblieben, aber die durch Partikelemitter theoretisch realisierbaren Effekte sollten sich in ihrer Anzahl etwa verdoppelt haben. Was unterscheidet die alten Partikelemitter nun von den neuen? Was die alten konnten, will ich hier nicht aufführen, aber ich lasse mich mal auf einen kleinen Exkurs zu den Möglichkeiten der neuen ein:

Das ist der Partikelemitter eines Antriebsstrahls:
Zitat:

[PEMTYPE=PEM_ENGINE_RED_1X4]
LifeTime=-1
ZPosition=0
EmitStep=New
EmitType=New
Delay=16
DelayPhase=16
ParticleType=PAR_ENGINE_RED
Number=1
Direction=180
Speed=0.1,0.2
SpreadX=2
SpreadY=0
InitialRelativeSpeedMult=0.0
DurationRelativeSpeedMult=0.5
EmitType=End
EmitStep=End
[/PEMTYPE]

Dieser Partikelemitter ist nicht sehr spektakulär. Er lebt unbegrenzt lange (LifeTime), befindet sich hinter jedem Objekt, an dem er dranhängen kann (ZPosition). Alle 16 Millisekunden (Delay), sein Timer beginnt nach der Aktivierung direkt bei 16 (DelayPhase), erstellt der Partikelemitter einen (Number) Partikel des Typs "PAR_ENGINE_RED" (ParticleType) mit einer zufälligen X-Verschiebung relativ zur Position des Partikelemitters von -2 bis 2 (SpreadX) und schickt ihn mit einer Geschwindigkeit von 0.1 bis 0.2 (Speed) nach hinten (Direction). Dieser Partikel übernimmt während dem Flug 50% (DurationRelativeSpeedMult) der Geschwindigkeit des Partikelemitters / Schiffs, an dem der Partikelemitter sitzt, erhält dafür aber bei seiner Emission keine (InitialRelativeSpeedMult) zusätzliche Geschwindigkeit von ihm.
Das zu realisieren war auch in AltST kein Problem. Was aber hier bereits neu ist: EmitTypes und EmitSteps. Hierzu eine kleine Erklärung:
Jeder Partikelemitter hat beliebig viele EmitSteps. Er beginnt mit dem ersten EmitStep und verhält sich so, wie darin beschrieben wird. Nach Ablauf einer dort angegebenen Zeitspanne wechselt er in den nächsten EmitStep, bis er beim letzten ankommt und von dort aus wieder in den ersten wechselt. Es wird immer nur EIN EmitStep gleichzeitig ausgeführt, während die anderen, gerade inaktiven völlig ignoriert werden.
Innerhalb jedes EmitSteps können beliebig viele EmitTypes stehen. Ein EmitType steht stellvertretend für einen Partikeltyp, der emittiert wird. EmitTypes laufen während ihr EmitStep aktiv ist alle gleichzeitig ab, können aber alle eigene Verzögerungen, Austrittswinkel, etc. besitzen. Soger eine eigene Austrittsposition relativ zur Position des eigentlichen Emitters ist möglich. Abgesehen davon können Emittierte Partikel eine Drehung erhalten und die wichtigsten Parameter (Speed, Direction, Spin) unterstützen sowohl einen Zufallswert zwischen zwei Grenzwerten als auch eine gleichmäßige Verteilung zwischen diesen beiden Werten. Konkret: Bei 0,9 und gleichmäßiger Verteilung würde bei 10 Partikeln folgendes zustande kommen: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9.

Ein Partikelemitter kann also schon ein recht komplexes Verhalten an den Tag legen, aber das oben beschriebene reicht für einige sehr aufwändige Effekte noch nicht aus. Deswegen ist es auch möglich, dass ein Partikelemitter neben Partikeln auch noch Partikelemitter emittiert, was eigentlich so ziemlich jede beliebige Emissionsform oder -struktur ermöglichen sollte, denn auch emittierte PartikelEmitter gehorchen denselben Parametern wie die Partikel.

Kommen wir nun zu den Partikeln. Hier ist mal einer:
Zitat:

[PARTICLETYPE=PAR_ENGINE_RED]
LifeTime=300,450
SlowDownMult=1.0
SpinSlowDownMult=1.0
GfxStep=new
Duration=100.0,1
StartColor=225,160,45,255 | 185,105,5,255
EndColor=0,0,0,255
Image=standardparticle.png
GfxStep=End
[/PARTICLETYPE]

(Es ist übrigens der, den der oben gezeigte Partikelemitter verwendet)

Dieser Partikel lebt 300 bis 450 Millisekunden (LifeTime), wird nicht langsamer (SlowDownMult) und behält auch seine eventuelle Rotation völlig bei (SpinSlowDownMult). Er besitzt einen GfxStep. Ein GfxStep, was ist das? Jeder Partikel besitzt mindestens einen davon und es verhält sich hier ähnlich wie mit den EmitSteps der Partikelemitter: Es ist immer nur einer aktiv und alle werden von vorne bis hinten durchgegangen, bevor das ganze wieder von vorne losgeht. Ein GfxStep enthält alle Informationen im Bezug auf die Optik des Partikels und dauert immer eine bestimmte Zeit. Die Dauer eines GfxSteps kann entweder relativ zur tatsächlichen lebenszeit des Partikels (Remember: Zufallswert zwischen 2 Grenzwerten!) oder in einer absoluten Zeitspanne angegeben werden. Aber nun zurück zu unserem Beispielpartikel:
Sein einziger GfxStep dauert 100% seiner Lebenszeit (Duration), bei Beginn dieses GfxSteps wird seine Farbe 8Alphawert inklusive) auf einen Zufallswert zwischen 225,160,45,255 und 185,105,5,255 gesetzt (StartColor) und während der Dauer dieses GfxSteps wechselt die Farbe dann zu 0,0,0,255 (EndColor). Während dieses GfxSteps hat der Partikel das Bildchen "standardparticle.png" aus dem Gfx-ordner.

Auch Partikel können mehr, als man hier sehen kann. Nicht nur bei StartColor sondern auch bei EndColor lassen sich 2 Werte angeben, die eine nBereich bilden. Selbiges gilt für StartSize und EndSize, die die Größe des Partikels verändern können. Optional kann man auch, damit keine Farb- oder Größensprünge entstehen die StartColor weglassen, was dazu führt, dass einfach die Farbe beim Wechsel des GfxSteps als StartColor verwendet wird. Partikel können auf Wunsch auch Additiv gezeichnet werden, was für Lichteffekte toll ist und für einige Partikel ist es auch sinnvoll, den Verhaltensmodus von "Sprite" auf "Spark" umzuschalten, was dazu führt, dass die Grafik mithilfe der letzten Position des Partikels wie ein umherfliegender Funke gedreht und skaliert wird.

Es ist fast schade, dass ich vieles davon (Additives Zeichnen, ALpha, Größenvariation,...) in NeuST nicht verwenden werde, aber ich hab nunmal einen Grafikstyle zu bewahren Wink

...solche Spielereien überlasse ich den Moddern *g*

	Justus	Mo, Apr 17, 2006 21:55 Antworten mit Zitat
Du scheinst wirklich jeden einzelnen pixeligen Pixel deines gepixelten Pixelzeugs zu lieben Weiter so ^^

Justus

Mo, Apr 17, 2006 21:55
Antworten mit Zitat

Du scheinst wirklich jeden einzelnen pixeligen Pixel deines gepixelten Pixelzeugs zu lieben Wink

Weiter so ^^

	Ironstorm Erstklassiger Contest-Veranstalter	Di, Apr 18, 2006 12:35 Antworten mit Zitat
^^ Was fürn Satz Justus! Gibt es eigentlich schon ein Modder der einen bessere Grafik gemacht hat???? Hoffentlich, weil ich verliere den Spielspaß wenn ich diese Pixelgrafik anschaue. Das ist meine meinung. MFG Blitzmaker

Ironstorm

Erstklassiger Contest-Veranstalter

Di, Apr 18, 2006 12:35
Antworten mit Zitat

^^ Was fürn Satz Justus!

Gibt es eigentlich schon ein Modder der einen bessere Grafik gemacht hat????

Hoffentlich, weil ich verliere den Spielspaß wenn ich diese Pixelgrafik anschaue. Das ist meine meinung. Wink

MFG
Blitzmaker

Gehe zu Seite Zurück 1, 2, 3 ... 10, 11, 12, 13, 14, 15 Weiter

Übersicht

Sonstiges

Projekte

Nach Oben

BlitzBasic Portal

Immer aktuelle News: StarTrade - aktuelle Beta: 12.06.05

Ava

Ava

Ava

Sung