Beiträge von Andar

    Ich bin da halt etwas pingelig

    das sollte dann aber in beide Richtungen gehen, denn das was Du in Deinem Post oben zusammengetragen hast ist exakt dasselbe was ich in meinem von Dir beanstandeten Post geschrieben habe:

    Das das Skript zuerst einen Fehler hatte der es nicht in der legalen Version laufen lies, das dieser Fehler dann korrigiert wurde aber das Skript trotzdem auch in der zweiten Version fehlerhaft war, weil der zweite Fehler mit der @option immer noch drin war.


    Und das das skript in einigen Versionen funktioniert liegt wahrscheinlich an unterschiedlich implementierten Ruby-Interpretern. Strings werden in den meisten Programiersprachen intern als arrays aus Buchstaben gespeichert. Deshalb kann die Referenz auf dieselben Werte zeigen, auch wenn die Befehle logisch falsch sind und als solche vom Interpreter abgefangen werden sollten.

    Bitte keine falschen Informationen verbreiten und für Verwirrung sorgen.
    Bei der illegalen RMXP-Version ging es um einen fragenden Poster, der keine ordentliche Fehlermeldung von der Maker-Engine bekommt,

    Ich denke, Du hast da einen Post verwechselt. Die Fehlermeldung ist weiter unten in dem topic.

    Das Zitat auf das ich mich bezog war


    Zitat


    OK I just tried this out. It works in the Postality Knights version but not the legal version of RMXP.

    von WYZRD in antwort #3, gefolgt von einem "Script Fixed" direkt im nächsten Post.

    Die Fragezeichen-Fehlermeldung kam erst nach dem "Script Fixed", wie soll man das also anders interpretieren?

    Leider muss ich zustimmen, dass meine erste option doch die richtige war.


    Der originale Skripter hat es tatsächlich geschafft ein Skript ZWEIMAL defekt zu posten. Wenn Ihr Euch die Antworten auf den verlinkten Post anschaut, kommt direkt die erste das das originale Skript nur mit einem modifizierten RMXP in einer der alten Piratenversionen funktioniert, gefolgt von einem Post das der Fehler behoben wäre - nur das der Fehler der falschen @option immer noch drin ist.

    Ich halte es für unwahrscheinlich dass die Änderung im Code funktionieren wird. Denn das würde den Fehler nur technisch beheben aber im Kontext keinen Sinn machen.


    Der Programmierer hat das Skript so geschrieben, das es funktioniert mit @option.


    Der Fehler besagt das die Funktion einen Array erhält, wenn Sie ein einzelnes Element (eine Zeichenkette/string) erwartet.


    Das kann aber zwei verschiedene Ursachen haben:

    Ein Programmierfehler mit dem falschen code (das was Grandro vermutet und korrigiert hat)

    Ein Konfigurationsfehler bei dem die falschen Daten an die Funktion gegeben werden (weshalb ich in meinem Post oben von falschen Daten sprach)


    Und was ist jetzt wahrscheinlicher?

    Wenn es ein Programmierfehler war, dann hat das Skript niemals und für niemanden korrekt funktioniert. Und kann auch weitere Fehler enthalten, da nie getestet.

    Oder dass Du in der Konfiguration einen Fehler gemacht hast, was nur in Deinem Projekt die falschen Daten an die Funktion liefert?


    Aber um das zweite (und meiner Meinung nach wahrscheinlichere) prüfen zu können, brauchen wir das ganze Skript (als Link) sowie was Du als Konfiguration eingetragen hast (wie auch immer das Skript konfiguriert wird).

    der Fehler sagt im wesentlichen, dass die Zeile die falschen Datenformate bekommen hat.

    und in dem Kontext würde ich sagen, dass Du das Skript falsch konfiguriert hast - mit den falschen Daten.


    um so etwas genauer analysieren zu können, braucht man sowohl das Originalskript alsauch eine Liste der Änderungen, die Du in der Konfiguration vorgenommen hast.


    das muss aber jemand anders machen, da ich mich mit XP gar nicht auskenne.

    leider kann ich die Agilität nicht in den Minusbereich setzen.

    das liegt daran, dass der Parameter ein multiplikativer ist.


    Basis = 100%

    erhöhen bei >100%

    verringern bei <100%


    wenn Du den parameter auf 0% setzt dann hat Dein Held gar keine Agilität mehr (0% mal AGI ergibt 0), schlechter als das gehts gar nicht.

    "Farbewerte aus transparenten Pixeln" aktiviert habe.

    das hört sich eher nach genau der falschen option an.


    moderne transparenz (und die modernen maker) arbeiten mit alpha-channel für transparenz.


    farbaustausch transparenz ist eher alt und wird heute nur noch bei formaten ohne alpha (z.B. jpg) genutzt.



    wenn dieser Tip nicht reicht, dann hänge das Bild als anhang an, dann muss das jemand genauer prüfen.

    Schlimmer - das was man sieht ist eindeutig von einer sehr frühen Entwicklungsversion und hätte lediglich in ein Devlog-Video gepasst aber niemals in einen Werbetrailer.


    Sieht so aus alsob das Marketing mal wieder Druck für einen zu frühen Release-Termin macht.


    und das neue Devlog ist auch geschmackssache - sie haben das Modell für Vorschläge (das bisher auf Actor-Werte und Schadensformel begrenzt war) deutlich erweitert und sage das es jetzt das Balancing vereinfachen würde. Aber sowas kann auch schnell daneben gehen und falsche Eindrücke erzeugen.

    die von alten makern genutzte pseudo-transparenz per farbaustausch ist eine eher schlechte (weil sehr rechenintensive) Lösung, deshalb nutzen neuere Maker Bilder mit echter transparenz.


    Die Antwort auf Deine Frage hängt davon ab, woher der Schatten kommt.

    Falls der Schatten ein Teil des Tilesets ist, öffne das Tilesheet in irgendeinem besseren Grafikprogram und ändere die Transparenz dort.

    Falls der Schatten nicht zum Tileset gehört sondern automatisch vom Karteneditor platziert wurde, benutze den Schattenstift im Editor.

    Ich finde es zwar seltsam, dass man ein Common Event per Event-Befehl, jedoch nicht per Script-Call aufrufen kann,

    weil genau genommen auch der event befehl etwas leicht anderes macht, nur ist der Unterschied hier egal. "call common event" ist das equivalent eines GOSUB befehls anstelle eines GOTO das viele Leute suchen. Und es ist das GOTO das nirgendwo existiert und auch nicht existieren darf.

    Es gibt einen Grund weshalb ich oben erwähnt hatte das der eventbefehl andere Einschränkungen hat...

    Also ersteinmal: Es gibt absolut gar keinen script call, um ein common event direkt zu starten.


    lest euch doch mal den namen der oben genannten scriptfunction durch:

    es heißt ausdrücklich nicht "starte common event" sondern "RESERVE common event".


    Und der Grund dafür ist das dieser Befehl dem Computer lediglich sagt "Führe dieses Common event bitte irgendwann mal aus, wenn Du die Zeit dafür hast".


    Das einzige was common events direct verknüpfen kann ist der Event Befehl "Call Common Event", und der hat ganz andere Einschränkungen.

    Seit VXA (genau genommen sogar seit VX, aber es gab ein paar kleine Änderungen von VX zu VXA) gibt es für alle Tilesheets genau 6 verschiedene Formate, und die Formate unterscheiden sich in mehr als nur der Größe.


    Die Tilesheets A1 bis A5 passen NUR in die slots gleichen namens, und unterscheiden sich nicht nur in der Größe sondern auch welche form von Tiles wo platziert ist.

    z.B. müssen animierte Autotiles auf A1 sein, sie funktionieren in keinem anderen Slot.


    Die vollständigen Definitionen für alle sechs Formate sind in der Hilfe unter Asset Standarts.


    Und jedes Tilesheet muss exact die richtige Größe haben, aber es ist egal ob Du das mit aanderen Tiles oder Transparenten Feldern auffüllst.

    selbst die Preload-Images "zucken" ein bisschen.

    und wann genau hast Du den Befehl zum preload gegeben?


    wie ich schon oben geschrieben habe, automatischer preload funktioniert nicht!!!


    Wenn Du den Befehl zum preload erst direkt vor dem show picture gibst, dann hat der Computer nicht genug Zeit um zu laden und das Blinken wird nur um ein paar Frames reduziert.


    Wenn Du den Befehl zum preload zu früh gibst (viele automatische preloader machen dass zum Spielstart), dann funktioniert das nur für eine sehr begrenzte Menge an Bildern - denn der automatische Garbage Cpllector entfernt automatisch die ältesten Resourcen , sobald der RAM knapp wird. Und dann ist das genauso als wenn es gar keinen preloader gegeben hat.


    Also: wo in dem event mit den Show picture hast Du den Scriptbefehl zum preload eingesetzt?

    das problem mit preloads ist, das der Computer dumm ist und nicht weiß, wann in der Zukunft ein Bild benötigt wird.


    die einzige sinnvolle Lösung ist, das der Entwickler den Preload zur rechten Zeit anweist.

    Dafür braucht das Preload-Plugin aber die richtigen Befehlsoptionene, und der Entwickler muss sie zur richtigen Zeit einbauen.


    Ein automatischer Preloader kann niemals korrekt funktionieren, egal wovon manche Entwickler träumen.

    es gibt noch ein zweites Problem: seine Karte hat wahrscheinlich die falsche Größe.


    Es gilt immer:

    Größe des Kartenbildes in Pixel = Größe der Karte in Tiles multipliziert mit der Anzahl der Pixel pro Tile.


    wenn diese Zahlen nicht zueinander passen, dann ist das Bild nicht korrekt fixiert.


    was genau macht das "!" beim paralx?

    Wie der entsprechende Eintrag in der Hilfe-Sektion angibt, schaltet das ! das Parallax ab.


    Um diesen Satz zu verstehen muss man aber wissen, was das Parallax überhaupt ist.

    Das Wort "Parallax" hat genau genommen absolut gar nichts mit Karten zu tun.


    Ein Parallax ist eine bestimmte Form von Hintergrundbild-Bewegung, und der Slot für dieses Bild war ursprünglich nie für ein Kartenbild vorgesehen.

    Aber weil in der Entwicklung von RMXP zu RMVX zu viele Funktionen des Karteneditors eingeschränkt wurden, haben die Nutzer nach alternativen gesucht und eine davon bestand darin, die Parallax-Bewegung per Skript abzuschalten und dann das Hintergrundbild für eine Karte zu zweckentfremden.


    Später wurde diese Option dann so populär, das in MV und MZ offizielle Wege zum abschalten des Parallax ohne Skript/Plugin existieren.

    Es gibt nur bei "Ab 18" echte Einschränkungen und legale Anforderungen.

    Etwas Nacktheit und ähnliches fällt eher unter "ab 16", und das hat keine spezifischen legalen Anforderungen (abgesehen davon dass es markiert sein sollte und Du dafür keine Werbung in einem Kinderforum machen solltest und ähnliches.


    Erst wenn Du die Ab-18-Grenze überschreitest, musst Du alles absichern und ein Postident-Verfahren oder ähnliches haben um sicherzustellen, dass kein Kind vortäuscht 18 zu sein und es herunterlädt etc.

    "Ach, ich könnte mich doch einfach mal so schliessen!"

    Nur ein Kommentar:


    das passiert nicht "einfach so", es gibt IMMER einen Grund weshalb ein Program abstürzt.


    Und wenn das regelmäßig passiert, dann sollte man den Grund suchen und beheben, bevor noch schlimmeres passiert.