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

Wertebereich modifyXPopularity #12

Open
nittka opened this issue Jun 2, 2021 · 4 comments
Open

Wertebereich modifyXPopularity #12

nittka opened this issue Jun 2, 2021 · 4 comments
Assignees

Comments

@nittka
Copy link
Collaborator

nittka commented Jun 2, 2021

Es gibt eine Handvoll Nachrichten, die die Beliebtheit (Genre und Person) modifizieren. Die Werte liegen da zwischen -0.07 und 0.075 (jorgaeff) sowie 0.1 und 2 (Ronny).
Der Code für die Anpassung scheint derselbe zu sein (game.popularity.bmx, TGameModifierPopularity_ModifyPopularity). Dort steht als Kommentar, dass der Min und Max-Wert durch 100 geteilt wird, was im Code allerdings nicht zu passieren scheint. Beim Einlesen zumindest wird der Float-Wert ohne Änderung übernommen und auch in der RunFunc-Methode bleibt die Größenordnung des changeBy-Werts unverändert; zudem werden Trend und Popularity angepasst.

Es sieht so aus, als ob die Beliebtheit ein Wert von -50 bis 100 sein soll. Wenn die min/max-Werte aber 1:1 verwendet werden (Draufaddieren des changeBy-Werts), scheinen sehr kleine Werte nicht wirklich Sinn zu ergeben. Man muss das natürlich vom trigger abhängig machen (happen!=broadcast). Im Moment sind aber alle "happen", d.h. der Effekt wird einmalig beim Erscheinen der Nachricht ausgeführt. Da kann man eine Anpassung von 0.05 (und selbst 0.2) aber eigentlich auch gleich lassen.

Hintergrund des Tickets:

  • Prüfen ob die oben getroffenen Annahmen/Aussagen stimmen, damit vorgeschlagene Wertebereiche für min/max-Werte in die Dokumentation übernommen werden können.
  • Ggf. Anpassung der Werte in der Datenbank.
  • Ggf. Kommentare im Code korrigieren
  • Ggf. Codeanpassung (Anpassung Trend und Popularity vom Wert her trennen; einmalig 5% Beliebtheitsgewinn muss den Trend nicht auch im gleichen Maß verschieben)
@GWRon
Copy link
Member

GWRon commented Jun 2, 2021

was im Code allerdings nicht zu passieren scheint

Method RunFunc:int(params:TData)
...
local changeBy:Float = RandRange(int(valueMin*1000), int(valueMax*1000))/1000.0
...
End Method

Hier wird aus bspweise "0 - 2" ein "1,34".
Das sind die einzigen Multiplikationen im dortigen Modifiercode.

die "durch 100" - ich glaube, damit ist eher gemeint, dass 100% als "1.0" dargestellt werden. Will man also +10% machen, soll 10/100 (0.1) geschrieben werden.

jorgaeffs Werte sind also -7 bis 7,5% -- und meine gehen von 0.1 bis 0.2 (bei Person nicht bis 2) und sind somit 10 - 20%.
Fuer das Filmgenre hingegen ... ja, da sind die Zahlen wohl um Faktor 10 zu gross.

popularity.SetPopularity(popularity.popularity + changeBy)
-> denke hier war frueher "ModifyPopularity" angedacht, denn das haette als ersten Parameter einen Prozenzsatz ("changeBy") erwartet.

@nittka
Copy link
Collaborator Author

nittka commented Jun 2, 2021

Diese Codestellen habe ich auch gefunden und gemeint. Insb. die Verwendung von poplarity.SetPopularity scheint aber das Problem zu sein, denn dadurch fließen doch die Werte so wie sie sind ein: alte popularity=23 (da laut Kommentar nicht von 0-1 sondern 0-100) changeBy=0.075 -> neue popularity 23.075

Ich muss mir das aber auch nochmal am laufenen Code anschauen.

@GWRon
Copy link
Member

GWRon commented Jun 2, 2021

Wir koennten die Chance auch gleich dazu nutzen, hier die Floats komplett rauszuschmeissen.

Die Werte wuerden dann von -50.000 bis zu 100.000 gehen (falls wir 3 "Kommastellen" brauchen). Muessten natuerlich die Trendberechnungen darauf angepasst werden (0.50.5 ist halt was anderes als 500500 - musst die "Kommastellen" immer mit einberechnen).

Ich habe dazu schon ein paar Ueberlegungen angestellt (eigene Structs, die als sFakeFloat oder so angelegt waeren und intern einen :Long-Wert und ein :byte-Praezision (Anzahl Kommastellen) beinhalten wuerden. Allerdings geht das mit der derzeitigen Reflection-Funktionalitaet noch nicht.

@nittka
Copy link
Collaborator Author

nittka commented Jun 2, 2021

Das klingt nach einem größeren Refactoring (inkl. Kompatibilität der Bestandsspielstände). Von der Prio her würde ich das jedenfalls nicht unmittelbar als nächstes sehen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants