replacing Lua files

[indrkl]

Hello, I'm currently trying out Kael's guide to modding and am trying to add a new screen with Lua. Now I've led to believe that when I have Lua files with the original names, then they are automatically replaced? But somewhy this still doesn't work. I could do the menu part when adding DiploCorner.lua to InGameUI content, and the menu displays as expected, but when clicking on it, it still displays the original notification log popup as if it didn't check the Data==999 condition.

Adding NotificationLogPopup.lua to content in any manner also didn't provide any results. Only time it did anything was when adding to InGameUI, then it simply pops it up in the beginning of the game and I can't close it(so I figure thats not the place for it).

Can anyone help me with this issue? How do I make it understand to use my .lua files instead in a proper manner?

 

[indrkl]

Sorry for posting, allready found out that the issue was, that I had to put Import into VFS True for all Lua files. Though it is still a little bit confusing, why I wouldn't need to set to update ModList.xml as in the Actions properties and how all these Actions, Content and VFS relate to each other.

 

[Spatzimaus]

Though it is still a little bit confusing, why I wouldn't need to set to update ModList.xml as in the Actions properties and how all these Actions, Content and VFS relate to each other.

It's really not that complex. There are basically three options.

1> GameData files (most non-UI xml, and all SQL) uses the Actions tab's OnModActivated/UpdateDatabase. VFS should stay False, although it doesn't actually hurt anything to set these to True. While these modify the core game's database, they do NOT replace the core files in their entirety, instead using Updates to modify or Rows to add to the existing content.

2> Executable Lua that you've added for yourself, (i.e. that doesn't replace any existing Lua functions) uses the Content tab to load, with "InGameUIAddin" being by far the most common choice for the first column. VFS needs to stay False for this, or else things might trigger twice.
Again, this should only be done for EXECUTABLE Lua, as in things with Event or GameEvent declarations that the game wants to trigger itself; any utility Lua that's intended to be loaded through an Include statement by other Lua files should NOT be loaded this way. The file can have some non-executable functions, if they're used by others in the same file, but if the file has ANY Event triggers it needs to be loaded this way.

3> EVERYTHING ELSE uses VFS=True. This is very common for UI mods, since it includes anything that replaces an entire file in the core game (but not GameData files), but also comes up for a lot of other things, like modifying resource allocation in AssignStartingPlots. Custom assets, like DDS or MP3 files you want to use in your mod need to have this set as well; at the moment we can't actually create new sound definitions, so adding an MP3 would be pointless, but this is still the basic method you'll use once that's working. And as mentioned above in #2, any "utility" Lua that's not intended to run on its own, but that is loaded by other Lua files, needs VFS set True as well.

Any file that's not loaded through one of these three methods will be completely ignored by the game.

 

[Pazyryk]

2> Executable Lua that you've added for yourself, (i.e. that doesn't replace any existing Lua functions) uses the Content tab to load, with "InGameUIAddin" being by far the most common choice for the first column. VFS needs to stay False for this, or else things might trigger twice.
Again, this should only be done for EXECUTABLE Lua, as in things with Event or GameEvent declarations that the game wants to trigger itself; any utility Lua that's intended to be loaded through an Include statement by other Lua files should NOT be loaded this way. The file can have some non-executable functions, if they're used by others in the same file, but if the file has ANY Event triggers it needs to be loaded this way.

I'm not sure if I'm contradicting you or not, but I have plenty of Event triggers that are in the "included" lua files and not the file added by InGameUIAddin. Maybe that is what you are saying. Just to be clear, I'd break this into 3 categories:

2a. Lua file(s) that you load as InGameUIAddin with VFS=False. Each of these creates a different "state", so my advice is to have only one of these as your "main.lua". In this file, use include statement to load files in 2b.

2b. Lua files loaded by an include statement only from a 2a file above. These have VFS=True. Although loaded differently, as far as I can tell they operate exactly as 2a files and can have Events or do anything else your 2a file does. These are useful for organizing your 5000 lines of code into different logical parts.

2c. Lua files included by any of the above and other Lua (say from UI). VFS=True for these too. This is good for small utilities that you want to access from multiple states. You are creating multiple instances (is that the right word?) of these by including them from different states, but that's useful for a lot of utility functions (but don't expect a local value to hold the same value in these different instances).


Or in any case, that's how I have my code organized. (But I'm only dealing with one mod, albeit 5000+ Lua lines and growing.)

 

[Spatzimaus]

I'm not sure if I'm contradicting you or not, but I have plenty of Event triggers that are in the "included" lua files and not the file added by InGameUIAddin.

Right, you CAN do that; I should have been clearer. What happens there is that an included file is treated, internally, as being pasted directly into the other file(s). If you've got something with an Event or GameEvent declaration, it needs to be in a file loaded through InGameUIAddin... or in a file that's included by one of those, or in a file that's included by a file included by one of those, and so on down the chain. SOMEWHERE upstream of the Event trigger needs to be a file added through InGameUIAddin (with VFS=False). And to include a file, you need its VFS to be true. So basically, it's still going to be one or the other, but never both at the same time.

The danger with using Events inside a file that's going to be included by other files is that if multiple files include it, it can sometimes trigger the event multiple times (since effectively you'll have loaded multiple copies of it). Generally this is something you don't want to have happen, although as long as you verify your inputs it's usually not going to break anything. If you've got full control over your code and you're just trying to break things into more usable chunks, then sure, feel free to go heavy on the includes. Personally, I prefer to go the other direction to reduce my dependence on global data storage.