-
Notifications
You must be signed in to change notification settings - Fork 186
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
Comments
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: Wie sich das lösen lässt, darüber muss ich erst etwas grübeln. |
@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? |
Das Ganze ist etwas komplexer, aber ich habe schon einen Plan, wie es sich lösen lässt: Der Kostenrechner wird die Zeile dann mit Gewinn 0 und Kurs 200% anzeigen. |
...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. |
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:
In der weiteren Folge hat es für die Variante 1 für das Umschalten zwischen 85% und 90% die 2 Buttons 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: 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. 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. |
Warte mal... vielleicht denke ich ja auch falsch... Den User interessiert doch fürs Snipen die Spalte "Einsatz" - und der echte Gewinn. 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? 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. 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? 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. |
...ach was mir gerade auffällt: |
Das verstehe ich nicht ganz. 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. |
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. Und hier halte ich es für sinnvoll:
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. |
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. Beispiel: 2.) Die Lösung mit den Buttons Snipen/185/190 würde so aussehen: 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. 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. |
Wahrscheinlich denke ich zu quer. 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. @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... |
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: |
Der Vorabscan zeigt einen möglichen Gewinn an, der Kostenrechner nicht...
The text was updated successfully, but these errors were encountered: