Forgottenserver: [Question] Introducing more scripting languages

[pzaj2]

Hello

Just some sort of a question / enquiry. Would you consider introducing other scripting languages to work with TFS? Like python for example?

I admit I didn't look into this yet, so this is strictly a theory, but would you find it feasible to abstract the exposure of functions / objects / whatever is available in lua and thus allow writing "wrappers" (or call it however you wish to call it) for scripting languages to work with TFS. Most probably also introducing pluggable architecture for these wrappers, so you can load them based on config, working either exlusively or side by side.

The question is both theoretical (whether it would be feasible) and practical (as in, if you consider it a valuable addition).

You may ask for reasons, well, I believe this could attract people with different background, for example web developers using python for back-end, to work on scripts for TFS. Another reason, perhaps even more important from developers point of view, would be the ability to switch to another scripting language more easily (a good example here is Squirrel which seems a nice alternative, offering syntax closer to C++ and is Object-oriented) without the need to trash all currently used lua scripts.

[ranisalt]

This is pure overkill IMHO. Lua was chosen because it is light, has simple syntax and is easy to extend from the host language. Python is much harder because the syntax changes pretty frequently (e.g. last addition is async/await and type hinting) and it would he hard to catch up.

I'd also suggest JS for it's natural asynchronous style and functional stuff, but then again it's under heavy development and not yet stable, besides a steeper learning curve.

[pzaj2]

@ranisalt

Yes, I can agree both of them are under development and Lua is more mature.

Regarding Python, I've seen pretty nice examples of extending with both C and C++ and so I believe this would be no problem. Also the syntax itself is not that hard, though I can understand that changes made frequently may make it harder to catch up, then again, I did mention developers utilizing Python in web dev, meaning they need to be familiar with these changes anyway.

As for JS, yes, this was my first thought actually, considering what you already said. But if being rapidly developed is the sole factor here, then JS would be no different to Python I guess. I just wanted to notice that, as far as I know, JS is pretty much BC and I don't think this will change in near future.

Anyway, I'm really glad to see your opinion and even suggesting JS. You didn't say anything about Squirrel which seems to eliminate issues you mentioned about Python and JS. Just a little quote from their website (http://squirrel-lang.org):

Squirrel is a high level imperative, object-oriented programming language, designed to be a light-weight scripting language that fits in the size, memory bandwidth, and real-time requirements of applications like video games.

It's syntax seems to be stable enough with their focus aimed towards improving performance. I suppose that depending on requirements it may only require a subset of features to create currently used lua scripts. You know more than I do about the needs of TFS in terms of scripting, perhaps there are other things that could be done with Squirrel that are otherwise impossible / hard to do in Lua.

Anyway, once again, I really appreciate your opinion and while I believe it is wise to put your efforts towards other stuff mentioned in Roadmap, but going back to my question, perhaps I should have stated it more explicitly, would this stand a chance of being merged into TFS, considering some less and more obvious conditions / constraints:

1. Good / proper design
2. Efficient implementation
3. Compatible with currently implemented Lua scripts

Like I said above, we may not actually need any wrapper other than for Lua at this point, but it would definitely decouple it significantly, thus allow for seamless introduction of other scripting languages in the future, if you decide there's a good candidate. This would also allow for other people work on their own "wrappers" and perhaps scripters among people who are otherwise unwilling to deal with Lua for some reasons.

Also, feel free to close this issue in case you think this would never be merged anyway. Otherwise any directions / suggestions will be great. I am not sure if my C++ knowledge if sufficient to implement such things - didn't work with C++ for years now (C#, PHP, JS/Node.js are my things really), but I would be willing to give it a go - this seems to be a nice opportunity to catch up on C++ related stuff and refresh my knowledge.

[djarek]

If selecting the scripting engine was a compile-time feature, well, I might be willing to accept it. But are you really ready to rewrite ~20K SLOC ? I think that we first need the to tidy up the exsiting scripting system and then think about such features.

[pzaj2]

@djarek

Yes, I agree that rewriting part of code that significant without tidying it up makes no real sense. Perhaps these two things could be done simultaneously, which would result in neat and decoupled abstraction layer for scripting. But I suppose it could as well wait for the clean up.

Would you mind if I ask why compile-time feature would be better? Othen than being probably easier to implement. Do you think it could have significant impact on performance to make the choice on startup?

In the end I think it would be nice addition, whether compile-time feature or configurable on startup and I'm glad to see it being taken under consideration.

[djarek]

@pzaj2
The reason I believe compile-time implementation of this would be better is that the data pack isn't something you replace at whim at any time. It makes no sense to have this type of polymorphic behavior, since if the user wants to switch to different scripting language, then it's reasonable to require a recompilation of the engine. And as g++'s -flto shows, inlining can save around 20-25% in binary size in typical C++ projects. With modern processors code size heavily affects performance. Though this might not be a significant number in the case of static vs dynamic polymorphism when it comes to the scripting subsystem.

[pzaj2]

@djarek
I find your arguments convincing enough, as long as this would allow using multiple scripting engines working side by side. We do have a strong lua scripts base and I can't really think of rewriting them all just because we have a team of scripters that prefer another scripting language. Other than that, considering your arguments, I agree this should be compile-time only feature.

[ranisalt]

We shouldn't let this idea sink but it's not thinkable before, say, TFS 3.0?

[DSpeichert]

As a question, this was answered, hence I'm closing this. I doubt that we would actually see this implemented as a feature due to the time cost.