Bankwesen auf Stufe 100 erhöht (UPDATE) [W1-14]

[Schlawacko]

Am einfachsten leider nicht, technisch

Ich kenn mich programmiertechnisch jetzt nicht sonderlich aus, aber wenn jetzt jemand aktuelle Kosten von 500gm hat und items einlagert und dann 520gm hat, kann man dem system nicht einfach sagen "überschreibe immer dann den aktuellen wert, wenn der neue wert höher als der gespeicherte ist"?
Und wenn reset ist, nimmt es dann halt immer den neuen aktuellen wert an?
Stell mir das jetzt irgendwie nicht schwierig vor.
Hör mir aber gerne an, was hier eine problematik darstellen würde.

[jSnax7]

Auch nicht soviel Ahnung von Webentwicklung, aber zumindest Programmierer. Disclaimer: Ich habe keine Kenntnisse vom Freewar-Code und spekuliere hier nur.
Aktuell gibt es wahrscheinlich eine Formel um die Schließfachgebühren zu berechnen. Diese Formel wird zweimal verwendet - einmal bei der Anzeige an den Banken, wie hoch deine Schließfachgebühren sind, und dann nochmal bei Tageswechsel, wo der tatsächliche Goldwert vom Konto abgebucht wird (verrechnet mit Zinsen). D.h. die Schließfachgebühren werden derzeit nicht gespeichert, sie werden nur ad hoc berechnet, wenn sie gebraucht werden. Neu müsste es ein in der DB pro Spieler verankertes Feld für die Schließfachgebühren geben und es müsste je nach spezifischer Umsetzung in bestimmten Situationen aktualisiert werden. Bei jedem Ein- und Auslagern von Items, zu bestimmten Zeitpunkten oder nur beim Einlagern von Items nach deinem letzten Vorschlag - und zusätzlich auf jeden Fall beim Tageswechsel. Die Anzeige an der Bank müsste dann auch neu diesen Wert referenzieren.
Und dann müssen Texte angepasst werden, denn die bisherige Formulierung für die Schließfachkosten stimmt nicht mehr. Sonst gibt es sicherlich bald den ersten Bug-Report, dass jemand bei Tageswechsel an der Bank steht und die Schließfachgebühren springen von bspw. 1000gm auf 500gm, ohne dass ein Item rausgenommen wurde.

Das klingt jetzt vielleicht auch nicht nach wenig Aufwand, aber wenn man solche Änderungen im Datenmodell macht, will man sie auch erstmal vernünftig testen. D.h. je nach Grad von Sauberkeit, der im Projekt Freewar herrscht, muss man hier einige Testcases anlegen oder halt mal manuell in der Testwelt die entsprechenden Edge-Cases nachstellen. Während man bei der grundlegenden Änderung, die hier gemacht wurde, lediglich Faktoren in einer Formel ändern muss. Das erfordert selbstverständlich auch Tests, aber wenn wir von einem sauberen Projekt reden, dann muss man hier auch nur Zahlen in einem Testcase anpassen. Sonst halt 1-2 Smoketests in der Testwelt mit 10.000 Items und verschiedenen Stufen Bankwesen.
Zusammengefasst würde ich den Aufwand für deinen Vorschlag bei mehreren Stunden beziffern.
Ich weise weiterhin drauf hin, dass eine viel einfachere Lösung - sowohl von visueller Klarheit als auch vom Programmieraufwand her - eine Begrenzung der kostenlos einlagerbaren Items pro Tag wäre.

[burning eagle]

Warum so kompliziert?
Neues Datenbank-Feld für maximale Anzahl Items im Schließfach anlegen, beim Herausnehmen von Items (bzw davor) "if(dbValue == null || countItems > dbValue) dbValue = countItems", beim nächtlichen Berechnen (sowie bei der Anzeige der Kosten) "max(countItems, dbValue ?? countItems)" sowie nach nächtlicher Berechnung ein Reset aller Datenbank-Werte auf null und fertig (das ist bewusst vereinfacht, aber sollte jeder Entwickler verstehen wie es gemeint ist).

Selbst mit sauberen Tests (die es im fw-Code eher nicht gibt), dürfte das locker in ner Stunde umsetzbar sein.

[Largudrübe]

Mir würden die Performanz-Gedanken dabei riesige Kopfschmerzen bereiten.

[jSnax7]

Warum so kompliziert?
Neues Datenbank-Feld für maximale Anzahl Items im Schließfach anlegen, beim Herausnehmen von Items (bzw davor) "if(dbValue == null || countItems > dbValue) dbValue = countItems", beim nächtlichen Berechnen (sowie bei der Anzeige der Kosten) "max(countItems, dbValue ?? countItems)" sowie nach nächtlicher Berechnung ein Reset aller Datenbank-Werte auf null und fertig (das ist bewusst vereinfacht, aber sollte jeder Entwickler verstehen wie es gemeint ist).

Selbst mit sauberen Tests (die es im fw-Code eher nicht gibt), dürfte das locker in ner Stunde umsetzbar sein.

Zuallererst mal - das unterscheidet sich in der Komplexität 0 von dem, was ich vorher geschrieben habe. Zweitens, deine Lösung beruht darauf, dass das Feld erstmal null ist und erst beim ersten Herausnehmen / Einlagern oder beim Tageswechsel befüllt wird? Cool, das heißt also, dass du einen NullPointer für jeden Spieler hast, der sich an die Bank begibt, denn bei der Anzeige auf dem Feld stehen deine Schließfachgebühren... Daher musst du erstmal ein DB Update manuell durchführen. Und nochmals - in einem Projekt dieser Größe machst du nicht einfach Tests auf DB-Ebene in unter einer Stunde. Du ziehst dir einen Klon von der produktiven DB, führst dort das Skript aus und machst mindestens Stichprobentests. Das ist idealerweise in einem schönen Prozess verpackt und daher lightweight (ich bezweifle das für FW), aber in unter einer Stunde machst du das nur, wenn es sich um einen Hotfix für ein systemkritisches Problem handelt.

[bwoebi]

Wir haben übrigens Testumgebungen, die on-the-fly durch einen Push eines Git Branches erzeugt werden inklusive Kopie einer Datenbank.

Es ist wirklich Code ändern, pushen, kurz die Datenbank abändern testweise und schon kann man es (manuell) testen.
Da Freewar ziemlich modular aufgebaut ist (Sotrax' Lieblingsfeature am Fw-Code), ist für Änderungen außerhalb der Engine fast alles relativ isoliert und schnell testbar.

Das Implementieren dieses Features - eine Spalte hinzu plus an 2 Stellen diese Spalte beim Einlagern updaten, den Text ändern und nächtlich auslesen für die Gebühren - dürfte nicht mehr als eine halbe Stunde dauern, inklusive Testen, eher etwas weniger.

[jSnax7]

I stand corrected. Definitiv unerwartet für mich, aber wenn's von einem Admin kommt wird's stimmen.

[burning eagle]

Zuallererst mal - das unterscheidet sich in der Komplexität 0 von dem, was ich vorher geschrieben habe.

Doch. Du wolltest, wenn ich es richtig verstanden habe, an mehreren Stellen jeweils die Schließfachgebühren berechnen und diese in die Datenbank schreiben.
Ich wollte lediglich die aktuelle Anzahl SF-Items in die Datenbank schreiben, wenn diese vorm Herausnehmen von Items größer als der bisher gespeicherte Wert war oder für den Tag bislang kein Wert gespeichert war.

Meine Variante spart sich die mehrfache Berechnung der Schließfachgebühren und funktioniert auch richtig, wenn der Spieler an dem Tag ne Stufe Bankwesen gelernt hat.


Wieso ich null als default nehmen würde?
Ich sehe grundsätzlich 2 sinnvolle Varianten, wenn man die maximale Item-Anzahl in die Datenbank schreibt.

Variante 1 (Wert für jeden Spieler vorhanden):

Code: Alles auswählen

Initiale Berechnung für alle Spieler nötig
Update beim Einlagern if(countItems > dbValue)
Berechnung mit max(dbValue, countItems)
Nächtlicher Reset auf countItems (soll ja nur die maximale Itemanzahl an dem jeweiligen Tag beachtet werden)

Variante 2 (default null):

Code: Alles auswählen

Keine initiale Berechnung nötig
Update vorm Herausholen if(dbValue == null || dbValue < countItems)
Berechnung mit max(dbValue ?? countItems, countItems)
Nächtlicher Reset auf null

• Die Anzahl der Datenbank Schreib-/Lesevorgänge bei der Berechnung (also auch bei der Anzeige an der Bank) und beim Einlagern/Auslagern (ausgehend davon, dass beides gleich häufig passiert) sind bei beiden Varianten gleich.
• Variante 2 hat bei Herausholen und Berechnung einen zusätzlichen Null-Vergleich auf die Variable mit dem dbValue.
• Variante 2 muss beim nächtlichen Reset nicht für alle Spieler die Werte aktualisieren, sondern nur alle not null Werte auf null setzen.
• Variante 2 braucht keine initiale Berechnung

Der zusätzliche Null-Vergleich dürfte für die Performance keine relevanten Auswirkungen haben. Da der Reset mit null aber deutlich performanter ist, würde ich diese Variante nutzen.

[Simpletrix]

Und diesen ganzen technischen Schnickschnack mitsamt solchen Auswüchsen könnte man sich wie schon gesagt sparen, indem man auf diesen Endstufenbonus verzichtet und gegebenenfalls stattdessen eine alternative Vergünstigung vornimmt, die nicht diese Schwierigkeiten mit sich bringt.
Aber warum einfach, wenn es auch unnötig kompliziert geht?

[Troop]

Und diesen ganzen technischen Schnickschnack mitsamt solchen Auswüchsen könnte man sich wie schon gesagt sparen, indem man auf diesen Endstufenbonus verzichtet und gegebenenfalls stattdessen eine alternative Vergünstigung vornimmt, die nicht diese Schwierigkeiten mit sich bringt.
Aber warum einfach, wenn es auch unnötig kompliziert geht?

Nur weil eine Änderung komplizierter ist als eine andere, sollte man sich nicht davor scheuen, wenn die kompliziertere Änderung das eher gewünschte Ergebnis mit sich bringt Einfach kann jeder!

[Schlawacko]

Und diesen ganzen technischen Schnickschnack mitsamt solchen Auswüchsen könnte man sich wie schon gesagt sparen, indem man auf diesen Endstufenbonus verzichtet und gegebenenfalls stattdessen eine alternative Vergünstigung vornimmt, die nicht diese Schwierigkeiten mit sich bringt.
Aber warum einfach, wenn es auch unnötig kompliziert geht?

Das Implementieren dieses Features [....] Dürfte nicht mehr als eine halbe Stunde dauern, inklusive Testen, eher etwas weniger.

Das von Bob war doch auf diese thematik bezogen, oder?

[Simpletrix]

Für mich hat hat es halt so ausgesehen, als wolle man zur Not auch die Quadratur des Kreises vollbringen, um an diesem Endstufenbonus mit all seinen möglichen Tücken festzuhalten, während man mit womöglich einfacheren Mitteln dasselbe Ergebnis erreichen könnte und wollte darauf hinweisen. Wenn dem nicht so ist und sich tatsächlich alles einfach lösen lässt, dann ist ja alles bestens.

[SplasherW11]

Bezüglich den eigentlichen kosten welches stimmt denn nun eigentlich? Die Aussage von Avalon (war nur ein Anzeigefehler) oder die Aussage von Nyrea (kein bug sondern gewollt die kosten tiefer)?

[Innspiration W1]

Und wann kommt das Update in die anderen Welten? Wäre schön, wenn das bereits vor den anderen Updates passiert

[Nyrea]

Bezüglich den eigentlichen kosten welches stimmt denn nun eigentlich? Die Aussage von Avalon (war nur ein Anzeigefehler) oder die Aussage von Nyrea (kein bug sondern gewollt die kosten tiefer)?

Kann vermutlich nur Sotrax beantworten. Die ursprüngliche Ankündigung enthielt jedenfalls den Satz "Weiterhin wurden die Gebühren für eingelagerte Items gesenkt.".