Scripting with remote debugger?

[Akira13]

For couple of reasons:
script editor must come with debugger - breakpoints and locals inspection. I'm not gonna use prints to debug anymore, I'm not a caveman.
must have auto complete and syntax highlight
I want script editor to look good
documentation-wise lua is lua and those pascal scripts are dialects so to speak

I didn't ruled out DWScript or PascalScript yet but my first impression when I've downloaded the repos:
PascalScript documentation link doesn't work, included in repo is a .docx file, is it 1999 again?
Example IDE with debugger relies on TSynEdit but some old branch apparently, doesn't compile, great start.

DWScript: is maintained by single person, documentation is a mess.
Half of included examples doesn't compile, also relies on TSynEdit.

I'm leaning towards Firemonkey as I need some non standard functionality like container with controls that can be zoomed in and out. There's no SynEdit for Firemonkey and I don't have time or resources to develop my own text editor hence remote debugger looks like a way to go.

I knew it was possible with lua so I've started with it.
Now I'll investigate if there are any remote debugger options for those pascals as I'm pretty sure script integration into my code would be less work than with lua.

As for shipping stripped down fpc, wouldn't that mean compiled 'sctipts' would come as dynamic loaded libraries and whole new field of problems to solve?

Well it's light, free and has all the features I need + built in versioning support. If you have better script debugging editors handy then I'm all ears.

Take a look at LAPE:

https://github.com/nielsAD/lape

It was pretty much built from the ground up to be a better version of PascalScript/TitanScript/e.t.c. It has an included "IDE" example that admittedly does require SynEdit as the others did, but I'm not really sure what the issue with that is? You're writing a library in Object Pascal to begin with. As such, the people using it are 99% likely to be using Lazarus or Delphi anyways, and are equally likely to be moderately to highly familiar with SynEdit. (Not that they need to be... it's just a text editor component! (And a good one at that.) You can simply "set it and forget it" the vast majority of the time.)

The other advantages to staying within the Pascal ecosytem are numerous: it is far closer to native code and therefore much faster (or even just actually native code if you used FPC itself) than what you'd come anywhere close to by pulling in something like Lua from a DLL. Lua is a perfectly fine language (except for its one-based-arrays...) but it's very slow and not at all designed for high-performance use. Additionally, the closer you stay to Pascal, the more maintainable your code will be from a development standpoint due to having the scripting language as a direct extension of the dev language.

All of the big game engines (CryEngine, e.t.c) that you've probably heard of using Lua were doing so in a very careful way, which basically boils down to simply using it as a "trigger" to notify various event handlers that were implemented in C++ code, or in some cases using JIT-compiled forks of it to be directly interoperable with C++. Nobody has ever "just used" Lua to directly implement their game logic in any kind of remotely noteworthy release. You would also need to figure out some kind of Pascal-based solution for that too if you wanted the engine to actually perform well.

As far as shipping FPC, I'm unsure about where you got the idea that the output would have to be dynamic libraries, but that's definitely not true. You could simply use FPC to compile real executables the same way it always does. Here's an example of a game engine that actually does use FPC to do exactly this:

https://github.com/MrDan2345/g2mp

Lastly, again, you said yourself that getting Lua to work with VS Code was a pain in the ass (which is not surprising) and you're someone who already uses VS Code. However, it's really not realistic to assume that most if any of the people who might seek out and attempt to use an Object Pascal game engine will have ever used VS Code. The real Visual Studio? Different story. I myself use it all the time as I also code C++ and C# at work when I'm not maintaining Delphi projects. The general attitude towards VS Code, however, amongst most developers above the age of 22 to 25 or so that I've ever met seems to be "lol Electron", which is not exactly undeserved.