Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
Has anyone used BitSend (by Yonom) to send music to other users, and then have another client (that they would download) to stream the music/sound effects? So for example if someone went over a block or something it would make a sound, and that sound would be indicative of something.
For example, a zombie level might have a sound of a zombie get louder when a zombie comes closer, altering you that you have to move quickly.
A project was created from this thread:
Cardinal: https://github.com/Decagon/CardinalRight now, it cannot stream audio.
Offline
I planned on using such a system to display a RPG interface for a bot I was doing, but never really finished it (the bot). If I remember when, Bitsend uses a coin message, but I was planning on using 'm' though, since you can send more information in a single message.
Offline
The protocol can be more efficient now though, since that version was built when there was just one integer in the coin message.
I was planning on eventually building my own framework for it, but I never finished it.
Offline
The protocol can be more efficient now though, since that version was built when there was just one integer in the coin message.
I was planning on eventually building my own framework for it, but I never finished it.
And yet we talked about this so long ago... Curse on our laziness ==
Offline
lrussell wrote:The protocol can be more efficient now though, since that version was built when there was just one integer in the coin message.
I was planning on eventually building my own framework for it, but I never finished it.And yet we talked about this so long ago... Curse on our laziness ==
Even though it is unfinished, do you mind posting the source? I would be really interested in it because it could open up new opportunities for making Everybody Edits more interactive.
Offline
DataCoin Protocol Specification
Total "packet" size: 8 bytesEach packet will contain the following:
[1 byte, char] Type: Used to identify the type of message being sent.
[1 byte, byte (0-255 integer)] Id: Used to identify a packet within a set.
[6 bytes, byte array] Data: The binary data payload for a packet.Depending on the type, there can be a sub-protocol stored within the binary data.
For example, a DataChunk type ('c') could contain a 2-byte ushort location index
followed by the remaining 4-byte payload. If this were to be paired with a DataInfo
type ('i'), it would allow a client to know how many packets are remaining as well
as automatically determine where a resent packet should be placed within a set.Thus, you would end up with a protocol that could handle single 6 byte messages for
simple operations, or a 4-byte multi-packet protocol that can promise safe delivery of
up to 262144 bytes.
This was the best I managed to come up with at the time of when I tried. It's definitely not optimal but should work providing it doesn't have any logic holes. It would still provide a faster speed than the current BitSend implementation while possibly allowing a priority message to skip the queue because of the ID system as well as handling data arriving in any order. Plus, unlike BitSend, it would only need to send a single coin message for a small payload of 6 bytes or less.
(I'm waiting for "You can do this but you can't be bothered to implement it?" now. )
Offline
That's a nice and efficient protocol, and could definitely be used for this project!
Just thinking now, the payload for the music file could be sent when the player joins, for example, so that it could be cached on the client. Then, whenever the player touches something a sound effect is loaded by sending a single packet which corresponds to a specific sound to be played. This allows the sounds to be much more responsive, since they don't have to be downloaded every time.
Offline
[ Started around 1732812275.8604 - Generated in 0.108 seconds, 12 queries executed - Memory usage: 1.45 MiB (Peak: 1.58 MiB) ]