How reliable are usermessages, and is there any length limit for sending strings?

I’m thinking about remaking Bomberminge from scratch, as using prop_dynamics for all the crates scattered on the map was definitely not a good idea, plus it would generate reliable snapshot overflows on large maps with many players.
So I thought about using only one entity which would handle collisions for all players, and draw all the crates clientside. The idea would be to encode the position of every crates into a string, then send it to the client when they join, and update it using usermessages every time a crate is broken.

So far, I can turn a 30x30 grid into a less than 100 characters long string. Better than 900 times god know how many bytes for storing position, angle, color, model, for every crate, right?
Now, is it safe to send this to a client through a usermessage, or should I cut it into smaller parts and send them successively? And most importantly, can I send a usermessage every time a crate is broken, so the client generates gibs and no longer draws that crate? Is there any acknowledgement system that makes sure the client receives that message, or should I attempt to do one myself using concommands?

Yeah, I know I could have tried it by myself, but there is less than one month left to the contest, I didn’t do shit for a month, and I’d like to know if I’m going the right way or not. I have always been absolutely terrible at network optimization, prediction and that kind of stuff.

255 bits is the limit, I believe. Very reliable.

As I understand, they won’t be received by a client if said client is experiencing a lot of lag. Not sure if that’s true though but it’s what I’ve been told.

Any message won’t be received if the client is timing out. There’s nothing you can do to stop that except checking on the client if a message was received when expected.

255 bytes isn’t it?

Could well be. I just thought that sounded a little big though.

It is possible that clients will not receive usermessages, as the server does not know when a client didn’t get the message because the client doesn’t give any kind of confirmation whether they got it or not.

I just checked, It is definitely 255 bytes.

I suppose, each ascii character takes up a byte, so it must be 255 bytes.

Edit: Sappin mah automerge.

V Look below V

Not sure but I think the name takes up bytes too.

It’s UTF-8, so it’s a variable length encoding. All the characters can take from 1 to 4 bytes.

There’s also a lot of mis-information in this thread, I’ve explained this a bit in two posts:

Strings are n bytes + 1 for the null terminator. You have 252 bytes to work with. You can only fit a 251 byte string. Not that I recommend it.

Ok, thanks for the clarification ^^

Yeah, I’m thinking about making the clients reply using a concommand or something, so the server makes sure they received all the needed data.

Okay, I guess I’ll just cut my string into small parts and send them one after each other, making sure the client didn’t miss any of them. Anyway, it only does that every time a new round starts, so even if it’s slow, that shouldn’t cause too much of a problem, at least this shit waiting time Fretta inserts at the beginning of each round will have an use here. Thanks for the clarification!

This is the life long problem because, by doing what you just said, you’re pretty much replicating datastream, so when that happens to me, I use datastream. People need to stop being scared of datastream.

Yeah, about datastream, I strongly considered using it, but I wasn’t sure whether this is really what I need. Gotta look at the source code and see if it does cut strings into small parts before sending them.

There’s nothing wrong with the datastream assuming you use it correctly. Using the datasteam for a short, long or small string of course, is exceptionally dumb.

But medium strings are a-ok?

Anything that’s over the 251 byte limit of a usermessage, it’s saving you pointless code.

Bahahah, took me a while to understand that you were talking about “shorts”, “longs”, and “small strings”, and not “short, long and small strings”. :v:
Okay, then that’s pretty much what I need, thanks.