UnknownMurder Posted May 3, 2020 Posted May 3, 2020 So, we have NTSL2 programming language that is barely understandable and barebones. There are also no guidelines or understanding of how do "programming" and how to apply "programming" on the computer. Can we switch it over to Java, C#, or Python related programming and make it be able to interact with game environment?
Caelphon Posted May 3, 2020 Posted May 3, 2020 +1 I suck at NTSL2, but Java I actually know my way around. I'd imagine there would be security concerns, however.
Karolis2011 Posted May 3, 2020 Posted May 3, 2020 +1 I from the start of NTSL2+ - I hated it. It's hacked together language server code and it's awful obscure sintax that has guide, but experimenting with it and trying out your scripts while not in server is just awful experience. While I was still moddev I was starting to work on NTSL3 language server, but it didn't go far. You can checkout live demo of it's sintax and capabilities, currently it's based on JS. https://limitless-citadel-57623.herokuapp.com/
Skull132 Posted May 3, 2020 Posted May 3, 2020 The short answer is: no, we cannot. The long answer is as follows: All of the languages you listed are impossible to sandbox safely. And they need to be sandboxed, because they'll be running potentially malicious code. The only language that I've found where sandboxing to the required extent looks reasonable is Lua.
sonicgotnuked Posted May 3, 2020 Posted May 3, 2020 The syntax exsists for most functions. The wiki doesn't really explain anything though and there's not formatting compile errors.
TehFlaminTaco Posted May 3, 2020 Posted May 3, 2020 An option which I don't fully recommend is setting up LLVM. This would have the same level of security as we could control action speed and it would be in a nice little box. Plus it would be a language (languages) people understand. The down side is that that would mean implementing scalable VMs for a 2dspessmens game, and it's just as hard to test code, if a little easier.
Skull132 Posted May 3, 2020 Posted May 3, 2020 LLVM is a dumbass idea. I discussed this issue with Moondancer back in uh, December, a lot. And we did a bit of research. I do agree that any custom language will have the issue of documentation. But there are a great few butt's here. So lemme condense the analysis we did during that exchange. First, regarding documentation. I will thoroughly agree that any language needs good documentation, and that if we do not have it, we're fucked. This is actually something the original NTSL suffered from greatly: there wasn't any good documentation, just a tonne of example codes anyone could copy-paste. In my view, there's 3 things that need to be documented for any language that gets implemented as a replacement for NTSL(.*): language syntax, standard library, custom interfaces. Using an already existent language takes care of 1, since the syntax is expected to be documented in that case. 2 will also likely be largely taken care of, though we'd likely have to document what limitations we've applied. 3 is a "No" in both cases. So let's go look at the documentation for NTSL2, and see how many boxes we can tick off. 1 is there, 2 is there (actually surprisingly well done). What's missing is 3. There's absolutely nothing describing how the fuck this language interfaces with things like TComms or ICs. Replacing this language with something else does not inherently land us in a better place on this front. Next up, security! Security comes in two aspects: server security and clientside security. Both were a fuck in the case of the original NTSL. With the culmination of NTSL being bitcoin miners running on the server clients. However, this threat will remain with any of the languages implemented, since this is inherent to the implementation of the language's front-end(s), and not the language itself. The other, more pressing (to me) matter is server-side security. If someone gains access to run IO functions on our server, then we're all in for a treat. Secondary concerns are interpreter lock-up and OOM (though since we use docker for the interpreter currently, this isn't that large of a concern). This is also where the research by myself and Moondancer comes in. A lot of the languages listed above are not sandboxable. Embeddable Python interpreter README's literally say, "Do not use this to run untrusted scripts, it will not end well." Same for most JS engines that we looked at. The best we could find was a few Lua interpreters, but even they had warnings. Server-side security is one of the places where a custom language actually offers the best benefits: if it's implemented in a higher level language that handles garbage collection and the rest, then sandboxing it is a simple matter of simply never ever giving it access to IO functionality. And you'll be ahead of most other embedded interpreters on that front, since sandboxing those typically requires maintaining a blacklist or other similar solutions. Another consideration is developer bus-factor. Well, this is gonna remain high no matter what, probably. The project of creating an interpreter is one which requires a high degree of technical aptitude and while we do have a list of people who possess that aptitude, it is unlikely that more than 1 person invests themselves in this project unless needed. So going with anything else would really only replace "Look at and figure out Taco's shit-code" with "Look at and figure out X's shit-code". No real gain to be had here either way. So, to summarize. We have the issue of documentation to solve, the issue of server-side security, client-side security, and maintainability. Before we go down the path of implementing yet another interpreter, we should take stock of what the current one actually does well, and figure out what the new one would do better, without sacrificing what we've already done well. Also, the specific solution we're looking for is an embedded sandboxed interpreted language. Anything heavier than Python (Java, C#) is a fucking "No", anything that requires multistage compilation is a "No"; classes are not a requirement, etc.
Skull132 Posted May 3, 2020 Posted May 3, 2020 What I'd ultimately like is for all parties interested to contribute to the same project, whatever that may be.
UnknownMurder Posted May 5, 2020 Author Posted May 5, 2020 (edited) I'm interested in contributing to whatever it may be as well. I doubt anyone is willingly to use NTSL2 Interpreter without a documentation. The real deal question I have in hand is: What is it that we're going to implement and how are we going to do this? I've come up with one known method that I am capable of doing. Go over the documentation. Make clear examples and hope it piques someone's interests. Place a documentation book in Library and Research. Figure out how it can relate to jobs. How to sandbox and figure out we're going to embed a programming language into a console is beyond me without the program crashing. On the other note. An interesting read up related to this suggestion. A programmer colleague showed it to me just before I opened this suggestion thread to read more responses. (I know we have a documentation at hand for NTSL2.) https://blog.codinghorror.com/if-it-isnt-documented-it-doesnt-exist/ Double Edit: Just saw the recent messages in #code_dungeon. I feel left out now. Edited May 5, 2020 by UnknownMurder :(
Skull132 Posted May 10, 2020 Posted May 10, 2020 On 05/05/2020 at 03:54, UnknownMurder said: Double Edit: Just saw the recent messages in #code_dungeon. I feel left out now. The magic of open source. You're free to join in. Could start by pinging Taco.
Recommended Posts