Suchergebnisse

:ops:

ich hab dir mal ein einfaches beispiel zusammengestellt. es gibt aber noch einige galantere methoden nachrichten-boxen darzustellen: im beispiel erscheinen nach und nach 3 messageboxen, die man abwarten kann, oder einfach return bzw. die linke mazustaste drückt. eine nachricht wird so generiert: global.message_text='Hier kommt der Text rein...'; instance_create(250,200,obj_MessageBox); die werte 250 und 200 stellen die position an der die nachricht erscheint...

das ist kein bug sondern absicht. ein object das einen draw event ausführt, wird nicht mehr angezeigt, da es meistens andere sachen als sich selbst anzeigen soll. du kannst das object aber weiterhin anzeigen lassen, indem du im draw event z..b. diesen code verwendest: draw_sprite(sprite_get_name(image_index),-1,x,y) statt sprite_get_name(image_index) kannst du auch einfach den namen des sprites eintragen...

der show_message() befehl und entsprechend ähnliche funktionen sind leider etwas eingeschränkt. das liegt daran, das es nur modifizierte windows messageboxen sind. ein solches fenster springt "in den vordergrund" und hält die eigendliche anwendung (das spiel) solage kompett an. bestätigen ist mit der linker maustaste auf ok, der enter- sowie returntaste möglich, abbrechen nur mit der ESC-taste. also kann der user entscheiden ob er mit der maus bestätigen will, oder sich der tastatur bedient. ein…

es ist zwar etwas unforteilhsft gemacht, aber nun müsste es so funktionieren, wie du dir das gedacht hast: klickmichichbineinlink

für beide objecte geht es nicht. eine view kann immer nur einem object folgen. du kannst aber beim wechsel auf "spieler2" der view mitteilen, diesem object du folgen. einfach direkt nach dem wechsel (das object muss im raum vorhanden sein) view_object[0]=spieler2; eingeben.

wiso wechselt die spielfigur den überhaupt? es reicht, wenn du das spite änderst. eine playerfigur aus mehr als einem teil zu machen (ausgenommen extras wie waffen etc.) ist meistens nicht grade günstig. der code (der zumindest teilwiese richtig war) soll eigendlich das einrichten einer view in jedem neuen raum überflüssig machen: // Definiert das object, dem die view folgen soll view_object[0]=figur; // Definiert den horizontalen rand, bei // dessen berührung die view bewegt wird view_hborder[0…

ok das hätte ich vorher wissen müssen. der code muss dann so geändert werden: view_object[0]=obj_player; view_hborder[0]=(view_height[0]/2)-50; view_vborder[0]=(view_width[0]/2)-50; view_visible[0]=true; kann sein das das auch nicht klappt, hab ein bischen was gebechert... werde mir morgen nochmal meine verbrechen hier ansehen.

das der raum dem spieler folgt? das ist nicht möglich, da der raum eine feste grösse besitzt. du meinst warscheinlich, das eine view dem spieler folgt. das geht z.b. so: im createevent des players (oder was auch immer) view_object[0]=obj_player; view_hborder[0]=(view_hview[0]/2)-50; view_vborder[0]=(view_wview[0]/2)-50; view_visible[0]=true;

wenn du bei x und y den speed des splayers angibts, wird das messer oben links in der ecke angezeigt werden, das der speed des players ja meistens eine zahl zwischen 1 und 10 beträgt. das ist natürlich auch möglich aber du muss z.b. einen solchen code verwenden: vspeed=spieler.vspeed; hspeed=spieler.hspeed; es gibt manigfaltige möglichkeiten das messer an die entsprechende stelle zu bewegen. es ist vor allem fraglich, wie das messer im spiel agieren soll. hier ein kleines beispiel, wie ich mir d…

wenn du diesen code im step event des messers einfügst: if alarm[0]=0 { x=spieler.x-20 y=spieler.y } folgt es dem spieler auf schritt und tritt. allerdings dürfte es immer einen frame hinterherhinken. das liegt einfach daran, das der GM stepbsiert arbeitet und so eine sache nach der anderen abgefragt wird. eine weitere möglichkeit wäre, das messer im draw event des spielers anzeigen zu lassen: draw_sprite(x,y,spieler,-1); draw_sprite(x-20+alarm[0],y,messer,-1); oder sowas. alarm[0] stellt dabei …

ich bin mir ja nicht sicher ob das hilft, aber es gibt die befehle screen_redraw() und screen_refresh(). mit deren hilfe kannst du wärend eines steps den screen aktualisieren. screen_redraw() führt zusätzlich den draw event neu aus, das tut screen_refresh() nicht.

hallo! das ist eigendlich ganz einfach. du benötigst neben deinem camera object ein hud-object (man kann es auch in einem object lösen, muss dann aber ständig einige variablen umstellen). dort kommt dann in den draw event z.b. dieser code rein: GML-Quellcode (8 Zeilen)

If var >= 1 && var <=10 {"dein code"}

ich würde keine weitere variable definieren, sondern den alarm selber für meine abfrage benutzen: im create event: // setzt den alarm0 auf 90, ca. 3 sekunden alarm[0]=90 im step event: //zeigt wenn der alarm 0 grösser ist als 0 den text an if global.schluessel=0 && alarm[0]>0 {draw_text(100,100,'Es fehlt noch der Schlüssel');} das hat den vorteil, das du z.b. wenn der spieler gegen die tür läuft, den alarm wieder auf 90 stellen kannst un der text wieder angezeigt wird, um dem spieler darauf hinz…

warum wird den das object bei draw gelöscht? realtiv einfach lässt sich das so lösen, das du in dein steuerungs-object, im draw event, diesen code einfügst: if global.schluessel=0 {draw_text(100,100,'Es fehlt noch der Schlüssel');}

ich verstehe nicht so ganz was der "meterzähler" denn zählen soll. die bisher zurückgelegte strecke oder die entfernung zum nullpunkt? wie dem auch sei, einen wert negativierten kannst du mit einem einfachen minus: global.meter = spieler.x + (-global.spieler_y)

das mit dem spielstand laden ist im GM so eine sache. das spiel wird erst geladen, wenn der ganze code, des aktuellen events interpretiert wurde. nun ist aber dein letzer befehl, die zu ladende datei zu löschen, was auch ausgeführt wird. den spilstand kann der GM dann aber nichtmehr laden. du kannst dich aber eines kleinen trick bedienen wenn der quicksave gelöscht werden soll: einfach vor dem erstellen des quicksave einen alarm event oder ähnliches einrichten, der ein paar steps später ausgefüh…

Zitat: „Original von croxx +Benutzerfreundlich -laaaaaaaaaaannnnnggggggggggggsssssssssssssaaaaaaaaaammmmmmm -sehr große EXEn“ ich weis gar nicht was ihr alle habt. der GM wird nur langsam, wenn man scheisse proggt. wenn man sich etwas ansternegt und das object orierntierte progen einigermassen verstanden hat. kann man eine fast beliebige FPS anzahl rausholen. und das die "grund EXE" einen MB gross ist finde ich nicht schlimm.

also spiele wie Final 10 und warhammer 40k lassen sich nur schwer vergleichen. natürlich geben die japaner mal eben 2 mio für ein spiel aus, denn sie bekommen das ja auch wieder rein. eventuell hat ja mal jemand was von "Jager" gehört? das sind auch nicht viele leute gewesen und sie haben dennoch etwas nettes auf die beine gestellt (kenne die persönlich deswegen als bsp.). das aber kleine team grosse sachen auf die beine stellen können ist ja schon lange kein geheimniss mehr. die meisten haben n…