Thank you very much for everything it's nice phi update
Thank you very much for everything it's nice phi update
You're welcome @CapitaineCaverne ! Support the Patreon if you're able.
Bluewing Client updated to build 91.
b88: Updated DarkEdif SDK to v2 (better update notifs/fixed editor display).
b89: Added event numbers to error messages. Fixed crash on error, introduced in b87. Updated DarkEdif SDK to v4.
b90: Fixes float expressions' return values when a sub-expression is called on the same object in the same expression evaluation. Updated DarkEdif SDK to v5.
b91: Fixed occasional lock timeout and Msg Box Death popup when a connected Client running in multithreaded was quit. DarkEdif SDK now v6.
Bluewing Server updated to build 23.
b21: Fixed event numbers in error messages in Fusion 2.0. Fixed crash on error, introduced in b19. Updated DarkEdif SDK to v4.
b22: Fixes float expressions' return values when a sub-expression is called on the same object in the same expression evaluation. Updated DarkEdif SDK to v5.
b23: Close made somewhat safer, by adding the lock protection around handlers reset in close, akin to b91 Client update. Chance of it being more stable when closing. DarkEdif SDK now v6.
Both extensions have an update detector! This detector has more details and you can change settings following the instructions here.
These update checks run once on Fusion start, and the update notification will happen once an object is loaded or created in frame.
For support, tips and bug reports, contact me on Clickteam Discord.
The C++ server is still available (with pre-compiled binaries), as are the extension sources on GitHub.[/QUOTE]
Bluewing Client updated to build 92.
b90: Fixes float expressions' return values when a sub-expression is called on the same object in the same expression evaluation. Updated DarkEdif SDK to v5.
b91: Fixed occasional lock timeout and Msg Box Death popup when a connected Client running in multithreaded was quit. DarkEdif SDK now v6.
b92: Fixed app going Not Responding related to peer events. Fixed long delay after app quit before app closed in some scenarios.
Bluewing Server updated to build 24.
b21: Fixed event numbers in error messages in Fusion 2.0. Fixed crash on error, introduced in b19. Updated DarkEdif SDK to v4.
b22: Fixes float expressions' return values when a sub-expression is called on the same object in the same expression evaluation. Updated DarkEdif SDK to v5.
b23: Close made somewhat safer, by adding the lock protection around handlers reset in close, akin to b91 Client update. Chance of it being more stable when closing. DarkEdif SDK now v6.
b24: Fixed crash creating a channel with no master.
Both extensions have an update detector! This detector has more details and you can change settings following the instructions here.
These update checks run once on Fusion start, and the update notification will happen once an object is loaded or created in frame.
For support, tips and bug reports, contact me on Clickteam Discord.
The C++ server is still available (with pre-compiled binaries), as are the extension sources on GitHub.
Bluewing Client updated to build 93.
b90: Fixes float expressions' return values when a sub-expression is called on the same object in the same expression evaluation. Updated DarkEdif SDK to v5.
b91: Fixed closing for multithreaded client which was still connected, causing a slow shutdown and an emergency popup. Updated DarkEdif SDK to v6.
b92: Fixed Not Responding related to peer connections/disconnections in multithreaded mode. Fixed long wait during application quit before the app closed (max 3 seconds).
b93: Final ANSI build! Very minor performance enhancement with named loops.
Bluewing Server updated to build 25.
b22: Fixes float expressions' return values when a sub-expression is called on the same object in the same expression evaluation. Updated DarkEdif SDK to v5.
b23: Fixed write lock around handler reset/unhost ops in cleanup. This may not have been a problem, it just echoes Client's b91 fix. Updated DarkEdif SDK to v6.
b24: Fixed crash when a channel was created without a master.
b25: Final ANSI build! Allows servers to know if client was kicked due to corrupt messages. Added write lock around setting welcome message.
Both extensions have an update detector! This detector has more details and you can change settings following the instructions here.
These update checks run once on Fusion start, and the update notification will happen once an object is loaded or created in frame.
For support, tips and bug reports, contact me on Clickteam Discord.
The C++ server is still available (with pre-compiled binaries), as are the extension sources on GitHub.
just started using bluewing in a new project and wish I had checked it out sooner! thanks Phi.
@Phi thank you for your hard work with Bluewing!
Do you have any idea of the capabilities of Lacewing Blue Server?
Thank you! Sponsor the Patreon if you're able!Originally Posted by Ls2
Software wise, the protocol is capped to 65535 players and channels.
Message wise, as many messages as your app/server machine can process. TL;DR: Hardware speed is the cap, really. You can optimise it.
For more details, this is where it gets a little complicated.
In multi-threaded mode, a second thread is ran on C++ side, called the Lacewing processing thread.
The Lacewing processing thread auto-handles most of the messages it gets by default, without waiting for Fusion's event thread; for example, peer -> channel messages are received and sent on without pause. This is why there are auto-approve/auto-deny choices under Blue Server > Enable/disable conditions; that way if someone requests to set their name, it can be replied to with yes or a deny reason instantly by the C++ side.
If the Lacewing processing thread ever needs to talk to Fusion - e.g. see if events deny a name set - then the Lacewing processing thread locks the pending event queue and adds a new event to the queue, then unlocks.
Every frame tick (every FPS), the Fusion app locks the queue and triggers the first event, and if set to "wait for Fusion", replies to the client after the event processing finishes. It repeats this to remove X events from queue (currently X=10, but easily adjusted).
In single-threaded mode, the same Lacewing event handling happens, but instead the usual Lacewing processing happens in Fusion's thread every FPS, including the C++ auto-responses. So auto-approve/auto-deny is still faster as Fusion events aren't being triggered and processed, but stuff Fusion has nothing to do with, like processing pings, are also part of the processing on Fusion thread, so it will cause more slowdown for the app.
The server will create an error if you exceed X pending events repeatedly and the server is falling behind.
I've done some performance test on an older, slower version, here.
As far as stability, my Windows pure-C++ server has stayed up for months on end.
Here's a screenshot I took yesterday. It's serving 90 clients at the moment, 5k messages in/4k out, per second, and using 1.7% CPU. Most of that slowdown is from just displaying stats and messages on the console window.
As far as Client, I accidentally left a client connected 24 hours ago, and it's still connected. Most of the reason people are getting disconnected in new apps, is they're using single-threaded mode client and switch away from their app, so Fusion thread ticking pauses, so Lacewing Client processing pauses, so the server pings the client which doesn't process the ping, then server kicks them. You turn on "run while minimized/resizing" in app properties to keep Fusion thread ticking active when app is not in focus.
Thank you for all those valuable information, Phi!
So can I make my own server using the Lacewing Blue Server in order to serve a small game with ~1000 players? I don't know nothing about C++, so using the LBS object sounds a good option to meor is a better idea setup a server in some VPS?
Is there any .mfa with a basic server to be used as example?
Bluewing Client updated to build 94.
b92: Fixed Not Responding related to peer connections/disconnections in multithreaded mode. Fixed long wait during application quit before the app closed (max 3 seconds).
b93:Final ANSI build!Very minor performance enhancement with named loops.
b94: Final ANSI build! Fixed a bug with peer name changing condition not triggering.
Both extensions have an update detector! This detector has more details and you can change settings following the instructions here.
These update checks run once on Fusion start, and the update notification will happen once an object is loaded or created in frame.
For support, tips and bug reports, contact me on Clickteam Discord.
The C++ server is still available (with pre-compiled binaries), as are the extension sources on GitHub.
LBS will suffice, but Fusion runtime around it will add some overhead. The more the Fusion app listens to/interacts with the LBS, the slower it will run, as I described in my last post. Multithreading will also increase speed. You can exclude Fusion's overhead entirely if you use the pure-C++ version.So can I make my own server using the Lacewing Blue Server in order to serve a small game with ~1000 players? I don't know nothing about C++, so using the LBS object sounds a good option to me
For tips on speed, and how to set up so it's internet-accessible, see the Bluewing server thread.
Outside of that, you won't really know how it fares until you try.
Since everyone subbed to this thread will be messaged, it's better if you ask for support and capability questions on Clickteam Discord.
Posting Permissions
Reply With Quote