Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kostenrechner vs. Anzeige Vorabscan #276

Closed
Selene443Foe opened this issue Dec 30, 2019 · 12 comments
Closed

Kostenrechner vs. Anzeige Vorabscan #276

Selene443Foe opened this issue Dec 30, 2019 · 12 comments
Assignees
Labels
Bug Next Version Issue will be dealt with in the next update

Comments

@Selene443Foe
Copy link

Der Vorabscan zeigt einen möglichen Gewinn an, der Kostenrechner nicht...

44

@Gindi4711 Gindi4711 added the Bug label Jan 1, 2020
@Gindi4711 Gindi4711 self-assigned this Jan 1, 2020
@Gindi4711
Copy link
Collaborator

Wieder einmal das leidige Rundungsthema.

Also die Ursache ist, dass für die Übersicht der beste Kurs eines LG gespeichert wird. Das hat den Grund, dass sich der Gewinn beim Ändern des Archefaktors ja jederzeit ändern kann.

Wir haben nun den Fall, dass:
P2 145 FP gibt. Mit einem Archebonus von 90.2% sind das 275.79, was auf 276 gerundet wird. Der Kostenrechner errechnet nun, dass der Gewinn 0 ist und macht die Zeile deshalb rot.
Diese 276 FP ergeben wiederrum einen Kurs von 190.34%, was auf 190% abgerundet wird.
Die Übersicht stellt nun fest, dass die 190% bester Kurs besser als die eingestellten 90.2% Archebonus sind und macht die Zeile grün.

Wie sich das lösen lässt, darüber muss ich erst etwas grübeln.

@Th3C0D3R
Copy link
Collaborator

Th3C0D3R commented Jan 1, 2020

@andrgin wenn du selbst rundest? Also eine funktion bastelst die den Wert entsprechend rundet und dann eine flag setzt wie gerundet wurde, als einfach ein Boolean der mit true aufgerundet angibt und false abgerundet. Sobald dann das mit den % ist mit rechnen wird der flag abgefragt und du rundest wieder manuell. So sollte es doch dann gehen oder hab ich da ein Denkfehler?

@Gindi4711
Copy link
Collaborator

Das Ganze ist etwas komplexer, aber ich habe schon einen Plan, wie es sich lösen lässt:
1.) Der Kurs bekommt eine Kommastelle, da der Archefaktor ja auch eine Komma stelle hat.
2.) In Zukunft wird ein Gewinn von genau 0 auch grün angezeigt, da es ja immerhin noch BP und Medaillen gibt und man somit ja (abgesehen von der Kapitalbindung) immer noch Gewinn erzielt. Abgesehen davon macht das das Einzahlen in Förderketten, die FP genau abgesichert sind etwas übersichtlicher.
3.) Dann ergibt sich noch das Problem mit der FP Rundung an sich. Hier gibt es folgendes Beispiel:
P5 netto: 5FP
Archefaktor: 90%
FP brutto: 9.5 -> aufgerundet auf 10
Kurs ist 10 / 5 = 200%

Der Kostenrechner wird die Zeile dann mit Gewinn 0 und Kurs 200% anzeigen.
Das ist mit den bisherigen Daten nicht möglich, da nur anhand des Kurses nicht bestimmt werden kann, ob das LG grün ist. Stattdessen werden nun die Netto FP und der Einsatz gespeichert. Angezeigt wird weiterhin der Kurs von Einsatz/FP netto gerundet auf 1 Stelle. Für die Filterung wird jedoch auf (Einsatz-0.5) / FP Netto überprüft.

@Selene443Foe
Copy link
Author

...bei der Gelegenheit - ich glaube es passt gut hierzu... es gibt ein Ticket hierfür wo mal darüber philosophiert wurde, aber ich finde es mal wieder nicht:

Ich verwende den Kostenrechner, so wie auch der Ersteller des Tickets das ich nicht finde, auch um zu schauen was ich bei 1,80 oder 1,85 oder eben 1,9 einzahlen muss.
Dabei ändert sich die Anzeige des Gewinns in der gleichen Richtung wie die Eingabe der Einzahl-Prozente.
Wenn ich also mit 1,85 einzahle mache ich z.B. 10 Gewinn, wenn ich mit 1,9 einzahle mache ich 12 Gewinn. (die Zahlen stimmen jetzt nicht, ist nur ein Bsp)
Das ist aber bei dieser Art der Verwendung nicht ganz logisch, da sich, egal wie viel ich in ein LG einzahle, ob mit 1,8 oder 1,9 Prozent, die Größe meiner Arche und damit der Gewinn den sie erwirtschaftet, nicht ändert.
Vielleicht könnten wir hier auch nochmal eine schönere Lösung finden?

@Gindi4711
Copy link
Collaborator

Das mit dem falschen Gewinn haben wir schon sehr intensiv diskuttiert, allerdings ist da noch nichts raus gekommen.

Das Problem ist, dass es 2 Wege gibt den Kostenrechner zu bedienen:

  1. Klassische Variante mit 90% Archenbonus und Einzahlen in ein Gilden LG per 190er Förderung: Man sieht in der 1. Spalte "Ertrag" nach. Wenn man 190 FP zurück bekommt zahlt man auch 190 ein. Der Rest ist egal solange der Platz safe ist. Ist man in einer 185er Gruppe stellt man den Archebonus auf 85% und macht es genauso. As stimmt dann zwar eigentlich nicht mehr, erfüllt aber funktional seinen Zweck.
  2. Die modernere (und technisch korrektere) Variante beim Snipen: Man schaut in die 4. Spalte "Einsatz". Die Differenz auf Einsatz und Ertrag ist der Gewinn.

In der weiteren Folge hat es für die Variante 1 für das Umschalten zwischen 85% und 90% die 2 Buttons gegeben.
Für die Variante 2 hat es dann die Buttons zum Schnellumschalten gegeben.

Und genau hier haben wir dann das Problem, dass beides in der Kombination dann nicht mehr funktioniert.

Die rechnerisch korrekte Lösung für das Problem wäre:
a) Alle steigen auf die Variante 2 um und lesen nur mehr von der Spalte "Einsatz" ab.
b) Statt der Buttons "85%" und "90%X gibt es nun die Buttons "Snipen", "85%" und "90%", wobei letztere einen Mindestkurs festlegen.

Als Kompromiss wäre es auch möglich die Spalten "Einsatz" und "Ertrag" zu vertauschen. Dann muss sich jeder ein bisschen umgewöhnen. Ich habe das testweise einmal probiert, bin aber nicht wirklich glücklich damit geworden, da ich instinktiv immer noch in die 4. Spalte schaue.
Ein anderer Plan war die 190% Förderfunktion durch den EA Rechner zu ersetzen, der sich zwar grundsätzlich auch auf fremde LGs anwenden lässt, jedoch in der Praxis einige Anpassungen erfordert z.B. um zu verhindern, dass man auf P4 einzahlen will wenn man schon auf P1 drin ist.

Egal was wir machen es hat alles davon Nachteile für eine bestimmte Gruppe an Nutzern, weshalb wir uns damals dazu entschieden haben es so zu lassen, wie es aktuell ist.

@Selene443Foe
Copy link
Author

Warte mal... vielleicht denke ich ja auch falsch...
hab mal rum probiert. Beim Snipen wird in der Spalte "Einsatz" immer dassselbe angezeigt. (Testweise Archebonus 100% bei Einsatz 356 Gewinn 148 / verglichen mit den 85 und 90Prozent)
Weiß nun nicht wie das mit größeren LG ist, mir ist grad keins in die Finger gekommen...
Nur die Spalte Ertrag ändert sich natürlich ständig.
Heißt also - fürs Snipen muss mein "echter" Archebonus drin stehen damit der Rechner korrekt anzeigt.
Wenn ich in der Förderung einzahlen will muss ich das anklicken mit was ich fördern will, sagen wir mal 90%.
Jetzt sehe ich in Spalte "Ertrag" korrekt was ich einzahlen muss.
An dieser Stelle verstehe ich noch immer nicht, warum unter Gewinn nun was "falsches" angezeigt werden muss.

Den User interessiert doch fürs Snipen die Spalte "Einsatz" - und der echte Gewinn.
Fürs Fördern die Spalte "Ertrag" - und immernoch der echte Gewinn. Was macht denn ein "falscher" Gewinn für einen Sinn?

Blöd ist ausserdem, dass man nicht recht sehen kann, welcher Button wirklich geklickt ist. Könnte man das nicht mit "sunken" besser kenntlich machen?
Wenn man fördern möchte, dann gibt ja der echte eigene Archewert einen falschen Wert aus, falls dieser geklickt ist...

Die Idee mit den Button finde ich garnicht so übel. Das zergeht mir gerade auf der Zunge :D

Unter Archebonus kommt der eigene Archebonus rein.
dann gibt es drei Button.
Snipen / Förderung 90% / Förderung 85%

Wenn "Snipen" gedrückt ist, könnte zur Kenntlichmachung die Spalte "Ertrag" angegraut sein, da diese dann eh zweitrangig ist.

Mit den Button "Förderung 90%" / "Förderung 85%" könnte die Spalte "Einsatz" angegraut sein, da diese hier nicht von Bedeutung ist.

In beiden Fällen bezieht sich aber die Spalte "Gewinn" auf den echten Archebonus.

Ich halte das nicht für eine zu große optische Umstellung. Auch denke ich, dass dies ohne große Erklärungen verständlich wäre?
Oder??

Und ich plädiere immernoch im Kostenrechner / Vorabscan für die Anzeige der Gilde in welcher der Spieler ist, um Bündnispartner leicht identifizieren zu können.

@Selene443Foe
Copy link
Author

...ach was mir gerade auffällt:
es ist auch bei jedem neuen LG was man aufruft, der eigene Archewert geklickt.
In meinem Testfall mit den 100% hätte ich gerade in der 90er Förderung stattlich minus gefahren wenn ich nicht vorher nochmal auf Verdacht die Button betätigt hätte. Auch darum wäre meines Erachtens eine Kenntlichmachung in oben genannter Form keine schlechte Lösung :)
Auch würde ich denken es macht Sinn, mit dem zuletzt geklickten Button ins nächste LG zu gehen...

@Gindi4711
Copy link
Collaborator

Das verstehe ich nicht ganz.
Im Archefaktor Feld sollte immer der eigene Archefaktor stehen. Dieser sollte in der Regel nur dann geändert werden, wenn man die eigene Arche ein Level hochzieht.

Beim Öffnen eines LGs sollte immer der eigene Archefaktor voreingestellt sein. Die Buttons 85% und 90% sind nur dazu da, wenn man in eine 185/190er Gruppe einzahlt und der Eigentümer nicht ausgescnrieben hat wieviel. In diesem Fall klickt man auf den Button und liest aus der ersten Spalte ab.

@Selene443Foe
Copy link
Author

Ich vermute jetzt mal deine Frage / Antwort bezieht sich auf meinen zweiten Post zu den immer gleichen Button im nächsten LG?!

Ja das stimmt ja auch, im Archefaktor steht der eigene Archebonus.
Wenn du jetzt etwas fördern willst, schaust du auf die Spalte "Ertrag" um das einzutippen was da steht. Soweit so gut...
Ich weiß ja nicht wie viel Ihr so fördert, aber bei mir geht das hintereinander weg. Und jedesmal wenn du ein neues LG aufmachst, musst du auch immer wieder den 90er oder 85er Button anklicken, weil dir sonst immer dein eigener Bonus angezeigt wird...

Und hier halte ich es für sinnvoll:

  1. den angeklickten Button besser erkennen zu können (Stichwort "sunken" / entsprechende Zeile anzugrauen <- siehe erster Post)
  2. den zuletzt angeklicken Button beim nächsten LG noch aktiv zu halten.

Beim Neustart des Rechners, kann ja von mir aus der eigene Bonus wieder aktuell sein. Warum nicht. Aber im Grunde brauche ich den doch nur beim Snipen. Keine Ahnung für was die User den Rechner mehr benutzen.

@Gindi4711
Copy link
Collaborator

Oh den ersten Post hatte ich übersehen:

1.) Der Einsatz ist die Anzahl an FP, die man einzahlen muss, damit das Gebäude safe ist. Dieser Wert ist unabhängig vom Archefaktor.
Der Ertrag sind die FP, die man als Mäzenbonus zurück bekommt. Der Gewinn ist dann die Differenz aus beiden, da der Rechner davon ausgeht, dass du auch nur den Einsatz einzahlen wirst.

Beispiel:
P1 gibt 100 FP netto zurück (also 190FP bei 90% Archebonus), ist aber schon bei 180 FP safe.
Ertrag ist 190FP
Einsatz ist 180FP
Gewinn ist 10FP

2.) Die Lösung mit den Buttons Snipen/185/190 würde so aussehen:
Die Ertrag Spalte bleibt immer gleich
Der Einsatz steigt nun bei 185 bzw. 190 immer auf mindestens 190% der Netto FP an (in unserem Beispiel 180/185/190), wobei hier nun auch geprüft werden kann, ob die FP überhaupt noch rein passen.
Gewinn und Kurs werden dementsprechend richtig angepasst.

In diesem Fall darf jedoch nicht mehr von der Ertrag Spalte abgelesen werden, sondern von der Einsatz Spalte. Dann müssen sich aber alle, die bisher auf die Ertrag Spalte geschaut haben umgwöhnen.
Oder man vertauscht die Spalte Einsatz mit dem Ertrag. Dann müssen sich die anderen umgewöhnen.

3.) Ich nehme den Kostenrechner auch hauptsächlich zum Snipen bzw. wenn bei uns ausgeschrieben wird, dann meistens mit FP d.h. ich schaue nur, ob auch safe ist.
Allerdings war der Kostenrechner laut @dsiekiera ursprünglich gar nicht fürs Snipen gedacht, sondern nur für 190er Förderung.

@Selene443Foe
Copy link
Author

Selene443Foe commented Jan 5, 2020

Wahrscheinlich denke ich zu quer.
Es geht doch garnicht um die Änderung der Berechnung, sondern nur um das Anpassen der Anzeigen an das was wirklich passiert.
Wenn ich auf Förderung 85 / 90 klicke und das einzahle was mir unter "Ertrag" angezeigt wird, dann habe ich nicht das als Gewinn was die Spalte "Gewinn" mir anzeigt...
Dieser angezeigte Wert wird aus der Spalte "Ertrag" minus "Einsatz" ermittelt.
Ich zahle aber den vollen Ertrag ein. Im Fall von 90% und einer 80er Arche also nix Gewinn.
Bzw - und darum geht es - wenn mein Archebonus höher ist als 90% habe ich doch wieder Gewinn und den würde ich gern angezeigt bekommen.
Bzw bei einer 80er Arche und Förderung mit 85% den korrekten Gewinn.

Wollte man den Gewinn für den Fall Förderung korrekt anzeigen, dann muss das Ergebnis aus dem der Differenz des echten Archebonus resultierenden (und bei klick auf 85 / 90 nicht angezeigten) echten Ertrages und dem angezeigten Ertrag gebildet werden.

Heißt also - bei Klick auf Förderung 85 / 90 könnte man die hier nicht benötigte Spalte "Einsatz" ummünzen und da den echten Archebonusertrag eintragen. Die Spalte "Gewinn" kann so, jetzt für jedermann nachvollziehbar, den korrekten Gewinn bei der Förderung anzeigen = echter Ertrag aus Archebonus minus angezeigter Ertrag aus Button 85 / 90

Für den Fall Snipen müsste man garnichts ändern.
Ich würde die Spalte "Ertrag" wie gesagt angrauen damit das verständlicher ist und man sich nicht vertut.

@ursprünglich nicht zum Snipen gedacht.... ahhh... darum wird die Gilde der ausgewählten Spieler nicht angezeigt. Beim Fördern sind Bündnispartner ja kein Problem :D Beim Snipen schon...

@Gindi4711 Gindi4711 added the Next Version Issue will be dealt with in the next update label Jan 6, 2020
@Gindi4711
Copy link
Collaborator

Also die Rundungsthemen für die Übersicht werden mit dem nächsten Update gefixed.

Das andere Thema mit dem Archefaktor haben wir sehr intensiv diskutiert und auch schon probiert, haben aber entschlossen, dass wir vorerst einmal bei der bestehenden Lösung bleiben. Der Hauptgrund ist, dass es dadurch deutlich komplizierter wird und wir für die bestehenden Spieler ohne zwingenden Grund nicht auf ein anderes Bedienkonzept umstellen wollen.

Also kurz gesagt:
Wer fördert liest weiter von der Ertragsspalte ab, der Rest ist egal.
Wer sniped liest weiter von der Einsatz Spalte ab und schaut auf Gewinn/Kurs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Next Version Issue will be dealt with in the next update
Projects
None yet
Development

No branches or pull requests

4 participants