[Suggestion] HTTP module

[EK.IceFlake]

I suggest you make some kind of HTTP module using Curl and Websocket++ or something. It'd be very useful for, for example, Discord integrations. The one I had (with the official squirrel module) used 2 text files for communicating with a node.js discord bot which must be run seperately.

[.]

I actually did have several attempts here. The problems that I've encountered are centered around multi-threading. Because Squirrel is not a thread-safe language. And most networking libraries are multi-threaded because they need to be non-blocking.
Second: In order to overcome that issue and not affect the game-server performance by, let's say a blocking web-server/client, you'd have to start it in a separate thread. However, the problem that I can't seem to figure out here temporarily is the huge amount of context switches between threads when you have to interact with the network connection. Because you're in the main thread and the connection is in another one. So the locking required to communicate with will make your code run like crap.

And there may be way's to work-around this but then you'll have to remember that I'm dependent on the server frame-rate and also the fact that they would be two separate plugins. Which get's even more annoying. And you'll want to avoid a blocking connection at all costs in the context of a game-server.

I have thought of several approaches and I have tried several implementations. But they all looked horrible so I've discarded them. This is a pending feature that I keep circling back and forth for a proper implementation.

[EK.IceFlake]

I actually did have several attempts here. The problems that I've encountered are centered around multi-threading. Because Squirrel is not a thread-safe language. And most networking libraries are multi-threaded because they need to be non-blocking.
Second: In order to overcome that issue and not affect the game-server performance by, let's say a blocking web-server/client, you'd have to start it in a separate thread. However, the problem that I can't seem to figure out here temporarily is the huge amount of context switches between threads when you have to interact with the network connection. Because you're in the main thread and the connection is in another one. So the locking required to communicate with will make your code run like crap.

And there may be way's to work-around this but then you'll have to remember that I'm dependent on the server frame-rate and also the fact that they would be two separate plugins. Which get's even more annoying. And you'll want to avoid a blocking connection at all costs in the context of a game-server.

I have thought of several approaches and I have tried several implementations. But they all looked horrible so I've discarded them. This is a pending feature that I keep circling back and forth for a proper implementation.

You can look for some inspiration in node.js's event loop.

[KAKAN]

I actually did have several attempts here. The problems that I've encountered are centered around multi-threading. Because Squirrel is not a thread-safe language. And most networking libraries are multi-threaded because they need to be non-blocking.
Second: In order to overcome that issue and not affect the game-server performance by, let's say a blocking web-server/client, you'd have to start it in a separate thread. However, the problem that I can't seem to figure out here temporarily is the huge amount of context switches between threads when you have to interact with the network connection. Because you're in the main thread and the connection is in another one. So the locking required to communicate with will make your code run like crap.

And there may be way's to work-around this but then you'll have to remember that I'm dependent on the server frame-rate and also the fact that they would be two separate plugins. Which get's even more annoying. And you'll want to avoid a blocking connection at all costs in the context of a game-server.

I have thought of several approaches and I have tried several implementations. But they all looked horrible so I've discarded them. This is a pending feature that I keep circling back and forth for a proper implementation.

You can look for some inspiration in node.js's event loop.

And you think that would stop it? Event loop is pretty useless here. Think about it again.
Possibly libuv can help, but as far as I know, it uses threads too and SLC can't sue it in his plugin.

[.]

Node.js is also multi-threaded. And the reason I want to avoid a blocking implementation is because if I were to, let's say, flood your connection enough to increase the time it takes the game-server to wait and process all that useless information. Then I just introduced a weakness that can be used by people to lag your server without even playing on it.

I did try several approaches. But they look ugly and after I tried to revise the whole plugin to make it cleaner I got into a point where the overwhelming amount of code that had to be adjusted was too much and I simply didn't bothered about it anymore. People didn't had any interest in the plugin and lately they're loosing their interest into the game. So there wasn't too much of an incentive for me to resume my work on the revised version.

[KAKAN]

Node.js is also multi-threaded.

^

Node.js is also multi-threaded. And the reason I want to avoid a blocking implementation is because if I were to, let's say, flood your connection enough to increase the time it takes the game-server to wait and process all that useless information. Then I just introduced a weakness that can be used by people to lag your server without even playing on it.

What about libuv,. that can manage the threads by itself so you don't need to do it, right? It might help I don't know for sure though( never used C/++ that much )

[EK.IceFlake]

Node.js is also multi-threaded.

Code execution is still handled on a single thread.

You could try something like this:

Code Select Expand

local connection = HTTPRequest("bing.com");
connection.SetHeader("user-agent", "SLCHTTP/1.0");
connection.OnData.Connect(function (data)
{
//...
});
connection.Send();

[KAKAN]

oh man, can't you really understand that thing? That's just what he doesn't want.
Squirrel is synchronous in nature, if that code is executed, then every player will lag until the data is received.
So, its doing something like this:

Code Select Expand

player-on-chat:
while(true){};
That condition will stay true until the data is received.
Now suppose, its for 5 seconds, then that message would appear after 5 seconds, and during that 5 seconds, chat or heck the players won't be synced because the server is busy in doing something else.

[EK.IceFlake]

oh man, can't you really understand that thing? That's just what he doesn't want.
Squirrel is synchronous in nature, if that code is executed, then every player will lag until the data is received.
So, its doing something like this:

Code Select Expand

player-on-chat:
while(true){};
That condition will stay true until the data is received.
Now suppose, its for 5 seconds, then that message would appear after 5 seconds, and during that 5 seconds, chat or heck the players won't be synced because the server is busy in doing something else.

How then do client streams work?
Events, right?
Exactly.

[Thijn]

oh man, can't you really understand that thing? That's just what he doesn't want.
Squirrel is synchronous in nature, if that code is executed, then every player will lag until the data is received.
So, its doing something like this:

Code Select Expand

player-on-chat:
while(true){};
That condition will stay true until the data is received.
Now suppose, its for 5 seconds, then that message would appear after 5 seconds, and during that 5 seconds, chat or heck the players won't be synced because the server is busy in doing something else.

Then you didn't understand his code. A callback function is fired when the separate thread where the request is being done is finished, so there will be no blocking.

It's just like the sockets implementation of the official plugin.

[maxorator]

I would actually be interested to see wider adoption of the Java plugin. Although very limited, communication between plugins is also possible, so it could just be built on top of existing Squirrel code. With Squirrel there's an endless need for different modules to implement things for which there are dozens of libraries already available in Java. In terms of performance it would also make much more sense.

As for the original reason this was mentioned for, I'd be glad to make a sample Java project for Discord integration, it should actually be pretty simple with the libraries currently available.

[.]

Pretty sure everyone would love Java as a scripting environment. Especially me. Strongly typed? Good OOP? JIT? Plethora of existing libraries? Gawd, I'd kill for those. The problem though is the learning curve. With Squirrel, it's simple. You just drop the plugin and that's it. With Java... not so much. Some day though. Who knows.

[EK.IceFlake]

Java is popular so it has more libraries. It has more libraries so it gets more popular. It gets more popular so it has more libraries. It has more libraries so it gets more popular.
Squirrel isn't popular so it doesn't have many libraries. It doesn't have many libraries so it doesn't get much popular. It doesn't get much popular so it doesn't have many libraries. It doesn't have many libraries so it doesn't get more popular.

Somewhere, somehow, we have to inject something in the middle of Squirrel's loop. Which means either making it more popular or making more libraries for it.

As for static typing, I'd always go for dynamically typed languages if I can. It's always much easier to implement things in dynamic languages, especially parsers or VMs.

JIT might be a good point, but if Squirrel gets popular, I reckon we'd have a new version of it with JIT.

[maxorator]

It takes a great amount of force to get a large community involved in developing a language. Squirrel has no chance. It was not even originally designed to be particularly efficient or extensible (apart from interfacing with whatever you script with it). If you look at the recent languages which have enjoyed moderate success in at least the hobbyist community (Rust, Go, etc), then you see that no one really started using them until they were incredibly efficient. And they had their technical niche, which is why they were started in the first place. To reach this point where people even started considering them, it took hundreds of man-months of work and the backing of large corporations.

From the technical side, Squirrel has nothing going for it that would make it appealing for further development. Its only commercial use is in use cases where performance does not matter (since it will never be a bottleneck) and libraries for the language itself aren't needed at all. Combine that with the fact that the language is not self-sufficient - you can't really write the libraries in Squirrel itself, mostly because of performance.

[KAKAN]

Off topic:

As for static typing, I'd always go for dynamically typed languages if I can. It's always much easier to implement things in dynamic languages

I'll​ say that I like the idea of not talking to you. Guess a personal preference.
I love statically typed languages, I'm not so well with handling errors in JavaScript. That's just what makes me hate JS and live TS.

Java, yeah, that's much more better. Unfortunately, if someone releases a script with Java, only a few members from this forum can only use it, and needless to say, most of them don't like running VCMP servers