Scripting vs "Scripting"

[exectails]

When we started work on Melia, I immediately jumped at the chance to finally use a real scripting language for a server, like Lua. The reason was that, having used Ragnarok server emulators for years, I always had a soft spot for such languages. But this was an entirely subjective and kind of random choice. Lua is simple, it's fast, and designed from the ground up to be used from a host application, but I really just wanted Melia to feel a little bit more like eAthena, for nostalgia's sake. On all my other servers, I actually went a different route though.

If we are to use a scripting language, Lua is a fine choice. However, you don't necessarily need a scripting language. With .NET in particular, it's very simple to compile source code and load the assemblies at run-time. This means that you can store .cs-files in your script folder, and when the server starts, you compile them, load the assemblies, pick out the script classes, like maybe all instances of NpcScript, and then execute them, so they can do their thing. That might be setting up NPCs, creating quests, all the things you usually do in scripts.

public class TestNpcScript : NpcScript
{
	public override void Create()
	{
		SetRace(10001);
		SetName("Test");
	}

	protected override async Task OnTalk()
	{
		Msg("How are you?", Button("Good"), Button("Bad"));
		var response = await Select();

		if(response == "Good")
			Msg("Nice!");
		else
			Msg("Sucks.");
	}
}

public class TestRegionScript : GeneralScript
{
	public override void Load()
	{
		CreateSpawner("GrayWolf", amount: 20, region: 1, area: Area(6690, 20303, 13585, 25668, 16347, 22118, 9452, 16754));
		CreateSpawner("Sheep", amount: 1, region: 1, delay: 900, delayMin: 10, delayMax: 20, area: Area(6690, 20303, 13585, 25668, 16347, 22118, 9452, 16754));
	}
}

I have done this over multiple projects, over many years, and it works great. There is a big advantage in going this route, that has several interesting side effects: It's C#.

• You don't have to write an API or create specific script functions that interpret calls from the scripting environment, you simply use what you have on the script classes.
• You're directly hooked into the application, so you can do anything the core can do, without any additional work.
• You're able to easily do things that might be difficult to accomplish in a scripting language.
• There's no concern over performance or crossing the border between the core and the scripting environment, because the two are one and the same.
• The "scripts" can double as a plugin system, because you can do anything from them.
• Since the core and the scripts speak the same language, users who start by modifying simple scripts also become familiar with the language in the core, making it easier for them to understand and work with it.

But of course there are also disadvantages.

• A scripting language like Lua is usually simpler. No includes, no usings, no typing, no boilerplate code, etc. You open a file, you write print("Hello, World!"), and you're done.
• Unless you jump through a lot of hoops, there is no sandboxing. A C# script can do pretty much anything, including wreaking havoc on the server or wiping a user's machine. This is not usually the case with scripting languages, which you can put restrictions on.

I've seen users grow accustomed to C# scripting, who then went on to contributing to the core, which is pretty neat, even if the learning curve for scripting is a little higher. And it's so nice to be able to use everything that is already available in the core. Pass around characters, use core events, etc. The disadvantage of scripts not being safe could potentially be a concern, but only if Melia were to grow to a size where complete newbies might get random scripts from others and run them without a care in the world.

To me it's largely a stylistic choice. A scripting language has a certain appeal to me, and even though it means more work, I would probably keep using Lua, just because I like it. I still wanted to bring up this discussion, however, because I do think that it warrants one. There are definite advantages in using C# scripts, especially for the developers. I'm curious to hear your opinions on this topic.

[ovflowd]

Off: I was going to suggest allowing NPCs made in JavaScript for /pun sake.

You're directly hooked into the application, so you can do anything the core can do, without any additional work.

I suppose we would need to dynamically resolve namespace Imports? Or how would it work? In your snippet, there are no imports but multiple classes are being used.

The "scripts" can double as a plugin system because you can do anything from them.

I would prefer having Plugins being pre-compiled. Since their complexity is way bigger than possibly of a simple NPC... Imagine if we chose a route of all features being Plugin-based as we discussed before... That would create a bigger load during the runtime of the Emulator.

---

There's yet another big caveat of doing JIT with C#, users would need to install .NET SDK instead of just having .NET-RE (.NET Runtime)

Unless you jump through a lot of hoops, there is no sandboxing. A C# script can do pretty much anything, including wreaking havoc on the server or wiping a user's machine. This is not usually the case with scripting languages, which you can put restrictions on.

I definitely would love to Sandbox the scripts. Users might just download a "NiceBeautifulMarketLady.cs" and it actually formats the computer or installs Malware. That's why I would prefer not to allow the CS script to load namespaces, and have direct Class calls, and during the Bootstrap we inject/import the classes that should actually be available. It is important to mention (IMHO) that there are several routes of reading the CS Plugin/NPCs code:

• Eval'ing the C# code into a Sandboxed
• .NET Assembly namespace
• Other's I suppose?

---

My conclusion: I'd love to take this route. But it needs to be carefully done since it is dangerous. (With great powers comes great responsibilities).

[ovflowd]

True, but no-one could inject a malicious plugin into the main melia branch

Not really, lol.

[ovflowd]

But only the official ones, that's the point I was trying to make. A normal user might not suspect that a plugin or a script, that is running "inside" the trusted application, could also do something malicious.

I agree with that :)

which we know is complete nonsense. Not the general public though.

Completely agree :)

[exectails]

no-one could inject a malicious plugin into the main melia branch

I feel like we're talking past each other^^ Yes, it is unlikely that any malicious code will make it into the official master branch. No argument there. But one of the big things about scripts and plugins is that users can create their own and also share them.

If you will, imagine a big community around a server emulator, with dozens of active users around the clock. Let's see, there are 78 users and guests online on the rAthena forum at the the time of me writing this. Now someone posts a great looking C# script, or even worse, a closed source plugin, on the forum. What do you think how many people could download that script/plugin, put it into their server, set it running, and brick their system, before that thread is taken down? Or what if the malicious function is more sneaky, and it doesn't activate until hundreds of people are already using the script?

The worst is that even with source code you aren't entirely safe. I could easily hide a few file deletion instructions in a C# script or resource files, without you noticing them, because if I can run arbitrary code, I have unsafe code, I have the windows API, I can hide things in byte arrays or even strings, I can rewrite what the code does at runtime. It might require a few lines of code that seem kind of weird to you, but that's not something the casual user would notice or worry about.

I believe one has to acknowledge that this is a complete non-issue with Lua scripts, which are 100% sandboxed by default. Unless you allow it, a Lua script can do absolutely nothing, and even the least careful user in the world will be safe. At least from scripts.

[Adephx]

I get your point and I'm in support of lua scripts. The easier it is to maintain a project, the better. What I wanted to say is that the issue might be somewhat moot, because if people get infected by malicious code through random 3rd party plugins, they might also get infected by downloading pre-assembled server packages from said forums. I'm just not 100% if that is something that we should worry about. If we want to be 100% sure, we could always implement so that the server only runs plugins that are certified either through community or directly by us.

[exectails]

You're right, pre-compiled packages are a potential problem as well. It could be mitigated a little bit, by us providing official releases, but there is always a risk remaining. Whether we should be concerned about that, well, that's the big question. I firmly believe that we have to be aware of it, but to me, the degree by how much we bend ourselves backwards, to make sure users can't do anything stupid, is up for debate.

Honestly, certifying plugins might not be the worst idea ever. And you could always include an option to disable the check for that, in case someone doesn't care about the risks or knows that their plugins are safe. I think we should keep that idea in mind.

[exectails]

It seems like we have one vote for C# right now and one for Lua, with myself being somewhere in between. But the discussion about safety made me think that maybe we should stick with Lua. While a Lua script will never have the power of a C# script, there also won't be any concerns about safety. Additionally, Lua scripts are way easier to understand by less experienced users and are more flexible in several ways. And if we add a plugin system at some point, maybe via C# scripts, plugin developers will gain the powers they lacked before.

[exectails]

Then again, what do I care about my babbling from 2001? C# it is! Yes, Lua is safe and simple, but I just can't ignore how much more powerful and flexible C# is =/ NPCs might become a tiny bit more verbose and not quite as easy to grasp at a glance for beginners, but I'm also thinking about how rarely we will write simple NPCs in the future. Once we have a solid base, we will primarily see utility scripts being written, and those benefit heavily from full access to the core and more language features.

With that I'm going to close this discussion for now, until 2 years from now, when I change my mind again =)