Beiträge von Wörki

Immer wieder schön...

Ist er zufällig der letzte gewesen, der in der Konversation antwortete?

Das Problem ist hier die systemtechnische Pauschalisierung. Das System kann nicht beurteilen, ob ein Beitrag hilfreich war oder ob jemand Offtopic in einem Thread reinschreibt. Insoweit sind die Reaktionen ein deutliches Merkmal für die Qualität jeglicher Beiträge - und damit ist ein Beitrag jedweder Natur gemeint, egal ob ein Post oder ein Download-Eintrag.

Das System berücksichtigt auch nicht die Art der Reaktion (positiv, neutral, negativ), sondern für das System ist es lediglich eine Reaktion, gleichgültig welche Wertung (weil die negativen Reaktionen auf den Beschluss der Community deaktiviert wurden).

Gleichwohl ist die Reaktionszahl ein Indiz für "aktive stille Leser", die sich so immerhin auch eine Punktzahl verdienen können und so ihre Aktivität zeigen, obwohl sie selbst nichts konstruktives beisteuern oder sich an einer Diskussion beteiligen. Auch diese User-Gruppe müssen wir respektieren und berücksichtigen.

Die Vergabe des "hilfreichster Beitrag" in einem Problem-Lösungs-Thema ist höher zu bewerten als der eigentliche Beitrag. Darüber kann nur der Fragesteller befinden, weil nur er/sie (oder es - scheiß "Multigender" ) beurteilen kann, wer es aus persönlicher Sichtweise entsprechend des individuellen Wissensstands hinreichend beantwortet hat.

Eventuell sollten wir an anderer Stelle die Punkte separat beleuchten und sie ggf. "reformieren".

Eigentlich sollten etwaige Beiträge in den Offtopic-Bereichen (Screenshots, Plauderecke, etc.) nie gewertet werden. Irgendwann haben sie sich versentlich heimlich aktiviert, was aber nicht beabsichtigt war.

Hintergrund ist einfach: Es sollen nur OMSI- und systemrelevante Beiträge gewertet werden, unabhängig von ihrem individuellen Thema (sprich also alles mit WebDisk-Bezug, OMSI-Hilfe, Diskussionen über Addons und Hilfe zu MODs, technische Hilfe, Arbeits-Foren, etc. pp.) Für jedes Forum können wir dies individuell an- und ausstellen.

Da dieser Fehler uns selbst nicht direkt betrifft, sondern den Server/Host von Halycon: Auf "Kein Fehler" gelabelt.

Volker_Rieck

Sieht nach einem Datenbankproblem bei euch aus

Kann gut sein, dass wenn ein Post gelöscht wird, dass es dann noch in der Benachrichtigungs-Warteschlage (je nach dem, was man selbst in den Benachrichtigungseinstellungen festlegte) hängt/hing und das System dann da etwas strubbelig wird/ist, weil es dann nicht mehr zuordbar ist/war - oder weil der User ignoriert ist/war. Das ist für mich gerade die einzige plausible Erklärung, wie es dazu kommen kann.

Wir müssten es beobachten, ob und wie sich das Problem reproduziert und in welchem Zusammenhang es steht, um ggf. eine klare Info an die DEVs weiterzugeben, ansonsten suchen die sich genauso einen Wolf, weil sie ebenso den Einfluss durch Plugins dritter Entwickler ausschließen oder ggf. auf deren Zuständigkeit verweisen müssten.

Ist das möglicherweise ein stilabhängiges Problem?

(Templates sind oftmals stilabhängig, daher ist das nicht auszuschließen)

Das System hinter den Punkten ist etwas komplexer, weil darüber - von der Absicht der Entwickler ausgehend, - auch das Erreichen von Rängen möglich ist, was wir uns bislang nicht Zunutze machen.

Es wäre utopisch viel Rechenarbeit, wenn im Hintergrund nach jeder Aktion in der Webdisk (sprich: Reaktion vergeben, Kommentar verfassen, Posting schreiben oder Thread eröffnen, Datei im Download-Bereich hochladen oder Neueintrag erstellen, Wiki-Eintrag verfassen usw.) dann sofort auch die gesamte Benutzer-Kalkulation auch neu erfolgt.

Zugegeben, bei geringer Aktivität (sagen wir 1-10 Usern) ist das auf die Systemlast kaum relevant, aber die WebDisk ist halt etwas größer, weswegen dies ein Automatismus (sog. "Cronjob") für alle User in einem Rutsch erledigt und damit auch zusätzliche Möglichkeiten gewährt. So bleiben ausreichende Ressourcen übrig für den regulären Betrieb (bspw. Benachrichtigungen per Desktop & Mails). Es gibt so auch eine Abfrage via Steam-API, der Discord-API und einiges mehr, was ebenso per Automatismus in regelmäßigen Abständen erfolgt.

Ich kann es gerne in einem Technik-Artikel näher erläutern, das da alles im Hintergrund abläuft und weshalb das ein oder andere andere daher nur mit geringer Verzögerung erfolgt.

// Entwickler informiert, falsche Sprachvariable angesprochen zu haben

Fixed, hing wieder mit der 32bit-Limitierung zusammen.

File upload >2,1 GB | MySQL fail (PHP 32bit > 64bit)

Bin noch am Testen, aber sowohl 525,45 MB als auch 1,31 GB konnte ich nunmehr hochladen.

Ich arbeite mich Stück für Stück weiter hoch, aber bislang sieht's gut aus.

Das ist keine zufriedenstellende Antwort auf meine Rückfragen. Ohne genau Zeitangaben ist es schwierig bzw. unmöglich, genau zu schauen, woran es liegt und den Fehler einzugrenzen.

Es kann so bspw. an einer maximalen Ausführungszeit des Uploads dienen, wenn du auf dem Land lebst oder sonstig eine "Bambusleitung" hast, wodurch der Upload der kleinsten Datei bereits utopisch lange dauert. Es kann genauso an der Dateigröße liegen (zu groß, vgl. o.g. falsches Dateipräfix unter Windows und der damit verbundenen falsche Angabe der Dateigröße auf deinem lokalen PC) oder ebenso an einem Fehler irgendwo anders liegen.

Ich bräuchte ein paar mehr Infos:

• Wie lange dauert es, bis die Meldung kommt?
• Ist der Upload vollständig oder wird inmitten des Uploads abgebrochen?
• Ist die Dateiendung der hochzuladenden Datei auf der Whitelist?
  Vgl. Erlaubte Datenendungen: ...
• Überschreitet die Angabe tatsächlich nicht die zulässige Größe?
  Die Angabe des Maximums ist in der WebDisk in GB (GigaByte, dezimal), unter Windows hast du aber GiB (GibiByte, binär), vgl. unterer Spoiler in diesem Artikel. 4 GB entsprechen unter Windows somit 3,725 GiB => folglich würde ein Upload wegen Überschreitung dieser Maximalgröße abgebrochen/abgewiesen.
  Ohnehin sollte generell so stark wie zumutbar komprimiert und doppelte Dateien zusammengeführt werden (in WinRAR die Einstellung "Identische Dateien als Verweise speichern"), um so Speicherplatz und zugleich Traffic zu sparen.

Ja, wir haben die DDoS-Potection umgestellt. Problem ist leider, dass eine permanent aktive DDoS-Protection die Website (für Bots und sonstige Automatismen) gänzlich unzugänglich macht, worunter auch die App fiel. Jetzt springt der DDoS-Schutz nur noch bei einem Angriff an, also ein Mittelweg.

Das wäre dann etwas, was ihr individuell an WSC Connect melden müsstet, dem App-Entwickler und Schnittstellen-Betreiber.

hello@wsc-connect.com

Dann kann er die spezifischen Probleme nachstellen, ob es an der App oder der Bridge liegt.

Einfach neu verbinden. Hab gerade auf menem Handy geguckt und nach Drücken auf den Button "Verify ..." war ich auch schon drin. Ging ratz-fatz.

Schon wieder? :o

Oder ich hab bei der Behebung des anderen Anzeige-Bugs irgendwas verpatzt und den daduch reaktiviert.

Ich habe jetzt gerade selbst eimal meine 2FA deaktiviert (gelöscht), neu eingerichtet, mich dann verifiziert und ... klappt alles, wie es soll.

Der Fehler ist für mich so nicht nachvollziehbar und - insbesondere - reproduzierbar.

Reaktionenanzahl im Thema Omsi Driving Screenshots

Reaktionsfehler bei der Kommentarfunktion in Screenshot threads

Reaktion scrollt nur zum Seitenanfang

Alle 3 Fehler hängen miteinander zusammen und sind ein Resultat des "Beiträge kommentieren"-Plugins. Der Autor, Hanashi, kommt nur leider - trotz zigfacher Meldung - nicht aus dem Quak, das mal zu beheben.