How to remove the warnings from your WB compiler [V1.132] UPDATED!

Users who are viewing this thread

Everybody probably knows what I am talking about here (I hope). Those 'unassigned variables' you get every time when you compile your mod for Warband.

Like this;

13173649.jpg

I know this is standard in latest versions of Warband, but still, the point of not showing up would make it more easier for you track down faults in the compiler. I tested this and Warband keeps functioning normally in both SP and MP.

cmsz.png



To apply to an existing Module System;


1.

Add this script at the end of your own module_scripts file.

Code:
#OC begin

    ## Fix MS errors, credits  to Sinisterius for making this code ##
   ("cf_rpw_fix_native_errors",
   [
       (eq, "$tutorial_1_finished", 0),
       (eq, "$tutorial_2_finished", 0),
       (eq, "$tutorial_3_finished", 0),
       (eq, "$tutorial_4_finished", 0),
       (eq, "$tutorial_5_finished", 0),
      (eq, "$g_election_date", 0),
      (eq, "$g_presentation_lines_to_display_begin", 0),
      (eq, "$g_presentation_lines_to_display_end", 0),
      (assign, "$g_presentation_marshall_selection_max_renown_3", 0),
      (assign, "$g_presentation_marshall_selection_max_renown_3_troop", 0),
      (eq, "$g_presentation_marshall_selection_max_renown_3", 1),
      (eq, "$g_presentation_marshall_selection_max_renown_3_troop", 1),
   ]),

#OC end

Compile it, and copy the variables.txt from your module folder into your MS folder.

And then you should get this,

cmsz.png

Credits for Sinisterius for posting this code here.

Hope this helps you.
 
Purely cosmetic, but it clogs up the compiler, making it more confusing when trying to track down your own errors.

Thanks Jezze!
 
Caba`drin said:
Is this just cosmetic, or does it speed up compiling at all?

From my own experience, its just cosmetic. I did not see any faster compiling with the variables still in the MS.

COGlory said:
Purely cosmetic, but it clogs up the compiler, making it more confusing when trying to track down your own errors.

Thanks Jezze!

Thanks :wink:. I saw a post once long time ago about this, so maybe it was good to make a topic about it, since I do not know how long these variables will stay in the MS.
 
Thanks this is a great post. I would like to suggest, however, taking the native module system, making these changes, and releasing it as a fixed module system. The changes are easy, but doing something like this might goad the programmers into releasing a fixed version themselves, with the next release. :wink:
 
Those tutorials and marshal election menus/presentations are deprecated - see line 817 of simple_triggers. You can safely comment out the entire thing (mnu_marshall_selection_candidate_ask + prsnt_marshall_selection), removing a few more global variables in the process. I've trimmed mine to 945 variables from 1201 in the latest version of native.
 
Somebody said:
Those tutorials and marshal election menus/presentations are deprecated - see line 817 of simple_triggers. You can safely comment out the entire thing (mnu_marshall_selection_candidate_ask + prsnt_marshall_selection), removing a few more global variables in the process. I've trimmed mine to 945 variables from 1201 in the latest version of native.

Does this decrease the compiling time actually, when you compile the whole mod? Then it would be good to remove them indeed.
 
In most programming languages, global variables are bad - I assume their elimination will save a couple of byte or so of memory and disk space inside savegames - not all that sure.
 
imo, it is actually a bad idea to "hide" warnings, esp by changing actual behavior.  may have issues wrt to save-game. e.g. some warnings could be partial stuff meant for future completion, but your having removed the lines will may it break existing save-game in a future build. (it may preserve the savegame if the global variables were declared in definitive order, even if unused or unassigned now, but somebody more experienced in globals should make the comments).

Lumos said:
A guid to noobs. Perfect, we needed one* all along.

* - Not one noob, one guide for noobs... :lol:

lol. If we're into modding, we are half a foot into coding already.  i.e. you CAN start out as a noob, but I don't think you cannot be forgiven if you STAY as a noob in the modding community.  so, I really think we should try to get rid of noobish habits: even if we can't get rid of some habits immediately, we should at least know which direction who should go towards.  Doing stuff like hiding warnings without knowing the full implications (just to make it pretty?) is definitely a step backwards.

Don't mean to offend anybody, but I'm just trying to prevent more people from falling down what I see as a trap.  It may seem like a good idea at first, but it really isn't in the long run.
 
The standard 1.131 module system compiled with no warnings for me; you just need to copy the variables.txt file from the 1.131 client Native module folder into your module system directory. As someone hinted at - don't remove global variables from the file if you are making a tweak to native, because it will change the id number of all global variables after them; breaking saved games and making a huge unnecessary diff, if you are trying to see what your change compiled into. Additions to module_strings and so on should go at the end for the same reason, unless you are making a separate mod.
 
Vornne said:
The standard 1.131 module system compiled with no warnings for me; you just need to copy the variables.txt file from the 1.131 client Native module folder into your module system directory.
I have been doing that for WB MS since 1.113. Don't remember who came up with that solution.
 
Vornne said:
The standard 1.131 module system compiled with no warnings for me; you just need to copy the variables.txt file from the 1.131 client Native module folder into your module system directory. As someone hinted at - don't remove global variables from the file if you are making a tweak to native, because it will change the id number of all global variables after them; breaking saved games and making a huge unnecessary diff, if you are trying to see what your change compiled into. Additions to module_strings and so on should go at the end for the same reason, unless you are making a separate mod.

Hmm, didn;t know that. Works a lot better than this way I guess :razz:.
 
I've said it in other threads, but I'll mention it again because there seem to be some folks who don't know:

The reason the developers don't remove these unused global variables themselves is because it would break savegame compatibility in Native, which is obviously too high a cost to pay for getting rid of some cosmetic warnings that most users will never see.
 
ThunderClaw said:
I've said it in other threads, but I'll mention it again because there seem to be some folks who don't know:

The reason the developers don't remove these unused global variables themselves is because it would break savegame compatibility in Native, which is obviously too high a cost to pay for getting rid of some cosmetic warnings that most users will never see.

The current code in the OP does not remove the variables, rather it includes a dummy script that "pretends" to test for equality for these variables so they don't show up as unused.

I believe (though don't quote me on this) the previous version of this idea commented the declarations out, which would have the possibility of breaking savegames. As it stands, the faux-script will "use" the variables so the warnings disappear, while maintaining their presence in the variables.txt file. Though, just using the Native variables.txt when you compile would have the same effect.
 
The latest version wouldn't keep save game compatibility even though all variables are kept, as the order is important - the game uses their id (or index) - if they are not listed in the module system variables.txt they are added to the end in the order they are written. To keep compatibility, the proper (and only, as far as I'm aware) way is to copy the variables.txt from the client, and this will build exactly the same thing as the client native module for all warband module system versions. I think I should add a bug report to the tracker, to see if the developers actually have a good reason for not including the file, or if the consequences are unintended.
 
The changes don't affect anything ingame, not on singleplayer or multiplayer. I use it on all MS files I use and I have no problems, neither with savegames as ThunderClaw declares. The old method did disabled them and made the module more incompatible, but I think you can say with safety that this does not effect anything in your mod or files on global variables.
 
I decided to test this, to make sure:
First, I started with a clean 1.132 module system, with the client variables.txt copied across; compiling it gives no differences at all to the clean 1.132 native module (I keep record of changes in modules using git), so I removed the variables.txt from the module system directory, and recompiled: this gives all the normal warnings, and makes a large amount of changes to the output module:
Code:
 conversation.txt      | 3034 ++++++++++++++++++++++++------------------------
 menus.txt             |  522 +++++-----
 mission_templates.txt |  652 ++++++------
 presentations.txt     |  172 ++--
 scene_props.txt       |   20 +-
 scripts.txt           |  476 ++++----
 simple_triggers.txt   |  106 +-
 triggers.txt          |   22 +-
 variable_uses.txt     | 1562 ++++++++++++--------------
 variables.txt         |  566 ++++------
 10 files changed, 3458 insertions(+), 3674 deletions(-)
I then reverted back to the latest variables.txt, and made a small change to module_game_menus.py, adding this to the end of mnu_character_report:
Code:
    (val_add, "$g_test_variable_1", 3),
    (val_add, "$g_test_variable_2", 66),
    (assign, reg61, "$g_test_variable_1"),
    (assign, reg60, "$g_test_variable_2"),
    (display_message, "str_archery_target_hit"),
I then compiled it once, copied across the new variables.txt (which was only changed by the two added variables at the end), then compiled again to give a diffstat of:
Code:
 menus.txt         |    2 +-
 variable_uses.txt |    2 ++
 variables.txt     |    2 ++
 3 files changed, 5 insertions(+), 1 deletions(-)
I then started a new game in warband, and opened the character report a few times, to verify that the output was correct (starting from 0 and incrementing by 3 and 66) until the output was "Distance: 15 yards. Score: 330". I then quit warband, restarted, loaded the game, and checked that the output was correct; it was: "Distance: 18 yards. Score: 396". I then edited the variables.txt in the module system, swapping around the two added variable entries, compiled, checked the differences (just the variable ids different), and started up my saved game again; this time opening the character report window gave the expected erroneous output: "Distance: 399 yards. Score: 84"; thus proving that changing the order of entries in the variables.txt file used to build the module is very likely to break previously saved games, by using the wrong saved values for any global variables that don't have the same line number in variables.txt.
To summarize: If you are making any single player module that is required to load games saved with a previous version, you must use the correct variables.txt when building the module; no other method is likely to work properly. For people making small mods for native, this means using the official variables.txt; and for larger mods that have updates that should work in with the native updates, they should probably add a reasonable amount of unused dummy entries to the end of the latest native variables.txt, then add their own ones; then when updating to a new official version, swap dummy lines for whatever was added.

I really don't see why there is so much resistance to using this method; as it seems to be the official feature for this purpose, and I think it's much easier than mucking around changing the module system scripts, much less likely to break something by accident, and makes it possible to use a diff utility to see exactly what changed compared to native, without a huge amount of variable id changes cluttering things up.
 
Back
Top Bottom