-= Gametoast.com =-

Hi,

i often wonder how the manipulation with userscripts work for lua. Of cause i often used them in my mod (custom GC, the addme file, custom stat page,...) But i never realy understanded how it works.
So i'd like to understand it now and i hope you can help me with that.

To learn about this i'd like to add an new legal screen and later change the menu background music.
Here are my script files. I'm sure that there will be problems with the code, but even if i start the debugger no user script was loaded. Only the custom_gc scripts.

user_script_1.req user_script_1.lua
I hope you can help me to add an new legal screen and than i'd try to change the menu backgroundmusic by my self.

User scripts are loaded by a modified game_interface.lua. game_interface is loaded at the start of every map so user scripts can only modify ingame stuff. Custom GC scrips are loaded by a modified shell_interface.lua. shell_interface is loaded any time you enter the shell so cGCs can modify shell related things and any inshell maps (ifs_legal is a shell script so you'll need to use a cGC). Since I lost the source code, I can't say exactly when the custom scripts are loaded within their interface files. It is harder to change the things that are loaded before them than changing the things loaded after them. If you modify something that was loaded before the script, you have to wrap the primary function calls and dynamically makes changes every time the function is called. If you modify something that's loaded afterwards you have to wrap the function call that performs the loading, but your changes become 'built-it'.

I don't have a copy of ifs_legal, so I can't give you specific advice, but I think you'll want to wrap the function call that performs the loading of the screen. ifs_legal is not a function, it's the variable that holds the IFShellScreen structure before it's build and some modified version of it after it's built (I consider a screen to be 'built' after its been registered with the game's exe through AddIFScreen). You want to makes changes before ifs_legal is built. To do that, wrap AddIFScreen and watch for when the second parameter is "ifs_legal". When it is, then you know the first parameter is the ids_legal structure you want to modify.

I still have v0.01 of the Modded Shell mod*. It has a modified start up sequence. I don't have the source code, so I don't know if it'll be useful to you or not, but I can email you the 3.3MB file if you want it.

*For personal reference: hiawatha/swbf2/res/shell 6-21-2006.zip

Ah thank you I think I know now what the userscript is good for. So I'll try with an gc script next.


That's the ifs_legal script.
But since you don't know if the gc is loaded before or not, I think it's a bad example. So what about an new button Hello World on the login page (where you select the account)

==EDIT==

OK now i have an idea about how to wrapp an function. But how can i change variables that are defined in an other script. Let's say interface_util. At the top they define gTitleTextColor = { 0, 0, 0} and i want it to be 255,0,0. Do i only write in my custom script gTitleTextColor = { 255, 0, 0}?? And what can i do if my script ran first??


==EDIT2==
First i killed the AddIFScreen Funktion (only black screen) but now it works

I remember you told me once something about NAME = function(parameter1, parameter2) is bad and that you always should write NAME = function(parameter1, parameter2,..) But i haven't understand it correctly why to use it and how. How can i use the unknown parameter in the function call backup_NAME()??


==EDIT3==

Is there a way to know what kind of mod was selected in an user script??

gTitleTextColor is a global variable which makes things a bit easier. In your script, check to see if it's already set. If it is, then you're loading after interface_util. If not, then you're before interface_util and interface_util will wipe out any changes you make so you need to run after it. If after, all you need to do is set it to something else. It won't change anything that's already using the old version, but anything new will get your changed. If before, then you need to watch for interface_util to be loaded and make your change when it's done. To do that find the first, uniquely identifiable function call or return after interface_util. interface_util is loaded from game_interface.lua. The line in there is: ScriptCB_DoFile("interface_util"). So ScriptCB_DoFile is the function you want to wrap and you'll be watching for when the first parameter is "interface_util". When you see that parameter, you call the normal ScriptCB_DoFile, then when that call returns you make your change and return whatever the original call would have returned.

Yes, always use ... when wrapping functions. There's no way to know if some other mod added more parameters to that function. "..." is 'and everything else'. Any ... values get automatically stored in the "arg" array. When forwarding the call to the original function you'd do: FunctionName(paramIKnowAboutAndChanged, unpack(arg)). And don't forget to return whatever it returns, even if it normally doesn't return anything. Someone else might have modded it to return a value. Skipping these two steps create bugs that are incredibly difficult to find and reproduce. v1.3 had two of them and it took years to uncover them.

I'm not sure what you mean by selected mod, but the v1.3 readme should list two global variables that you can check to see which game mode and era are being played: __thisMapsCode__ and __thisMapsMode__
They're set after the ReadDataFile calls that load the map. The code for that section is in utility_functions2.lua if you have the recovered v1.3 source or here if you don't:It's a good example of function wrapping using ... and arg, but I didn't return ReadDataFile's return value!

Yes the two global variable will do.
About returning the value the original function returns. How would i do that??
simply return RetailReadDataFile( unpack(arg) ). or blub = RetailReadDataFile( unpack(arg) ) and then return blub??

==EDIT==

i just tried to wrapp the fakeconsole script, but you wrapp it after me with something from the v1.3 scripts to add all the commands.

My custom_gc script:
i want to change the gamefont from small to tiny with that. But it doesn't work. I'm sure that it is something like that:
(((original fakeconsole script) my modification that changes the gamefont) your modification that changes the gamfont back)
How can i get behind your modification to just change the gamefont??


==EDIT==

my next try was using an custom user script to fix the fakeconsole problem.
But i always get the message
No ifs_fakeconsole_fnBuildScreen() to take over or
No ifs_AddIFScreen() to take over
when i try to wrapp them. What does that mean??

My idea is:
If era = r
fakeconsole_listbox_layout.font = "my_new_font"
end
But i cannot find an function for the user script to wrapp this around and if i'm doing it with the gc i cannot check for the era. So how can i do it??

For returning both methods should work, but "blub" should be a local variable: local blub = ....
should beand you forgot to return the result from calling us1_AddIFScreen. And that call should have been: us1_AddIFScreen(table, name, unpack(arg))

v1.3 directly modified ifs_fakeconsole and the other shell screens it modified, there was little reason to wrap things. You were correct to change to a user script. ifs_fakeconsole is an ingame screen. cGCs are more for changing shell screens.

ifs_fakeconsole_fnBuildScreen will be very hard to wrap because it's created, used, then destroyed with nothing inbetween those steps and only 3 function calls while it's in use: ScriptCB_GetFontHeight, NewButtonWindow*, ListManager_fnInitList. It should be possbile to get at it when it's defined, but you'll have to deal with messing around with _G's metatables and I don't have much experience doing that.

You're getting the error on ifs_fakeconsole_fnBuildScreen because it's wipped out (set to nil) right after it's used. Your script never sees that function existing. As for ifs_AddIFScreen, there's no such function. Perhaps you meant AddIFScreen? If you get the error on AddIFScreen then your script is loading before AddIFScreen is defined. So you'd have to go find what creates AddIFScreen and wrap that so you can wrap AddIFScreen after that thing creates it.

But luckly you said what you're trying to do so you shouldn't try any of that. Lists in SWBF2 are always filled with empty items. Those are created from the CreateFn functions. When there's data to display, the PopulateFn functions set all the data on all those preexisting items. Notice in Fakeconsole_Listbox_CreateItem that Temp.showstr is a NewIFText and is almost the only place that deals with fonts? Now checkout the Fakeconsole_Listbox_PopulateItem. It sets the text, color, and alpha of that showstr (Temp is the Dest in Fakeconsole_Listbox_PopulateItem). Hmmm, we want to change showstr's font. Lets look at every function containing the text "IFText_fn"... Ah, there's a IFText_fnSetFont! and a IFText_fnSetScale too.

Wrap Fakeconsole_Listbox_CreateItem and tweak its return value or wrap Fakeconsole_Listbox_PopulateItem and maybe change Dest before the real Fakeconsole_Listbox_PopulateItem call. We'd prefer not to change Dest after Fakeconsole_Listbox_PopulateItem because at that point the new data is already visible to the user and we don't want to risk it flickering.

You know to look at Fakeconsole_Listbox_CreateItem and Fakeconsole_Listbox_PopulateItem because fakeconsole_listbox_layout uses them for its CreateFn and PopulateFn fields.

But before all that, you should modify ifs_fakeconsole.lua directly on a non-v1.3 SWBF2 and make sure the changes you're planning to make actually work. Changing the GUI around can be a huge pain.

*In Lua, doing NewButtonWindow{bag='Plastic'} is a shortcut for typing: NewButtonWindow({bag='Plastic'})

I tryed to wrap the ScriptCB_DoFile function, and i could wrapp it, but nothing changed.
But i think the problem with it is, that the build function is called at the end of the script and after all objects are builded, the new parameter does nothing.

I'll try to wrap Fakeconsole_Listbox_CreateItem next.


==EDIT==
Result: No Fakeconsole_Listbox_CreateItem() to take over

You should try changing ifs_fakeconsole.lua directly on a non-v1.3 SWBF2 before moving the changes into a custom user script. If you can't get it working directly on the file you're not going to get it working through code injection.

Era printed out nil because the map isn't detected until the map ReadDataFile lines in the mission script. You'll have to wait until after that to determine which map you're on. ifs_fakeconsole is loaded on the ingame.lvl read which is before the map is read. If you end up changing the layout structure, do it by wrapping ScriptPostLoad (after you tested it directly first).

You couldn't wrap Fakeconsole_Listbox_CreateItem because ifs_fakeconsole wasn't loaded yet and that's the file that creates Fakeconsole_Listbox_CreateItem. Remember you had to wrap ScriptCB_DoFile in order to wait for ifs_fakeconsole? You still need to wait until Fakeconsole_Listbox_CreateItem exists (which is after ifs_fakeconsole loads). You can wrap any function after ifs_fakeconsole loads (such as ScriptPostLoad) or the function that loads it (ScriptCB_DoFile).

I loaded the stock ifs_fakeconsole, and modifyed it to use my font. Then i loaded it in a custom common.lvl and everything worked (v1.3 installed) I only changed the font. But your 1.3 fakeconsole has more commands than the stock one (only ToggleQosDisplay).
But when i try to wrap where ever around the new font is never taken.

Ok, now make those modifications as if they were in a user script. So if you're wrapping Fakeconsole_Listbox_CreateItem and changing the return value then directly change the return value inside the real Fakeconsole_Listbox_CreateItem. If that's working and your user script isn't, post both of them.

After i wrote my last exame i have the time to fix my font problem now.

I got a work around, but I need some more help.

That's my script so far, and the fakeconsole entries are all displayed.


But now I need to fix the description text. You know, if you have the cursor on an command, an little description is displayed at the right side. But I don't know what font you took for it. Do you remember if you took one of the defined fonts:
And the last problem is that the game Crashs for other eras, because the gamefont_rc is unknown.
Any ideas how to fix that? I wanted to check the mod id, but it's unknown when my script ran.

To fix the crash you need to manually load your gamefont_rc before you attempt to use it.

To check the mod id, wrap ScriptInit then check when that function returns. It should be set by then.

I don't know what font I used, probably "gametont_large", but there's a good chance I directly coded that font instead of using a variable like gListboxItemFont. But change all those global font variables to your custom one first, just to be sure. If that doesn't work you should be able to get a reference to the text control that's displaying the descriptions. You'd need to wrap all of the ???SetUString, ???SetString, ???SetText, and related functions and watch them until one is called with a string starting with "mods.fakeconsole.description." (actually you'd probably need the localized version of that string). When you see that then you know whatever it's operating on is the description object. Once you find that you can use one of the SetFont methods to update it. When testing, you'll need to be sure to run the Fake Console and select the command who's description you picked so that the set text method actually gets called to set that description. That'll work for all the v1.3 FC commands. To change custom commands you'll have to take that description object and work to find a different way to reference it. Custom FC commands probably don't localize their descriptions to mods.fakeconsole.description. You'd do this by printing out the ID of the description object (looks something like "table: 03DE3DAC") then printing all nested globals and seeing where else that ID shows up. Then you might be able to directly reference that location from within your script.

This is what's great about Lua. In other languages you won't have a chance to change the description's font (or much of anything else), but in Lua we can drill down through all the tables and find it. You can hide things in Lua to prevent that, but few people bother to do so.

wrap the scriptinit function didn't work. But i got the PostLoad function
Problem: I still do not know if it is the cw, gcw, dt, bfx or rc era. Any Idea how to check this?? I could munge the new fonts to a new lvl and load these fonts for every map, but i wanted to do it only for my mod it should be more compatible with other scripts that way.
I changed all global fonts, but the description didn't look good. So it looks like the complicate solution...
But first I'd like to fix the fonts for my mod only.


==EDIT==

i tried this: And it only fixes for the era where i defined the __thisIsRcEra__ in the ScriptInit function. Alle great. But the new fonts are not used for the pausemenu. I'm sure it's because the menu is already created. Any ideas how to fix the fonts only for RC??

User scripts are read in as part of ingame.lvl, which happens in ScriptInit, which is why you can't wrap that function. Sorry, I should have remembered that.

Set __thisIsRcEra__ at the top of the script file and return to using your ScriptCB_DoFile wrap to find ifs_pausemenu.

you are my hero!!!

Thank you so much for your help. I think I won't fix the description problem, it's not so important.
An other thing I wanted to fix was the era list in the single player instant action. I wanted to add an slider like the one from the map list. But when I loaded my script instead of the original one (I waited for the script_cbdofile to call ifs_missionselect and called my script instead) But then all maps had the same colour, there where only the stock eras,.... so most v1.3 changes were removed. Furthermore I found the part where the both eras are added to the list and there were no list. they are just two container. So to fix that I need to know if you added more containers per era or if you put everything in a list. And then in need to know how you did it. So after the source are lost I think this is impossible to fix.

Yes, a lot of the 'lists' are faked. I was able to replace them with real lists, but then the checkboxes didn't work and instead it used normal list selection highlighting. The checkboxes looked a lot better. You could add a slider than manually 'scrolled' through the fake era list. I hadn't thought of doing that. Basically as the slider moves you'd hide, move, and show the proper checkboxes in the proper sequences. Luckily by the time I was making era changes I had enough experience to be putting all my changes in separate files instead of embedding them within the shell. I made minor tweaks to some parts, but most of the changes were replacing functions with new versions. All of the new versions are in ifs_era_handler.lua which is part of the v1.3 recovered source. I'm not sure if that file is the latest version, but it's at least very close to the version within v1.3. Do not replace that file. If you want to change how those functions work you should wrap them.

ifs_era_handler.lua: first half:

ifs_era_handler.lua: second half:

Wow, that's great. I'll have a look at this.