Have you tried with [Root.GetName]? I think our text system is still a bit harsh on case-sensitivity.About log comand.
tryed this:
log = "plague start on planet [root.GetName]"
And
In event desc this:
population_improved_plague.10.desc:0 "[event_targetopulation_improved_plague_count.population_improved_plague_pop_num]\n\n[population_improved_plague_count.population_improved_plague_pop_num]"
And get this:
Code:[22:27:34][game_text.cpp:314]: Unknown property: GetName [22:27:34][game_text.cpp:314]: Unknown property: GetName [22:27:34][game_text.cpp:314]: Unknown property: GetName [22:27:34][game_text.cpp:314]: Unknown property: GetName [22:27:34][game_text.cpp:314]: Unknown property: GetName [22:27:34][game_text.cpp:314]: Unknown property: GetName [22:27:34][game_text.cpp:314]: Unknown property: GetName [22:27:34][game_text.cpp:314]: Unknown property: GetName [22:27:34][game_text.cpp:314]: Unknown property: GetName [22:27:34][game_text.cpp:314]: Unknown property: GetName [22:27:38][game_text.cpp:314]: Unknown property: population_improved_plague_pop_num [22:27:38][game_text.cpp:314]: Unknown property: population_improved_plague_pop_num
Scoping to an event_target in text functions should not include the prefix "event_target:" unlike how it's used in the script files. Then I guess that you're trying to print the value of a scope-stored variable? It should work with just writing the name of the variable on the right-hand-side of the dot. However if the variable name is not initialized for that scope then it will throw that error for you.
We know that having variables on the right-hand-side of numerical parts of script triggers and effects would be immensely powerful. It's however quite an overhaul on all of the projects that is required since we need to update the code on all of the relevant triggers and effects. I won't promise anything but if I see a possibility to port a system for this across all of our projects in a semi-smooth way I'll be right on it. In the meantime however you'll unfortunately have to make due with what is available.As discussed in this thread: https://forum.paradoxplaza.com/foru...d_planet_flag-based-on-size-of-planet.978735/
We attempted to figure out why a malformed token was being returned in a set_timed_planet_flag statement. We discovered that, apparently, days must always be passed an explicit numeric value. Attempting to give it a dynamic non-explicit value from a variable caused the code to seize up, and all uses of days by paradox themselves also only ever uses explicitly defined whole numbers. This is somewhat complicating as this means we would have to create an if statement for each assignment. This greatly limits flexibility in handling events where a countdown timer is preferred over a less defined, probabilistic function such as MTTH.
Is it possible for days/months/years to have better assignment values? One example would be such that "....days = 1000" could also be "....days = some_variable" or potentially "....days = this.some_variable"
- 1