RP Compatible changes
exdysa opened this issue · comments
Hello!
Firstly, I really enjoy this project, it's very simple and well executed. It has changed my life as I frequent a roleplaying server, though I had to do a number of changes to the add-on to accommodate the different playstyle. I would like to list some changes I've made towards improving RP quality-of-life. I'd also like to jot down some bigger ideas for the admittedly niche situation that I have not taken the time to implement yet. I am not that familiar with how GitHub works on a code contribution level, so if it would be more acceptable to 'fork' changes let me know. If you'd like me to split this issue into two posts I can do that as well.
BIGINPUTBOX.XML
Line 6
<Size x="420" y="48"/>
I make the text box the maximum height to accommodate all the text of a custom-written emote and para/multi-para+ RP styles. With only one visible line, it is extremely difficult to review what has been written in the default WoW chat bar, and it is always faster and more advisable to write directly in the game than to write in another window. RP-Wise, copy/paste increases the speed between posts and possibility of loss of text, and sometimes someone interrupts you or walks up in the middle of a chat. You won't be aware of any environmental changes if you aren't focusing the game window.
Line 153
<OnEditFocusLost>
...
--self:GetParent():Hide();
There are few things worse than spending 10 minutes writing an amazing RP response only to lose it accidentally by clicking out of the window. This made me cry multiple times until in complete frustration I commented this line out.
Line 157
<OnEscapePressed>
...
self:GetParent():Hide();
</OnEscapePressed>
Since BigInputBox no longer closes after losing focus from the above change, we need to close the window somehow. ESC seems like an easy fix.
MAIN.LUA
Line 256
OnPostShow = function(self)
...
self:SetMultiLine(true)
This line makes the text box actually wrap and support multiple lines, versus be a giant empty window that functions otherwise identical to default.
A screenshot of BigInputBox with modifications applied.
These changes are all well and good, but occasionally the cursor does not line up with the text on lines after the first, which is annoying but manageable.
It is important to point out that-
these changes enable what I thought this add-on already did
-what the name implied to me before I even tried it.
After using this for about a month, I also have a number of new ideas that could be implemented. If I have time I can implement them myself, but some might be bigger projects than I can handle.
- A toggle for the above. I wouldn't force ALL players to have a giant, unwieldy text box centered on their screen, however I find this ideal for RP situations. Therefore, a simple way to toggle an RP mode via a /slash command, or possibly even a full tab in the Interface options pane would be sufficient. I know how to do this, but I am not very good at code and I've certainly never written anything as neatly as your project.
- Support languages. BigInputBox only sends in Common, no matter what you've set the chat language to reply with. I don't know how to do this as of this moment.
- Multiple Boxes. This is a bit of a stretch, but many RPers write 2-5 chatboxes worth of text. As it stands, there is a project called EmoteSplitter that allows an automatic split of these texts into Input box-friendly length. This is great, but TotalRoleplay3 recognizes quotes and asterisks. This means that when EmoteSplitter breaks a line before a quote or asterisk ends, the colors of the RP are interrupted. This makes the emote much harder to read. I could request EmoteSplitter change, or I could request TotalRoleplay3 for a compatibility change, but seeing a giant textbox in BigInputBox makes it very easy to approximate the length required, and I find manual splitting of emotes and /says a very elegant writing solution. Unintentional breaks inhibit the flow of reading and writing. I find it more useful for players to actually know the length of their chat window, something easily communicated by a modified, tall BigInputBox. Therefore I suggest the option of a few more identically displayed boxes that only hold text rather than send. Something to write an entire page in that you can actually read in game. As far as allowing me to implement this, it sounds completely overwhelming, but also not impossible with my skill set. However, I will mention again I only hack solutions, and rarely build anything properly.
From what I have found, nothing like the modified BigInputBox exists in the community, and I know thousands and thousands of people would appreciate such an amazing contribution, especially with all these additional features. I would absolutely love to spread your great work among the multitudes that practice wordcraft within Warcraft.
Thank you very much for your time.
Hi!
Been diving a bit into these problems this morning, trying to figure out ways to make it work better for RP without infringing on the design or functionality. So let me start with what I'm NOT going to do:
- Not going to add any sort of options. If it requires setup, chat commands, or any of that, it's not the addon I want to make anymore.
- Not going to let it start out as a huge blob of a window, not as an option, never.
Having that said, I think I still found some really nice workarounds today. In short, the editbox resizes. If you write a little above the width, it grows wider. If you write a lot over, it returns to normal width but adds more visible lines. And keep expanding vertically from there on. I tried filling the box, everything was constantly visible.
When it comes to the problem of losing large text blocks from losing focus, I solved it by simply not resetting the contents when that was the case. The contents will only be reset when you either hit Enter to send the message, or hit Esc to cancel it. Clicking anywhere on the screen will hide it as now, but when you next hit Enter, the text you typed is still there! Yay? :)
I haven't uploaded anything yet, but will after a bit more testing. I mean, I was unsure of whether it was even doable to resize it, because as it needs to be able to cast secure commands like spellcasting, there are quite a few limits to what we can do to it. But it appears to be working fine. I could write multiple lines of gubberish while fighting a combat dummy, and still /cast regrowth through the chat. So crossing my fingers!
Update hopefully coming later today! :)
Dev update:
Ran into another hopefully minor problem. It doesn't accept using alt + up to show the last thing we typed when using multiline mode. And toggling between them with the editbox visible will bug the cursor position, making it appear at the wrong place, being seemingly unfixable.
Trying to figure out a workaround.
Elegant solutions. I knew you'd do a better job than me.
Can confirm, alt-up and the cursor. I rarely use Alt-Up so I won't complain there. If it helps, on my edit I notice that an issue with the cursor is triggered by the text character that takes the last space of the line . As in, the next character that would be entered wraps a word to the next line. The box seems to adjust the lines just before the wrap is triggered when it bugs out the cursor. It only seems to happen SOMETIMES, likely because of the use of a non-fixed width font. Perhaps when there's no adjusting to be done, that's when it bugs, and if the character has a smidge of space the cursor works fine? I entered this in the text box if it helps
Test one two three four five six seven eight nine ten elven twelve fifteen sixteen seventeen eighteen nineteen twenty. tfdwenty one twenty wnety three our twenty five tewenty six twenty seven twenty eight twenty nine thirty. t
Where it says 'tfdwenty', if you type a lowercase d,q,p,e,a,o,n,g,u right after 'tfd' and before 'wenty' it breaks the cursor, replicating the bug on my end. If you type just about any other alpha there it doesn't happen. Note that these are lines that I wrote in sequence completely then went through and randomly deleted words from. The deleted words lay where the number sequence is shown to skip. This backwards editing may have something to do with the cursor issue as well and is often how I trigger the issue, but I can't say for certain it's the reason.
Obviously I also can't say if this will replicate for you as your code is different but hopefully this gives a clue.
This is a big maybe after all of the other matters are sorted out, but with the way you're making a seamless, automatic feeling of the add-on rather than options... perhaps a completely filled input box spills additional text over to new boxes? Sort of a larger parallel to the way you are creating a multi-line display. I imagine the box replicating, gridding itself two, three or maybe even four additional times as the user writes. Four boxes would be a generous amount for the more long-form RP writers, while five is honestly just too many.
Anyway, thank you.
Yeah I already figured out what triggered the multiline issue. Problem is it's unfixable unless the box is constantly super large. And that's just a butt fugly addon that I wouldn't make, so if you want a constantly large box, personal edits is the way to go.
As of now, I'm not going to include the multiline input box. Just no way to make it work in a good way. The other changes with "remembering" the contents unless we use Esc/Enter, though, those will remain.
Also, that multiline boxes don't support history and alt-up, that's a complete dealbreaker for that feature. Me and many others do use that feature. It's just not an input box without it! :o
Kind of feels like all these problems are bugs with the game that should be fixed, though. I'm going to send a tweet or something to the blizzard devs later with it! They'll probably just shrug and ignore it, but worth a shot! :D
They'll probably just shrug and ignore it, but worth a shot! :D
Agreed. Better to be solved formally than bandaged after. Two things.
-
Would it be acceptable for me to use what you've written and write an alternate version with a clear variation on the title and some major changes, given proper distribution of the MIT license along the way? This could be a project for me to play with and learn to code on and likely not much more, but if it went well maybe I'd share it? I have little aspiration or patience when it comes to such technical projects, much less troubleshooting for others. If your answer is yes and I do decide to push it somewhere, how would you wish to be credited?
-
Can I have a copy of the code you did write for the scaling box? It would still be nicer than what I wrote, even if I just keep it to myself, and if the answer to 1 is yes I'd likely throw it in a new project as the lines just do what I already know 'works', but better. Well, that is... unless I'm wrong and you think it's actually better functionally to force the window to be large the way I'm doing already?
Heres to hoping Blizz sees the value in such a patch.
Edit: Post-thought.... is multi-line something that could be fixed by not using SetMultiLine() and writing it some other way to the screen?
Could languages be switched by a ctrl-click of the bar title?
The code is MIT, the assets/graphics are not, as mentioned in the license file:
https://github.com/GoldpawsStuff/BigInputBox/blob/main/LICENSE.md
So do whatever you want with the code, and feel free to fork the project and make your own versions here on GitHub, but do not redistribute the graphics outside of GitHub, plix.
When it comes to the code itself, everything I've written so far is in github. The muliline stuff I don't have anymore. Was nothing I could get working properly, so there is no "perfect" or even really working build for that. But the rest with the auto-expanding single-line version is here. I just haven't published it to curseforge yet, because I'm still tweaking some things before I'm fully happy with it.
Sorry for the delay, btw. Working on language toggling!
So far I've made a label beneath the box, with slightly smaller text than the one above, which will show the language when we hover above the inputbox. If we click the language text, it toggles to the other language, and the text change. When a non-default language is chosen (something other than Orcish or Common, that is), the text remains visible even when moving the mouse away, as a reminder we're not using the default.
Tests are good so far, it appears to be working, outputting the chosen language into the chat :)
Will push out the update once I've cleaned the code up and made sure everything is working as intended! :)
Latest changes uploaded, and should be available once 1.0.14-Release goes through on CurseForge. Closing this issue, as there's not really much more I can do here! :o