# Common Common is, well, the most common file you'll be working in in CK3. Common also has the most varied files, and is where the majority of things in CK3 are defined, outside of events, history, and localization. To get to this folder, click browse local files for CK3 and then open the game folder. Common is inside that. Because of how each subfolder defines something different in the game, they all have their own syntax and not all of them actually use script. Most of its subfolders I will not cover, as they either don't fall under this guide or will never be touched by you. That said, most common subsfolders have a .info file that will explain how to make stuff in them. It contains: - achievements - activities - ai_goaltypes - ai_war_stances - bookmark_portraits - bookmarks - buildings - casus_belli_groups - casus_belli_types - character_backgrounds - character_interaction_categories - character_interactions - coat_of_arms - combat_effects - console_groups - council_positions - council_tasks - courtier_guest_management - culture - customizable_localization - deathreasons - decisions - defines - dna_data - dynasties - dynasty_house_motto_inserts - dynasty_house_mottos - dynasty_houses - dynasty_legacies - dynasty_perks - effect_localization - ethnicities - event_backgrounds - event_themes - factions - flavorization - focuses - game_concepts - game_rules - genes - governments - holdings - hook_types - important_actions - landed_titles - laws - lease_contracts - lifestyle_perks - lifestyles - men_at_arms_types - messages - modifier_icons - modifiers - named_colors - nicknames - on_action - opinion_modifiers - playable_difficulty_infos - pool_character_selectors - province_terrain - religion - schemes - script_values - scripted_character_templates - scripted_effects - scripted_guis - scripted_lists - scripted_modifiers - scripted_relations - scripted_rules - scripted_triggers - secret_types - story_cycles - succession_election - suggestions - terrain_types - traits - trigger_localization - tutorial_lesson_chains - tutorial_lessons - vassal_contracts Of these folders, you will only ever touch maybe 5-6 on a regular basis. Maybe closer to 10 if you are making a total conversion mod. ## ![](./scripting_2_common_media/image26.png){width="4.021527777777778in" height="5.604166666666667in"}Decisions This subfolder of common has a fairly simple job. Want to guess what it is? If your guess was decisions, you're correct. If it wasn't, I'm questioning your ability to read. Here, we have an example of a basic decision. Please note that the picture file I added there doesn't exist, but the decision images **are** all in that folder. Ok, so: we have the decision key, test_this_decision, which is the key used when you call that decision and the loc key for the decision's name. We also have a desc, which is the description for the loc. There is also a test_this_decision_confirm and test_this_decision_tooltip, but those are defined by the decision key and not the code. Major = yes is not a necessary line, but if you add it the decision becomes a major one (think found a new kingdom) Ai_potential essentially just tests to see if the ai can use the decision. Copy over your code from is_shown and is_valid. Ai_check_interval asks how often the game checks the decision. Ai_check_interval = 5 means the ai will check every 5 months. If it's set as 0, they will never check. Ai_will_do just sees if the ai will use the decision. Here, if the ai character is brave, they have a 50% chance to use the decision. Otherwise, they won't at all. Is_shown checks if the decision even shows up for you, while is_valid test if you can do it. Here, the decision shows if you are brave, but you can't use it unless you are also feudal. Neither of these blocks is necessary, and if removed the default for it is just always true. Cost can cost prestige, piety, and/or gold. You don't need all three in it, I just added it for an example. This block is also unnecessary, and can be removed if you want the decision to be free. Effect = {} should be self-explanatory. Anything you add to it is what happens to you when you use the decision. Hidden_effect = {} is not unique to decisions, btw, and can be added anywhere if you don't want the effects to show up if the effects are being shown to the character. ## ![](./scripting_2_common_media/image27.png){width="3.865122484689414in" height="7.740663823272091in"}Character_interactions Character interactions are also a fairly self-explanatory name. Once again, you have the interaction key, here test_interaction, the desc line, an ai_will_do, is_shown, ai_frequency, and ai_potential. Here, we also have ai_accept, which determines the ai accept chance (out of 100.) If you want it to always be accepted, replace ai_accept = {} with auto_accept = yes. Can_send is the same thing as is_valid from decisions and on_accept is the same as effect = {}. We can also add an on_decline = {} block. Note that we need to couch all triggers in either scope:actor (the person using the interaction) or scope:recipient (the person targeted.) Interface priority determined how high up in the list it will show in the interactions menu. Finally, common interaction should generally just be yes. A non-common interaction shoots up to the top of the interface. While what I showed here is the most basic interaction ever, there are multiple other tags you can add to the interaction, some of which I will list below and are explained in the character interactions .info file. - is_highlighted = trigger - Should the interaction be highlighted in the menu - highlighted_reason = loc_key - Tooltip if highlighted in menu - scheme = elope/murder/etc. - The type of scheme the interaction starts - popup_on_receive = yes - Have the interaction pop-up for the recipient when received - pause_on_receive = yes/no - Pause the game on receive. It usually makes sense to combine it with popup_on_receive - use_diplomatic_range = yes/no/trigger - Does this interaction check diplomatic range? Yes by default - can_send_despite_rejection = yes -- Ever if the AI's chance of accepting this is 0, it can still be sent. It equals no by default - ignores_pending_interaction_block = yes -- Lets you ignore the "ai is already considering a proposal from you." Defaults to no - ai_maybe = yes - The ai can reply maybe. Not sure why'd you use this - ai_min_reply_days = 4 - Minimum days before ai replies. Useful if you want to control this. - ai_max_reply_days = 9 - Maximum days before ai replies - greeting = negative/positive - Sets tone in request text (what's sent to the recipient) - notification_text = loc_key - Request text (what's sent to the recipient) - cooldown = { years = x } - How long until the decision can be taken again? - cooldown_against_recipient = { years = x } - How long until the decision can be taken against that specific person again? ## Scripted_effects, Scripted_triggers, Scripted_modifiers, and Scripted_lists These 4 folders are very useful for simplifying your code. What they are is essentially templates for your code. Maybe you're repeating your code often and want to simplify it. So, you make a scripted (whatever your code is) and then can call on that in your code. ![](./scripting_2_common_media/image28.png){width="3.0420909886264216in" height="3.6463418635170606in"}![](./scripting_2_common_media/image29.png){width="2.0836242344706912in" height="1.0313943569553805in"}With this scripted effect, I can add the line "basic_scripted_effect = {}" or "basic_scripted_effect = yes" to any effects area, the scopes character will gain 100 gold, 50 piety, and 10 prestige in only one line of code. Scripted triggers are exactly the same, except that they're for triggers. Scripted effects and triggers are what I used above such as add_gold_to_person for examples Scripted modifiers are like scripted effects but for weighting things. If you have a weight = {} or ai_chance = {} or anything like that, you can add basic_scripted_modifier = yes and all of the modifiers contained within will be applied (assuming the scope meets the conditions.) Once again, scripted modifiers are useful for preventing unnecessary duplication of linger lines of code. ![](./scripting_2_common_media/image30.png){width="4.469373359580053in" height="0.8542858705161854in"}Scripted lists are a unique one here. You know every_ruler, random_ruler, any_ruler and the stuff like those? Well, if you ignore the prefixes, you have a list called ruler. Scripted lists mean we can create our own lists, using another as a base and then applying a number of triggers, like the government type. You can consider the conditions = {} block the same thing as a limit = {} block. With this scripted list, I can now call on every_feudal_ruler, random_feudal_ruler, and any_feudal_ruler. Alright, on to other folders ## ![](./scripting_2_common_media/image31.png){width="3.9484678477690287in" height="4.573555336832896in"}Script_values Script values have one use: dynamic values. You can add, subtract, divide, set a min and max for the values, make it round decimals into integers or leave them as is. You can add other dynamic values to it as well, such as other script values. Whenever you see an "add = sometext," it's adding a script value. You won't really need script values for basic code, but later on, when you are making more advanced code/mechanics, script values are extremely useful. Script values don't really do anything on their own, but rather their use is tied to when they are called. Please note that these CANNOT be used in traits and affecting modifiers. ## On_action Alright, this will be the last common/ subfolder I will cover in this guide. On actions are a very useful tool in CK3, as the vanilla ones trigger at specific events for characters. What does this mean? I'll show you ![](./scripting_2_common_media/image32.png){width="2.8337292213473315in" height="1.3856102362204725in"}Specific on actions, which I'll call root on actions, are triggered by the game at specific times. These often link to other on_actions, or branch on actions, which you can see here. On_birthday triggers for a character whenever it's their birthday (as I'm sure you guessed.) We can't create root on actions, but we can create branch ones. ![](./scripting_2_common_media/image33.png){width="2.135715223097113in" height="2.8441469816272966in"}In an on action, we can have 4 blocks: trigger, effect, events, and on_actions. If a trigger is false, none of the on actions triggers for the scoped character. Effect should be self-explanatory, you add effects to it. In the events and on_actions blocks, you can add different events and on actions you want the on actions to run. You can list as many as you want, without needing to add more than a line break. ![](./scripting_2_common_media/image34.png){width="1.6564807524059493in" height="0.7813593613298337in"}Now a major thing you should know **if** you are editing an on action. If you want to edit what it does, the file that it is located in ***MUST*** be named the same as the on action is originally from. If you are editing an on action in a separate file, all you can do is add on_actions for it to branch off into. It's kinda annoying.