Descentforum.DE

[Q]

Yo,

Smiddy hat recht - auch von mir ein spätes,
aber trotzdem fettes Danke für die Mühe
mit der Stats-Seite (ich denk nur an die
Diagramme, progg das mal wer mit der gd
und Daten und so).

zur philosophischen Seite des Themas:
Do-Checkor und Sidekicker habens genau
ausformuliert; letztlich wirds wohl immer
etwas geben was nicht paßt. Aber könnte
man ja alles ausformulieren, dafür sind
Foren doch da...
Das mit Smiddys point/kill-Rate erkläre ich
mir so, daß er bereits über drei Jahre in
den Stats steht und wohl von Anfang an
weit oben war, also immer unter 1 pt/kill
bekommen hat.

Zur technischen Seite des Problems:
Wenns an zu schwacher Hardware liegt, dann
greift Zorc's Argument. Ich wär durchaus
bereit dafür, nur fehlt mir halt der 5k-€-Rechner
Wenns an Code oder Database liegt, könnte
man ja mal schaun wieviele sich Arbeit
anzutun bereiterklären würden; Munk
sprach ja davon daß er halt keine Zeit
hat das Problem zu beheben.
Und inzwischen gibts halt

[Marix]

Naja, ich glaube Rechnerleistung wäre jetzt weniger das Problem. Da wüsste ich im Notfall schon wie man das löst, auch wenn's dann nur eine wöchentliche Aktualisierung gibt. Sollte das Problem aber wirklich die DB sein, dann löst das das Problem nicht, da die Daten da immer noch wieder rein müssen. Da könnte man sich dann aber mal die Tabellenstruktur genau anschauen. Vielleicht findet sich da ja noch die eine oder andere Optimierungsmöglichkeit. Ich auf jeden Fall würde mich gerne mal daran versuchen, zumal ich auch schon längere Zeit die Idee einer Art gewichteter Effizenz mit mir rumtrage, welche ich gerne mal ausprobieren würde.

[Q]

Yo,

[Munk]

Datensätze manuell löschen ist keine Option, bei nem Reparsen der Files wären sie ja wieder drin. Außerdem muss man tierisch auf jegliche Seiteneffekte aufpassen, denn als man den Code geschrieben hat ging man ja davon aus daß die Datensätze noch drin waren.

Die Tabellenstruktur selbst läßt sich nachträglich auch kaum ändern, denn das kommt einer kompletten Neuprogrammierung schon sehr nahe - die wäre zwar wohl nötig, aber von mir zeitlich nicht schaffbar.

[Marix]

Manchmal lässt sich auch schon durch geschickte Nutzung von Indizes und Views einiges rausholen. Aber ich gebe zu, der Arbeitsaufwand dafür ist nicht zu unterschätzen.

[Maulwurf]

Wenns aber Spaghetticode ist und die SQL-Statements überall im Code verteilt sind, passt das evtl nicht zur View...
Ach so ein unnützes Gelaber samt Spekulationen um Arbeiten Dritter sind doch immer wieder völlig unnötig und bringen überhaupt niemandem was.

[Q]

Yo,

@Munk
mit 'Datensätze löschen' meinte ich,
daß ich dadurch mal die Performance
eines Servers total ruiniert habe &
es einiges an Detektivarbeit gebraucht
hat bis ich's gefunden/gefixt habe.

@Maulwurf
Du hast natürlich recht; ich denke halt
daß dieser Thread eher dazu da ist, um
alle 'Willigen' zu finden/organisieren als
über Dritter Leute Arbeit zu
schwadronieren.

[Derick]

Man könnte ja auch extra für die Stats einen VServer anmieten.
Die Berechnung würde dann zwar etwas länger dauern aber irgendwas is ja immer.

Ich hatte Dir ja mal vorgeschlagen dich an Wormy zu wenden. Vielleicht wär es möglich auf einen seiner Server die Berechnung, Nachts durchführen zu lassen?!

And last but not least:
Ich habe vor kurzem ein Leitungsupdate bekommen.
Mein Provider stellt grad alle Leitungen auf HDSL (High Data Rate Digital Subscriber Line) um.
Zur Not könnte auch ich einen Homeserver dafür abkomandieren

[Do_Checkor]

Nochmal kurz bemerkt für die, die scheinbar die Posts nur überflogen haben:

Das Projekt IST nun auf nem neuen Server, aber selbst auf nem "normalen" hat es bisher schon ne Ewigkeit gedauert. Auf dem V-Server würd es vermutlich über ne Woche dauern. Ich dachte auch schon dran, anzubieten DF.net dafür zu nehmen - scheint ja momentan die potenteste Kiste zu sein und Gameserver stehn ja (noch) genug, aber:

Worauf Munk meines Erachtens nach AUCH hinaus will ist:

Datenberechnung solcher Art wird bei ansteigender Anzahl von Datensätzen exponentiell aufwendig. Wer nicht weiss was das heisst schau mal hier rein. Sprich: JETZT würd es noch reichen, einen dickeren Server zu nehmen, oder den Intervall runter zu drehen, aber in vielleicht 6 Monaten (oder so) wird das NICHT mehr reichen.

Von daher sind "halbherzige" Änderungen Unsinn bzw. Zeitverschwendung.

Die Idee nur ein Zeitfenster der Stats für Scores zu betrachten find ich da wesentlich besser! Heutzutage ist es für einen guten Anfänger bald unmachbar (wenn er nen Job oder ne Freundin hat) überhaupt noch in die Top-20 der Stats zu kommen.

Nur das letzte halbe Jahr der Stats für die Scores zu betrachten könnte meiner Meinung nach Unmengen an Last vom Server nehmen, und zudem noch diverse andere positive Aspekte bringen. Auch würden dann die, die ganz oben sind Ansporn haben, weil Ihr Platz sonst immer weiter nach unten absackt, wenn sie nicht spielen...

[Marix]

Also Jungs, ihr habt Do_Checkor gehört, lasst eure Ansätze für kreative Scoreberechnung hören.

[Munk]

Also eine Stats-Seite die generell nur Spieledaten des letzten Jahres (oder 3 Monate oder so) enthält, ist definitiv machbar.
Der Datenumfang wächst dann mit der Zeit ebend genau nicht an, d.h. auch die Berechnungsdauer bleibt ungefähr gleich.

Der Änderungsaufwand ist nur minimal, beschränkt es sich ja nur, alle alten Datensätze aus der Datenbank zu entfernen.
Gesamtkills und -deaths könnte man trotzdem noch irgendwie reinbasteln für die Detailseite, allerdings dann halt nicht mehr aufgeschlüsselt nach Leveln, Mods etc. (das aufgeschlüsselte würde dann nur noch für das vergangene Jahr gelten).

Vorteil wäre, daß auch Neueinsteiger nicht benachteiligt wären, spätestens nach einem Jahr sind sie dann ja vollkommen gleichberechtigt.
Nachteil wäre halt, daß man die Scores oder Kills-Entwicklung halt nurnoch maximal 1 Jahr macht.
Also wer dann mit Spielen ne Pause einlegt, verliert dann auch wieder ziemlich schnell seine Punkte (nämlich halt ungefähr die, die er zu Anfang des Jahreszeitraums erspielt hat)

[Do_Checkor]

[Marix]