Messagerie
-
Salut, oui tu peux trouver Mario Sorb ici: https://lecomptoirduclickeur.fr/game/2019-10-08-22-06-super-mario-sorbXenon3K - 20/09/2024 14:15:26 -
Quelques jeux ici également: http://sscompf.free.fr/Xenon3K - 20/09/2024 14:16:54
-
Merci Xenon j'espère que ça va bien depuis le temps ^^burnedsoul - 20/09/2024 20:49:04 -
Le premier lien est down sur le comptoir mais je vais voir sur ssc ;)burnedsoul - 20/09/2024 20:49:30
Bluewing (extension pour jeux en réseau ou autre)
Bonjour
gros mis a jour de Lacewing Blue Client passe en b70 et avec nous avons en prime la première édition publique du serveur (Lacewing Blue Server b4)
le lien de Téléchargement de Lacewing Blue Client b70
le lien de Téléchargement de Lacewing Blue Server b4
gros mis a jour de Lacewing Blue Client passe en b70 et avec nous avons en prime la première édition publique du serveur (Lacewing Blue Server b4)
le lien de Téléchargement de Lacewing Blue Client b70le lien de Téléchargement de Lacewing Blue Server b4
Bonjour voila plus info sur 
Lacewing Blue Server
[quote]
Lacewing Blue Server, or Bluewing Server, is a port of Lacewing Relay Server, which enables multiplayer games to be made in Fusion, and for Fusion applications to communicate with each other via the internet or LAN. This first release is build 4.
Why this was made:
The project was paid for by "the god of snake". He requested a HTML5 version of Lacewing Blue Client. I couldn't do that initially as it requires a server with HTML5 WebSocket support, so I needed to make Bluewing Server so I could add WebSocket support alongside regular Lacewing.
Unfortunately, after the regular Lacewing part of the server was finished, before HTML5 was added, the sponsor cancelled the HTML5 project, as he'd decided to switch to non-Fusion HTML5.
So the current Bluewing Server supports Windows, Android and Flash clients. I can later modify it to add HTML5, but I'm not doing that without funding. Bills to pay, kids to throw money at, etc.
Like Lacewing Blue Client, the new Blue Server uses liblacewing 0.5.4 (final) instead of 0.3.0.
The source code will be withheld from public release for a while as per the sponsor's request, then it'd be on GitHub alongside the client. (The current server code on GitHub is the code as it was before he funded it, and very not usable).
Once the source code is released, presuming you know C++, you could make a custom server outside of Fusion to get full C++ speed without Fusion's overhead. I'm using such a system on Darkwire Server I now.
Notable facts about this server:
Lacewing Relay Client and Lacewing Blue Client can both connect and exchange messages with each other on this server.
The server supports Windows, Android and Flash clients. (Note that Flash as a whole does not support Blast/UDP, so you still can't use that.) Flash uses raw sockets but requires a policy file to be sent before it allows it, and that part of liblacewing hadn't changed, so although the sponsor didn't need it, it was minimal effort to implement.
Multithreading is not implemented fully. Between the clients doing something, the server doing something, and Fusion doing something, it became out of sync very quickly. For that reason I've disabled that functionality. Single-threaded can still be extremely fast if Enable Conditions is used properly.
I've changed the "Enable conditions" menu. You now have five modes you can handle say, a channel join:
Auto-approve and don't tell Fusion (instant)
Auto-deny and don't tell Fusion (instant)
Auto-approve and tell Fusion (slower, use for logging)
Auto-deny and tell Fusion (slower, use for logging)
Wait for Fusion events to approve/deny (slowest, use when events must dictate approve/deny)
If 1 through 4 are used, then Bluewing Server instantly responds to the client with the OK or NO response.
If 2 or 3 are used, Fusion events will trigger but have the deny reason and such already set.
Attempting to deny with 2 or 3 would create an error and do nothing. If you want to deny something already auto-approved, try to find the opposite - e.g. for channel join, it's making the client leave.
If 5 is used, the client gets no response from Bluewing, the message's data is queued like with 2-3, and the Bluewing extension moves onto the next message.
Once Fusion eventually processes it (dependent on application framerate, which is dependent on machine speed), then the client will get an OK or NO response.
This introduces delay, naturally - an extension running on 60fps has at least 0.016s between frames. With Bluewing having to process a lot of messages, that delay increases.
For best performance:
You should use Enable Condition modes 1 or 2 by default.
Only inform Fusion for events you need to log (modes 3 or 4).
Never use mode 5 unless it's absolutely required.
You should not listen to client/channel messages (modes 3-5), as it will delay the messages, and introducing a delay with UDP messages can make an extremely painful movement lag on games that use it.
You should increase the application framerate to decrease processing between messages, and thus decrease ping and response times. That's in application properties under the 3rd tab (Runtime options).
You can increase it up to 1000, but note the higher it is, the more CPU your Fusion server program will use.
For what it's worth, some mode performance comparisons:
I had a Fusion app that had Rich Text and such "heavy" displaying objects on it.
The app would do nothing when it received a channel message. The conditions were still triggered by the extension, but no events were in the MFA with those conditions so Bluewing would trigger it, get no deny, and thus approve and respond to it.
The server was set to run at 1000fps (max).
Meanwhile, 20 clients each sending 5 channel messages per second were running.
That's 100 messages in, 1900 messages out per second.
• Fusion events approve all channel messages (Mode 5):
Result: 50fps
• Auto-approved, Fusion events triggered (Mode 3):
Result: 80fps
• Auto-approved, Fusion not told (Mode 1):
Result: 400fps
• I later used 50 clients under same environment with mode 1:
250 messages in, 12,250 messages out per second
Result: 170fps
These numbers are probably lower than actual results, as I had to run all the clients on the same machine that the server was running on, so they were probably using resources. But, the server machine was a high-spec desktop machine (what I use for Darkwire Server I), so that gives some sort of balance.
Exposing the server machine for connections:
There are three parts to this:
1) Allow access through server machine firewall (LAN or Internet access)
For both Internet and LAN, make sure the firewall on the server machine is not blocking it. Add it to Windows Firewall and any antivirus firewalls you have.
For LAN, steps 2 and 3, for port forwarding and ISP firewall checks, are not necessary.
2) Allow access through router (Internet only)
If you're making an internet-accessible server, you'll need to use port forwarding on your router for TCP and UDP on the correct port, which is normally 6121.
You should also port-forward ports 843 & 583 TCP if you're hosting Flash.
3) Allow access through ISP firewall (Internet only)
This step depends on your ISP having extra security measures, and may not be necessary. If you've followed step 2 for port forwarding and Internet clients still can't connect, you'll need to access your ISP settings for firewall. Your best bet is to google your specific ISP port forward instructions (e.g. AT&T, Verizon, PlusNet, etc).
Connecting to your server:
Connect to the server with Lacewing Relay Client or Lacewing Blue Client extensions.
Clients on LAN should use your server's local IP to connect, which you can get via ipconfig or the Fusion LocalIP or LocalIP++ extensions.
Internet clients can then connect via your remote IP from this link. You can also use it for LAN clients, but that will result in a slower connection.
If the server is on the same machine as the client, use "localhost" or "127.0.0.1" as the IP for the client to connect to.
If you host on 6121 (default), Lacewing will add the port for you. If you use a different one, add ":newport" to the connect-to address. So for port 6150 you'd use "localhost:6150", "betsysawsumserver.legitsite.com:6150" for example.
For non-Lacewing clients trying to connect:
The server mercilessly disconnects clients that don't follow Lacewing protocol. I had one plank trying to access the Lacewing server with a HTTP web browser and it was crashing things.
An error will also be made in this case, but note there's no client you can select in Fusion for that type of error, as without sending a Lacewing Connect Request message, you don't get On Connect triggered on the server. As such Fusion has no client it can select and mess about with. The IP of the booted non-Lacewing client will be in the error message, though.
Other notes:
Firstly, you should, of course, always have an On Error event in your server application. Without it, you won't be told about any internal errors or things your Fusion server app is doing wrong.
Typically, these are not fatal errors; e.g. if the master were to leave a channel with autoclose enabled, so other clients will be booted, you may get an error if there's a channel message sent from another client that now can't be delivered. They're worth listening to.
Secondly, the server will also handle generic server problems without you needing to worry about it. For example, a client trying to set its name to one that another client is already using will get a NO and a deny reason "name already used" sent back from Bluewing automatically, without Fusion coming into play. Don't write events that cover these sort of cases as it's totally unnecessary.
Thirdly, if you're tempted to use mode 5, you should only do that if you need the server to run events every time for deciding whether it's okay for approving it. If the server just has a "allow/deny" checkbox in the UI, you'd be better off switching the mode of handling when the checkbox is changed, and setting the deny reason as appropriate.
Fourthly, a server that has 5 clients on a channel and gets a channel message will need to forward four copies of that message. For this reason, the server machine's upload bandwidth will need to be higher than your download bandwidth.
Fifthly, this server's actions, conditions, and expression IDs match up Lacewing Relay Server. Theoretically, you could replace the Lacewing Relay Server MFX with the corresponding one from Lacewing Blue Server.
Sixthly, while this server comes with a help file, it doesn't have any details for Blue Server. The guide for Relay Server should be sufficient, but you may want to refer to this post. As always, I'm available on Clickteam Discord most of the time, and several other users are familiar with Lacewing there too.
Download link for the server, again: HERE.
If you're hosting Flash, there's an example policy file here. You'll have to edit the file if you're not using port 6121, but you can do that in Notepad.
Have fun making your first MMORPG.
Cheers,
~Phi [/quote]
Lacewing Blue Server [quote]
Lacewing Blue Server, or Bluewing Server, is a port of Lacewing Relay Server, which enables multiplayer games to be made in Fusion, and for Fusion applications to communicate with each other via the internet or LAN. This first release is build 4.
Why this was made:
The project was paid for by "the god of snake". He requested a HTML5 version of Lacewing Blue Client. I couldn't do that initially as it requires a server with HTML5 WebSocket support, so I needed to make Bluewing Server so I could add WebSocket support alongside regular Lacewing.
Unfortunately, after the regular Lacewing part of the server was finished, before HTML5 was added, the sponsor cancelled the HTML5 project, as he'd decided to switch to non-Fusion HTML5.
So the current Bluewing Server supports Windows, Android and Flash clients. I can later modify it to add HTML5, but I'm not doing that without funding. Bills to pay, kids to throw money at, etc.
Like Lacewing Blue Client, the new Blue Server uses liblacewing 0.5.4 (final) instead of 0.3.0.
The source code will be withheld from public release for a while as per the sponsor's request, then it'd be on GitHub alongside the client. (The current server code on GitHub is the code as it was before he funded it, and very not usable).
Once the source code is released, presuming you know C++, you could make a custom server outside of Fusion to get full C++ speed without Fusion's overhead. I'm using such a system on Darkwire Server I now.
Notable facts about this server:
Lacewing Relay Client and Lacewing Blue Client can both connect and exchange messages with each other on this server.
The server supports Windows, Android and Flash clients. (Note that Flash as a whole does not support Blast/UDP, so you still can't use that.) Flash uses raw sockets but requires a policy file to be sent before it allows it, and that part of liblacewing hadn't changed, so although the sponsor didn't need it, it was minimal effort to implement.
Multithreading is not implemented fully. Between the clients doing something, the server doing something, and Fusion doing something, it became out of sync very quickly. For that reason I've disabled that functionality. Single-threaded can still be extremely fast if Enable Conditions is used properly.
I've changed the "Enable conditions" menu. You now have five modes you can handle say, a channel join:
Auto-approve and don't tell Fusion (instant)
Auto-deny and don't tell Fusion (instant)
Auto-approve and tell Fusion (slower, use for logging)
Auto-deny and tell Fusion (slower, use for logging)
Wait for Fusion events to approve/deny (slowest, use when events must dictate approve/deny)
If 1 through 4 are used, then Bluewing Server instantly responds to the client with the OK or NO response.
If 2 or 3 are used, Fusion events will trigger but have the deny reason and such already set.
Attempting to deny with 2 or 3 would create an error and do nothing. If you want to deny something already auto-approved, try to find the opposite - e.g. for channel join, it's making the client leave.
If 5 is used, the client gets no response from Bluewing, the message's data is queued like with 2-3, and the Bluewing extension moves onto the next message.
Once Fusion eventually processes it (dependent on application framerate, which is dependent on machine speed), then the client will get an OK or NO response.
This introduces delay, naturally - an extension running on 60fps has at least 0.016s between frames. With Bluewing having to process a lot of messages, that delay increases.
For best performance:
You should use Enable Condition modes 1 or 2 by default.
Only inform Fusion for events you need to log (modes 3 or 4).
Never use mode 5 unless it's absolutely required.
You should not listen to client/channel messages (modes 3-5), as it will delay the messages, and introducing a delay with UDP messages can make an extremely painful movement lag on games that use it.
You should increase the application framerate to decrease processing between messages, and thus decrease ping and response times. That's in application properties under the 3rd tab (Runtime options).
You can increase it up to 1000, but note the higher it is, the more CPU your Fusion server program will use.
For what it's worth, some mode performance comparisons:
I had a Fusion app that had Rich Text and such "heavy" displaying objects on it.
The app would do nothing when it received a channel message. The conditions were still triggered by the extension, but no events were in the MFA with those conditions so Bluewing would trigger it, get no deny, and thus approve and respond to it.
The server was set to run at 1000fps (max).
Meanwhile, 20 clients each sending 5 channel messages per second were running.
That's 100 messages in, 1900 messages out per second.
• Fusion events approve all channel messages (Mode 5):
Result: 50fps
• Auto-approved, Fusion events triggered (Mode 3):
Result: 80fps
• Auto-approved, Fusion not told (Mode 1):
Result: 400fps
• I later used 50 clients under same environment with mode 1:
250 messages in, 12,250 messages out per second
Result: 170fps
These numbers are probably lower than actual results, as I had to run all the clients on the same machine that the server was running on, so they were probably using resources. But, the server machine was a high-spec desktop machine (what I use for Darkwire Server I), so that gives some sort of balance.
Exposing the server machine for connections:
There are three parts to this:
1) Allow access through server machine firewall (LAN or Internet access)
For both Internet and LAN, make sure the firewall on the server machine is not blocking it. Add it to Windows Firewall and any antivirus firewalls you have.
For LAN, steps 2 and 3, for port forwarding and ISP firewall checks, are not necessary.
2) Allow access through router (Internet only)
If you're making an internet-accessible server, you'll need to use port forwarding on your router for TCP and UDP on the correct port, which is normally 6121.
You should also port-forward ports 843 & 583 TCP if you're hosting Flash.
3) Allow access through ISP firewall (Internet only)
This step depends on your ISP having extra security measures, and may not be necessary. If you've followed step 2 for port forwarding and Internet clients still can't connect, you'll need to access your ISP settings for firewall. Your best bet is to google your specific ISP port forward instructions (e.g. AT&T, Verizon, PlusNet, etc).
Connecting to your server:
Connect to the server with Lacewing Relay Client or Lacewing Blue Client extensions.
Clients on LAN should use your server's local IP to connect, which you can get via ipconfig or the Fusion LocalIP or LocalIP++ extensions.
Internet clients can then connect via your remote IP from this link. You can also use it for LAN clients, but that will result in a slower connection.
If the server is on the same machine as the client, use "localhost" or "127.0.0.1" as the IP for the client to connect to.
If you host on 6121 (default), Lacewing will add the port for you. If you use a different one, add ":newport" to the connect-to address. So for port 6150 you'd use "localhost:6150", "betsysawsumserver.legitsite.com:6150" for example.
For non-Lacewing clients trying to connect:
The server mercilessly disconnects clients that don't follow Lacewing protocol. I had one plank trying to access the Lacewing server with a HTTP web browser and it was crashing things.
An error will also be made in this case, but note there's no client you can select in Fusion for that type of error, as without sending a Lacewing Connect Request message, you don't get On Connect triggered on the server. As such Fusion has no client it can select and mess about with. The IP of the booted non-Lacewing client will be in the error message, though.
Other notes:
Firstly, you should, of course, always have an On Error event in your server application. Without it, you won't be told about any internal errors or things your Fusion server app is doing wrong.
Typically, these are not fatal errors; e.g. if the master were to leave a channel with autoclose enabled, so other clients will be booted, you may get an error if there's a channel message sent from another client that now can't be delivered. They're worth listening to.
Secondly, the server will also handle generic server problems without you needing to worry about it. For example, a client trying to set its name to one that another client is already using will get a NO and a deny reason "name already used" sent back from Bluewing automatically, without Fusion coming into play. Don't write events that cover these sort of cases as it's totally unnecessary.
Thirdly, if you're tempted to use mode 5, you should only do that if you need the server to run events every time for deciding whether it's okay for approving it. If the server just has a "allow/deny" checkbox in the UI, you'd be better off switching the mode of handling when the checkbox is changed, and setting the deny reason as appropriate.
Fourthly, a server that has 5 clients on a channel and gets a channel message will need to forward four copies of that message. For this reason, the server machine's upload bandwidth will need to be higher than your download bandwidth.
Fifthly, this server's actions, conditions, and expression IDs match up Lacewing Relay Server. Theoretically, you could replace the Lacewing Relay Server MFX with the corresponding one from Lacewing Blue Server.
Sixthly, while this server comes with a help file, it doesn't have any details for Blue Server. The guide for Relay Server should be sufficient, but you may want to refer to this post. As always, I'm available on Clickteam Discord most of the time, and several other users are familiar with Lacewing there too.
Download link for the server, again: HERE.
If you're hosting Flash, there's an example policy file here. You'll have to edit the file if you're not using port 6121, but you can do that in Notepad.
Have fun making your first MMORPG.
Cheers,
~Phi [/quote]
Utilisateurs en ligne
- Aucun utilisateur en ligne
- 9 visiteurs au total
