Pasquale1223 Posted September 9, 2023 Share Posted September 9, 2023 It is true that _h files are "header" or "include" files and are not compiled to become executables by themselves.- however - They are source code. They are sourced into other files when they are compiled and when they are changed the other files that include them and *do* compile into executables need to be re-compiled for the changes to take effect. If they need to be re-compiled, how does editing and saving headers via toolset causes the changes that are made in headers appear in the game? Does the toolset re-compile every script together when you make a change in the headers? Not automatically. As I explained elsewhere, you can see a file's dependencies by right-clicking on the filename and selecting properties, then choose the "References" tab (other files included by this file) or "Referenced By" tab (other files that include this file). Link to comment Share on other sites More sharing options...
Guest deleted187826421 Posted September 9, 2023 Share Posted September 9, 2023 (edited) It is true that _h files are "header" or "include" files and are not compiled to become executables by themselves.- however - They are source code. They are sourced into other files when they are compiled and when they are changed the other files that include them and *do* compile into executables need to be re-compiled for the changes to take effect. If they need to be re-compiled, how does editing and saving headers via toolset causes the changes that are made in headers appear in the game? Does the toolset re-compile every script together when you make a change in the headers? Not automatically. As I explained elsewhere, you can see a file's dependencies by right-clicking on the filename and selecting properties, then choose the "References" tab (other files included by this file) or "Referenced By" tab (other files that include this file). I understand that. The part I don't understand; if making a change in the header file does only work when the other files that include them and "do" compile into executables need to be re-compiled, How does making a change "only" in the header file via the toolset makes it so that changes are apparent in the game? Edited September 9, 2023 by Vesper94 Link to comment Share on other sites More sharing options...
Guest deleted187826421 Posted September 9, 2023 Share Posted September 9, 2023 a) It should be recognized in that location. I personally place all my edited ncs/nss files in that override folder.b) MyModuleName_en-us.tlk/MyModuleName_c_en.tlkc) Module talk tables are just split into 2 one MyModuleName_c_en-us.tlk the other MyModuleName_en-us.tlk. It just seems to be how they get exported. It seems that each talk table type handles different types of strings. I believe because the vanilla game has some strings set as core and other as single player, example vanilla tends to have GUI, item names and descriptions, sound sets, etc are under core (Core) and dialogue, creature name, creature descriptions, etc. under Single Player (Module). I just don't think it makes sense when making custom talktables because it is less strings/info. But I would keep both in case deleting one breaks your talktables.Thanks again, I'll try this and see if it works. Link to comment Share on other sites More sharing options...
HollownessDevoured Posted September 9, 2023 Share Posted September 9, 2023 (edited) Thanks again, I'll try this and see if it works. Good luck, I know how frustrating it can be trying to get a scripts and mods to work, but when it does (and exactly how you want), it is a great feeling! Edit: I realized I forgot to reiterate, module talktable files stay in their respective addin folders. I have mentioned this before, but I forgot to confirm when you asked. Edit edit: Here is a talk table example, sometimes I find it helpful to just see so it has the export, the file locations and the string working in game... Edited September 9, 2023 by HollownessDevoured Link to comment Share on other sites More sharing options...
Pasquale1223 Posted September 9, 2023 Share Posted September 9, 2023 I am starting to get more comfortable with scripts, but I am still very much self taught. If you are adding a custom scripts you need to use with PRCSCR.That depends on the script and what it is designed to do. PRCSCR scripts are primarily intended to alter areas when they are loaded. True but you can use "any", it depends on the script and what you are trying to achieve. I am just trying to think of alternate ways to use a script for the OP. Edit: example Dain's plus heal fix... the fixbaseheal.ncs file void main() { object[] arParty = GetPartyPoolList(); int i; for (i = 0; i < GetArraySize(arParty); i++) SetCreatureProperty(arParty[i], 51, 100.0, PROPERTY_VALUE_BASE); } the prcscr_plusheal.gda file line 892314240 any fixbaseheal Dain apparently wanted to set that value for every member of the party while entering every area. It's a fair amount of overhead to run that script every time the game loads an area, but it's what Dain decided best suited the situation. Note: an alternative method would be to use a traditional module event handler and act on EVENT_TYPE_GAMEMODE_CHANGE, check the previous game mode for GM_LOADING, and if those conditions are met, go ahead and run that logic. That would also run the logic every time the party enters a new area, just as the PRCSCR does. Other alternatives (using a traditional module event handler) could include processing EVENT_TYPE_CHARGEN_END (coming out of the level-up GUI might be a good time to adjust those character properties) or EVENT_TYPE_PARTY_MEMBER_HIRED (a party member has been selected via the partypicker and added to the current party) or EVENT_TYPE_PARTYPICKER_CLOSED (the party is complete, you can process the entire party now). I'm not sure why Dain chose that implementation; perhaps it was because there are a number of event handlers with the other features offered in the mod. There's usually more than one way to do a thing; some are more efficient than others. Link to comment Share on other sites More sharing options...
HollownessDevoured Posted September 9, 2023 Share Posted September 9, 2023 Dain apparently wanted to set that value for every member of the party while entering every area. It's a fair amount of overhead to run that script every time the game loads an area, but it's what Dain decided best suited the situation. Note: an alternative method would be to use a traditional module event handler and act on EVENT_TYPE_GAMEMODE_CHANGE, check the previous game mode for GM_LOADING, and if those conditions are met, go ahead and run that logic. That would also run the logic every time the party enters a new area, just as the PRCSCR does. Other alternatives (using a traditional module event handler) could include processing EVENT_TYPE_CHARGEN_END (coming out of the level-up GUI might be a good time to adjust those character properties) or EVENT_TYPE_PARTY_MEMBER_HIRED (a party member has been selected via the partypicker and added to the current party) or EVENT_TYPE_PARTYPICKER_CLOSED (the party is complete, you can process the entire party now). I'm not sure why Dain chose that implementation; perhaps it was because there are a number of event handlers with the other features offered in the mod. There's usually more than one way to do a thing; some are more efficient than others. The OP talking about alternatives, I thought I throw it out there. It may not even be considered. Link to comment Share on other sites More sharing options...
Guest deleted187826421 Posted September 9, 2023 Share Posted September 9, 2023 (edited) Thanks again, I'll try this and see if it works. Good luck, I know how frustrating it can be trying to get a scripts and mods to work, but when it does (and exactly how you want), it is a great feeling! Edit: I realized I forgot to reiterate, module talktable files stay in their respective addin folders. I have mentioned this before, but I forgot to confirm when you asked.Okay so here's what I did: Image#5 Any ideas on what I did wrong, or how I can do something different and better? However if I insert the new strings into the core talk table and export and put "core_en-us.tlk into the packages/core/override folder and edit the headers via toolset it works: Image#6 Edited September 9, 2023 by Vesper94 Link to comment Share on other sites More sharing options...
HollownessDevoured Posted September 9, 2023 Share Posted September 9, 2023 (edited) That is odd, maybe weapon statdefines have to be in the core talk table. Because you look like you did everything correctly. Nope, I just tested by replacing the Strength modifier string with one of my module strings: Edited September 9, 2023 by HollownessDevoured Link to comment Share on other sites More sharing options...
HollownessDevoured Posted September 9, 2023 Share Posted September 9, 2023 (edited) Wait, where is your imfvll_c_en-us.tlk file? You look like you have 2 imfvll_en-us.tlk files instead. edit: what does your string edit look like? do you have a mismatch for table and owner? Edited September 9, 2023 by HollownessDevoured Link to comment Share on other sites More sharing options...
Guest deleted187826421 Posted September 9, 2023 Share Posted September 9, 2023 Wait, where is your imfvll_c_en-us.tlk file? You look like you have 2 imfvll_en-us.tlk files instead. edit: what does your string edit look like? do you have a mismatch for table and owner? I made a mistake in the previous post. I fixed it now, it should look like this right? Image#7 This didn't work either. Link to comment Share on other sites More sharing options...
Recommended Posts