Suchergebnisse

Das is nice. Cool, danke für die Info

Also, bei persistenten Klassen reicht es eigentlich, wenn Du sie im ersten Room des Spiels setzt und dann in keinem anderen mehr. Falls Du das aber nicht willst, sollte das eigentlich funktionieren: GML-Quellcode (3 Zeilen) Einen eigenen Counter zu machen wäre seltsam, da GML-Quellcode (1 Zeile) genau dasselbe macht. Dass diese beiden Methoden bei Dir nicht funktionieren kann ich mir schwer vorstellen. Wo führst Du denn die Überprüfung genau aus?

Kleiner Tipp: Verwende bei Vergleichen immer "==" und klammere das ganze Comparison ein, also so: GML-Quellcode (1 Zeile) Auch wenn's in GML mit nur einem "=" funktioniert, es ist recht unsicher und kann nach hinten losgehen. Normalerweise wird in dieser Art von Syntax (C++, php, C, usw) ein einzelnes "=" nur zum setzen einer Variable verwendet, aber nie zum vergleich. Dazu gibt's oben drauf noch "===", als typensicheren Vergleich (den kenn ich aber bis jetzt nur aus php)

Danke für diese ausführliche Antwort, Lewa. Also, ich verwende nicht 200 Surfaces im Spiel, ich habe nur einmal 200 Surfaces im Prototyp erstellt, um es zu testen. Das hat auch wunderbar funktioniert, nur in meinem tatsächlichen Projekt waren manchmal 2 Surfaces bereits tödlich. Das heißt, dass das Problem ja wohl definitiv an dem Code meines Projekts liegt. Mir geht es auch nicht um FPS Drops, das Problem ist, dass das Spiel (vor der Überarbeitung) bei absolut jedem Tester gecrashed ist. Lustig…

Habe nun nen Bugreport dazu erstellt. Diese Notification sollte nur beim Speichern einer Resource gezeigt werden, nicht während dem editieren.

Zitat von Balls of Steel: „Meine Ansätze die ich ausprobieren würde: Lass das Programm nicht mehr benötigte Surface löschen. Überprüfe vor jedem Zugriff auf ein Surface ob es vorhanden ist. Wenn das nicht hilft, dann halt leider den zusätzlichen Code in kleinen schritten einfügen und so die Quelle des Problems eingrenzen.“ Das habe ich alles bereits gemacht. Ich lösche sogar die Surfaces direkt nach der Erstellung, da sie nur für einen Draw verwendet, und nicht Realtime berechnet werden. (werden…

Hallo Leute, ich hab Heute ein kleines Licht/Schatten-Programm gecodet, das durch die Verwendung von vielen einzelnen Surfaces einen halbwegs realistischen Licht/Schattenwurf erzeugt. Im Testprojekt, quasi dem Prototypen, lief Alles fein, keine Abstürze bei 200+ Surfaces/Lichtquellen und Shadowcasters. Hab sogar mit Gewalt versucht, das Programm zum abstürzen zu bringen, keine Chance. Endete meist nur bei <10 fps (während Realtime-Licht/Schattenberechnung, Stepfrequency von 60.) Wenn ich aber di…

Welche ich aber relativ hässlich finde und absolut nicht meiner Handschrift entspricht. Ich benenne meine Klassen z.B. "Player" und meine Methoden "playerDraw();". Es ist hoffentlich verständlich, dass ich meine Handschrift nicht einfach ablegen kann oder will. Eine Möglichkeit, diese komplett irrwitzige "Notification" auszustellen, muss es doch geben.

Guten Morgen, mit jedem Tag, den ich mit GM:S verbringe, komme ich mir ein Stück mehr wie ein D&D-Anfänger vor. Heute dachte ich, ein Surface könnte ganz gut in mein Konzept reinpassen. Haha! Wer's glaubt. Fall #1: Ich habe im Room Start-Event meines Objektes (persistent) folgenden Code stehen: GML-Quellcode (3 Zeilen) Eine Frage nach 'surface_exists()' gibt immer false zurück. Erst wenn ich während dem Step(!) Event den obigen Code aufrufe, wird ein Surface instanziert. Selbiges mit Fall #2, ic…

Hallo Leute, hab hier ein echt nerviges Problem. Will ich in GM:S einen neuen Script erstellen (zB "gameDraw"), der gleich anfängt wie eine anderere Ressource die bereits existiert (zB "Game", die Klasse), poppt eine Warnung auf und GM:S resetted den eingegebenen Namen wieder. Ich verstehe natürlich den Sinn dahinter, aber kann man das abdrehen? Ich kann so nicht arbeiten. Zurzeit muss ich jedes mal "ameScriptName" eingeben, und dann vorne ein "g" hinzufügen, damit GM:S nicht rumschreit. Echt ni…

Aber eine einfache Entschlüsselung würd doch reichen, es den Leuten um einiges schwerer zu machen. Was darin resultieren würde, dass es weniger versuchen. Muss wohl damit klarkommen, dass mein Projekt nun doch Open-Source ist D:

Ich bin mir sehr sicher, dass das geht.

Sorry, es geht schon um GM:S aber dachte im Studioforum gehts um Platformspezifische Sachen. War etwas verwirrt. Danke für Deine Antwort, genau das wollte ich wissen!

Mann kann die Scripts extrahieren. Fügt zu einem beliebigen Script in Eurem Spiel die Zeile "testingthis_lel = 1" hinzu und sucht per STRG+F im Editor nach "testingthis". Du wirst es finden, sowieso alle anderen Ressourcen, quasi das gesamte Spiel.

Danke für den Ausgleich meiner mentalen Beschränktheit.

Ich habs als Installer exportiert und installiert. Hier ein Auszug: Zitat: „ generateMap mapID saveMap gotoMapPlanet demoScore demoTimer room inventoryShow inMenu gameShowInventory logShow gameDrawLog gameDrawHud view_xview _viewx view_yview _viewy SCORE: string draw_text viewx viewy itemBox itemList itemBoxHud index margin invPosX invPosY itemPosX itemPosY h w posx posy inventorySlot draw_sprite selectedItemInMenu i playerItemSlots s playerSpellSlots playerKeySkillUse keyPressed _swap spellSlot…

Hi Leute, ich habe grad auf den YYG Foren gelesen, dass das data.win File halb unverschlüsselt ist. Hab das nun gecheckt, und es stimmt tatsächlich - mitten im File sind alle <ALLE> ressourcen komplett unverschlüsselt hinterlegt. Jeder Variablenname, jeder Spritename, sogar die Inhalte von Scripts und Klassen. :< Das ist doch absolut uncool, so kann einfach jeder den gesamten Sourcecode einsehen, ev. sogar decompilen. Was genau hat sich YYG hierbei gedacht? Kann man das umgehen? Wird's in einem …

Hi Leute, hätte da schon wieder ein Frage. Mein Team und ich haben zurzeit ein etwas größeres Projekt am laufen. (Nein, es ist weder WoW 2.0 noch Minecraft 4D, sorry) Das Spiel wird (grob geschätzt) 400 animierte Sprites haben. Ist das mit GM:S noch regelbar, oder sollte ich die Files auslagern? Bzw. lagert GM:S die Files automatisch in das "data.win" File? Mir kommt vor da mal was gehört zu haben. edit: Habe gerade herausgefunden, dass GM:S alle Spielressourcen zwar extern lagerd, aber unversch…

Danke für die Antwort! Ich hatte diese extension schon mal, aber da hat irgendwas nicht gestimmt. Ich glaub es war die Tatsache dass "working_directory" beim schreiben ja immer nur auf %appdata% geht. Gibts eine Möglichkeit das Verzeichnis, wo die .exe liegt, mit dieser extension zu finden?

Hi Leute, ich hab wieder mal ein wenig rumgespielt mit GM:S, folgender Code ist nun relevant: GML-Quellcode (9 Zeilen) Wenn ich das Spiel nun im Testmodus (von GameMaker aus) starte, wird das unter "...\AppData\Local\Game\..." gespeichert. Das ist ja OK. Aber! Wenn das Spiel nun als Build gestartet wird (nach dem Export) speichert er das immer noch dort. Obwohl in meinen Logs folgendes steht: "Saving Map in C:/Users/Name/Game/maps/M_27a39bf28a2669867d6319fb8334ee24.map". Wie umgehe ich das?