|
몇몇 시스템적 요소들은 이처럼 특정한 DLC 를 요구하는 경우가 있습니다. 그러나 모딩을 하는 우리 입장에서는 어디까지가 어떤 DLC 의 영역인지 알기가 사실 어렵습니다. 그래서 일반적인 모드의 경우에 이 조건문을 제대로 넣어 둔 경우가 그리 많지가 않은데, 이것이 가끔 오동작의 원인이 되곤 해요. 대부분의 모드의 설명에, 모든 DLC 가 실행 가능할 것이 권장되는 이유입니다.
어떤가요? 해석이 되시나요? 정리해보면,
이벤트의 trigger = { } 섹션에서 설정하는 조건은 기본적으로 ROOT 에 대한 조건입니다. 따라서, 이 이벤트는 딸에게 발생하는 이벤트이고, 그 결과 ROOT 는 딸입니다. FROM은? 없다고 생각하시는 게 좋습니다. 이 기본 스코프 문제는 절대 혼동하시면 안 됩니다.
이 정도 해석이 무리없이 되신다면, 이벤트의 트리거를 작성하시는 데는 문제가 없으리라 생각됩니다. 예전에 조건문 이야기에서도 말씀드렸지만, 항상 조건 연산의 기본은 AND 입니다. 따라서 OR = { } 로 묶이지 않은 조건들은 모두 AND 처리 하시면 됩니다.
한 가지 주의 사항. trigger = { } 구문은 조건을 만족할 시에 해당 이벤트를 실행하지만, 몇 번 실행한다는 규칙은 없습니다. 따라서, 한 번 이벤트가 실행된 후에도, 해당 조건을 만족하는 한 트리거 확인 쿨타임이 돌아올 때마다 CKII 는 이 이벤트를 계속 실행합니다. 기본값이라면 20일 간격으로 같은 이벤트를 끊임없이 보게 돼요. 따라서 한 번만 실행해야 하는 이벤트라면 앞에서 본 플래그 등을 사용하여 제어를 해 주시고, 일정한 주기를 요한다면 다음에 설명하는 mean_time_to_happen = { } 구문을 사용하거나, 나중에 설명할 모디파이어 등을 이용해서 제어를 해 주시기 바랍니다.
보통은 trigger = { } 와 함께 등장하죠. 평균적으로 얼마 정도의 시간마다 이벤트를 발생시킬지를 정하는 구문입니다. trigger = { } 만 지정되어 있다면 조건을 충족하고 거의 곧 이벤트가 발생하지만, mean_time_to_happen 이 함께 지정되어 있다면 지정된 시간만큼 이벤트의 등장이 늦춰집니다.
단, 여기서 정하는 시간은 정확한 시간이 아닙니다. "평균적으로" 그렇다는 것이므로, 지정된 시간보다 일찍 이벤트가 발생할 수도 있고, 더 늦게 이벤트가 발생할 수도 있습니다. 예를 들면, 1년 정도를 지정해두었더라도 5-6개월만에 이벤트가 발생하는 경우도 종종 있습니다. 혹은 2년 또는 그 이상 걸리는 예도 있고요.
바로 위 예제에, 아래의 mean_time_to_happen 구문을 덧붙이겠습니다. (원본에도 똑같이 있는 것입니다.)
mean_time_to_happen = { months = 400 modifier = { factor = 0.5 trait = lustful } }
시간은 days, months, years 중 무엇을 써도 됩니다. 예제에서는 400달(약 33년~34년 정도)를 걸어뒀네요. 그런데, 바로 밑에 낯익은 게 보이시죠? modifier = { }. 어디서 봤었죠? 네. 5화에서 확률/랜덤 구문에 지정한 확률을 수정하기 위해 사용했던 녀석이죠. 여기서도 같은 요령으로 사용 가능합니다. 400달로 지정했지만, 만약 딸내미가 음탕한(lustful) 트레잇을 가지고 있다면 그 지정한 기간에 0.5 를 곱해주게 되므로 200달, 약 16~17년 정도의 주기로 줄어들게 되네요.
또 하나, 제가 이 항목의 첫 줄에 어느 부분을 강조해 뒀는지 보이시나요? "평균적으로" 라는 부분은 정확히 그 만큼 시간이 흐르면 실행되는 게 아니라는 점을 강조하기 위해 볼드체로 써 놓았고, 그 뒤에는 "마다" 에 강조가 되어 있죠. 앞에 trigger = { } 만을 사용한 경우와 마찬가지로, 이 이벤트는 조건을 충족하는 한 평균적으로 정해진 시간마다 계속 발생합니다. 따라서, 이를 제어하기 위해서는 위와 같이 뭔가 다른 조건을 주는 것이 필요해집니다. (사실 모든 트리거가 다 그래요. 조건을 충족하는 한 횟수에 제한 없이 발생하죠. 그래서 실제 원본 이벤트를 봐도 신나게 캐릭터 플래그 때려박잖아요.)
어찌 생각하면 가장 중요한 옵션인데, 이걸 이제야 설명하게 되네요.
지금 우리는 일정한 조건을 충족하면 이벤트가 자동으로 실행되도록 하는 방법을 보고 있습니다. 그런데, 어떤 이벤트들의 경우에는 그렇게 자동으로 실행되면 안 되는 경우가 있습니다. 예를 들면, 일련의 이벤트 체인으로 연결된 다수의 이벤트들의 경우, 그 이벤트 체인의 트리거가 되는 최초 이벤트는 trigger = { } 및 MTTH 등의 조건을 이용해서 조건을 걸어 둡니다만, 그 뒤의 이벤트는 바로 앞의 이벤트가 실행됨에 따라 단계적으로 실행되어야 하는 이벤트들입니다. 조건에 따라 무작위로 실행되면 안 되는 이벤트들이죠.
예를 들어, A(시작) → B → C → D → E → F(끝) 의 여섯 개의 이벤트가 이벤트 체인으로 이어져 있다고 합시다. 즉, 일정한 조건을 충족하여 A 이벤트가 실행된다면, 순서대로 B, C, D, E, F 의 이벤트가 실행되고 마지막으로 F 이벤트가 실행됨으로써 이 이벤트 체인은 종료됩니다. 이렇게 여러 개의 이벤트가 단계적으로 연결 실행되는 체인 이벤트는 CKII 에 상당히 많습니다.
이 경우, B 이벤트는 A 이벤트가 실행되는 것이 필수 실행 조건입니다. A 가 실행되지도 않았는데 멋대로 B가 실행되어 버리면 곤란하다는 겁니다. 그래서 아예, B는 A(또는 다른 이벤트)가 실행해 주지 않는 한 절대로 실행되지 않도록 못 박아 버리겠다 이거죠. C, D, E, F 역시 마찬가지입니다. 그 결과, A 이벤트 내에는 B 이벤트를 실행시키는 코드가 필수적으로 들어 있어야겠죠. B 이벤트 내에는 C 이벤트를 실행시키는 코드가 들어 있어야 할 거고요. C,D,E 역시 마찬가지. 이제 이해가 되시죠?
바로 이 "이 이벤트는 멋대로 실행하지 마!" 라고 CKII 에 알려주는 옵션이 이 옵션입니다. 이 조건이 붙어 있는 이벤트는 다른 이벤트(디시전 포함)에 의해서 트리거되지 않는 한(실행되지 않는 한) 절대로 실행되지 않습니다. 따라서 사용자의 선택이나 다른 이벤트에 의해서만 실행되어야 하는 이벤트에는 반드시 이 조건이 붙어 있어야 합니다.
예전에 깜빡하고 이 옵션을 빼먹었다가 황당한 일을 당했었습니다. 게임을 시작했는데 막 사방에서 캐릭터들이 자살을 하더라고요? 그러더니 며칠 지나니까 제 캐릭터도 자살했습니다 뜨고는 게임 오버. 뭔가 했더니, 자살 이벤트의 앞에 is_triggered_only = yes 를 붙이는 걸 까먹어서, 모든 캐릭터들에 대해서 이 이벤트가 막 실행된 겁니다. 어쩐지 초반 랙이 장난 아니더라니... ㅋㅋ
character_event = { id = TST.1004 desc = EVTDESC_TST_1004 picture = GFX_evt_feast is_triggered_only = yes .... }
이 옵션은 원본에서도 너무나 흔히 볼 수 있는 옵션입니다. 아마 모드를 작성하실 때도, 이 옵션을 대다수의 이벤트에 붙여야 할 것입니다.
hide_window = yes 를 사용하는 트리거 이벤트를 별도로 설계하는 이유 중 하나입니다. 조건을 트리거 이벤트로 빼 버리고, 그 후속 이벤트들을 모두 이 옵션을 주어서 정의하면 이벤트의 실행과 관련하여 이벤트가 멋대로 잘못 실행되는 문제를 방지할 수 있습니다.
이번에 다룰 내용은 조건의 설정에 있어서 약간 미묘한 위치를 점유하고 있는 섹션에 대한 내용입니다.
제목은 이렇게 달았습니다만, 기본적으로는 바로 위에 적은 mean_time_to_happen = { } 과 유사하게 동작하는 것처럼 보입니다. 태생이 mean_time_to_happen = { } 의 대안으로 나온 녀석이기 때문이죠. 위키의 기술은 "특히 하루와 같이 아주 짧은 기간을 지정하는 mean_time_to_happen = { } 의 대안으로써"(as an alternative to MTTH, especially MTTHs with a very low value such as one day) 등장했다고 합니다. MTTH 보다 엔진이 핸들링하기가 더 쉽다고도 적혀 있습니다.
실제로 돌려 보면, 일단은 MTTH 처럼 동작하기는 합니다. 지정한 시간보다 길거나 짧거나 하는 경향성의 차이를 보이기도 하지만, 기본적으로는 동일하게 돌아갑니다. 예를 들면,
weight_multiplier = { days = 120 modifier = { factor = 0.5 trait = lustful } }
이런 식으로 trigger = { } 와 함께 쓰는 경우, 의도한 대로 돌아는 간다는 겁니다. (다만 MTTH에 비해서 그 편차가 좀 큰 느낌이 들었습니다. 물론 시행 횟수가 많지 않으므로 신뢰성은 없습니다.)
의도한 대로 멀쩡하게 돌아간다는데, 그런데 뭐가 문제냐... 제가 Validator 를 사용하기 시작하면서부터 문제는 시작되었습니다. trigger = { } 와 weight_multiplier = { } 를 함께 사용한 이벤트 코드를, Validator 가 번번히 오류로 판정했기 때문입니다.
오류 메시지: This non-triggered-only event should not have a weight multiplier.
즉, is_triggered_only = yes 를 사용한 경우가 아니라면 weight multiplier 를 사용해서는 안 된다는 겁니다. 뭔가 이상하지 않습니까? is_triggered_only = yes 을 사용하면, 다른 이벤트에 의해 트리거되지 않는 한 이벤트가 실행되지 않기 때문에, 이 이벤트는 trigger = { } 의 조건에도 불구하고 절대로 자동으로 실행되지 않습니다. 자동으로 실행되지 않는데 그 간격을 조정하는 weight_multiplier = { } 이 의미를 가질 리가 없죠. 대체 이게 무슨 뚱딴지같은 소립니까. is_triggered_only = yes 를 쓰면 weight_multiplier = { } 가 무의미해지는데, is_triggered_only = yes 를 써야만 weight_multiplier = { } 을 쓸 수 있다니요.
그럼에도 불구하고, 원본 이벤트를 검색해 보면 is_triggered_only = yes, trigger = { }, weight_multiplier = { } 3종 세트를 함께 사용한 이벤트가 차고 넘칩니다. 몇백 개는 되는 것 같습니다. 원본 파일이 대규모로 오류를 낼 리가 없다고 보면 뭔가 다른 문제가 있다는 이야깁니다.
이상한 걸 하나 더 보여드리죠. 아래 이벤트를 보십시오. 좀 길지만, weight_multiplier = { } 내의 modifier = { } 를 잘 살펴보세요. 참고로, 이 이벤트는 원본의 이벤트로서, "전장에서 용감히 싸우다 죽음을 맞이하였습니다." 이벤트입니다. 용감하게 싸우다가 전사하는 이벤트죠. (battle_events.txt 의 제일 위에 있는 이벤트입니다. 당하면 엄청나게 짜증납니다.)
character_event = { id = 242 desc = EVTDESC242 picture = GFX_evt_death border = GFX_event_normal_frame_war is_triggered_only = yes trigger = { NOT = { trait = berserker } } weight_multiplier = { days = 1 modifier = { factor = 1.5 trait = brave } modifier = { factor = 0.5 trait = craven } modifier = { trait = clubfooted factor = 1.25 } modifier = { trait = hunchback factor = 1.25 } modifier = { trait = lisp factor = 1.1 } modifier = { trait = stutter factor = 1.1 } modifier = { trait = dwarf factor = 1.25 } modifier = { trait = genius factor = 0.9 } modifier = { trait = quick factor = 0.9 } modifier = { trait = slow factor = 2.0 } modifier = { trait = imbecile factor = 3.0 } modifier = { trait = inbred factor = 3.0 } modifier = { trait = strong factor = 0.7 } modifier = { trait = weak factor = 2.5 } modifier = { factor = 1.25 trait = stressed } modifier = { factor = 1.25 trait = depressed } modifier = { factor = 1.5 trait = lunatic } modifier = { factor = 1.5 trait = possessed } modifier = { factor = 1.1 trait = ill } modifier = { factor = 1.25 trait = pneumonic } modifier = { factor = 1.25 trait = syphilitic } modifier = { factor = 2.0 trait = leper } modifier = { factor = 1.15 trait = wounded } modifier = { factor = 1.25 trait = maimed } modifier = { factor = 2.0 trait = infirm } modifier = { factor = 3.0 trait = incapable } modifier = { factor = 1.1 trait = drunkard } modifier = { factor = 1.1 trait = has_tuberculosis } modifier = { factor = 1.1 trait = has_typhoid_fever } modifier = { factor = 1.5 trait = has_typhus } modifier = { factor = 1.5 trait = has_bubonic_plague } modifier = { factor = 1.1 trait = has_measles } modifier = { factor = 1.1 trait = has_small_pox } } ... }
앞에서 본 MTTH에서는 날짜에 그대로 factor 가 곱해지기 때문에, 숫자가 작아질수록 이벤트가 일어나는 주기가 짧아졌습니다. Weight Multiplier modifier = { } 의 factor 도 그대로 곱해지는 수치이기 때문에, 이론적으로는 동일해야 맞습니다. 실제로 위에서 똑같이 써 봤잖아요?
그런데 보십시오. 적 앞으로 용감히 뛰쳐나가서 싸우다가 죽었다는 이벤트인데, brave 가 1.5 이고 craven 이 0.5 입니다. 오히려 용감하면 이벤트가 안 일어나고, 겁쟁이면 이벤트가 더 잘 일어나는 판입니다. 이게 무슨 모순입니까? 상처입거나 불구의 몸으로 전장에 나가면 더 싸우다 죽기 쉬울 것인데도, wounded, maimed 모두 1보다 큰 값입니다. 웃기지 않습니까? 술주정뱅이(drunkard)나 각종 질병들도 전부 다 1보다 큰 값을 갖는 말이 안 되는 상황입니다.
이쯤 되면 역설사가 미쳤거나, 제가 뭔가 잘못 알고 있거나 둘 중 하나라는 게 되네요.
힌트는 위키에 있습니다. "Weight multiplier modifiers, as used by on_action events, increase the chance of an event occurring, rather than increase the amount of time the event takes." 대충 해석해 보면, "on_action 이벤트에 사용되는 Weight Multiplier Modifier는, 이벤트가 발생하는 시간의 합을 늘리는 것이 아니라, 해당 이벤트가 발생할 확률을 높인다."
위의 이벤트를 보시면, 앞에서 이야기했던 is_triggered_only = yes, trigger = { }, weight_multiplier = { } 가 모두 존재합니다. 즉, is_triggered_only = yes 로 인하여 이 이벤트는 스스로는 실행될 턱이 없는 이벤트라는 것입니다. 허나 실제로 이 이벤트는 실행이 되고 있거든요. 저도 한 번 당해본 적이 있고.
비밀은 On-Action Event 에 있습니다. CKII에서 실행되는 이벤트는, 사용자가 실행하는 이벤트도 있고, 앞에서 본 것처럼 trigger = { } 을 이용하여 일정 조건을 만족하면 즉시 실행하는 이벤트도 있습니다. 그 외에, 일정한 사건이 발생했을 때(예-죄수가 감옥에서 풀려났을 때 등)에 실행되는 지정 이벤트들도 있습니다. 이런 지정 이벤트들의 목록을 관리하는 파일이 바로 on_actions.txt 파일입니다. 파일의 위치는 common\on_actions\00_on_actions.txt 입니다.
앞에서 본 242번 이벤트의 경우도, 해당 파일의 on_combat_pulse = { } 내에 랜덤 이벤트로 등록되어 있습니다. 전투 시에 정한 확률에 따라서 발생할 수 있는 이벤트라는 거죠. 잠깐 가져와 볼께요.
on_combat_pulse = { random_events = { 2750 = 0 10 = 242 # Killed 20 = 243 # Wounded 10 = 244 # Maimed 5 = 245 # Serious head injury 50 = 246 # Improves martial education 20 = 247 # Flat improvement to martial skill 20 = 248 # Knowledge boost in capital from battle. 10 = 255 # Marshal: Unnecessary violence 25 = 270 # Gain Brave 25 = 271 # Gain Craven 20 = 272 # Gain Wroth 20 = 273 # Gain Patient 30 = 96500 # Gain Combat Trait 1 15 = 96501 # Gain Combat Trait 2 15 = 96502 # Gain Combat Trait 3 15 = 96503 # Gain Combat Trait 4 50 = TOG.3000 # Becomes Berserker 15 = TOG.3001 # Berserker Maimed 20 = TOG.3002 # Berserker Wounded 15 = TOG.3003 # Berserker Killed 25 = TOG.3004 # Berserker Kills Many } }
앞에 정의된 숫자가 확률 정의입니다. 242 이벤트 앞에는 10 이라는 확률이 기록되어 있네요. 참고로 저 10은 10% 를 의미하는 것이 아닙니다. 마치 random_list = { } 와 random = { } 을 혼합한 방식으로 동작해요. 즉, random_events = { } 내에 정의된 모든 확률의 숫자를 더해서 그 합을 분모로 하여 새로 확률을 계산(이건 random_list = { } 와 같습니다)하되, 저 중에서 몇 개의 이벤트가 일어날지는 알 수 없습니다(이건 random = { } 과 같죠). 따라서, 이 242번 이벤트가 전투 중 일어날 기본 확률은 10/3185 = 약 0.31% 의 독립된 확률이라는 겁니다. Weight Multiplier 의 각 Modifier Factor 값은 이 확률값에 대해서 적용됩니다. 만약 Brave(용감한) 트레잇을 가지고 있다면, 10에 1.5가 곱해져서 15가 되니까, 15/3190 = 약 0.47% 의 확률로 확률이 상승하게 되죠!
물론 이 0.47%라는 확률은 실제는 더 높을 수도, 더 낮을 수도 있습니다. 다른 모든 조건을 빼고 Brave 트레잇 조건만을 가지고 생각한다고 할 때도, 위에 열거된 열 개가 넘는 이벤트 중에서 Brave 와 관련된 모디파이어 조건이 있을 경우에는 분모 값이 또 변경될 것이기 때문이죠. 게다가 대개의 캐릭터는 여러 개의 트레잇을 가지고 있게 마련이고, 그런 모든 트레잇들에 대해서 모디파이어를 적용한 후의 최종적인 분모값과 확률값을 가지고 확률 계산을 해야 하니..
각설하고, 만약 이 기본 확률 0.31%의 확률을 뚫고 이 이벤트가 실행된다면, 이 이벤트는 on_actions.txt 의 설정에 의해서 실행되는 것입니다. On-Action 트리거에 의해 실행되는 것이므로 is_triggered_only = yes 가 있더라도 실행에 문제가 없습니다. 그리고, Weight Multiplier 의 Modifier 수치들은, 바로 위의 위키 설명대로, weight_multiplier = { } 내의 날짜에 곱해지는 수치가 아니라, on_actions.txt 내에 정의된 해당 이벤트의 발생 확률에 곱해지는 수치라는 것입니다. MTTH와 같지 않다는 거죠.
이렇게 On-Action 트리거에 의해 실행되는 경우에는, 다른 이벤트 트리거의 경우와 달리 trigger = { } 내의 조건이나 Pre-Trigger 의 조건들이 모두 유효합니다.
weight_multiplier = { } 구문은 mean_time_to_happen = { } 처럼 사용하더라도 그와 유사하게 동작을 합니다. 그러나, weight_multiplier = { } 의 본연의 임무는 on_actions.txt 와 결합하여 랜덤 이벤트의 발생을 제어하는 것으로 생각됩니다. (On-Action 트리거에 의해 실행되는 이벤트에는 MTTH를 사용할 수 없고, 반드시 Weight Multiplier 를 사용해야 합니다.) 게다가 weight_multiplier 를 mean_time_to_happen 과 동일한 용법으로 사용할 경우 Validator 가 죄다 오류로 잡아냅니다. 그렇다면, On-Action 트리거와 연계된 실행이 아닌 이상, Weight Multiplier 를 사용하는 것은 꺼려질 수밖에 없습니다. 대신 MTTH를 사용하는 것이 마음이 편하죠.
사실 더 찜찜한 것은, on_actions.txt 이벤트와 결부되어 실행되는 경우와, 단순히 trigger = { } 와만 결부되어 실행되는 경우에 modifier factor 의 해석 방법이 달라진다는 부분입니다. 잘못 작성하면 엉터리 이벤트가 나올 수 있어요!. 이런 경우 혼란을 막기 위해서는 어느 한 쪽을 사용하지 않는 게 맞다고 생각해요.
그래서 저도 요즘은 On-Action 트리거와 결부되지 않은, 순수하게 trigger 에 일정한 시간 연기 옵션을 다는 경우 MTTH 를 사용하지, Weight Multiplier 를 사용하지 않습니다. 이 글을 보시는 분들의 선택은 자유입니다. 겉으로 보기에는 같은 용법으로 써도 결과는 나오므로, 문제는 없어 보입니다. 그러나, 최소한 is_triggered_only = yes, trigger = { }, weight_multiplier = { } 가 모두 있는 이벤트는 특수한 이벤트로 On-Action Event 를 통해 실행되는 것이라는 사실은 알고 계셔야 합니다. 그래야 저렇게 되어 있는 원본 이벤트를 그대로 복사해서 수정한 후에, 왜 트리거 조건을 충족했는데도 실행이 안 되냐고 화를 내는 상황을 방지할 수 있기 때문입니다. 저런 종류의 이벤트는 On-Action Event와 결부되지 않는 한, 절대로 트리거 조건 충족했다고 해서 실행 안 됩니다.
바로 앞에서 on_actions.txt 파일에 특정한 이벤트와 결부하여 확률에 따라 이벤트를 실행할 수 있다고 말씀드렸었습니다. 따라서 자신의 모드에서 이런 경우에 어떤 특별한 기능을 부가하고 싶다면 그런 이벤트를 만든 후, 그 이벤트 ID 를 on_actions.txt 의 해당 부분에 등록해 주면 됩니다. 정말 많은 종류의 On-Action 트리거가 존재하므로, 매우 유용하게 쓸 수 있습니다.
그런데, 이 파일에 상당히 재미있는 부분이 있습니다. on_yearly_pulse = { }, on_bi_yearly_pulse = { }, on_five_year_pulse = { } 등, 1년, 2년, 5년마다 랜덤하게 실행할 수 있는 이벤트의 목록 가지고 있습니다. 만약 모드에 특정한 이벤트를 이런 조건으로 실행시키고 싶다면, is_triggered_only = yes, trigger = { }, weight_multiplier = { } 을 모두 사용하여 이벤트를 작성하고 이 이벤트의 ID 를 위의 목록에 등록하면 됩니다.
이 파일 내에서는 이런 조건 이외에도, 2~16세의 미성년자에게만 랜덤하게 실행되는 이벤트(on_yearly_childhood_pulse = {}) 등 여러 가지 조건하에서 랜덤하게 이벤트를 실행할 수 있는 방법을 제공하기 때문에, 이런 조건을 원한다면 이 파일의 수정 내지 새로운 파일의 추가도 고려해 볼 만 합니다. 다만, 기존 파일을 수정할 경우, 원본 파일을 모드 폴더에 복사한 상태로 수정하는 것이 가장 안전합니다. (물론, 1화에서 말씀드린 것처럼, 각각의 섹션 단위로 다른 이름의 파일에서 수정하는 방법도 있기는 합니다만, 이 경우도 최소한 해당 섹션의 내용들은 모두 복사가 된 상태에서 수정에 들어가야 합니다. 상당히 까다로운 부분이어서 그 때도 이해가 안 되면 그냥 넘어가시라고 말씀드렸었죠!)
7) has_landed_title 은 위키에서는 title 또는 BOOL(Yes/No) 을 값으로 받는다고 되어 있습니다만, BOOL 값은 경험상 제대로 동작하지 않는 것 같습니다. 원본에서도 Yes/No 를 받도록 쓰인 예가 없습니다. 따라서 일단 특정 title 값만 받는다고 생각하시는 게 좋겠습니다. Yes/No 형태로 쓰고 싶으시면 (작위가 있는지 없는지를 확인하는 경우) is_landed 조건문을 사용하시면 됩니다.
첫댓글 좋은 정보 감사합니다.
호... 한번씩 열다보면 이해 안가는 부분이 있었는데... 이글을 읽어보니 약간의 이해가 되네요. 깨알같이 조건을다는 구나...
?is_female = yes 는 아시겠죠. 여성에게 '만' 발생합니다. => 이부분을 여성과 남성 같이 발생하게 하려면 어떻게 해야 할까요?
그 조건문을 안 쓰면 됩니다. 원래 모두에게 발생하는 것을 조건을 걸어서 여성에게만 발생시키도록 한 것이니까요.
하루동안 끙끙 앓다가 어렵사리 질문드립니다...
사신의 수확에서 홀딩 추가 이벤트의 확률을 반으로 낮출려고 하는데 도대체 어디서부터 수정해야 할지 감을 못잡겠습니다.
염치 불구하고 조언 부탁드립니다...
RIP.11705 이벤트가 맞나요? (홀딩 슬롯이 1 늘어나는)
확률을 반으로 낮춘다는 이야기는 보통 말해서 MTTH 를 2배 늘린다는 이야기로 환원할 수 있네요.
따라서 mean_time_to_happen = { } 안에 modifier = { factor = 2.0 } 한 줄만 추가하면 되겠습니다.
아 그렇게 간단한 방법이 있을 줄은 몰랐네요.
정말 감사합니다!