Eigt. ganz einfach.

Zum aufheben:
Spieler:
-Create Event:


Waffe/n
Key press I Event


Und bei deinewaffe kommt noch ins step event

Das Erklären überlass ich jetzt mal Prustel, aber dass muss in Zeile 8 des Key Press I Event so heißen:


oder wenigstens


-Tobi

Das ist ziemlich paradox, Prustel. Ich sehe nicht, dass es in der Praxis Probleme geben dürfte, aber theoretisch ist es konzeptioneller Stuss. Du hast jetzt eingeführt, dass Waffen bei Knopfdruck auf I prüfen ob sie Kontakt mit dem Spieler haben und alles mit einer globalen Variable "Waffe" gelöst. Das heißt also, dass wenn tausend Waffen rumliegen, tausend Checks durchgeführt werden. Und zusätzlich gibt es jetzt nur eine Waffen-Variable im gesamten Spiel, sodass man das Game nicht ohne weiteres um einen zweiten Spieler ergänzen oder das System auch auf Gegner übertragen könnte. Und als Sahnehäubchen: Du musst nochmal ein umständliches System einführen um feuern (da die aufgehobene Waffe sich in nichts von rumliegenden Waffen unterscheidet - es sei denn Du willst wie schon beim Aufheben bei jedem Schuss prüfen ob Kontakt mit dem Spieler existiert).

Professioneller wäre es dem Spielerobjekt die Variable "Waffe" zu geben.
Drückt man "i" während eine Kollision mit einer Waffe vorhanden ist, sollte die rumliegende Waffe zerstört und dafür eine getragene einfach "gedrawt" werden - mehr nicht.
Das Feuern sollte beim Spielerobjekt erfolgen, allerdings muss natürlich geprüft werden welche Waffe er trägt - d.h. also beim Aufheben der Waffe sollte die Variable "waffe" einen passenden Wert zur aufgehobenen Waffe kriegen (mit 0 = unbewaffnet, 1 = Pistole, 2 = Schrotflinte) - sprich: einfach beim Key-Press Event von "i" prüfen welche Waffe rumliegt und einen entsprechenden Wert zuweisen.
Und nun sollte beim Schussevent immer geprüft werden welchen Wert die Variable "waffe" hat um entsprechende Schüsse zu createn.
Und außerdem sollte wiederholtes Drücken von "i" die aufgehobene Waffe wohl besser nicht einfach zerstören, sondern fallen lassen - also die Variable "waffe" auf 0 setzen und eine von diesen rumliegenden Waffen kreieren, am besten mit Gravity und auf Handhöhe, damit die Waffe ganz stylish runterfällt.

So würde ich es machen. Ich habe es natürlich nicht absolut genau beschrieben, wie man es machen muss - ebenso bin ich jetzt nicht darauf eingegangen, wie ich es machen würde um verschiedene Feuerraten zu machen - aber schließlich sollte auch etwas Eigenarbeit dabei sein.

Ich finde aber, das mit der "virtuellen" Waffe, die eig gar nicht existiert und der Spieler selbst das Schiessen und so übernimmt, ist nicht gerade eine schöne Lösung. Da musst du ne ewig lange switch-Anweisung schreiben und zusätzlich ein Waffen-Objekt erstellen. Auf die Dauer ist das ziemlich nervig und unflexibel(Zumindest, wenn man etwa während dem Spiel neue Waffen generieren möchte). Ich würde ein Standart Waffenobjekt haben, das als Parent Objekt von allen anderen Waffen genutzt werden kann. Der Player überprüft nun Kollision mit dem Standart-Waffenmodell und fügt die Waffen-id entsprechend einer Liste hinzu oder aktiviert die Waffe einfach, wobei die Waffe über die ID des Players, der die Waffe aufgehoben hat, bescheit weis. Das Waffenobjekt selbst hat nun 3 "States", die den aktuellen Zustand der Waffe beschreiben. State 1: Waffe liegt rum, bereit zum Aufheben. State 2: Waffe gehört dem Player, ist aber nicht aktiv. State 3: Waffe aktiv.
Nun überprüft die Waffe den State und benimmt sich entsprechend. Ist der State nun etwa 3, also die Waffe aktiv, und bekommt sie vom playerobjekt den Befehl zum Schiessen, schiesst sie ihre individuelle Kugel ab. Alle anderen Waffen erben jetzt von dieser BasisWaffe und man muss nur noch Eigenschaften wie Schusstyp oder dergleichen anpassen. Klingt jetzt komplizierter als es ist... Mache vl ein Beispiel, wenn erwünscht.. Natürlich, ich glaube, dir würde F4LLOUTS Lösung völlig genügen, nur wenn dein Spiel komplexer wird(würde), ist seine Methode weniger geeignet.

Naja vielleicht ist es als Anfänger komplizierter, aber F4LL0UTs lösung ist nicht so schlecht wie du behauptest. Außerdem spart man sich die verschiedenen Objekte. Und wenn du zb am Anfang Arrays für die Scripts der verschiedenen Waffen einführst, bröuchtest du beispielsweise im Mouse-Pressed nur mehr script_execute(waffe[ nummer ]) ausführen, ohne aufwendige switches.
Ich will dir jetz nix unterstellen, aber ich glaube net, dass du diese Lösung gut untersucht hast, denn das ist so wirklich die kompakteste und am leichtesten ausbaufähigste.

Die Lösung von blubberblub halte ich für die Beste. Mache ich auch in etwa so.

Ich habe z.B. ein Weapon-Parent und änder das mit instance_change jeweils in den Waffentyp den ich brauche. Schießen und Munition werden so spezifisch von jeder Waffe selbst geregelt. Alles was die Waffen gemeinsam haben ist ihre Oberklasse Weapon-Parent von der sie grundlegende Dinge erben wie z.B. die Darstellung an Player.x und Player.y.
Waffen aufsammeln habe ich auch über eine Liste gelöst. So kann man bequem festlegen welche Waffe der Player gerade benutzt und entsprechend darauf reagieren. Kein einziger Switchblock oder ähnliche Variablenspielereien.
Das kommt zwar auf die persönliche Vorliebe an aber ich halte das wie gesagt für die sauberste Methode. Das tolle am GM ist ja die Objektorientierung inkl. Vererbung also sollte man das auch voll ausnutzen.

Wenn ihr wollt kann ich das auch mal in ein Example packen :x

Da du mit Lite arbeitest gehen dummerweise keine Listenfunktionen und das selbst zu implementieren duerfte fuer dich zu komplex sein, ansonsten haette ich einfach meine murksige Platformengine hochgeladen
Nen Example wie man das mit den Waffen macht hab ich trotzdem, auch wenn ich auf Variablen zurückgreifen musste.
Hab soviel unnoetiges Zeug wie moeglich weggelassen und nur das Noetigste eingebaut, das muesste recht einfach zu verstehen sein, hab auch alles kommentiert.

Zu Parents:
Es gibt einen Satz mit dem steht und faellt die Objektorientierung: Jede Instanz einer Subklasse ist auch Instanz ihrer Basisklasse.

Also ist jedes Objekt das du erstellst und dem du ein Parent zuweist, auch gleichzeitig vom Typ des Parentobjekts.
obj_Pistol hat Weapon als Parent, d.h. du kannst jede Instanz vom Typ obj_Pistol auch ueber Weapon ansprechen. Diese Vielgestaltigkeit ist meiner Meinung nach noch ein viel maechtigeres Werkzeug ist als reine Code-Vererbung.

Mit
with(Weapon){
...
}

kannst du nun z.B. alle Waffen ansteuern, egal welche konkrete Gestalt dieses Objekt hat.

OOP
Was ich nich ganz kapier, is, wieso du die Waffen nich einfach in nen Array gepackt hast? Das Beispiel is ja ganz gut... aber.... die switch Schleife find ich unnötig.. =P

Ja nen array wär nen bisschen besser gewesen... aber ... du siehst ja, er weiß nich wasn array is :p

Ein Array ist uebrigens ein Feld von Werten (normalerweise) gleicher Datentypen. Weiss jetzt nicht wie der GM das unterstuezt, aber kann gut sein, dass man in ein Array auch mehrere verschiedene Datentypen ablegen kann.
Normalerweise legt man ein array auf eine bestimmte Laenge fest (sollte man zumindest) und kann dann ueber einen Index auf den Wert an dieser Position im Feld zugreifen. Besser kann ichs grad nich erklären x.x

@lewa:
Ne du musst nur shift druecken, dann kannste die Waffen durchschalten. Das war jetzt nurn Beispiel für Parents.

Die Waffen programmierst du dir wie du lustig bist. Dann legst du dir nen neues Object an z.B. item_pistole oder so.
Wenn der Spieler jetzt auf dem item-Objekt steht und irgendne Taste drueckt kannst du die aktuelle waffe so aendern:

with(WeaponParent) {
instance_change(die_waffe_die_der_spieler_haben_soll, true);
}

Dann hat der Spieler eben nur noch die Waffe. Wenn du ne Art Inventar willst machste das wie in dem Beispiel. Du kannst die Switch-Anweisung noch um beliebig viele Waffen erweitern, musst dann allerdings die Variable maxweapons anpassen.

Besser kann ichs grad nich erklären x.x

Dann versuche ich es gerade, weil dieses informatische Kauderwelsch mich auch am Anfang in den Wahnsinn getrieben hat, während die Erklärung eines Arrays am Ende etwas ganz einfaches gibt.

Arrays sind im Prinzip Sammlungen von Variablen. So wie Du in einer Variable einen Wert festhalten kannst, kannst Du in einem einzelnen Array ganz viele festhalten. Und wo die Werte sind, das hältst Du mit Addressen fest. Ein Array sieht beim Zugriff im Prinzip so aus "array[x]". Das wäre ein Beispiel für ein eindimensionales Array. Du kannst nun etwa "array[0]" auf einen Wert setzen, "array[1]" auf einen anderen und "array[2]" auf einen wieder anderen. Dann hast Du also in einem einzelnen Array, wenn Du immer weiter durchgehst mit den eckigen Klammern viele verschiedene Variablen (und kannst mit zählschleifen etwa den Inhalt des gesamten Arrays in einem Stück auslesen. So kannst Du etwa das Array mit [0] = T, [1] = E, [2] = S und [3] = T ausfüllen. Wenn Du das Array nun von Addresse zu Addresse weiter gehend ausliest erhältst Du das Wort "TEST".

Nun kannst Du aber nun Arrays auch mehrere Dimensionen geben (der Gamemaker unterstützt allerdings maximal 2 Dimensionen) was etwa gut geeignet ist um Rechteckige Felder festzuhalten wie etwa ein TicTacToe-Feld. So steht dann "array[0,0]" für das Feld ganz oben links, "array[0,2]" für das Feld unten links (nämlich 0 Felder nach rechts und zwei nach unten) und "array[2,2]" für das Feld unten rechts. Willst Du etwa festhalten, dass sich im mittleren Feld ein "x" befindet, setzst Du einfach "array[1,1]" auf "x" (von oben links ausgehend, ein Feld nach rechts und eines nach unten ist logischer Weise die Mitte).

Natürlich sollte man das Array nicht einfach "array" nennen, was nämlich zu bösen Problemen führen könnte, aber ich denke das Prinzip hinter Arrays dürfte nun klar sein. Wenn nicht, frag ruhig nach - mich hatte das ehrlich gesagt ziemlich zur Weißglut gebracht, als mir alle sagten "ja, ist'n Feld mit mehreren Dimensionen", ohne mir etwa an einem praktischen Beispiel zu zeigen, was die damit wirklich meinen. Ich denke das TicTacToe-Beispiel (zu Deutsch "x und o" - nur für den Fall ;)) ist sehr gut dazu geeignet um Arrays zu beschreiben.

Sorry, wenn ich das hier wieder hochkrame, nur hab ich mich grade fast verschluckt. So eine Frage und dann LEWA? WTF! Aber dann das Datum,und meine Beruhigung

Jetzt mal ernsthaft... Hast du es wirklich seriös für notig gehalten diesen absolut überflüssigen Post zu schreiben? O.o

" *beil auf deinen Kopf hau* Ups.. sorry, ich hab dich umgebracht. "

Einfach "sorry" zu sagen entschuldigt auch nicht alles, solltest du vieleicht wissen.

Vieleicht bräuchte dieses Forum ein "Archiv" (wo alte Threads automatisch hin verschoben werden) so wie es andere auch haben so dass solche Leichenschändung nicht mehr vorkommt..

Ich finde, das zeigt wie krass LEWA sich entwickelt hat. Jeder hat so angefangen. Jeder lernt täglich hinzu und erweitert seinen Horizont.
Dennoch halte ich ein Archiv für sinnvoll. Ist vielleicht übersichtlicher.

So ein Archiv gibt es bereits, automatisch hinverschieben tun wir da allerdings nichts - schon gar nicht Technikfragen, die ja später noch als Referenzlektüre für Andere dienen sollen.

Und ansonsten kriegt Tezla jetzt halt ne Verwarnung mit dem freundlichen Hinweis, sich doch nach 5 Monaten Mitgliedschaft bitte endlich mal die Regeln durchzulesen und, wie alle anderen auch, die immer wieder schöne Einsicht, dass auch der profihafteste Profi mal Fragen zu ganz simplen Sachen stellen musste.

Achja, und der Thread kriegt ein vergoldetes Vorhängeschloss. Und schon sind alle wieder glücklich, fallera.

Edit:
@ DragonGamer: Also, den Vergleich hab ich hier ja auch noch nie gesehen. Threadnekromantie <=> Mord? Wow. Wusste gar nicht, dass wir hier so viele Schwerverbrecher im Board haben. Sind Fangames dann gleichzusetzen mit Atombombenbau? o.o