The base protocol was implemented using pascal "short" strings which are 255 characters in length. When pascal says short, they really mean short. Just one byte was allocated to length. If it had been 2, you would not have this issue.
This is why things like Wuzzy's hacks script have both long and compact script param representations.

This restriction on parameter length can probably be lifted once the engine rewrite in rust is completed.

Well, it could be lifted now by using variable length strings but it'd be a signficant rework.

Maybe you could describe a bit more about your project and we could possibly come up with workarounds.

The base protocol ... If it had been 2, you would not have this issue.
⠀⠀⠀That is very unfortunate, especially for me. Although, why does it have to be a short string?

This is why things like Wuzzy's hacks script have both long and compact script param representations.
⠀⠀⠀Sadly, my project can't have the luxury of compacting the params. Most of them are literals, in full length because of the requirement itself - The engine needs it that way, like for say params for the file name, file path, or Global variables. Simply put, shortening the params can't be the solution.

This restriction on parameter length can probably be lifted once the engine rewrite in rust is completed.
⠀⠀⠀Is it... Is it soon, or is it Hedgewars soon - far in the future? I don't know anything about it fyi.

Well, it could be lifted now by using variable length strings but it'd be a signficant rework.
⠀⠀⠀I'm really curious at what makes it sound like a big rock that can't simply be moved, which isn't like what I've imagined. Is it hard-tied to the engine or something?

Maybe you could describe a bit more about your project and we could possibly come up with workarounds.
⠀⠀⠀To be honest, I don't want to spoil anything about it, hence the redaction above. But I think I can say that, hmmm...

⠀⠀⠀My project can combine scripts - any scripts, any number of scripts, seamlessly. New or old, they'll just work - except if there's major contradictions between them. Now just imagine the implication of customizability when an original script is combined with modding libraries. Let's just say that it'll be endless.
⠀⠀⠀⠀⠀⠀[REDACTED]

⠀⠀⠀I can't really say much about it, but it's not a bs. Tiotimolina said that it would be either a mad or gen--- concept, S.D as I quoted said that it sounds crazy, and KoBeWi said that it would be impossible... Well, I proudly say that it is possible. In fact, it'd be "truly" completed if this issue didn't come and stand against it.
⠀⠀⠀Well, that is about it. With that, I can't see any workaround other than removing the limitation or adding a new open dialog box for entering a script param in an easier manner. Or an unorthodox way in making it possible, like say, a new param system for an advanced user, or something, idk...
⠀⠀⠀

---

⠀⠀⠀
Nevertheless, I really appreciate the response, and now I'll be looking forward to the next. I'd wait for further explanations, solutions, or stuff, whichever. Anyway, thank you nemo.

The network protocol expects short strings in its processing.
Rewriting that could easily cause breakage/desyncs, so it's a significant rework. Putting the effort into the rust rework seems more useful.

Could you offer more detail as to what you're trying to do with all those files and such? Perhaps alternatives can be found.

⠀⠀⠀⠀⠀⠀Could you offer more detail as to what you're trying to do with all those files and such? Perhaps alternatives can be found.
⠀⠀⠀They're going to be loaded, and the param is the listing medium because it doesn't cause desync upon modification (I assumed, as there's no testing has been done yet due to this and other issues).
⠀
⠀
⠀
⠀⠀⠀So the question would be: How long is the ETA for the so-called rework and to essentially fix this problem? Should I wait another year or something? I would like to know the approximation rather than the usual blind-wait I/we usually do.

There's no ETA. In open-source projects feature/bugfix is there if someone contributes it. It might happen today or in 5 years.

I don't like the limit on script parameter either, and yes, I think it is stupidly low.

But I really don't think it's “IMPORTANT”. It's obviously important to you, but probably not to most players.
If your script is so complex that it requires more than 250 chars of script parameter, that might be a sign that we need to extend the engine instead. Depends on what you are trying to do.

Heck, even my own script “Game Hacks” can exceed this limit, even in the short form, if you change like all the settings. But this script is actually a workaround about that many settings that are not exposed in the GUI yet. Most of the stuff in Game Hacks is stuff that ought to be configurable already.

Frankly, it's unlikely I will touch this anytime soon. First of all, I'm currently inactive. Second of all, I have other plans for future versions, like extending singleplayer significantly. Something which I wanted to improve for a long time. And the other devs obviously don't care enough about this feature as well, otherwise they would have already done it.

However, I am convinced that increasing the character limit is totally possible *without* a full rewrite. It might be easier to change than I think it is (or not), but either way it's rather low on my priority list.

What actually concerns me much, much more about the script parameter is its usability. Currently, players are expected (without telling them) to just “know” how the script parameter works and find the wiki. And they have to work out this syntax somehow. It's very user-unfriendly. But ideally, all this syntax stuff is abstracted away behind a nice GUI so you don't have to look up the wiki (or worse, the .lua file) every time.

And I think the scheme editing menus need a rework anyway, they aren't the user-friendliest.

Anyway, I don't even know what your plans with your script are. What are you trying to do that you can't do due to the character limit?
It might also help if you just show actual code.