EU3 DW MODEN

[Nichts13]

Klar, das war ja auch eine eigene Frage.

Über Teile der Seite bin ich auch schon ein paarmal gestolpert, aber die Hauptseite hatte ich bisher noch nicht, danke.

Zusatz: Und noch eine kleine Minifrage: Multiplizieren/Addieren sich AI-will-do-Modifier auf, wenn sie die gleiche graduelle Abfrage beanspruchen?
Also zB wenn es

modifier = {
factor = 2
emperor = {
badboy = 0.5
}
}
modifier = {
factor = 1.5
emperor = {
badboy = 0.2
}
}

ist, hat dann einer mit Ruf über 0.5 als verändernder Faktor nur 2 oder noch durch den zweiten Modifier auch modifiziert?

[Mhhkay]

Beides. Da müsstest du noch hinzufügen NOT = { badboy = 0.5 }. Dann wäre es jeweils nur einer.

[Nichts13]

Ah danke. Da es sowieso wohl immer die gleichen Schritte werden, kann ich es auch einfach beides nehmen lassen (wobei, bei Multiplikation, wäre das ja Zinseszinssteigerung - naja, bei den Häufigkeitsberechnungen auch nicht das Schlimme).

Wollte mit der Console meine neue Eventfolge testen ... scheitere dabei nur leider gewaltig.

# Rückgabeforderung wird laut
province_event = {

id = 201000140001

trigger = {
emperor = {
exists = yes
war = no
}
hre = yes
NOT = { is_core = THIS }
is_capital = no
NOT = { has_province_flag = emperor_nagged_for_it }
NOT = { has_province_flag = given_to_the_emperor }
owner = {
is_emperor = no
war = no
}
}

mean_time_to_happen = {
months = 48 # Random Province Event

modifier = {
factor = 0.5
owner = { centralization_decentralization = 0 }
}
modifier = {
factor = 0.5
owner = { badboy = 0.15 }
}
modifier = {
factor = 30.0
owner = { luck = yes }
}
modifier = {
factor = 1.5
owner = { NOT = { centralization_decentralization = -1 } }
}
}

title = "EVTNAME201000140001"
desc = "EVTDESC201000140001"

option = {
name = "EVTOPTA201000140001" # Rückgabeforderung wird laut
emporer = {
country_event = 201000100001
}
}
}


# Entscheidung über Rückgabeforderung
country_event = {

id = 201000100001

is_triggered_only = yes

title = "EVTNAME201000100001"
desc = "EVTDESC201000100001"

option = {
name = "EVTOPTA201000100001" # Anfrage um Rückgabe
ai_chance = {
factor = 80
modifier = {
factor = 1.5
from = {owner = {badboy = 5}}
}
modifier = {
factor = 3
from = {is_core = {vassal_of = emporer}}
}
}
from = {
province_event = 6007
}
}
option = {
name = "EVTOPTB201000100001" # Keine Anfrage um Rückgabe
ai_chance = {
factor = 20
modifier = {
factor = 1.5
from = {owner = {relation = { who = emporer value = 150 }}}
}
modifier = {
factor = 3
from = {owner = {vassal_of = emporer}}
}
}
owner = {relation = { who = emporer value = 50 }}
add_imperial_influence = -7
from = {set_province_flag = emperor_nagged_for_it}
}
}

Es bringt mir irgendwie immer nur das Erste (oder zumindest eines ohne Auswahl), aber mit der Localisation vom Zweiten. (Und ja in der Localisation sind sie richtigrum zugeordnet.) Aber es scheint auch nicht die Folge-Events zu feuern. Ich habe schon mehrmals durchgeschaut, ob ich vielleicht vergessen hätte eine Klammer zu schließen, aber leider habe ich da bisher nix finden können. Könnte es an der hohen EventID liegen, dass er damit nicht zurechtkommt? (Ist ein Kode, keine hochzählende Zahl, deswegen ist sie so lang). Oder macht die console nicht so ganz, dass was sie soll, wie zB Folgeevent feuern? Was ich auch noch seltsam fand, dass ich beide IDs nehmen konnte und dennoch scheinbar beim gleichen Event lande - aber auch wenn ich bei einem eine 1 davorsetze (in der Annahme, dass die ID zu lang wäre und er nur die ersten Teile durchgeht) und somit die IDs direkt in der ersten Ziffer ändere, bleibt es so bestehen. Deswegen fürchte ich eigentlich am ehesten, dass da was mit den Klammern nicht stimmt ... kann nur leider gar nix finden, was da nicht passen würde.

Zusatz: Wenn ich die Namen und den Text vom zweiten Ereignis rausnehme, dann bekomme ich ein Localisation missing - er nimmt also nicht deswegen die zweite Localisation, weil er sie mit der ersten verwechseln würde; irgendwo muss da doch ein Fehler drin sein und wahrscheinlich nur so eine verdammte Klammer, die ich einfach nicht finde. Ist aber immernoch ein Ereignis mit nur einer Wahlmöglichkeit und es scheinen keine Folgeevents zu feuern. Irgendwo im ersten vor "title" muss ich wohl den Fehler haben ... arg.

Zusatz 2: Ich kann das Event ganz rausnehmen und kann es mit der Console immernoch triggern ... irgendwie muss das wohl doch an der ID liegen. Hoffentlich ist die nicht auf Integer oder sowas "Kleines" begrenzt ...

Zusatz 3: Und weils so schön ist nochmal ein Zusatz: Lag wohl wirklich an der hohen ID - scheinbar ist irgendwo bei 10 Ziffern Schluss (tiefe zehnstellige gehen noch, 9999999999 nicht). Schaue gerade, in welchem Rahmen der Umsprung ist.

[Mhhkay]

http://www.mediafire.com/?bxmm7x21l22uko5

Drüber laufen lassen.

Und was allgemeines. Ich würde nicht per Console Events ausführen. Mach lieber die Mean time to happen auf 0 oder 1 Monat. Dann sorg für die richtigen Bedingungen und so weißt du auch sofort, ob deine trigger stimmen.

PS: Er sagt was von invalider Event ID. Also kürze da mal ein paar Zahlen raus und probiers nochmal.

[[B@W] Abominus]

In der Console werden die aber auch angegegeben, wenn ein Trigger nicht erfüllt ist, ist ein kleines rotes Sternchen davor.

[Mhhkay]

In der Console werden die aber auch angegegeben, wenn ein Trigger nicht erfüllt ist, ist ein kleines rotes Sternchen davor.

Ok dann ists ja schnuppe^^

[Nichts13]

Ja, die Console zeigt da einiges an ... man muss nur erstmal herausfinden, wie es überhaupt aussieht, wenn die Console es normal schaffen soll. Hätte ich gewusst, wie die Console bei Erfolg aussieht, hätte ich schon daran erkannt, das was Grundlegendes falsch ist.

Hm, ob die Zahl bei Fehlversuchen die Maximalzahl ist? Direkt mal schauen, war glaub auch bei 12stelligen gleich.
Zusatz: Die bei zu Hoher Zahl angezeigten 2147483647 scheinen so etwas wie die Obergrenze zu sein, womit er zurecht kommt - wenn auch vielleicht nicht die absolute, aber "weit" scheint es nicht darüber zu gehen. Scheint aber schon dieser Wert als letzte Mögliche ID zu sein. Jetzt muss ich nur noch rausbekommen, warum er das Folgeevent nicht feuert; vielleicht ist dazu die Obergrenze noch kleiner. Oder es werden Folgeevents auch mit Console nur gefeuert, wenn die Bedingungen zutreffen?
Zusatz: Folgeevente dürfen mit ihrer ID wohl nicht über 2147483 gehen, damit sie auch aufgerufen werden können - höhere IDs (ab 2147484, hier auf die Einerstelle genau ausgetestet, so ich nicht glatt mal falsch getestet habe) kann der Comp wohl nicht zuordnen.

[Nichts13]

Habe jetzt das ID-System umgestellt und damit eine viel kleinere passende Zahl (12000 und 12001) und es passt auch vom Text her - jetzt erkennt es auch im Tooltip zwar, dass es das Folgeevent starten sollte und erkennt es auch mit Namen ... nur startet es dann leider nicht. Irgendwas ist da immernoch nicht ganz stimmig; auch wenn ich nicht weiß, ob das nicht vielleicht an der Console liegt - wobei, mit der hatte ich eig auch schon ein Folgeevent gestartet bekommen ...

Man, war das eine Schwere Geburt - noch eine geschwungene Klammer hat gefehlt und emporer war natürlich falsch geschrieben ... jetzt klappt nur eins noch nicht (so ich es jetzt richtig sehe - aber wenn ich den Abschnitt als Kommentar entschärfe, klappt es wie es soll):

modifier = {
factor = 3
from = {is_core = {vassal_of = emperor}}
}

da ich abfragen will, ob ein Vasalle des Kaisers einen Anspruch auf die Provinz hat und nicht ob der Besitzer oder ein Spezifisches Land einen Anspruch darauf hat (was ja sowieso schon weiter vorne ausgeschlossen worde).

Dagegen klappt

modifier = {
factor = 3
from = {owner = {vassal_of = emperor}}
}

bei der zweiten Option problemlos - aber da ist die Anfrage natürlich auch auf den Besitzer speziell und nicht als Rundumschlag.

Weiß jemand, wie ich das erste so abändern kann, dass der schaut, ob ein Kaiservasalle einen Kern auf die Provinz hat? Haha, any_core war das Gesuchte. Gerade auf der Suche nach der Abfrage für die Rufgrenze (ich hoffe die gibt es, scheint bisher eher schlecht) gefunden. So langsam kann ich mich an die Feinabstimmung der kaiserlichen Rückgabeforderung machen.


Und da ich bei meinem Suchen jetzt auch noch über http://www.paradoxian.org/eu3wiki/Li...scope_triggers gestolpert bin, da aber wieder die Abfrage vermisst habe: Kann man und wenn ja wie abfragen (natürlich für was anderes als das oben genannte) ob ein Land durch ein anderes Land (in dem Fall letzteres mit this abhandelbar) garantiert ist? Würde gerne verhindern, dass die Vasallenannektionsmission bei Vasallen kommt, die man garantiert - könnte man zwar auch mit Spionen und einem country-flag machen (und ich glaube ich kann mir auch denken wie), aber das wäre dann doch etwas "grob" - und irgendwo muss der Computer die Abfrage ob Garantiert oder nicht ja ansich auch haben.

[Nichts13]

Und dann mal wieder weiter mit der großen Nichts-kapiert-mal-wieder-nichts-Runde:

Ich habe bereits ausgeschlossen, dass der Besitzer auf die jeweilige Provinz einen Kern hat – nun bräuchte ich aber noch die Abfrage, ob ein (existentes oder nicht existentes) Land noch einen Kern auf die Provinz hat: Zu gutdeutsch: Ich bräuchte die Abfrage ob auf eine Provinz (province_event) irgendein Kern besteht. Mit is_core und any_core bin ich leider nicht weitergekommen. Auch ein existing_country oder sowas habe ich nicht gefunden und exists bringt mich ja leider nicht wirklich weiter, da ich da dann einen tag dazu bräuchte. THIS geht leider nicht, dass ist schon vom Provinzbesitzer besetzt.



Und noch ein wenig negatives maximales Ruflimit:
Ich habe jetzt zwar eine ganze Zeit versucht, das Negative Ruflimitproblem anders zu lösen (so, dass es bei negativem Ruflimit Plus auf das Ruflimit gibt, aber dafür einige andere Einschränkungen), doch leider scheint das kaum wirklich möglich zu sein.
Bei getriggerten Modifiern kann ich zwar auf das Verhältnis zugreifen (sehe also, wann es negativ ist, nämlich wenn das Verhältnis negativ wird), weiß damit aber natürlich nicht wie weit es wieder hoch muss – sogesehen sind 1 zu -1 (aktuell zu Maximum) das Gleiche wie 4 zu -4. Und weder das Maximum noch den aktuellen Wert bekomme ich rein. Über Events geht es auch nicht, da kann ich nämlich nicht nur nicht auf das Ruflimit zugreifen (scheint er als zu messenden Wert für Modifier und Events einfach nicht zu kennen), sondern auch nicht auf das Verhältnis – da kann ich nur auf den wirklichen Rufwert zugreifen. Alleine bringt der mir nur leider nichts. Mit dem Verhältnis zusammen würde ich es mir ja (mühsam) zurückrechnen lassen können, aber beide getrennt helfen mir leider nicht. Und dann kann ich auch nicht einfach den wirklichen Rufwert des Events einer Variablen zurechnen und damit bei den Modifiern hausieren gehen …
Ihm sind Variablen zwar unwichtig genug, dass er

set_variable = {which = Neg_Ruf_Var value = badboy}

übergeht, aber er kümmert sich dafür nicht darum welcher Wert im Badboy ist, sondern nimmt einfach 0.
Am besten wäre es wohl das über getriggerte Modifer zu machen (die berechnet er wenigstens auch nicht jeden Tag für jedes Land – das als derartige Events würde wohl dem Comp einiges an Rechenarbeit einbringen); man müsste zum Verhältnis aber noch einen absoluten Wert dazubekommen – ansonsten würde wohl nur Versuch und Irrtum helfen: Was wieder in einer Unmenge Rechenleistung endet und möglicherweise auch mehrere Monate Spielzeit. Anscheinend scheint es wirklich mit das einfachste zu werden, die Ruflimitmodifikatoren so abzustimmen, dass sie nicht im Negativen landen; hätte es ansich ja lieber eleganter gelöst.

Zusatz: Wobei mir gerade einfällt, dass ich vielleicht mittels Variablen den Wert übertragen kann - auch wenn das eine ziemliche Mühe (und ein weiteres nichtssagendes Event mehr) wäre, die doch eigentlich nicht nötig sein sollte. aber so könnte ich wohl wenigstens den aktuellen Rufwert übertragen ... mal sehen, vielleicht finde ich ja noch einen passablen Weg.

[Mhhkay]

Zu erstens. Nein gibt es meines Wissens nach nicht.

zu "set_variable = {which = Neg_Ruf_Var value = badboy}" zum einen muss der Variablenname nach which in "". Zum anderen funktioniert das mit value = badboy nicht... oder? Deswegen ist es auch kein Wunder, dass er 0 als Wert nimmt. Mach mal die Anführungsstriche hin und schau nochmal.

Und ich weiß auch nicht, warum es NICHT elegant wäre, die Ruflimit Modifkatoren, aufeinander abzustimmen. Hast du überhaupt schon mal daran gedacht, manche Modifikatoren einfach nicht zuzulassen, wenn das Ruflimit negativ würde?

[noxx-0]

any_core = {
exists = no
}

das klappt nicht?

[Mhhkay]

any_core = {
exists = no
}

das klappt nicht?

Glaube ich kaum, da any_core für den Country-Scope vorgesehen ist, und somit auf IRGENDEINE Core von dem zuvor bestimmten Land switcht.

[Nichts13]

Zu erstens. Nein gibt es meines Wissens nach nicht.

zu "set_variable = {which = Neg_Ruf_Var value = badboy}" zum einen muss der Variablenname nach which in "". Zum anderen funktioniert das mit value = badboy nicht... oder? Deswegen ist es auch kein Wunder, dass er 0 als Wert nimmt. Mach mal die Anführungsstriche hin und schau nochmal.

Und ich weiß auch nicht, warum es NICHT elegant wäre, die Ruflimit Modifkatoren, aufeinander abzustimmen. Hast du überhaupt schon mal daran gedacht, manche Modifikatoren einfach nicht zuzulassen, wenn das Ruflimit negativ würde?

Die Variable war ja nur ein Lösungswegversuch - der leider nicht geklappt hat, eben da ich auf diese Weise den Badboy nicht der Variablen zuweisen kann - habe bei in der Wiki aber auch nur gefunden, wie ich eigene Werte (also Zahlen ansich) der Variable zuweise - damit ginge es natürlich schon, aber dann müsste ich natürlich für jeden "Sicherungsschritt" eine neue Abfolge schreiben, die ansich doch fast alle nur das gleiche enthalten. Und spätestens bei nichtmal Hundert würde mir wohl der Spaß daran vergehen ... .
Mit elegant meinte ich, dass es ein Weg wäre, bei dem man nicht sonderlich auf die Ruflimit-Modifikatoren achten bräuchte, aber dennoch davor sicher wäre, versehentlich ins Minus zu rutschen. Gegenseitige Abstimmung geht natürlich auch, nur dann führt man einen weiteren ein und muss alles neu Abstimmen.
Das Problem ist halt, dass Ruflimit kein abfragemöglicher Wert ist (oder ich zumindest nicht finden konnte) - gäbe es diesen, wäre es wunderschön einfach gegangen. Aber so haut er einem die Mali ständig rein, weil er die Abfrage nicht lesen kann und dass ist ja auhc nicht Sinn der Sache.

Irgendwo bin ich glaub mal über etwas gestolpert, dass abfragt, ob eine Provinz einen Kern von irgendjemanden hat - ich weiß nur leider nichtmehr wo.


noxx: exists ist leider eine Abfrage, die als Wert nur TAGs (und glaub auch this) zulässt - aber das ist ja leider nicht das was ich suche, will ja nicht abfragen, ob es nicht irgendwo in der hintersten Ecke ein Land geben könnte (oder zumindest existieren könnte aber nicht tut), dass einen Kern hat und jedes Land einzeln abfragen. Das wären ja schon im Ungemoddeten Zustand glaub über 200 Länder ... (das gäbe einen Text ... wobei, so könnte es im Notfall gehen - wenn ich keinen anderen Weg finde, mache ich es vielleicht doch so. Wird sich zeiten müssn.) Werde es zur Sicherheit aber dennoch mal austesten.
Zusatz 2: Wenn ich den console-Text jetzt richtig gelesen habe (Jede Kern-Nation = Existiert nicht), dann müsste er es sogar wirklich schlucken. Dann hatte ich wohl irgendwas falsch eingegeben. Dann muss ich es jetzt nur noch so ummodeln, dass er daraus eine Abfrage nach einem Kern macht - ob die gleiche Abfrage nochmal dazu aber mit Not verziert und or verbunden das bringen würde, was ich suche? Oder ob er sich dann selber abschießt? Mal sehen. (Wobei, da würde ich an der Console wohl nur sehen, ob er es macht, nicht ob er es richtig macht ...)
Zusatz 3: Dem Console-Text nach schluckt er yes sogar richtig und nicht als TAG. Wenn ich es jetzt richtig lese (>>Einer der folgenden Punkte muss zutreffen: Jede Kern-Nation = Existiert nicht oder Jede Kern-Nation = Existiert<<), müsste das doch jetzt eine Abfrage sein, ob die Provinz irgendeinen Kern von irgendjemanden hat, egal ob existent oder nicht. Das sicher herauszufinden (oder ob ich es damit so abgeschossen habe, dass er daraus immer trifft nicht zu macht) erfordert dann wohl eine größere Testreihe. Mal sehen, wann ich dazu komme, dass soweit wirklich zu sichern.


Zusatz:

Glaube ich kaum, da any_core für den Country-Scope vorgesehen ist, und somit auf IRGENDEINE Core von dem zuvor bestimmten Land switcht.

Den habe ich aber auch schon Provinzbezogen verwendet, da schaut er, ob irgendein Land, dass einen Kern auf die untersuchte Provinz hat, etwas zutreffend hat ... was war das gleich? Ah, da, beim Modifier:

from = {any_core = {vassal_of = emperor}}

Bezieht sich explizit auf die Kerne der entsprechenden Provinz, und nicht auf einen Kern des untersuchten Landes.
Oder meintest du das?

[Nichts13]

Da ich das bisschen Zeit gerade mal wieder für ein wenig Modden genutzt habe, sammeln sich direkt mal wieder Fragen in Massen:

Wie lautet die Abfrage, ob das Zielland bei Missionen eine Garantie hat? Würde gerne die Annektionsmission soweit abändern, dass sie nur kommt, soweit man das Opfer nicht garantiert.

Wie kann ich den „temp_claim = THIS“ Modifier für Eroberungen nach einer bestimmten Zeit wieder enden lassen? Würde gerne eine Spio-Mission einbauen, die einen Eroberungskriegsgrund (der stark in der Ruf-Reduzierung gesenkt wird; was der da (zumindest in der Stärke) zu suchen hat, verstehe ich sowieso nicht) gegen eine Provinz gibt; aber anders als bei normalen Missionen haben die Spio-Missionen ja keinen Punkt „abort_effect = {remove_temp_claim = THIS}“ Kann ich dies vl gar auch einfach über ein duration lösen? Will bei dem cb eigentlich nicht soviele province-flags zusätzlich einbauen, wie es Länder gibt ...

Ich suche eine Abfrage für die Dauer eines Zustandes, in dem Fall des Verbündetseins – Will die Mission Nachbarn zu schlucken soweit ändern, dass sie nichtmehr bei Ländern kommt, mit denen man über lange Jahre verbündet war und gute Beziehungen unterhielt. (Bei Staatsehenmöglichen würde es ja auch ohne Schwert gehen, aber auch da wären über 10 Jahre doch etwas viel … und es zerstört zumindest für mich auch etwas die Atmosphäre, besonders bei Nationen, die ansich auf Augenhöhe zueinander sind und ist natürlich umso blöder bei Nationen, bei denen die einzige Möglichkeit sie zu schlucken sie zu erobern ist. Wäre aber sicherlich auch noch für anderes sehr hilfreich.

Ich bräuchte eine Liste für Effekte, die aber nicht Zufallsgebunden ist, sondern „Fakt-gebunden“, also zB hat Provinz-Mod XY, mache XY, aber hat es Provinz-Mod ZQ mache ZQ. Gibt es sowas? Würde nur ungern da für jede einzelne Möglichkeit ein eigenes Ereignis machen, das gibt ja nur unnötigen Datenmüll …

Gibt es noch eine Event-artige Möglichkeit, die aber im „Blinden“ abläuft? Wenn ich da jede Provinzflag mit Event abändern muss, kann man im Spiel entweder nur alle Ereignisse abstellen (sehr unschön) oder es würde irgendwann verdammt nervig werden, wenn sich Provinzflags wie bisher weiter ansammeln; vor allem wenn nur um einen Provinzmodifier zu tauschen, weil zB der Besitzer die Religion gewechselt hat, bzw die Provinz in den Machtbereich eines Andersgläubigen überging.

Und wo wir gerade dabei sind: Kann mir jemand sagen, warum dieser Trigger funktioniert? (Und ja, ich habe keine Klammer zu vergessen zu kopieren, dass ist es ja gerade ... mit einer weiteren Klammer zu funzt es nicht.)

trigger = {
and = {not = { province = {religion = this}}
# not = {owner = { religion = this } }
this = {missionaries = 1}
}

PS: Die stillgelegte Zeile ändert nix am Zustand des Funktionierens bzw mit weiterer Klammer nicht Funktionierens.

[Alexander III.]

Hab auch mal ne Frage.

Möchte gern ein Event einbauen, dass mir meldung gibt wenn in nem anderen Land ein Triple 9 Herrscher an die Macht kommt. Oder von mir aus auch wenn der so einen Erben bekommt. Hab aber keine ahnung wie. Die KI bekommt bei mir auf Triple 9s sehr hohe Boni(triggered_modifiers) und kann damit ne menge Unfug anstellen. Ein menschlicher Spieler könnte damit nonstop alles um sich herum annektieren, ohne auf den BB achten zu müssen. Denn dieser wird sehr schnell abgebaut. Würde gern darüber informiert werden, wenn ich demnächst eins auf maul bekomme.

Grüße