Beiträge von Andar

    Also Autorun funktioniert grundsätzlich , wird aber von übergeordneten Parallelen Events überschrieben.

    falsch - wenn ein autorun läuft, dann ist das absolut.


    Ich vermute eher, dass Du einen oder mehrere logische Fehler in Deinen Events hast, und das diese Fehler die normalen Sequenzen durcheinander bringen.

    Nur um das erkennen zu können, müssten wir Screenshots dieser Events sehen.

    einfach die events per autorun steuern - Du hast den Fehler gemacht und sie als Parallel Process laufen gelassen, und das ist in solchen Fällen falsch.

    ein autorun schaltet die Eingabe automatisch ab.


    wenn Du damit probleme hast, gib screenshots des steuernden events.

    Region ID's sind u. a. auch toll wenn du Parallax-Mapping benutzt, um die Begehbarkeiten per Plugin zu regeln.

    nicht wirklich - die benutzung von region IDs für passability ist bequem (weniger arbeit), aber alles andere als toll, da zu eingeschränkt.


    die korrekte Methode für parallax mapping ist die benutzung eines unsichtbaren tilesets, nur ist das ein vielfaches der Arbeit.


    Man benötigt ein Tilesheet mit transparenten Symbolen für alle tileset-optionen, von passability über ladder und bush etc. sowie ein komplett transparentes tilesheet (ohne symbole) desselben Namens.

    Dann erstellt man ein Tileset mit dem Symbolsheet und gibt allen symbolen die passenden Einstellungen in der datenbank zu tilesets.


    dann erstellt man seine Karten mit den Hintergrundbildern als Karte und platziert die Symbole wo man die unterschiedlichen Optionen haben will.


    und wenn das Spiel fertig ist, vor der Verteilung tauscht man das Tilesheet-Bild im Ordner aus gegen das komplett transparente Bild desselben Namens.

    dadurch werden alle symbole für den Spieler unsichtbar, aber die passenden Optionen der Tiles sind nach wie vor aktiv.


    Das gibt die vollen Optionen anstatt nur grundlegender Passierbarkeit wie bei Region-ID, und benötigt keinerlei Plugin.

    wenn ich 60 Schonsteine und 3 Pakettypen habe?

    ja und nein


    ja, es würde funktionieren - aber je mehr events abgefragt werden umso complexer wird das alles.


    deshalb lohnt es sich für ortsfeste zielpunkte auf einen anderen Mechanismus zu wechseln: Region ID.

    alle Zielpunkte erhalten eine spezielle Region-ID anstatt oder zusätzlich zum event zur Markierung, und Du fragst dann das ab.


    Ich habe den Maker gerade auf englisch und weis deshalb nicht wie der Befehl in deutsch heißt, aber "get location info" erlaubt es die region ID einer beliebigen Position in eine Variable zu speichern. das ist dann einfacher abzufragen als die Koordinaten von mehreren dutzend Zielpunkt-events.

    Nur mal als detailliertere Erklärung:


    die ursprüngliche CS2-Version (die kaufbaren Original-CDs) benötigt einen speziellen (und veralteten) DRM-Server, der von Adobe vor Jahren abgeschaltet wurde. Die aktuellen Adobe-DRM-Server funktionieren nur mit CS3 und später.


    D.h. jeder der die originalen CS2-Programme besitzt kann diese nicht mehr von den Original-CDs installieren, da das Setup den dazu notwendigen DRM-Server nicht mehr findet.


    Damit diese alten Kunden trotzdem noch mit ihrem gekauften Programm arbeiten können, hat Adobe die oben verlinkte Spezialversion von CS2 in den Download gestellt.

    Die Verwendung dieses freien Downloads ist aber per EULA an den Besitz einer Originalen CS2-Lizenz gebunden.

    Wenn man eine solche Lizenz nicht besitzt, darf man das Programm auch nicht nutzen.

    Wobei ich hier ehrlich gesagt keinen wirklichen Sinn darin sehe, denn man kann vom MZ mehrere Instanzen öffnen.

    aber dann basieren alle instanzen auf derselben variante.


    Ich hatte z.B. eine Zeitlang den Maker einmal deutsch und einmal englisch installiert, um passende Screenshots machen zu können.

    Oder es gab eine Version des MV (1.6.0 oder 1.6.1, weiß nicht mehr genau), mit der es schlichtweg unmöglich war ein Projekt mit einem 1.5.x oder älteren cores zu öffnen.

    Und es gibt noch ein paar andere Fälle, bei denen die Option zwei unterschiedliche Maker zu haben ganz nützlich war.

    1) es ist kein zusätzlicher Key, es ist dieselbe Lizenz - und dementsprechent ist es nicht legal, jemand anderes damit arbeiten zu lassen.


    2) wie schon oben gesagt ist der Hauptgrund, das die Linux- und Mac-Versionen nur über Steam verteilt werden, es gibt keine Standalone für Mac oder Linux.


    3) die Steam-Version kann einfach zwischen verschiedenen Sprachen oder Editor-versionen (über die Beta-Tab) wechseln, ohne neu installiert werden zu müssen.


    4) der zusätzliche Vorteil ist, das man Standalone und Steam gleichzeitig installieren kann, und auf diese Art zwei Versionen gleichzeitig zur Verfügung hat, z.B. einen deutschen und einen englischen Editor oder einen Editor mit 1.6.2 und einen mit 1.5.1 je nachdem, was und wie man das nutzen will.

    das alles hat absolut gar nichts mit den Grafiken selber zu tun, es liegt an dem automatischen Layering des MV.


    Der MV hat ganz genau 3 Layer für tiles, den Bodenlayer und zwei obere Layer.

    Alles in den A-Tiles geht in den Boden-Layer, und es kann nur ein A-Tile an einer Position sein.

    Alles in den B-E tiles geht abwechselnd in die oberen Layer - was auch bedeuted das eine dritte "dekoration" die erste ersetzt.


    Von diesen Regelungen gibt es nur eine kleine Ausnahme:

    ganz specifische A1 und A2 tiles können im Bodenlayer kombiniert werden.

    Dies gilt aber nur für diese spezifischen Tiles und nicht für irgendein anderes A#-Tile.

    Das ist in den Help-Files des Editors genauer erklärt.

    Dein Problem ist, dass Du etwas versuchst für das die Sprites nicht vorgesehen waren. Die horizontalen Frames sind für die automatische, zyklische animation vorgesehen und nicht für direkte Kontrolle.


    Was Du willst ist NUR mit scriptbefehlen möglich, und selbst diese haben ein paar nebeneffekte.


    Es wäre genau genommen einfacher wenn Du die Animation auf mehrere Sprite aufteilst und dann das Sprite und die Richtung passend wechselst.

    D4rkD schrieb:

    Die Lizenz die du dir da kaufst ist in der Regel 1 Jahr befristet.

    Das ist jetzt auch so ein blöder Trend, den viele Programme in letzter Zeit einschlagen. X(

    Firmen brauchen Einkünfte um zu überleben und weiterhin support zu bieten.


    Früher konnten sie diese Einkünfte erzeugen, indem sie neuere Versionen mit neueren Features verkauft haben, aber alle Programme sind schon seit Jahren stabil und mit allen wünschenswerten Features ausgestattet...

    Bei dieser Problematik würde ich allwerdings auch noch über zwei alternative Lösungsansätze nachdenken:

    1) triple pixel artwork

    2) Shaz change tilesize plugin


    Im ersten Fall trickst Du die Ansicht indem Du jedes Tile und jedes Sprite in Photoshop oder so auf die dreifache Größe hochscalierst. Es sieht dann für den Spieler in Fullscreen ganz genau identisch aus (3x3 pixel-block für jeden original-pixel), aber es arbeitet auch ohne fullscreen und die Bildschirme bleiben normal (nur halt in modern)


    Im zweiten Fall arbeitest Du mit zwei verschiedenen Tilesets (editor benötigt zwangsweise 48x48, aber jedes dieser Platzhalter-Tiles wird im Spiel durch 16x16 tiles ersetzt). Der vorteil hier ist dann, das auch das Grid und die ganze Engine auf 16x16 umgestellt wird. Der Nachteil ist dass Du meistens größere Karten mit einem größeren Sichtbaren ausschnitt hast.

    Probieren ohne zu wissen was man tut hat oft eine Menge unerwünschte Nebeneffekte.


    Entweder man lernt systematisch was wie geht (d.h. mehrere Monate Tutorials), oder man sucht konkret Hilfe.

    Und für den zweiten Fall brauchen wir Screenshots von allen Events um zu gucken was läuft wie schief.

    es hängt davon ab, was die events machen sollen - verkettete autoruns sind in fast allen Fällen ein Problem.

    Aber Deine Beschreibung hört sich nicht so an alsob zwei Autoruns die richtige Lösung sind...

    Preloader Plugins

    Preloader sind per Definition Resourcenfresser - sie sollen ja schließlich Dateien laden, bevor der Computer weiß dass diese benötigt werden, und sie dann bereit halten.

    Was glaubt Ihr wo diese zusätzlichen Dateien gespeichert werden? Richtig, das RAM das bei vielen Computern sowieso knapp ist.


    Preloader bringen nur dann einen guten Nutzen, wenn sie ganz genau gesteuert werden und nicht nur die Dateien so kurzfristig wie möglich vorher laden, sondern sie auch so schnell wie möglich wieder entfernen. Und das geht nur mit entsprechender Steuerung durch den Spielentwickler.


    Aber das ist einfach zuviel technisches Verständnis für die meisten Benutzer, die glauben Preloader-Plugins könnten automatisch arbeiten.


    Savork

    Hast Du meinen zweiten Post oben gelesen?

    weil alle anderen danach scheinen diesen Punkt zu ignorieren, und das ist was ich momentan als wahrscheinlichste Ursache ansehe: Die andere Software auf der besagten Maschine.

    es gibt IMMER einen Grund für unterschiedliches Verhalten.


    Bei den oben beschriebenen Geräten und mit dem beschriebenen Spiel würde ich allerdings anfangen, die Ursache in der Software außerhalb des Makers zu suchen.


    Vergesst nie das der MV und MZ HTML5-Spiele erzeugen, die selbst bei lokalem export in einem Browser laufen.

    Es reicht ein besonders aggressiv eingestelltes Antiviren-Program das Webseiten besonders aufmerksam scannt, und das das Spiel als "Webseite" erkennt und schon geht die Performance abwärts...

    Was ich noch dazu sagen es Laufen 1 parallel event und 3 gewöhnliche Events auf parallel.

    Theoretisch kann ein einzelnes schlecht programmiertes Parallel Process Event selbst den modernsten Computer zum laggen bringen - aber bei dieser kleinen Anzahl an Events ist das eher unwahrscheinlich.

    Jeder computer hat eine reserve gegen lag - und diese ist bei manchen computern deutlich geringer als bei anderen.


    ohne genauere details über die verschiedenen computer mit angaben bei welchen es laggt unf bei welchen nicht kann man gar nichts sagen - noch nicht einmal ob die Ursache im RM-Spiel liegt oder nicht.

    Welche Auflösung hat eigentlich der RPG Maker 2K? Hab früher damit gearbeitet und hatte nie ein Problem .

    das hatte aber nichts mit der Auflösung des RM2K zu tun, denn die war noch problematischer.

    Alles bis einschließlich VXA war und ist auf eine maximale screen size von 640x480 beschränkt.


    Es gibt zwei unterschiedliche Gründe für den schwarzen Rand, und keiner von beiden hat was mit den Makern selber zu tun, sondern mit der Art wie Grafikkarten arbeiten.


    Das erste Problem ist das Seitenverhältnis.

    Wenn die eingegebene Bildschirmgröße ein anderes Seitenverhältnis hat als der Monitor, dann kann immer nur ein Wert an das Maximum angepasst werden, der zweite Wert wird aufgrund fehlender Daten automatisch kleiner bleiben. Je nachdem wie groß der Unterschied ist und auf welcher Achse, gibt es dann unterschiedlich breite schwarze Balken aufgrund fehlender Daten.


    Das zweite Problem sind billig programmierte Treiber und billig produzierte Grafikchips.

    Viele Grafikkarten sind nicht in der Lage, etwas anderes als die üblichen Standardwerte für Bildschirmgrößen zu verarbeiten. Wenn man diesen Grafikkarten eine ungewöhnliche Größe gibt, dann schalten sie stattdessen auf die nächst-höhere Standardgröße (z.B. 1024x768 anstatt 816x624). Und das bewirkt auch einen schwarzen Rand.

    (Allerdings gibt es auch gute Gründe für diese Vorgehensweise - je mehr unterschiedliche Optionen der Grafiktreiber verarbeiten muss, umso langsamer wird er. Und viele Gamer wollen schnelle Treiber...)

    nein, nichts kann den editor ändern.


    allerdings hat Shaz ein Plugin zum ändern der Tilegröße geschrieben, dass stattdessen mit zwei verschiedenen Tilesets arbeitet - ein Platzhalterset damit der Editor funktioniert, und im Spiel wird dann das grid und das tileset mit dem in der eingestellten Größe geändert.