I’m developing a plugin for managing animations and related data for my project. The system uses binary data internally, but I have buttons that let me copy/paste it as JSON text.
This is convenient and works with small files, but for larger files, the TextBox’s text gets truncated to 16384 characters.
I need to be able to copy this data as part of my workflow. I spent weeks working on this (binary data formats, json conversion, unit test, animation editor, etc.) and it’s frustrating to run into these limitations.
My experience also has books players can find and read in-game. My data tools use textboxes to input localized versions of these texts. So far there are only 5 books, but the longest one is 7838 character long (nearly half the limit!) I use a custom word wrap algorithm so rendering in-game is not an issue, but developers should be able to easily work with large amounts of data in studio.
Expected behavior
I should be able to copy and paste large amounts of data into textboxes, especially within a plugin context.
It seems like a waste of time for me to need to add a bunch of textboxes that automatically stack together and require manually copying and pasting chunks. The purpose of this system is for it to be easy for me to copy keyframe data between animations, or copy an animation and edit it for some other purpose. It’s core to my workflow, and I would probably mess up trying to paste 10 different things on my clipboard in the correct order.
There are plenty of valid use cases for needing to copy and paste large amounts of data, especially within studio widgets. In my current situation I’m trying to copy 49665 bytes, but I could imagine needing much more.
I’d rather not. There is also the book text use case. I’m not going to develop an external program just so I can compress it and input it into a Roblox textbox, and pasting it into a script would be just frustrating and disconnected from the otherwise convenient tools I spent time implementing. Also, not all data will compress below 16kb. Compression might be valid for inputting special user data from studio or something, but this is supposed to be a convenient development tool, and Roblox is meant to empower creativity. This project is huge (slightly overwhelming), and usually I have time to work around Roblox’s limitations, but I draw the line at pasting data into textboxes. I should be able to paste megabytes into textboxes with no issue beyond maybe a frame spike.
It’s almost certainly just a constant in the Roblox source that could be changed easily. The limitation used to be 1000 characters years ago due to a filtering mechanism. I assumed the limit had been removed entirely.
Yeah Roblox limitations get pretty annoying at times however there is not much we can do about it because I doubt that a engineer will go change a “int” to a “long” just because of a few complaints. All you can do Is find another solution or pray to the Roblox gods for a studio update.
Unfortunately, this is something that we all have to deal with. Fortunately for me, I haven’t needed to go beyond the 16K limit. One thing you can do is copy/paste your code into a module script and use the search/replace (CTRL-H) to replace all the quotes with a backslash quote. Then add a quote to the front and end of the string. Include the module script into your plugin and process it from there. You will have to do this for each animation that you are loading in.
Unfortunately, that’s the only thing that I can think of at this point.
In the meantime, you can put in a feature request to add something like a long text box class that’s the same as a text box, but accepts longer input, like 65536 characters (64KB) or 262,144 (256KB) or even 16,777,216 (16MB).
Have you considered converting the JSON into an animation file that Roblox understands and can import? That would remove the need for a plugin.
On the internet, I discovered that Blender has a python import/export script for FBX. Autodesk (which owns the format) has C++ and Python bindings for the format available as well. In fact, they have an entire SDK that you can add to Visual Studio on their website. It wouldn’t be difficult to write a command line utility to convert JSON to FBX and then import it into Roblox the usual way.
Copying text like this, especially for plugins, is definitely a valid use case worth considering. Data entry is a generally important feature.
Input player save data in a customer support context.
Input scripts or special code.
Copy logs and debug information.
Input of large or medium-size data sets for ML training.
Input heightmap data or user creations.
Input of book text, or long-form articles/posts like update logs.
Rich text formatting. This format can be verbose.
Unicode formatting for different languages. The limit is effectively <5500 graphemes if inputting Chinese, due to how utf-8 works.
Testing long request bodies for APIs, or editing/inserting long JSON configuration files.
Inputting custom subtitle data for viewport frames.
Inputting MIDI data for music.
Copying sales data.
Input of dialogue trees for NPCs.
Inputting long commands. It might even be dangerous if a developer pastes a large command into the developer console but it gets cut off such that the code compiles but doesn’t finish and has unexpected behavior.
I’m attempting to create extremely scalable content systems, and this limitation unacceptable for my use. Roblox can chip away at these use cases, but Roblox developers are highly creative and we should be able to create custom tools like this.
Even with ModuleScripts, the limit is 199,999 characters. We can work around limitations and make do with what we have, but 16384 is arbitrary and extremely limited. We can open files, which is a great feature, but unless we want to process rbxm files in another application or set up a web server, we can’t output them cleanly, and we can’t copy them to the clipboard easily; TextBox instances work great, especially for workflow-related tasks like routinely moving data around.
My assumption is the “even with module scripts” line refers to the inability to copy and paste large of texts through module scripts consistently, as you may be generating text over 200k characters. However, with the new script editor APIs you are able to get around this limit.
Yes that would work if he where to ran that through the command line, however I think he wants to just be able to copy and paste it into the script without having to run that. Also if he where to try and run that he would need to copy and paste the contents into that defeating the entire purpose.
It’s an arbitrary limitation that we shouldn’t need to deal with. I made powerful data management tools for my project, and it’s disheartening to realize I can’t even copy the data.
I use a custom animation system. It’s a long story, but I’ve been implementing custom characters since before Roblox had an animation system, and it’s just what I’m comfortable working with. I have implemented fbx conversion tools for my system, and even implemented acceleration-based smallest-three quaternion delta compression to keep the size very very small, but it’s a really convoluted process that I wanted to streamline. The animation tools I created last week let me edit animations very easily, and even migrate animations to a new skeleton, without needing to juggle pre-baked files.
A separate plugin-only textbox class could make sense if the 16384 limit is intentional. I’m not sure what the reasoning was behind the decision originally. In-game one could argue that the limitation protects the user in some way, but I’m still skeptical. To me it seems like a bug, especially in studio.
No, it’s not a bug, and it’s not arbitrary. I strongly believe that is was intentional.
Here’s why. Say you have the server accept a long int number of characters in a text box. That’s 231-1 characters or 2,147,483,647 characters (or bytes). To send that to the server it would take at least that much memory to process it, and an inordinate amount of time in a live game. Too many people sending data like that to the server will crash the server. So they limit it to 14 bits which is 16384. Even a short int will take a number up to 32767. So it’s a security safeguard against an attack on the server.
Another reason is that the .NET text input fields in Windows has a default max length of 32768 (I looked it up since it’s been awhile.) even though the data type is an int32 with the afore mentioned max value. So it sounds like you have an edge case that you are dealing with. Check this out:
So Studio was built with Visual Studio 2019. It’s highly likely they are using .NET, with other libraries. They are also using (and it’s mentioned outright) that they are using Autodesk’s FBX software as well.
The 16KiB limit was originally implemented because that was the upper limit on the replication layer back in the day, and so it had to be capped in order to allow the server to replicate changes to a SurfaceGui TextLabel, for example. However, the replication limit is now much much higher and this limit needs to be raised for Text now.
TextBox is a client-side object. It shouldn’t be sending anything unless the developer decides to send unsanitized text to the server over a RemoteEvent. Limiting text fields doesn’t stop an exploiter from firing a RemoteEvent with a 10GB string, so it doesn’t make any sense as a security safeguard. Even if this does happen, there are bitrate limits. It’s not like that 10GB file will arrive right away (unless there’s a decompression vulnerability); I haven’t tested it, but the client would probably just disconnect or time out trying to upload it.
I wouldn’t be surprised if it has some relation to .NET textboxes, but this doesn’t justify it. The .NET text field limit was probably devised 20+ years ago.
I understand text rendering might be an issue for very large strings. For my use I’d be okay with text rendering getting cut off after 16384, as it’s impractical to edit such large strings, but we should still be able to copy and paste huge strings.
I’m capable of working around limitations like this, and I love doing it, but now I have a family and don’t have the time I used to have. TextBoxes are for inputting text, and it should just work, so I can move on and work on more important aspects of the project.
