Tutorial:Submodding - Revision history

Cataph: /* ADVANCED SUBMODDING: DEPENDENCY MANAGER */

2025-03-23T13:57:12Z

ADVANCED SUBMODDING: DEPENDENCY MANAGER

← Older revision		Revision as of 09:57, 23 March 2025
Line 95:		Line 95:
	We enable it by right clicking on the packfile itself in tree view (not on a table, not on anything else, literally the very first line in tree view), Open>Open Dependency Manager. We add a line as if it was a table (ctrl+shift+A) and type EXACTLY the pack name of the mod we want to override (e.g. AK_seahelm.pack).		We enable it by right clicking on the packfile itself in tree view (not on a table, not on anything else, literally the very first line in tree view), Open>Open Dependency Manager. We add a line as if it was a table (ctrl+shift+A) and type EXACTLY the pack name of the mod we want to override (e.g. AK_seahelm.pack).
	DO NOT enable the tickbox aka boolean right now. Leave that thing alone.		DO NOT enable the tickbox aka boolean right now. Leave that thing alone.
			[[File:2025-03-23 145544.jpg\|thumb\|alt=depmanager]]
	If that tickbox is disabled, the stated pack will be referenced by RPFM and after a reload it will put the original mod as a resource in your Dependency Cache (you know, the tab from which you can access all vanilla content too). This will also stop flagging as invalid most of your keys, meaning any red key in your submod IS an issue.		If that tickbox is disabled, the stated pack will be referenced by RPFM and after a reload it will put the original mod as a resource in your Dependency Cache (you know, the tab from which you can access all vanilla content too). This will also stop flagging as invalid most of your keys, meaning any red key in your submod IS an issue.

Cataph: /* ADVANCED SUBMODDING: DEPENDENCY MANAGER */

2025-03-23T13:54:21Z

ADVANCED SUBMODDING: DEPENDENCY MANAGER

← Older revision		Revision as of 09:54, 23 March 2025
Line 93:		Line 93:
	This is a RPFM feature, and we're going to handle as it is after RPFM 4.3.6. ''USE WITH CAUTION'': at its best it might give you a false sense of security, at its worst it's essentially a data coring method.		This is a RPFM feature, and we're going to handle as it is after RPFM 4.3.6. ''USE WITH CAUTION'': at its best it might give you a false sense of security, at its worst it's essentially a data coring method.

	We enable it by right clicking on the packfile itself in tree view (not on a table, not on anything else, literally the very first line in tree view), Open>Open Dependency Manager. We add a line as if it was a table (ctrl+shift+A) and type EXACTLY the pack name of the mod we want to override. ~~As in “AK_seahelm~~.~~pack”~~.		We enable it by right clicking on the packfile itself in tree view (not on a table, not on anything else, literally the very first line in tree view), Open>Open Dependency Manager. We add a line as if it was a table (ctrl+shift+A) and type EXACTLY the pack name of the mod we want to override (e.g. AK_seahelm.pack).
	DO NOT enable the tickbox aka boolean right now. Leave that thing alone.		DO NOT enable the tickbox aka boolean right now. Leave that thing alone.
	If that tickbox is disabled, the stated pack will be referenced by RPFM and after a reload it will put the original mod as a resource in your Dependency Cache (you know, the tab from which you can access all vanilla content too). This will also stop flagging as invalid most of your keys, meaning any red key in your submod IS an issue.		If that tickbox is disabled, the stated pack will be referenced by RPFM and after a reload it will put the original mod as a resource in your Dependency Cache (you know, the tab from which you can access all vanilla content too). This will also stop flagging as invalid most of your keys, meaning any red key in your submod IS an issue.

Cataph: /* ADVANCED SUBMODDING: DEPENDENCY MANAGER */

2025-03-23T13:45:08Z

ADVANCED SUBMODDING: DEPENDENCY MANAGER

← Older revision		Revision as of 09:45, 23 March 2025
Line 91:		Line 91:

	== ADVANCED SUBMODDING: DEPENDENCY MANAGER ==		== ADVANCED SUBMODDING: DEPENDENCY MANAGER ==
	This is a RPFM feature. ''USE WITH CAUTION'', as it's essentially a data coring method.		This is a RPFM feature, and we're going to handle as it is after RPFM 4.3.6. ''USE WITH CAUTION'': at its best it might give you a false sense of security, at its worst it's essentially a data coring method.

	We enable it by right clicking on the packfile itself in tree view (not on a table, not on anything else, literally the very first line in tree view), Open>Open Dependency Manager. We add a line as if it was a table (ctrl+shift+A) and type EXACTLY the pack name of the mod we want to override. As in “AK_seahelm.pack”. ~~From this point onwards~~, ~~everything we do in~~ the ~~submod under identical paths~~ will ~~completely override content from~~ the ~~parent~~ mod ~~no matter~~ the ~~load or table order for stuff with the same name. Example, I~~ can ~~import a table, not change its name and completely delete its~~ content. This ~~would normally crash~~, ~~but not with DepManager~~.		We enable it by right clicking on the packfile itself in tree view (not on a table, not on anything else, literally the very first line in tree view), Open>Open Dependency Manager. We add a line as if it was a table (ctrl+shift+A) and type EXACTLY the pack name of the mod we want to override. As in “AK_seahelm.pack”.
			DO NOT enable the tickbox aka boolean right now. Leave that thing alone.
			If that tickbox is disabled, the stated pack will be referenced by RPFM and after a reload it will put the original mod as a resource in your Dependency Cache (you know, the tab from which you can access all vanilla content too). This will also stop flagging as invalid most of your keys, meaning any red key in your submod IS an issue.

	~~I said use this with caution because if~~ you ~~do this~~ you ~~REALLY~~ need to ~~stay up-to-date with the og mod. For example, you can remove the line that gives unit A the Regen passive,~~ and ~~it will work. However, any further~~ update ~~from~~ the ~~parent~~ mod in that table won’t take place unless you also mirror it. Again, this is normally not remotely required and you should steer clear of it because it’s just as bad as leaving a vanilla table called “data__”.		''If you've already been using dep manager before RPFM introduced that tickbox you need to disable it and push an update for the mod on Steam.''

	~~Additionally,~~ '''~~this will auto-enable~~ the ~~linked mod~~''' ~~as soon as it’s in data/ as if it was a movie pack. As such~~, ~~you don’t want to~~ do ~~this unless you’re doing a~~ submod ~~that already requires that linked~~ mod. ~~Because having stuff popping up even when you’ve disabled~~ a ~~mod is the worst~~.		Why? '''What happens if I tick the box?'''
			If you do tick the box, everything we do in the submod under identical paths will completely override content from the parent mod no matter the load or table order for stuff with the same name. Example, I can import a table, not change its name and completely delete its content. This would normally crash, but not with DepManager fully on.

	~~'''PSA''': If your~~ mod ~~makes use of~~ the ~~dependency manager PLEASE STATE THAT IT DOES AND ON WHICH OTHER MOD~~ in ~~your Steam description~~. ~~There~~ is ~~no telling how much time~~ you ~~could waste for other people finding the reason~~ of a ~~mod list problem~~.		I said use this with caution because if you do this you REALLY need to stay up-to-date with the og mod. For example, you can remove the line that gives unit A the Regen passive, and it will work. However, any further update from the parent mod in that table won’t take place unless you also mirror it. Again, this is normally not remotely required and you should steer clear of it because it’s just as bad as leaving a vanilla table called “data__”.

			Additionally, '''this will auto-enable the linked mod''' as soon as it’s in data/ as if it was a movie pack, meaning it will also cause issues with actual load order. As such, you don’t want to do this unless you’re doing a submod that already requires that linked mod, and even then '''only if you are POSITIVELY 100% SURE you need to data core stuff'''. Because having stuff popping up even when you’ve disabled a mod is the worst.

	'''~~''PS~~ PSA''': ~~with RPFM 4.3.6, you can disable~~ the ~~potentially~~-~~messy behaviour of dependency managers regarding load order. You will now see a toggle: if it's disabled, the stated pack will only be referenced by RPFM (for~~ your ~~errors and missing keys and stuff) and nothing else will happen for the game, as in it will not be auto-enabled when loading the game either~~. ~~You need to go and change it if~~ you~~'ve already been using dep manager before this RPFM and push an update~~ for the mod ~~on Steam~~.		'''PSA''': If your mod makes use of the fully-charged depmanager PLEASE STATE THAT IT DOES AND ON WHICH OTHER MOD in your Steam description. There is no telling how much time you could waste for other people finding the reason of a mod list problem.
	''

	== ADVANCED SUBMODDING: BACKGROUND TABLES ==		== ADVANCED SUBMODDING: BACKGROUND TABLES ==

Cataph: /* Originally written by Cataph */

2025-03-23T13:36:21Z

Originally written by Cataph

← Older revision		Revision as of 09:36, 23 March 2025
Line 1:		Line 1:
	=== ~~Originally written~~ by Cataph ===		=== Written by Cataph ===
	If you’re a modder, one of the most frequent comments next to romantical proposals (YMMV) will be “SFO/Radious/CTT/Lucky/yomama compatibility when”. Many modders don’t have an interest in making a submod simply because they don’t know and play a given overhaul and wouldn’t know how to balance it anyway.		If you’re a modder, one of the most frequent comments next to romantical proposals (YMMV) will be “SFO/Radious/CTT/Lucky/yomama compatibility when”. Many modders don’t have an interest in making a submod simply because they don’t know and play a given overhaul and wouldn’t know how to balance it anyway.

Cataph: /* ADDENDUM: UPDATING */

2025-03-23T13:36:00Z

ADDENDUM: UPDATING

← Older revision		Revision as of 09:36, 23 March 2025
Line 56:		Line 56:

	Sometimes the parent mod changes a few keys and then you might even crash until you update.		Sometimes the parent mod changes a few keys and then you might even crash until you update.

			This is one of the reasons why we touch only the strict necessary, and let the original mod handle the rest: that's less stuff that is going to need to be updated at any given moment.

	== SUBMODDING EXAMPLE: TRANSLATION ==		== SUBMODDING EXAMPLE: TRANSLATION ==

Cataph: /* PRIORITY */

2025-03-23T13:34:23Z

PRIORITY

← Older revision		Revision as of 09:34, 23 March 2025
Line 39:		Line 39:
	We currently have two tables, we select those table fragments (in this case, called “AK_seahelm”) and we rename them to take priority according to this alphanumerical order:<blockquote>! # $ % & ‘ ( ) + , – ; = @ 0-9 a-z [ ] ^ _ ` { } ~ Where “!” wins over “a”.</blockquote>Usually, adding a “!” in front does it. But we also want to make clear what submod this is for. Right click> Rename> type ''!{x}_unitsize'', which will become “!AK_seahelm_unitsize”.		We currently have two tables, we select those table fragments (in this case, called “AK_seahelm”) and we rename them to take priority according to this alphanumerical order:<blockquote>! # $ % & ‘ ( ) + , – ; = @ 0-9 a-z [ ] ^ _ ` { } ~ Where “!” wins over “a”.</blockquote>Usually, adding a “!” in front does it. But we also want to make clear what submod this is for. Right click> Rename> type ''!{x}_unitsize'', which will become “!AK_seahelm_unitsize”.

	''Note: DO NOT leave the table names as is, or you’ll crash. DO NOT leave a number as last character or it might glitch and crash anyway.''		'''''Note: DO NOT leave the table names as is, or you’ll crash'''. DO NOT leave a number as last character or it might glitch and crash anyway.''

	Aaaand, done! Now this submod of only two tables will correctly override unit sizes for a specific mod. Yeah, any non-vanilla key will be red in here, since you don’t define those in your pack, but no worries, it’s a submod that is designed to exist with the mod that actually has those keys.		Aaaand, done! Now this submod of only two tables will correctly override unit sizes for a specific mod. Yeah, any non-vanilla key will be red in here, since you don’t define those in your pack, but no worries, it’s a submod that is designed to exist with the mod that actually has those keys. If you don't like that and need more clarity to work on more complicated cases, read on for the Dependency Manager tool.

	In the possible case you need at some point to override parts that don't answer to table priority, like images or variants or whole script files, you might want to name the entire pack with a prefix that wins priority over the original mod. For example, again, “!AK_seahelm_unitsize”. Considering you don't want users to manually change load order, this makes sure that by alphanumerical order you're already overriding the og mod. Notice that you can't change a pack's name after you've uploaded it to the workshop.		In the possible case you need at some point to override parts that don't answer to table priority, like images or variants or whole script files, you might want to name the entire pack with a prefix that wins priority over the original mod. For example, again, “!AK_seahelm_unitsize”. Considering you don't want users to manually change load order, this makes sure that by alphanumerical order you're already overriding the og mod. Notice that you can't change a pack's name after you've uploaded it to the workshop.

Cataph: /* PRIORITY */

2025-03-23T13:33:00Z

PRIORITY

← Older revision		Revision as of 09:33, 23 March 2025
Line 35:		Line 35:

	== PRIORITY ==		== PRIORITY ==
	But it’s a submod, and we want to make sure we’re overriding the original mod’s values. No, not with load order on the mod manager, [[Troubleshooting\|and incidentally you shouldn't touch that and I do recommend you use community-made mod managers]].		But it’s a submod, and we want to make sure we’re overriding the original mod’s values. No, not with load order on the mod manager, [[Troubleshooting\|and incidentally you shouldn't touch that and I do recommend you use community-made mod managers, as they give you more utilities and clarity]].

	We currently have two tables, we select those table fragments (in this case, called “AK_seahelm”) and we rename them to take priority according to this alphanumerical order:<blockquote>! # $ % & ‘ ( ) + , – ; = @ 0-9 a-z [ ] ^ _ ` { } ~ Where “!” wins over “a”.</blockquote>Usually, adding a “!” in front does it. But we also want to make clear what submod this is for. Right click> Rename> type ''!{x}_unitsize'', which will become “!AK_seahelm_unitsize”.		We currently have two tables, we select those table fragments (in this case, called “AK_seahelm”) and we rename them to take priority according to this alphanumerical order:<blockquote>! # $ % & ‘ ( ) + , – ; = @ 0-9 a-z [ ] ^ _ ` { } ~ Where “!” wins over “a”.</blockquote>Usually, adding a “!” in front does it. But we also want to make clear what submod this is for. Right click> Rename> type ''!{x}_unitsize'', which will become “!AK_seahelm_unitsize”.

Cataph: /* WHAT DO? */

2025-03-23T13:32:00Z

WHAT DO?

← Older revision		Revision as of 09:32, 23 March 2025
Line 31:		Line 31:

	Thus, in the submod I’ll import said table/s by right click>Add…>Add from Packfile, find the pack, find the table and double click it. Close the add from packfile panel and we’re good to go, we have Sea Patrol’s main_units in our shizzle. We go in there and edit the numbers we want to change, in this case we select any num_men that is not a hero/lord’s, right click, apply math as ''{x}*2'' and done. Done? No, some of those units may be cavalry, so we need to adapt the number of mounts too. We import land_units as well and do the same thing on num_mounts. In the rarer case that there’s a multi-chariot unit, we leave mounts alone and multiply num_engines in land_units.		Thus, in the submod I’ll import said table/s by right click>Add…>Add from Packfile, find the pack, find the table and double click it. Close the add from packfile panel and we’re good to go, we have Sea Patrol’s main_units in our shizzle. We go in there and edit the numbers we want to change, in this case we select any num_men that is not a hero/lord’s, right click, apply math as ''{x}*2'' and done. Done? No, some of those units may be cavalry, so we need to adapt the number of mounts too. We import land_units as well and do the same thing on num_mounts. In the rarer case that there’s a multi-chariot unit, we leave mounts alone and multiply num_engines in land_units.

			Also, if all we're doing is increasing unit sizes, we have no interest in single-entity units and characters. In all the tables we touched, we should select the whole lines for those units we're not poking and delete those. This will leave them untouched by us (since, again, we don't need to), and the values used in the original mod will keep working. '''This is important: don't touch any more than you need to. Less work for you, less trouble for both you and the original modder.'''

	== PRIORITY ==		== PRIORITY ==

Cataph: /* PRIORITY */

2025-03-23T13:29:04Z

PRIORITY

← Older revision		Revision as of 09:29, 23 March 2025
Line 33:		Line 33:

	== PRIORITY ==		== PRIORITY ==
	But it’s a submod, and we want to make sure we’re overriding the original mod’s values. No, not with load order on the mod manager, [[Troubleshooting\|and incidentally you shouldn't touch that and you ~~should~~ use ~~KMM~~]].		But it’s a submod, and we want to make sure we’re overriding the original mod’s values. No, not with load order on the mod manager, [[Troubleshooting\|and incidentally you shouldn't touch that and I do recommend you use community-made mod managers]].

	We currently have two tables, we select those table fragments (in this case, called “AK_seahelm”) and we rename them to take priority according to this alphanumerical order:<blockquote>! # $ % & ‘ ( ) + , – ; = @ 0-9 a-z [ ] ^ _ ` { } ~ Where “!” wins over “a”.</blockquote>Usually, adding a “!” in front does it. But we also want to make clear what submod this is for. Right click> Rename> type ''!{x}_unitsize'', which will become “!AK_seahelm_unitsize”.		We currently have two tables, we select those table fragments (in this case, called “AK_seahelm”) and we rename them to take priority according to this alphanumerical order:<blockquote>! # $ % & ‘ ( ) + , – ; = @ 0-9 a-z [ ] ^ _ ` { } ~ Where “!” wins over “a”.</blockquote>Usually, adding a “!” in front does it. But we also want to make clear what submod this is for. Right click> Rename> type ''!{x}_unitsize'', which will become “!AK_seahelm_unitsize”.

Cataph: /* ADVANCED SUBMODDING: DEPENDENCY MANAGER */

2024-09-25T12:08:57Z

ADVANCED SUBMODDING: DEPENDENCY MANAGER

← Older revision		Revision as of 08:08, 25 September 2024
Line 98:		Line 98:


	'''PS PSA''': with RPFM 4.3.6, you can disable the potentially-messy behaviour of dependency managers regarding load order. You will now see a toggle: if it's disabled, the stated pack will only be referenced by RPFM (for your errors and missing keys and stuff) and nothing else will happen for the game, as in it will not be auto-enabled when loading the game either. You need to go and change it if you've already been using dep manager before this RPFM and push an update for the mod on Steam.		'''''PS PSA''': with RPFM 4.3.6, you can disable the potentially-messy behaviour of dependency managers regarding load order. You will now see a toggle: if it's disabled, the stated pack will only be referenced by RPFM (for your errors and missing keys and stuff) and nothing else will happen for the game, as in it will not be auto-enabled when loading the game either. You need to go and change it if you've already been using dep manager before this RPFM and push an update for the mod on Steam.
			''

	== ADVANCED SUBMODDING: BACKGROUND TABLES ==		== ADVANCED SUBMODDING: BACKGROUND TABLES ==