I have the Player Renamer mod. But it is now non-functional due to the lack of Text Input Menu. I only have one line of code that doesn't work. TIM:TIM.Open(2, label, Nora) Label is the title of the message, Nora is the name of the player As I understand it here, I need to rewrite the line like this: SimpleTextField.Open(ScriptObject akReceiver, string asFunctionName, label, Nora)
I just don't understand what I need to specify in "ScriptObject akReceiver" and in "string asFunctionName"
I tried to generate a script just like this, but the window won't open.
Anyway, I managed to open the window with the script. But for some reason, "Rename Anything" can't see what's written. When saving, it leaves the name blank. I'll keep looking into it. SimpleTextField.Open(self, "OnButtonPress", label, Nora)
You need some kind of receiver when opening the text field, so that any output can be retrieved via Papyrus. In your case, using "self" and "OnButtonPress" seems correct. Just be sure that you have a same-named function in your script with the signature: Function OnButtonPress(string asText) Debug.Trace("Text: " + asText) EndFunction
Yes. There needs to be some kind of callback for the menu to send changes to. Be also sure that you forward the name and the scriptobject to the Open function.
OK. I will post part of my code here Function RenamePlayer(Actor akActor) string label = (MSGBox as Form).GetName() string Nora = Player.GetDisplayName() SimpleTextField.Open(self, "OnButtonPress", label, Nora) RenameAnything.SetRefName((Player as ObjectReference), name) EndFunction
Function OnButtonPress(string name) --- EndFunction Here's what I have to write down in OnbuutonPress() if everything is performed in me in the Renameplayer() functions?
Looks mostly fine, though you need to call `SetRefName` with the `name` parameter in the `OnButtonPress` function. Then the name will change once the user presses the Ok button. Function RenamePlayer(Actor akActor) string label = MSGBox.GetName() string Nora = Player.GetDisplayName() SimpleTextField.Open(self, "OnButtonPress", label, Nora) EndFunction
Function OnButtonPress(string name) RenameAnything.SetRefName(Player, name) EndFunction
You're selling this short by not mentioning the 2 additional parameters the function takes for setting the window title and default text :)
This is so great! I haven't found a "real" use yet, but right now I'm having a great time using it for experimenting and prototyping. Instead of having to create a menu, add that as a property to the script, and then call the menu -- and having to edit that each time I add or change an option -- I can just pop open a in the script and have a big if/else thing to handle all the commands/tests I need (and then there is Papyrus Extender's regex parsing, too!). That makes it totally painless to try out random stuff. Thank you so much.
Thank you for the kind words :) I thought I already wrote in the description that you can modify the title and default text. Guess I will add that now. I have also thought about implementing some other menus, maybe putting them into a collection, similar to Skyrim's UIExtensions. If you have any ideas about menus that can be useful to access via Papyrus, let me know :)
I'll just say things that come to mind, don't take these as "requests"
For the text input, it would be neat to have parameter to not allow for multiple lines, so we can close the box with return. If it is possible to enable copying, and not just pasting, that would be sweet obviously.
As for other things, the first thing that came to mind is menus we can define by script. That is, pass in a string for the description/header, and an array of strings for the buttons. (Or even cooler, pass in a struct array for the buttons, with the text and an ID of our choosing for each option, so we could re-arrange them at will without having to update what array index means what). Ideally, allow us to pick what button is selected by default.
For that it would be also neat to support the (HTML-ish?) formatting FO4 already supports (at first thought that being able to pick text colors would be nice, but I think respecting the UI color is nicer). The option to have a button be slightly grayed out (and not selectable) by just using the HUD color at say 70% opacity would be useful.
Also, a menu that allows (de)selecting more than just one entry, basically check boxes (no need for actual boxes or check marks though). For each option we'd pass in the title, whether it's selected, and whether it can be toggled by the user (if it can't be toggled, it's slightly grayed out).
Another thing I kinda crave is menus that don't allow selecting one option, but changing any of a list of values, and then confirming or cancelling. Basically a tiny form generator, where each field has a title, a type, and the current/default value. Types could be string, int and float, and for the latter two you could have min/max and a step size, and allow entering values directly as well as clicking buttons to increase or decrease them.
Being able to display a custom bitmap above the description text, or using FallUI (or other?) icons in the menu options would also be "nice to have", but only if it's possible without insane amounts of work (which I doubt).
Just for overview, your suggestions in a nutshell: 1. Text Input, optionally single-line only and being able to get the text at any time 2. Message Box, allow to pass title, text and any amount of buttons, maybe with IDs (the game already supports it, see PCL's Message script) 3. Allow customization via HTML - AS3 partially supports it already, so it shouldn't be too difficult to implement 4. Button Group, allowing to individually disable selection (though I don't know where you would need this option) 5. Combo Box 6. Numeric sliders for ints and floats, customizing the min, max and steps 7. Icon support for titles (should be possible, may require a lot of work)
These look decent enough. I guess all of these can be useful at some point, especially 1, 2 and 6. Thank you for you suggestions :)
Thank you again for making this! Using it to test things really is the best, and it's really neat for prototyping menus and submenus without having to jump back and forth into xEdit. Now all we need is an F4SE plugin to allow hot reload of Papyrus scripts and we're off to 10x faster development cycles, just based on sheer loading times saved :D
Seriously though, I think 2 in and of itself would be such a game changer. Haven't people always wanted this? Just getting text in text boxes, not to mention the options that can be selected, without having to mess with aliases... that's always been the dream, I'm pretty sure.
For example, I always thought simple FTL-events like quests random NPC could have would be cool (so you walk up to them, get a bunch of text, and can pick one of several answers), but knowing I'd be limited to the text I pre-generated menus for made me not even really think about it further.
Being able to generate the text totally dynamically in script could allow taking all sorts of variables into account - they could greet you differently depending on weather, time of day, your companions, your health, your addiction status, your clothes, dozens of other things -- and it wouldn't even be a nightmare to make, you could easily re-use what you wrote for one thing with another in the comfort of your IDE... I'm honestly getting giddy at the idea that this might actually become a reality at some point.
The game already supports hot-reloading scripts - see the ReloadScript console command. I try to start working on the new menus soon, though it may take a while for it to be finished. I have plans to add a bunch of events and customizations to them, like altering HTML text, color, size, alignment, etc. Hopefully Papyrus won't cause too much trouble.
Thank you for this nice mod. I am hoping to use it to replace TextInputMenu in an existing mod. I did encounter a bug where the callback was not being called. If anyone else has this problem, try casting your script as 'ScriptObject': SimpleTextField.Open(self as ScriptObject, "CallbackFunction","Enter response") See post below for actual bug cause and fix.
I didn't know there was a mod already doing this, that's unfortunate. Anyways, the casting to ScriptObject should happen by default, since every script implicitly inherits from it. I tested it with a test plugin and it worked without having to explicitly cast it.
I know, it should have worked, I was passing a Quest argument. The CK wiki page was pretty insistent on casting parameters explicitly, so that's what I did and it worked. I just hope this helps anybody that runs into the same problem. Thanks.
Turns out it was a very different, random bug that happened to correct itself temporarily when I added that cast. The quest whose script I was using for the callbacks has two scripts associated with it. The code managing the callback, either the game or F4SE, would sometimes decide to call the wrong script. I added a proxy function in a different script, from a different quest, that then calls the right callback. Weird!
Could it be used as a scrollable in-game message log, similar to other rpgs where you can see things like damage given/taken, game-relevant messages, etc?
Technically, yes, though it would be quite annoying to have a text field appear every time you take damage. It should rather be used to listen for user input.
It's meant as a utility for modders, it doesn't do anything on its own. You can look at the code example in the description or at the source code from the main file, if you're familiar with Papyrus.
31 comments
I only have one line of code that doesn't work.
TIM:TIM.Open(2, label, Nora)Label is the title of the message, Nora is the name of the player
As I understand it here, I need to rewrite the line like this:
SimpleTextField.Open(ScriptObject akReceiver, string asFunctionName, label, Nora)
I just don't understand what I need to specify in "ScriptObject akReceiver" and in "string asFunctionName"
I tried to generate a script just like this, but the window won't open.
Anyway, I managed to open the window with the script. But for some reason, "Rename Anything" can't see what's written. When saving, it leaves the name blank. I'll keep looking into it.
SimpleTextField.Open(self, "OnButtonPress", label, Nora)In your case, using "self" and "OnButtonPress" seems correct. Just be sure that you have a same-named function in your script with the signature:
Function OnButtonPress(string asText)
Debug.Trace("Text: " + asText)
EndFunction
Be also sure that you forward the name and the scriptobject to the Open function.
Function RenamePlayer(Actor akActor)
Here's what I have to write down in OnbuutonPress() if everything is performed in me in the Renameplayer() functions?string label = (MSGBox as Form).GetName()
string Nora = Player.GetDisplayName()
SimpleTextField.Open(self, "OnButtonPress", label, Nora)
RenameAnything.SetRefName((Player as ObjectReference), name)
EndFunction
Function OnButtonPress(string name)
---
EndFunction
Function RenamePlayer(Actor akActor)
string label = MSGBox.GetName()
string Nora = Player.GetDisplayName()
SimpleTextField.Open(self, "OnButtonPress", label, Nora)
EndFunction
Function OnButtonPress(string name)
RenameAnything.SetRefName(Player, name)
EndFunction
This is so great! I haven't found a "real" use yet, but right now I'm having a great time using it for experimenting and prototyping. Instead of having to create a menu, add that as a property to the script, and then call the menu -- and having to edit that each time I add or change an option -- I can just pop open a in the script and have a big if/else thing to handle all the commands/tests I need (and then there is Papyrus Extender's regex parsing, too!). That makes it totally painless to try out random stuff. Thank you so much.
edit: Oh, and it even supports pasting text!
I thought I already wrote in the description that you can modify the title and default text. Guess I will add that now.
I have also thought about implementing some other menus, maybe putting them into a collection, similar to Skyrim's UIExtensions.
If you have any ideas about menus that can be useful to access via Papyrus, let me know :)
For the text input, it would be neat to have parameter to not allow for multiple lines, so we can close the box with return. If it is possible to enable copying, and not just pasting, that would be sweet obviously.
As for other things, the first thing that came to mind is menus we can define by script. That is, pass in a string for the description/header, and an array of strings for the buttons. (Or even cooler, pass in a struct array for the buttons, with the text and an ID of our choosing for each option, so we could re-arrange them at will without having to update what array index means what). Ideally, allow us to pick what button is selected by default.
For that it would be also neat to support the (HTML-ish?) formatting FO4 already supports (at first thought that being able to pick text colors would be nice, but I think respecting the UI color is nicer). The option to have a button be slightly grayed out (and not selectable) by just using the HUD color at say 70% opacity would be useful.
Also, a menu that allows (de)selecting more than just one entry, basically check boxes (no need for actual boxes or check marks though). For each option we'd pass in the title, whether it's selected, and whether it can be toggled by the user (if it can't be toggled, it's slightly grayed out).
Another thing I kinda crave is menus that don't allow selecting one option, but changing any of a list of values, and then confirming or cancelling. Basically a tiny form generator, where each field has a title, a type, and the current/default value. Types could be string, int and float, and for the latter two you could have min/max and a step size, and allow entering values directly as well as clicking buttons to increase or decrease them.
Being able to display a custom bitmap above the description text, or using FallUI (or other?) icons in the menu options would also be "nice to have", but only if it's possible without insane amounts of work (which I doubt).
Hope that helped :D
1. Text Input, optionally single-line only and being able to get the text at any time
2. Message Box, allow to pass title, text and any amount of buttons, maybe with IDs (the game already supports it, see PCL's Message script)
3. Allow customization via HTML - AS3 partially supports it already, so it shouldn't be too difficult to implement
4. Button Group, allowing to individually disable selection (though I don't know where you would need this option)
5. Combo Box
6. Numeric sliders for ints and floats, customizing the min, max and steps
7. Icon support for titles (should be possible, may require a lot of work)
These look decent enough. I guess all of these can be useful at some point, especially 1, 2 and 6.
Thank you for you suggestions :)
Seriously though, I think 2 in and of itself would be such a game changer. Haven't people always wanted this? Just getting text in text boxes, not to mention the options that can be selected, without having to mess with aliases... that's always been the dream, I'm pretty sure.
For example, I always thought simple FTL-events like quests random NPC could have would be cool (so you walk up to them, get a bunch of text, and can pick one of several answers), but knowing I'd be limited to the text I pre-generated menus for made me not even really think about it further.
Being able to generate the text totally dynamically in script could allow taking all sorts of variables into account - they could greet you differently depending on weather, time of day, your companions, your health, your addiction status, your clothes, dozens of other things -- and it wouldn't even be a nightmare to make, you could easily re-use what you wrote for one thing with another in the comfort of your IDE... I'm honestly getting giddy at the idea that this might actually become a reality at some point.
No pressure, I'm just saying ^_^
I try to start working on the new menus soon, though it may take a while for it to be finished.
I have plans to add a bunch of events and customizations to them, like altering HTML text, color, size, alignment, etc.
Hopefully Papyrus won't cause too much trouble.
And good luck on your quest :)
I did encounter a bug where the callback was not being called.
If anyone else has this problem, try casting your script as 'ScriptObject':
SimpleTextField.Open(self as ScriptObject, "CallbackFunction","Enter response")
See post below for actual bug cause and fix.Anyways, the casting to ScriptObject should happen by default, since every script implicitly inherits from it.
I tested it with a test plugin and it worked without having to explicitly cast it.
The CK wiki page was pretty insistent on casting parameters explicitly, so that's what I did and it worked.
I just hope this helps anybody that runs into the same problem.
Thanks.
The quest whose script I was using for the callbacks has two scripts associated with it.
The code managing the callback, either the game or F4SE, would sometimes decide to call the wrong script.
I added a proxy function in a different script, from a different quest, that then calls the right callback.
Weird!
It should rather be used to listen for user input.
You can look at the code example in the description or at the source code from the main file, if you're familiar with Papyrus.