Wertebereich modifyXPopularity

[nittka]

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]

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]

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]

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]

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.