GamezWorld.de - Forum
Von Spielern für Spieler
Du bist nicht angemeldet.
Ein Beispiel fuer eine News "2 Uhr in Deutschland: Stromausfall in Solarkraftwerk Oekosonne verunsichert Menschen":
<availability script="TIME_ISNIGHT = 1 && TIME_YEAR > 2000" />-> && verknuepft zwei Bedingungen mit "und"
-> || verknuepft zwei Bedingungen mit "oder"
-> ( ... ) Klammern erlauben Bedingungen wie "(a und b) oder c" (was nicht "a und (b oder c)" ist)."(TIME_DAY = 0 && TIME_HOUR = 1) || TIME_HOUR = 0"
Macht dementsprechend etwas verfuegbar, wenn:
- 1 Uhr am Tag 0
oder
- 0 Uhr generell
Dachte das waere verstaendlich genug gewesen 
Viel Spass beim "Basteln".
PS: Die News kann ja dann mit "Variablen" fuer die ganze Nacht eingebunden werden... sehr gut.
bye
Ron
Offline
Freilich, ist mir das äußerst verständlich. Dann später halt und nach dreimal doof fragen... 
Neue Frage:
Kannst Du die Nachrichtenauswahl so gestalten, daß abgefragt wird:
- ist eine News mit Jahreseinschränkung vorhanden
- ist eine News mit Zeiteinschränkung vorhanden
Sodaß diese mit einer höheren Wahrscheinlichkeit dran kommen, als die ohne Einschränkungen?
Offline
Momentan wird ueber die Liste verfuegbarer "Startnachrichten" (also keine Folgenachrichten) gegangen und ein zufaelliges Element ausgewaehlt.
Was Du vorschlaegst, benoetigt ueber jedes Ereignis die immer aktualisierte Kenntnis ueber die "Enge" des Zeitfensters.
Nur ist so ein Zeitfenster ja nicht immer direkt durch die Zeit definiert. Sie kann auch indirekt festgelegt sein ("nur wenn Programmlizenz X gerade im Besitz eines Spielers").
Das macht es dann doch sehr "tricky".
Wir koennten es aber zumindest "grob" angehen:
- fuehren einer Liste mit "verfuegbaren Initialnachrichten" (bei Abruf "gib mir eine neue Nachricht" angelegt)
- diese Liste wird sortiert:
- - generell verfuegbare Ereignisse (ohne "availability script, yearFrom, ...) nach unten
- - eingeschraenkte Scripts nach oben (dadurch muessen wir die eigentliche Script-Ueberpruefung nicht durchfuehren bzw interpretieren)
- - der Zufall nimmt nun eine Zahl von 0-ListeneintragMax, dies aber gewichtet (also in eine Richtung "gehaeuft")
- - die Gewichtung betraegt 0.5 - 0.5 * AnteilEingeschraenktVonMax (eingeschraenkt/max), da 0.5 "keine Gewichtung" bedeuten wuerde
Das Problem in allen Faellen ist: wenn es nur wenige eingeschraenkte Elemente gibt, wie koennen wir die genauso gleichverteilt "aufrufen", als wenn wir viele eingeschraenkte Elemente haetten?
Wir muessen ja vermeiden, dass nur diese eingeschraenkten aufkreuzen - oder nahezu nie.
Deutlich wird dies, wenn wir so vorgehen wuerden:
- alle eingeschraenkten in eine Liste
- alle unbeschraenkten News in eine andere Liste
- wenn Zufallswert(0-100) > 75 dann nimm aus normaler Liste, sonst aus eingeschraenkter
Wenn nun in der eingeschraenkten Liste nur 1 Eintrag ist, wird dieser zu 75% ausgewaehlt, die anderen (vielleicht 200 Stk) nur _insgesamt_ zu 25%.
Wie gesagt, das Problem ist der Mangel an Wissen ueber "Dringlichkeit".
Ja / nein / bloed?
bye
Ron
Offline
Hm. Hatte ich mir gedacht, daß das nicht ganz einfach zu haben ist...
Die Variante, die Dich und die Rechenkerne weniger belasten täte, wäre, soviele Nachrichten zu haben, daß wir den Großteil zeitlich einschränken können.
Oder wir leben einfach mit den Wiederholungen.
Am besten, ich schreibe erstmal fleißig weiter und wir beobachten das geflissentlich.
Habe Dir die vorerst endgültige sjaele.txt gesendet.
Offline
Hm...
Die Lösung, um doppelte Nachrichten völlig auszuschließen, läge wohl darin, daß jede (!) Nachricht nach dem Senden ausgemustert wird. Das wiederum hieße, wir bräuchten mindestens für jedes Abo x mal pro Spieltag Nachrichten...
Ist das Ausschließen von Nachrichten möglich?
Wie hoch sind derzeit die Abstände, in denen Nachrichten rausgegeben werden?
War schon irgendeine Verzögerung durch Nachrichtenketten implementiert?
Offline
Damit schliesst Du doch nur doppelte Nachrichten aus, aber dein gewuenschtes "bevorzuge Nachrichten die fuer diesen Moment extra freigegeben wurden" waere da nicht dabei.
Doubletten lassen sich auch so ausschliessen: ist ein Template genutzt, wird es in eine "genutzt-Liste" verschoben (ausser es ist einmalig, dann wirds ins Nirvana geschickt).
Diese "genutzt"-Liste wird nur geleert, wenn keine neuen Templates eines Ereignisses mehr verfuegbar sind. Geleert natuerlich nicht komplett, sondern so "gebe alles frei, was aelter als 5(4,3...) Tage ist" (Tage 5...0 bis es wenigstens 1 Template freigegeben hat - oder 0 erreicht wurde).
so laeuft es derzeit - die Dubletten entstehen dann nur durch den Mangel an neuen Nachrichten, bzw. der "Langlebigkeit" von Newsbloecken die in der "Sendung" platziert sind (rechts). Es sind dann aber keine "Dubletten", sondern nur Nachrichten mit zufaelligerweise gleichem Inhalt (und in den derzeitigen Versionen auch mit geteilter Aktualitaet...).
Die Abstaende sind ~2,5h oder so (weiss ich grad nicht genau - steht in der game.newsagency.base.bmx)
@ Verzoegerung
Du meinst eine Nachrichtenkette verzoegert die Neugenerierung von Ereignissen eines Abo-Genres? Nein, ist nicht integriert (da ich bis jetzt noch keinen trifftigen grund dafuer sah).
bye
ron
Offline
aber dein gewuenschtes "bevorzuge Nachrichten die fuer diesen Moment extra freigegeben wurden" waere da nicht dabei.
Das wichtigere wäre mir, daß nicht so oft Nachrichten wiederholt werden.
Daß die Nachrichten bei jedem Spiel anders ist, ist o.k.
@ Verzögerung
Ist nur wegen eventueller Nachrichtenschwemmen. Vor allem in Zukunft.
Ich habe noch paar recht lange Ketten. Aber vielleicht werde ich die gleich so bauen, daß pro Spieltag nur eine oder zwei Nachrichten davon fällig werden.
Wir sollten's einfach im Auge behalten.
Offline
Ich hab noch eine Idee:
- wir koennten solchen "begrenztes-Zeitfenster-Nachrichten" auch ueber eine Art "Prioritaets-Wertung" wahrscheinlicher gestalten
- wir koennten festlegen, dass "bei verfuegbar werden" eine Nachricht auch ausgeloest wird
- ein Nachrichtenereignis was sowieso "einmalig" ist, kann einen Ausloesezeitpunkt definieren
Zur Prioritaet: alles mit "Prio 1" landet 1x in einer Liste, mit "Prio 10" dann 10x, aus allen Listeneintraegen wird zufaellig ausgewaehlt. Wenn alles "Prio 10" waere, entspraeche das aber an sich wieder einer "prio 1".
Der Ausloesezeitpunkt ist fuer Deine "Nachrichten der einzelnen Jahre" vielleicht angebrachter.
Von dieser Art Nachrichten habe ich mich halt fern halten wollen, da wir mit einem Nachrichtenpool halt viele Spieljahre abdecken wollen. Und der "Pool" erstmal aufgefuellt werden muss, bis wir die "Wuerze" hinzubringen koennen.
bye
Ron
Offline
Na, ich habe erstmal zugesehen, daß ca. die Hälfte der neuen Nachrichten ohne Einschränkung sind. Und von denen mit Einschränkung die Hälfte auf 85/86 liegt.
Drum wäre es schon günstig, wenn dann erstmal die 85er verbraten werden, weil die ja später irgend nutzlos sind.
Ich bräuchte mal für's Abschätzen der gesamten Nachrichtenmenge die aktuellen Frequenzen der Nachrichtenabos. Hattest das - soweit ich mich erinnere - letztens nochmal ohne konkrete Angabe verändert.
Offline
game.newsagency.base.bmx:
Method Initialize:int()
'=== RESET TO INITIAL STATE ===
For local i:int = 0 until TVTNewsGenre.count
'NextEventTimes[i] = GetWorldTime().GetTimeGone() - 60 * RandRange(60,180)
NextEventTimes[i] = -1
NextEventTimeIntervals[i] = [180, 300]
Select i
case TVTNewsGenre.POLITICS_ECONOMY
NextEventTimeIntervals[i] = [210, 330]
case TVTNewsGenre.SHOWBIZ
NextEventTimeIntervals[i] = [180, 290]
case TVTNewsGenre.SPORT
NextEventTimeIntervals[i] = [200, 300]
case TVTNewsGenre.TECHNICS_MEDIA
NextEventTimeIntervals[i] = [220, 350]
case TVTNewsGenre.CULTURE
NextEventTimeIntervals[i] = [240, 380]
'default
' case TVTNewsGenre.CURRENT_AFFAIRS
' NextEventTimeIntervals[i] = [180, 300]
End SelectAngaben in Minuten.
Ich fuehre mal noch den neuen Flag "KEEP_TICKER_TIME" ein. Intern wird er ja aehnlich schon fuer einige Nachrichten (wie das Wetter) benutzt. Dadurch wird der Flag (Wert "16") fuer alle Nachrichten verfuegbar.
Eingesetzt wuerde das Ausloesen einer Nachricht den "Ticker" nicht erneuern. Sprich es wuerde eine weitere Nachricht erzeugt werden (da der Ticker noch "abgelaufen" ist).
Weiterhin fuehre ich noch "RESET_TICKER_TIME" ein (Wert 32). Der klingt erstmal gegenteilig ist aber vor allem fuer Folgenachrichten interessant. Denn die setzen den Timer fuer ein Genre _nicht_ zurueck (kommen also "zwischendrin").
-> alternativ koennten auch in den DB alle Folgenews den Flag "KEEP_TICKER_TIME" bekommen ... momentan loese ich das so, damit kein Datensatz das erst selbst definieren muesste.
Wir koennten auch noch einen modify_ticker_time="120" in der DB einfuehren, mit dem koennte zur bestehenden hinzugefuegt (oder subtrahiert) werden. Das Ausloesen einer solchen Nachricht wuerde den naechsten Ticker vorziehen/verschieben koennen. Leider erzeugt eine solche Funktion umfangreichere Begehrlichkeiten ("min/max", "nur wenn" ..) die das erstmal komplexer machen, als von mir gewollt - und dann vielleicht nur von 2-3 Nachrichten umgesetzt werden.
Letzteres braucht pro Objekt mehr Platz - ist halt eine "flexiblere" bzw "anpassbarere" Sache. Die Flags sind sozusagen wie "Vorlagen". Aehnlich waeren Flags "DELAY_TICKER_TIME_30", "DELAY_TICKER_TIME_60" ... - die lassen sich durch die "Eindeutigkeit" insgesamt in einer einzigen Zahl abspeichern (dem Flag-Wert).
bye
Ron
Offline
Die "modify_ticker_time" erscheint mir unnötig.
Der Reset für die Kettennachrichten hingegen sehr nützlich.
Kannst Du das irgend automatisch an Nachrichten von Typ=2 anhängen?
edit:
Können wir Priorität und Reset erst nach dem Komplettpaket einführen?
Offline
Einfuehren kann man es doch vorher, solange es kein Eintrag nutzt.
@ Automatisch anhaengen
Wenn ich das problemlos machen koennte, wuerde ja ein "KEEP_TICKER_TIME" als Flag ausreichen - alles wuerde per "Standard" zuruecksetzen und nur die mit "Keep..." wuerden die Zeit unangetastet lassen.
Das Problem mit Flags ist: man kann eingeschaltete nicht so einfach ausschalten. Denke an einen Lichtschalter - du hast den Befehl "Licht ausschalten?" und kannst nur ja oder nein angeben. Damit kannst Du aber halt nur das Licht ausschalten (den Flagwert zum Gesamtflag addieren). Um es wieder einzuschalten, muesstest Du den Flagwert wieder subtrahieren - was halt mit der DB-Loesung noch nicht vorgesehen ist (und ein Editor muesste dann wissen, was vordefinierte Flags um sie dann in einem Feld "subtract_from_flags" beachten zu koennen).
Ansonsten haette ich das schon so geloest. Und es gaebe einen "MODIFY_TICKER_TIME", der bei Initialnachrichten aussagt ob er resettet oder nicht. Und bei Folgenachrichten, ob er eben nicht zuruecksetzt.
Nur ist dann vorrausgesetzt, dass der Bearbeiter um eben die Unterschiede weiss. SO muss er nur wissen: KEEP oder RESET.
Ab jetzt ist es so:
- alle Nachrichten haben "keinen Standardflag" fuer KEEP/RESET
- Initialnachrichten setzen Timer zurueck wenn nicht KEEP-Flag gesetzt
- Folgenachrichten setzen Timer nur zurueck wenn RESET-Flag gesetzt
Hatte bezueglich Wetternachrichten glaube noch einen "Fehler" im DevPatch (und eher) drin - die wurden so erzeugt, dass die die naechste Tagesgeschehen-Nachricht verzoegerten. Denke mit der "Wetterbericht in News ist obligatorisch"-Ansicht ist das veraltet.
bye
Ron
Offline
Einfuehren kann man es doch vorher, solange es kein Eintrag nutzt.
und es nicht ausversehen irgendwelche anderen Kleinigkeiten beeinflusst, sagen wir durch temporäre Unaufmerksamkeit beim Codeschmieden.
Beim Nachrichtenschreiben bin ich auf folgendes gestoßen und beäumele mich recht ausgiebig:
https://de.wikipedia.org/wiki/Liste_der_Tr%C3%A4ger_des_Ig-Nobelpreises
Bin grade dabei uns zwei pro Jahr für die Nachrichten zu gönnen.
Offline
Aber doch nicht wegen "Erik von Schwediken" und seinen Ausserirdischen?
@ DAYOFSEASON
Hab da gleich mal in meinem "ScriptExpression" einen Bug gefunden, wenn "DAYOFSEASON=2" statt "DAYOFSEASON = 2" geschrieben wurde ... nun wird das korrekt ausgelesen. Nichtsdestotrotz heisst das, wie auch in meinen Postings angeklungen "TIME_DAYxxxx=2" (das "TIME_" fehlte ueberall).
mit "DAYOFSEASON" muessten wir aufpassen: was passiert, wenn der Tag > Anzahl Spieltage in dieser Jahreszeit ist? Dann schlagen ja die Bedingungen fehl.
Hmmmm
bekommst dann eine korrigierte Fassung von mir.
bye
Ron
Offline
mit "DAYOFSEASON" muessten wir aufpassen: was passiert, wenn der Tag > Anzahl Spieltage in dieser Jahreszeit ist? Dann schlagen ja die Bedingungen fehl.
Ähm, erschließt sich mir jetzt nicht so ganz.
Das mit der Season hat aber noch einen anderen Haken: Der Winter geht über die Jahresgrenze hinaus. Habe drum den Winter ein wenig vermieden. Ist halt blöd, wenn eine für den Jahresanfang gedachte Nachricht am Jahresende auftaucht.
Dränichen ist da eher der Lahmanteil...
Aber das hier geht doch?!
Technik: zu gleichen Teilen verliehen an
- John Keogh aus Hawthorn, Victoria (Australien), für die Anmeldung des Rades zum Patent im Jahre 2001 und
- das australische Patentamt, das ihm Patent #2001100012 ausstellte.
Wirtschaftswissenschaften: Joel Slemrod von der Michigan Business School und Wojciech Kopczuk von der University of British Columbia, für ihre Schlussfolgerung, dass Menschen ihr Ableben verschieben, wenn dadurch weniger Erbschaftsteuer anfällt.
Offline
@ SEASON
Nun, es gibt Spieltage (momentan 12 pro Jahr) und es gibt "Kalendertage".
Jahreszeiten gibt es so oder so 4 Stueck - DAYOFSEASON kann bei uns 1-3 bedeuten (3 Spieltage pro Jahreszeit). Kalendarisch koennte man ja direkt ueber "TIME_DAYOFYEAR" abrufen (in Spieltagen derzeit nur mittels "TIME_DAYSPLAYED" - dann aber nur generell, ohne Jahreszeitenbezug).
Ich weiss, ist grad alles n bissl "durcheinander", aber ich hab noch keinen praktischen "Weltzeit" und "Fernsehzeit"-Namen gefunden ... weisst ja, es gibt die Zeit im Hochhaus/TV und dann die "Weltzeit" fuer Jahreszeiten/Feiertage ... auf die wir die "Spieltage/Jahr" aufpfropfen"
Wenn wir irgendwann sagen: hey, 24 Tage pro Jahr - macht das ploetzlich 6 Tage pro Jahreszeit ...
Nun das Problem erkannt?
@ Ig-Nobelpreis
Ja ... das ist ja auch ein aehm "ganz spezieller Nobelpreis" :-)
Das mit den Aliens betraf den Literatur-Nobelpreis!
Hast uebrigens deine sjaele.xml zurueck (EMail).
bye
Ron
Offline
@ SEASON
Ist im Prinzip schon klar, aber
Tag > Anzahl Spieltage
hat mich doch irgend verwirrt.
Prinzipiell nutze ich grade lieber die Season. Es sei denn, ich brauch's speziell. (Wenn's am Jahresanfang liegen soll, ist DAY=1 dran.)
Die Monatssache ist noch nicht eingebaut?
@ Ig-Nobelpreis
Hab zur Erklärung auch schon zwei Nachrichten geschrieben, um das einzuführen.
Offline
Die "TIME_****" waren noch nicht im Programmcode drin (die Datei war da, aber vom Projekt nicht importiert).
Ich mach einfach heute Abend mal einen neuen DevPatch fertig - den nutzen wir dann als Basis.
bye
Ron
Offline
Wenn ich derzeit spiele, richte ich mich dabei an den über die "Tab"-Taste zufügbaren Details.
Dabei fällt mir die KI-Attraktivität auf. Die unterscheidet sich teils recht stark von der Qualität.
Wie berechnet sich die?
@ Einfluss der Nachrichten
Die Einflussmöglichkeiten der Nachrichten auf das Zuschauerverhalten sind derzeit recht eindimensional: Bessere Qualität der Nachrichten heißt höhere Quote.
Zusätzlich wäre ein zielgruppenspezifischer Einfluss wünschenswert.
Da sehe ich zwei Wege, die vielleicht auch kombinierbar sind:
a) Zuordnung der Abo-Genres zu den Zielgruppen
b) Zielgruppen haben Kombinationsvorlieben
zu a:
Jedes Genre erhält je Zielgruppe eine Wertung von uninteressant bis schwer interessant.
zu b:
Jede Zielgruppe hat Lieblingskombinationen von Nachrichten:
z.B. Jugendliche: Showbizz/Politik/Medien
Falls eine entsprechende Kombination (auch nur teilweise?) vorhanden, gibt's Bonus.
Könnten ja auch mehrere sein, auch mit Doppelnennungen.
Offline
@ KI
Momentan "Qualitaet * Preis". Sie kann ja nicht den Preismodifikator sehen und sich also auch nur nach den "Balken" orientieren. Es handelt sich um die Qualitaet, die auch die Abnutzung mit einbezieht.
@ Abogenres
Die beeinflussen bereits die Zielgruppen. Siehe dazu "config/newsgenres.xml".
Ich kann fuer die Nachrichten auch die gleichen Zielgruppenmods wie fuer Programme einbinden (<targetgroupattractivity pensioners="1.2" unemployed_female="0.5" />).
@ Kombination
Also sollte neben den eigentlichen "News", die "Newsshow" noch die Kombinationen ueberpruefen. Bedenke: fuer jedes Genre erhoeht sich die Anzahl zu konfigurierender Wertigkeiten:
Kultur-Kultur-Kultur
Kultur-Kultur-Tagesgeschehen
Kultur-Kultur-Sport
...
Sport-Sport-Sport
bye
Ron
Offline
@ Kombination
Ich würde da nicht die ganze Reihe einführen wollen.
Nur für jede Zielgruppe eine oder zwei.
Aber ist vielleicht wirklich nicht so zielführend. Wäre sicher auch über Flags zu machen. Sind da schon welche möglich?
@ Abogenres
Na, irgendwann merke ich's mir...
Günstig, daß ich's noch mitkriege, ehe ich mit dem Balancing durch bin.
@ KI
Gut, muss ich mir mal genauer anschauen.
Im Moment sind die generierten Nachrichten vor allem betroffen.
@ Generierte Nachrichten
Die sind im Vergleich zu den anderen Nachrichten viel zu gut. Weiß noch nicht genau, ob ich die Nachrichtenqualität generell höher ansetzen sollte...
Bloß fallen mir dann wieder die Preise etwas zu hoch aus, was lediglich über die Erhöhung der Werbeprämien kompensiert werden könnte. (Oder über den Preismod. Den wollte ich aber zur individuellen Steuerung nutzen.)
Gibt's ähnlich dem Werbeprämienmod in der dev.xml auch einen Mod für die Nachrichten?
@ Aktualitätsabnahme
Am liebsten wäre mir, wenn Du die über eine .xml für mich steuerbar machst.
Falls das nicht so fix geht, könntest Du auch erstmal die Abnahme über die
- Zeit um 20% verlangsamen
- Ausstrahlung um 20% erhöhen
Warum das Ganze?
Bei qualitativ ähnlichen Nachrichten macht es sich schon bemerkbar, wenn sie viermal (also von allen Sendern) gesendet wurde, dann fällt die Qualität unter die einer etwas schlechteren und die Auswahlmöglichkeit wird größer.
Am liebsten wäre mir, wenn auch schlechtere Nachrichten eine Chance hätten und nicht bloßes Füllmaterial wären.
Daß also nicht gesendete schlechtere Nachrichten zuzüglich ihres Zielgruppenwertes irgend nützlich für den Spielverlauf werden.
Oder wir lenken das alles über den Preis? Also die Nachrichtenpreise auf das Level der generierten anheben, daß sich einfach nicht jede Nachricht geleistet werden kann.
Da bin ich mir echt nicht schlüssig...
Offline
@ Flags
Was meinst Du genau? Also welche Art von Schalter? Zielgruppen "anschalten" oder sowas?
@ Preise
Nun, ich brauch ja nur intern den Multiplikator anpassen damit die Preise anders ausfallen (Preis = Multiplikator * "Wert durch Qualitaet etc.")
Momentan ist das:
Preis = Max(0, 4000 * Qualitaet * individuellerPreisMod )
Die dynamischen Nachrichten koennen wir ja auch anpassen, wenn Du mir mitteilst, was da so "erwartet" wird.
@ Nachrichtenmod
Nein, kann ich aber beisteuern - wenn gewuenscht.
@ Aktualitaetsabnahme
Koennen wir ja auch per DEV.xml machen (deine 20% waeren dann ein "0.8" usw.)
Ich glaube ich habe da aber bei dem "Alterseinfluss" eh einen Denkfehler drin:
AlterInStunden = ...
Alterseinfluss = 1.0 - 0.01 * Max(0, 100 - 5 * Max(0, AlterInStunden) )
Alterseinfluss = Alterseinfluss * GetModifier("topicality::age")
'je niedriger die Qualitaet des Ereignisses, desto hoeher der Alterseinfluss
'maximal 80% moeglich
Alterseinfluss = Alterseinfluss + 0.8 * (1 - Rohqualitaet )(der eigentliche Code sieht weniger lesbar aus...)
Besser - und wohl eigentlich von mir auch gedacht waere die letzte Zeile folgend zu haben:
Alterseinfluss = 0.2 *Alterseinfluss + 0.8 * (1 - Rohqualitaet )Denn dann waere bei 100% Rohqualitaet (eine Topstory/Weltsensation) der Alterseinfluss auf 20% beschraenkt. Eine Billignachricht hingegen wuerde bis zu 100% von der Alterung betroffen sein.
Momentan kommen mir die Preise der Nachrichten generell relativ niedrig vor. Aber da sie auch an das Sendegebiet gekoppelt sind, sieht es im Endspiel sicher ganz anders aus.
bye
Ron
Offline
DEV.xml unterstuetzt nun
<!-- Balancing Qualitaet auf Alterseinfluss -->
<DEV_NEWS_QUALITYAGE_INFLUENCE value="1.0" />
<!-- Balancing Altereinfluss auf Maximale Aktualitaet-->
<DEV_NEWS_AGE_INFLUENCE value="1.0" />
<!-- Balancing AnzahlAusstrahlungen auf Maximale Aktualitaet -->
<DEV_NEWS_BROADCAST_INFLUENCE value="1.0" />Ausserdem habe ich besagten Alterseinfluss korrigiert. Ich maile dir dann einen neuen DevPatch zu (nur Linux, zwecks Traffic).
bye
ron
Offline
Also "QualityAge" beeinflusst, in welchem Rahmen die Rohqualitaet den Alterseinfluss beeinflusst :-)
Der Standardwert fuer letzteres ist 0.8. also
Alterseinfluss = (1-0.8)*Alterseinfluss + 0.8*(1-Qualitaetroh)
und die 0.8 an beiden Stellen wird mit dem "QualityAge" multipliziert. Ein Wert > 1.0 kann also zu "komischen Dingen" fuehren (negative Zahlen).
bye
Ron
Offline