Ich bisher leider auch nicht.

Was mir noch auffällt: Das Ding scheint überhaupt keinen neuen Thread erstellt zu haben, sondern es scheint deinen alten "Der zweite Team-Hack ist draußen!"-Thread bearbeitet und dann meinen Post drangehangen zu haben. Vielleicht ist das ein Hinweis darauf, wo du suchen musst? Offenbar scheint das Ding ja irgendetwas überschrieben zu haben, was nicht hätte überschrieben werden sollen. Du könntest ja mal im Entwickler-Modus einbauen, dass immer, wenn ein neuer Thread erstellt wird, überprüft wird, ob ein Thread mit dieser ID schon existiert. Falls ja, kommt irgendeine Fehlermeldung mit nützlichen Infos (Thread-ID oder was auch immer). So lässt sich der Fehler dann vielleicht leichter nachvollziehen, sollte er nochmal auftreten.

EDIT: Es ist auf jeden Fall ganz sicher der Original-Thread. Der Thread hat eine ID von 1139, genau wie hier im Forum. Das heißt mein "Absenden" hat definitiv keinen neuen Thread erstellt, sondern nur in einen bestehenden Thread eingefügt und dann in besagtem Thread den Titel geändert.

EDIT: Ich denke ich weiß, was passiert ist. Die neuen Threads, die nach dem besagten Thread erstellt wurden, haben IDs von 1140, 1141, 1142 etc. Die kommen also direkt nach 1139. Ich nehme mal an, du benutzt vielleicht irgendeine Zähl-Variable oder sowas, um Thread-IDs zu vergeben. Möglicherweise stand diese ID an der falschen Stelle, und du hast im Thread-Erstellen-Code keine Sicherheitsmaßnahme drin, um das zu verhindern. Ich denke an dieser Stelle solltest du tatsächlich überprüfen, ob ein Thread mit der aktuellen ID bereits existiert, und falls ja, die nächste freie ID suchen und dann die Zählvariable entsprechend anpassen. Dann dürfte das Problem nicht mehr auftreten, wie auch immer das Ding falsch platziert gewesen sein kann.

EDIT:
Btw., wenn man in der Post-Übersicht hinten auf den Pfeil klickt, springt man dann immer zum letzten Post, oder springt man zum ersten neuen Post? Letzteres fände ich sinnvoller und auch wichtig. Ich benutze sowas meistens.

EDIT:
Noch ein, zwei kleine Anliegen hätte ich, Medaillen betreffend. Momentan gibt es ja eine Seite, auf der man alle Medaillen sehen kann. Die ist auch von jedem einsehbar. An und für sich finde ich das auch nicht verkehrt. Allerdings finde ich, dass nicht jeder User einfach alle Medaillen sehen können sollte. Deswegen schlage ich vor, folgende Änderungen an den Medaillen vorzunehmen:

• Den Medaillen-Namen und den Medaillen-Freischalt-Text teilen wie auf zwei Felder auf.


• Jede Medaille kann als "geheim" markiert werden. Wenn eine Medaille als "geheim" markiert ist, wird sie in der Medaillen-Übersicht nicht angezeigt, außer der momentan eingeloggte User hat die Medaille bereits freigeschaltet.


• Sind in einer Kategorie alle Medaillen geheim und der User hat keine davon freigeschaltet, wird auch die Kategorie ausgeblendet, sodass der User gar nicht weiß, dass diese Kategorie existiert.


• Hat ein User eine geheime Medaille freigeschaltet, wird sie ganz normal in seinem Profil angezeigt und ist auch von anderen Usern sichtbar, aber wenn ein entsprechender User die Medaille nicht selbst freigeschaltet hat, wird ihm der Freischalt-Text der Medaille nur als "???" oder "Geheim" angezeigt.


• Auf Wunsch kann man bei einer Medaille auch nur den Freischalt-Text auf geheim stellen. Dann wird die Medaille zwar jedem user in der Übersicht angezeigt, aber wenn der User die Medaille noch nicht hat, wird der Freischalt-Text eben als "???" oder "Geheim" angezeigt. Am besten löst man das ganze vermutlich als Dropdown-Menü. Man kann beim Anlegen eine Medaille dann auswählen zwischen "öffentlich", "geheim" und "geheime Bedingung".


• Optional kann man auch auf der Medaillen-Übersicht irgendwo unten dann noch sowas hinpacken wie "+ X geheime Medaillen". Dann weiß ein User halt zumindest schonmal, dass es noch mehr Medaillen gibt, die er erhalten kann, von denen er aber nichts weiß.

Das alles sollte ja vermutlich nicht sehr schwer zu machen sein. Nun habe ich aber noch ein Anliegen bezüglich Medaillen, und das könnte etwas aufwändiger werden.

Wenn du dir die aktuelle Medaillen-Übersicht ansiehst, wird dir auffallen, dass 80% aller Medaillen dort nur irgendwelche Medaillen aus Wettbewerben sind. Das ist natürlich insofern schon doof, dass die die ganze Übersicht vollspammen und das nicht schön aussieht. Es ist aber auch deshalb doof, weil das immer aufwändig und lästig war, die Medaillen für jeden Wettbewerb neu anzulegen und dann den Text zu kopieren, und weil das so lästig war, habe ich es dann manchmal auch entsprechend lange aufgeschoben, die Medaillen für einen Wettbewerb auszuhändigen.

Hier nun die Idee: Es sollte eine neue Art von Medaillen geben, "Medaillen-Schablonen" oder so etwas. Die Medaillen könnten mehrmals verliehen werden, und jedes mal, wenn man sie verleihen würde, müsste man direkt X Parameter mit angeben, die dann ausgefüllt würden. Wie kann man sich das nun vorstellen. Mal ein Beispiel. Ich lege im Admin-Panel folgende Medaille an:

Name: Goldmedaille - {1}
Bedingung: {2} den 1. Platz belegt ({3})
Kategorie: {4}

Wenn ich nun diese Medaille jemandem verleihen würde, wüde die Software mir direkt schon Textfelder für Parameter 1, Parameter 2, Parameter 3 und Parameter 4 anbieten. Dort könnte ich nun beispielsweise eintragen

{1}: Levelwettbewerb (September 2016)
{2}: Beim Levelwettbewerb
{3}: September 2016
{4}: Levelwettbewerb

Und der User würde daraufhin folgende Medaille verliehen kriegen

Name: Goldmedaille - Levelwettbewerb (September 2016)
Bedingung: Beim Levelwettbewerb den 1. Platz belegt (September 2016)
Kategorie: Levelwettbewerb

Klar, die Parameter sind bei diesem Beispiel jetzt nicht ganz optimal gewählt, aber es geht hier ja ums Prinzip. Das zu coden wäre sicher etwas Aufwand, aber man würde sich auf lange Sicht so unfassbar viel Zeit damit sparen.

In der Medaillen-Übersicht müsste man dann natürlich ein paar Anpassungen vornehmen. Entweder man schmeißt alle Schablonen-Medaillen gleich ganz raus (vermutlich am leichtesten), oder man fast sie alle zusammen und listet sie in der Übersicht zusammengefasst nur einmal auf (dann braucht man aber beim Erstellen von Medaillen die Möglichkeit, Standard-Parameter anzugeben, die einem hier angezeigt werden - das wäre aber auf jeden Fall wohl die eleganteste Lösung).

Jedenfalls, so ein System fänd ich äußerst cool, und es würde uns auf lange Sicht sehr viel Arbeit ersparen. Meinst du, etwas derartiges wäre machbar?

Frag ihn doch.



Na klar doch! Wir brauchen schließlich auch einen Anreiz, um Schäfchen auf die neue Seite zu locken!
Ne, klar, leuchtet schon ein, dass das nicht so eine Priorität hat. Bug Fixes sind auf alle Fälle erstmal wichtiger. Leg es einfach irgendwo ganz weit unten in deiner Feature-Wunschliste ab.

Hast auf jeden Fall bisher schon großartige Arbeit geleistet, und alleine dafür hast du Respekt verdient!

Häh, wie jetzt? Ich dachte, der wäre offiziell aberkannt worden? :/

Okay, der Spruch wird langsam alt (ha, genau wie WYE!).

Dann eben so



Anders als du, wird dieses Bild nämlich niemals alt!

Tja, leider zu spät. Damit bist du jetzt offiziell der schlechteste Mensch der Welt und sogar schlimmer als Hitler!

lol, neuen Bug (den bisher keiner von den anderen Schlingeln reportet hat).

Jeder User kann Medaillen verleihen, unabhängig von den Berechtigungen.

EDIT:
OK, offenbar stimmt das nicht. Mein Test-user war ja ein Moderator, hatte ich vergessen. Allerdings haben einige User sich offenbar selbst Medaillen verliehen. Kannst du das irgendwie nachvollziehen?

Bei Definitely_Not_Wysey habe ich eine "Untypisiert"-Medaille gesehen. Hast du die vergeben, oder war das jemand anderes? Falls das jemand anderes war, kann man vielleicht über SQL nachvollziehen, wer das war (was übrigens auch noch ein nice-to-have Feature wäre: Wenn man in der Medaillen-Übersicht eines Users auch sehen könnte, von wem eine Medaille verliehen wurde, und man Medaillen eines Users auch wieder löschen könnte). Denkbar wäre ja auch, dass es einer der anderen Mods war, dann wäre natürlich alles okay.

Ich habe gestern dem Celeros-Kontakt mal eine E-Mail geschickt. In ihren AGBs steht ja drin, dass Chats nicht erlaubt sind, außer man hat ihre vorherige schriftliche Genehmigung. Ich habe dann mal gefragt, ob es einen Unterschied macht, wie man den Chat umsetzt und ob gegebenfalls weniger belastende APIs wie z.B. WebRTC möglich wären. Danach habe ich noch gefragt, was gegebenfalls für so eine "schriftliche Genehmigung" notwendig wäre. Die Antwort war relativ eindeutig. Der Grund, das Chats verboten sind, sind nicht in erster Linie Belastungs-, sondern Sicherheitsgründe, und Ausnahmen werden hier wirklich nur bei vServern gemacht. Sie haben dann aber selbst nochmal bestätigt, dass eine Shoutbox eine mögliche Alternative und auf jeden Fall erlaubt wäre. Du würdest also nicht viel falsch machen, wenn du für die Seite vorerst eine Shoutbox bauen würdest.

Ganz allgemein würde ich das sowieso vorschlagen. Selbst falls wir irgendwann noch mal einen vollwertigen Chat einbauen sollten, wird die Shoutbox dadurch nicht gleich unnötig. Hier sind so meine Ideen:
-Die Shoutbox könnte immer dann an Stelle des Chats angezeigt werden, wenn ein User gerade nicht online ist. Die würde auf den selben Pool an Nachrichten zugreifen, nur diese halt nicht live updaten. So könnte halt jeder problemlos den Chat lesen, auch ausgeloggte User, aber um selbst teilzunehmen müsste man schon eingeloggt sein.
-Für das Chat-Archiv würde ich generell eine Art Shoutbox nehmen. Jetzt nicht unbedingt mit der Funktionalität, da auch was posten zu können, sondern nur so rein vom Design her.
-Optional könnte auch ein User in seinen Einstellungen den Chat manuell auf eine Shoutbox umstellen, z.B. wenn ihm der Chat zu viel Bandbreite verbraucht oder sowas.
-Die Shoutbox kann man immer und überall mal eben einbinden, ohne gleich einen ganzen Chat überall zu haben und damit viel Overhead zu erzeugen.
-Und dann natürlich noch die Tatsache, dass man jederzeit zur Not auf die Shoutbox wechseln kann, falls es mal Probleme gibt und man den Chat zumindest zeitweise nicht mehr benutzen kann.

Ich würde deswegen sagen, dass eine Shoutbox erstmal die bessere Lösung wäre und ein Chat dann, falls ein vServer finanziell möglich ist, noch hinterher kommen kann.

Viel haben sie dazu jetzt nicht gesagt, nur "Eine weitere Alternative wäre eine sogenannte Shoutbox die per PHP in die Webseite eingebunden wird, solch eine Shoutbox gibt es auch als Plugin für s.g. CMS's. "
Ich würde es also im Prinzip so sehen, wie du. Also ein Fenster wie ein Chat, das aber nur auf Knopfdruck aktualisiert wird. Alternativ kann man es sich auch folgendermaßen vorstellen: Ein kleiner Mini-Thread, der überall sichtbar ist und der, anstatt nur per F5, auch über einen eigenen Knopf aktualisiert werden kann.

Die Avatare könntest du ja zur Not schonmal auf ein Viertel der Größe schrumpfen, dann wäre der Chat nicht mehr so riesig und es wäre leichter, ihn an bestimmten Stellen einzubinden, ohne dass er gleich lästig wird. Von mir aus auch über eine User-Option, falls jemand die Bildchen doch ganz unbedingt in Originalgröße haben will. Ansonsten wäre noch ein animierter, sich irgendwie drehender Kreis ganz cool, wenn man auf "Aktualisieren" klickt und er gerade Nachrichten lädt (dass man halt weiß, dass er gerade am laden ist). Ganz oben als erste Nachricht im Chat (oder auch ganz unten, je nachdem, wie herum die Nachrichten sortiert werden) könnte man dann noch einen "Ältere Nachrichten anzeigen"-Link packen, der einen zum Chat-Archiv verlinkt, und zwar auf eine Seite, die einem die nächst-älteren Nachrichten anzeigt (logisch). Natürlich nur, falls es auch ältere Nachrichten gibt (ebenfalls logisch). Rechts, direkt unter dem "Chat-Archiv" Button, würde ich dann noch eine dünne Spalte einfügen mit "Aktive Benutzer" oder "Zur Zeit im Chat" oder irgendwie sowas. Hier wären halt alle User gelistet, die gerade im Chat sind (oder im Falle einer Shoutbox, alle User, die in den letzten x Minuten etwas gepostet oder Aktualisieren gedrückt haben oder sowas in der Art). In seinen User-Optionen bräuchte man dann natürlich noch die Einstellungsmöglichkeit, sich als "Unsichtbar" markieren zu können, falls man nicht will, dass der eigene Name in der Liste erscheint.

das wäre jetzt eigentlich alles, was mir so einfällt. Design-technisch finde ich das Ding toppo!

Yep, so ist's gleich besser, meiner Meinung nach. So bekommt man deutlich mehr Text auf weniger Raum.

AFAIK hat Addmusic keine Funktionalität, um einen Musiktrack ab Stelle X abzuspielen. Zu 100% sicher bin ich mir aber nicht, bin nicht genug in der Materie drin.

Sofern du nicht zufällig das SPC-700 programmieren kannst, sieht es da eher schlecht aus. Wirkliche Workarounds fallen mir da jetzt eigentlich keine ein, bis auf "mach das nicht".

Frage: Wieso fügst du denn überhaupt einen Standalone-Patch über uberASM ein? Das ist keine gute Idee und kann eigentlich nur schiefgehen.

Ganz so einfach geht das leider nicht. Dafür müsstest du den Patch an sich umschreiben. Der Patch hijackt ja gewisse Routinen des Spiels. Zu erkennen an
org $XXXXXX
Wenn du jetzt so einen Code einfach in uberASM einfügst, sieht uberASM das "org $XXXXXX" und denkt sich "oh, ich soll jetzt an Adresse $XXXXXX springen und allen nachfolgenden Code dort einfügen". Das kann dann auch erstmal gut gehen, weil der Code, den du dort haben willst, auch dort landet, aber zum einen wird der Code dann natürlich nicht dorthin geschrieben, wo der eigentliche Levelcode für dieses Level in uberASM landen soll, wird damit also niemals in diesem Level ausgeführt - bringt dir somit also schonmal nichts - und zum anderen überschreibst du damit auch die Zieladresse, an die jeder nachfolgender Code von uberASM geschrieben wird. Auch das willst du eigentlich nicht haben (wobei es vermutlich keine wirklich schlimme Nebenwirkung haben wird, weil diese Adressen sowieso meistens auf Freespace zeigen, im schlimmsten Fall würdest du also vermutlich nur deinen Code fragmentieren).

Eine einfache Lösung gibt es für das Problem nicht. Du müsstest den Patch an sich nehmen und ihn so umschreiben, dass er nur in einem Level aktiv ist und ihn ohne uberASM einfügen. Das wäre aber nicht leicht. Dafür müsstest du den Code gut verstehen und vermutlich an diversen Stellen anpacken. Eine andere Alternative wäre es, Code mit derselben Funktionalität zu finden, der aber nur uberASM benötigt, um zu funktionieren. Ich glaube aber nicht, dass es sowas gibt.

Aber ganz ehrlich? Ich glaube nicht, dass du irgendetwas davon brauchst. Lies dir nochmal die Beschreibung des Patches genau durch.

Die Beschreibung sagt doch schon, dass die Schwerkraft sich nur ändert, wenn man einen Block berührt. Dann ist es doch völlig egal, in welchem Level der Patch aktiv ist. Wenn du die Blöcke nur in ein einziges Level packst, ist die Schwerkraftänderung unterm Strich auch nur in diesem einen Level aktiv. Da brauchst du nicht groß Rumhacken oder Patches umschreiben oder sowas. Einfach Patch einfügen, Blöcke rein, fertig.

Durchaus möglich. Das kannst du ganz leicht überprüfen, indem du dir in beiden Patches Zeilen mit "org" anschaust und dann die Zahlen dahinter miteinander vergleichst. Gibt es in zwei oder mehr Patches ein org mit derselben Zahl, gibt es einen sicheren Patch-Konflikt (kann auch andere Arten von Konflikten geben, aber das hier ist der wahrscheinlichste und häufigste).

Kannst natürlich auch den Patch auf eine cleane ROM packen, der nur einmal durch Lunar Magic gelaufen ist. Wenn da drin das Problem immer noch auftritt, ist der Patch selbst dran schuld. Tritt das Problem nicht mehr auf, ist irgendetwas anderes schuld.

Du solltest ganz leicht rausfinden können, welche zwei Patches sich da beißen. Macht erstmal nur den Gravity-Patch auf eine cleane ROM, haue danach nacheinaner alle anderen Patches drauf und starte die ROM jedes mal kurz. Sobald der Bug auftritt, weißt du, welcher Patch das Problem verursacht.

Das ist sehr gut möglich und auch plausibel. Einen leichten Fix wird es dafür dann aber nicht geben, da es ja nicht einfach nur eine gemeinsame Adresse ist, die gehijackt wird. Man muss dann beide Patches sehr gut kennen um nachvollziehen zu können, wodurch genau das Problem verursacht wird, damit man es fixen kann. Ein Rezept gibt es dafür leider nicht, eine andere Lösung fällt mir nicht ein.

Hmm, naja... zu diesen Sprites fällt mir leider nur ein "at least you tried".
Die passen leider stilistisch überhaupt nicht zum SMW-Grafikstil und sehen größtenteils auch irgendwie eher seltsam aus. In einer eigenen Umgebung mit Figuren, die allesamt so aussehen, könnten sie gut funktionieren (zum Beispiel in einem Comic), aber so mitten in einem normalen SMW-Level wirken die doch sehr "out-of-place".

Schaut alles sehr schick aus! Auf die Demo werde ich wohl verzichten, da werde ich lieber eine Vollversion abwarten, sollte jemals eine kommen. Aber rein optisch gefällt mir das alles jedenfalls super.

Ein paar Gedanken dazu.

1) Vielleicht solltest du sicherheitshalber auch noch MarioBelow und MarioAbove hinzufügen? Vielleicht wird bei einem der Blöcke ja im entscheidenden Moment manchmal nur eine Kollision von unten erkannt oder sowas. Es wäre auf jeden Fall die sicherere Variante, alle Kollisionen abzudecken, denke ich.

2) Mir ist aufgefallen, dass am Ende von MarioSide überhaupt kein Branch-Befehl steht oder sowas. Das heißt wenn MarioSide zutrifft, wird auch MarioCorner immer ausgeführt. Das dürfte in diesem Fall das Ergebnis nicht beeinflussen, da beide Code-Blöcke als allererstes $7B laden, aber sobald du den Code mal änderst, könnte das natürlich durchaus zu Problemen führen, und so oder so ist es auf jeden Fall verschwendete Performance, den gleichen Code zweimal auszuführen, wenn die erste Ausführung überhaupt keinen Effekt hat. Du solltest deswegen ans Ende von MarioSide noch ein "BRA NoUnsign" packen.

3) Die einzige Möglichkeit, das Problem wirklich zuverlässig zu lösen, scheint mir ein Timer zu sein. Das wird vermutlich einen Patch oder ein Generator Sprite erfordern, ich glaube der Code von Blöcken wird nicht jedes Frame ausgeführt. Was ich machen würde ist folgendes:

• Mache einen Patch, der jeden Frame Marios Geschwindigkeit abfragt, ähnlich wie hier im Block-Code.


• Wenn Marios Geschwindigkeit einen bestimmten Schwellenwert überschreitet (in diesem Fall $25), dann initialisere eine Timer-Variable mit einem von dir definierten Toleranz-Wert, zum Beispiel 5 (das ganze versteht sich als eine Anzahl von Frames).


• Wenn Marios Geschwindigkeit den Schwellenwert im aktuellen Frame NICHT überschreitet, dann lass diese Timer-Variable um 1 runterzählen (außer, sie ist bereits 0).


• Nun zum Block-Code selbst. In dem fragst du Marios Geschwindigkeit jetzt schlichtweg gar nicht mehr ab. Stattdessen fragst du nur noch diese Timer-Variable ab. Ist ihr Wert größer 0, dann zerbricht der Block. Ist der Wert nicht größer 0, zerbricht der Block nicht.

Das Ergebnis des ganzen: Selbst wenn du durch den einen Block im vorherigen Frame bereits ausgebremst wurdest, würde der andere Block, solange du ihn noch berührst, trotzdem zerbrechen, weil die Timer-Variable noch nicht 0 wäre. Klar, das ganze würde dafür sorgen, dass in ein paar Rand-Fällen Blöcke auch zerbrechen würden, wenn man bereits langsamer laufen würde. Das dürfte aber kaum auffallen, weil das Zeitfenster dafür so kurz ist (eben nur ein paar Frames), und außerdem dürfte das das Spielgefühl eher sogar verbessern, nehme ich an.

Bemerkung: Diese Lösung basiert auf der Annahme, dass die Kollision mit Blöcken immer vom Spiel abgefragt wird, und nicht nur dann, wenn man auch eine Geschwindigkeit != 0 im aktuellen Frame hat. Ich weiß ehrlich gesagt nicht, wie das Spiel Kollisionen abfragt, deswegen kann ich nicht zu 100% garantieren, dass diese Lösung auch funktioniert. Falls das Spiel aber MarioSide usw. auch ausführt, wenn man sich gerade nicht bewegt, sollte meine Lösung so funktionieren.