Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Scripting with remote debugger?

  1. #1

    Question Scripting with remote debugger?

    Trying to figure out how to go about this:
    I need to add scripting capability to my program, script language doesn't really matter. Can be lua, Pascal Script or whatever as long as I can write scripts in decent external text editor (like Visual Studio Code) and be able to debug the scripts launched from my program.

    I know that some scripting libraries like Pascal Script or DWScript have simple debugger examples but they rely on SynEdit, are bugged and can't compare to mature modern code editor.

    Must be possible but I'm clueless

  2. #2
    I also intend on adding script support for one of my projects but unlike you I would prefer if the scripting language used is based on pascal or even better object pascal dialect. Unfortunately I also haven't found good enough solution yet.
    Also unlike you need to be able to write these scripts in-game as the scripting support will represent one of the main features of the game. So I'm afraid I might have to go and write my own code editor based on the game UI.

  3. #3
    Keep me updated on your solution, I need to do the same at some point.

  4. #4
    Managed to connect lua debugger in Visual Studio Code with my program.
    It was a major pain in the ass so here are the steps for future reference:

    0. get the debugger extension for VSC:
    https://marketplace.visualstudio.com...vCAT.lua-debug

    1. get lua 5.1 bindings from here:
    https://blog.spreendigital.de/2009/0...r-delphi-2010/
    Note that there are newer ones posted on same site for lua 5.3 but debugger works with 5.1

    2. Debugger VSC extension has some other lua libs dependencies. Tried binaries from different places and wasted whole day on it. Instead install luarocks and get dkjson and luasocket with it.

    3. Copy mentioned libraries, lua5.1,lua51 from luarocks to your programs' exe folder and overwrite dll that comes with delphi bindings.

    4. follow steps in debugger setup instructions (launch json config, add magic script lines in your client, call debbugee.poll in lua tick function called from client on timer).

    That's about it. Didn't play with it much yet but breakpoints are working, local vars can be inspected. So far so good.

  5. #5
    Never understood the point of external scripting languages in Object Pascal applications, personally. The syntax is already easier to read than almost everything else! Why not just use functionality from the compiler/RTL to execute user-written Pascal internally? Or even just distribute a binary copy of FPC and a stripped-down RTL build along with the application that you can invoke to compile user-written game project files or whatever it is you're trying to do. The overall number of "possibilities" you'd be able to expose to the user that way is a lot higher...

    Also...

    >Visual Studio Code
    >Mature Modern Code Editor

    one of these things is not like the other.
    Last edited by Akira13; 27-10-2017 at 12:54 AM.

  6. #6

  7. #7
    Quote Originally Posted by Akira13 View Post
    Never understood the point of external scripting languages in Object Pascal applications, personally. The syntax is already easier to read than almost everything else! Why not just use functionality from the compiler/RTL to execute user-written Pascal internally? Or even just distribute a binary copy of FPC and a stripped-down RTL build along with the application that you can invoke to compile user-written game project files or whatever it is you're trying to do. The overall number of "possibilities" you'd be able to expose to the user that way is a lot higher...
    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?

    Quote Originally Posted by Akira13 View Post
    Also...

    >Visual Studio Code
    >Mature Modern Code Editor

    one of these things is not like the other.
    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.

  8. #8
    Quote Originally Posted by laggyluk View Post
    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.
    Last edited by Akira13; 29-10-2017 at 01:10 AM.

  9. #9
    Quote Originally Posted by Akira13 View Post
    Take a look at LAPE:

    https://github.com/nielsAD/lape
    I will

    Quote Originally Posted by Akira13 View Post
    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.)

    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:
    Nope, it's not a game engine but evolved form of an automation tool I'm using for work with bunch of built in functionality that can be expanded with scripts. Performance doesn't matter much.
    It won't come with source code so that's why I thought about .dll weirdness

    Quote Originally Posted by Akira13 View Post
    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.
    For one thing it's not a tool for devs I'm working on and second, bunch of games is using it already for scripting.
    Last edited by laggyluk; 29-10-2017 at 01:51 PM.

  10. #10
    Well, I guess I shouldn't have assumed it was something game related you were working on as that does certainly mean a somewhat different set of requirements. I stand by what I said for anyone who actually is trying to write any kind of game engine, anyways.

    Not sure why a tool "not meant for devs" would require direct debugging functionality, though?
    Last edited by Akira13; 01-11-2017 at 10:56 PM.

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •