The online racing simulator
InSim Relay client information
(63 posts, started )
You make a good point on the native types. The marshalling backwards and forth were a little bit unnecessary and tbh did cause a little bit of lag on slower PCs.

Sooooo, I reimplemented jspack into using the native typed arrays/arraybuffers whilst maintaining the same API (https://github.com/theangryangel/jspack-arraybuffer) and then updated lfswsrelay.js. It's much faster I also implemented a way to register packets from other files...

I was bored this afternoon

Just need something useful to do with this now...
Better than me.. I got bored and in my quest to platinum NFS:MW.. I created this (It won't work in IE.. maybe IE9 and 10, I didn't test in Firefox but it's been reported to work. Works great on Webkit ):

http://nfs.gu3.st/

Entirely in Javascript. Uses Handlebars for templating. Some parts of it are kinda crappy because initially I was building the HTML in PHP, but then I decided to do it in JS, but I was not retyping all of those ****ing races back in a more Javascript appropriate format.. so I just created a translation function to turn it into a Javascript object.

It also uses Local Storage to keep the data saved (which was its primary goal.. me learning LocalStorage).

It's pretty cool. Opening it in 2 tabs too, and toggling buttons and watching the other one change is pretty cool as well
Just a small note that isrelay.lfs.net now also has an AAAA record, meaning the relay is IPv6 compatible.
As far as I can tell flash sticks with IPv4 when doing the resolve, but in the future, webbrowsers may select IPv6. Not that you'll notice much difference, but I thought you should know.
Quote from Victor :Just a small note that isrelay.lfs.net now also has an AAAA record, meaning the relay is IPv6 compatible.
As far as I can tell flash sticks with IPv4 when doing the resolve, but in the future, webbrowsers may select IPv6. Not that you'll notice much difference, but I thought you should know.

Thanks for the info Victor.

Very appreciated.
I still don't have access to an IPv6 address space on the Verizon FiOS (Fiber Optic) network. But once I do, I'll start checking it out!
I've been testing it via my server. I'm sure that my server browser will likely be hitting various things via IPv6
I've noticed that after connecting to a host via InSim Relay, the "size" numbers of the regular InSim packets sent over InSim Relay are not divided by 4. This is unlike how InSim behaves now, which does the division since version 0.7A.

Quote :
// Version 0.7A (INSIM_VERSION increased to 9)
// ------------
// New size byte for packets - now represents packet size / 4
// - this allows much larger packets, up to 1020 byte

For instance, if I request the IS_VER packet to be sent after connecting to a host via InSim Relay, the first byte of that packet will be 20, which is the actual size of the packet. If I do that in plain InSim, the first byte received will be 5, which is in accordance with the latest InSim protocol.

Is this a bug in the relay protocol?
Quote from Flame CZE :Is this a bug in the relay protocol?

I assumed that this was a bug in my implementation and for now I've effectively hardcoded the relay to "uncompressed" format.

I'm somewhat glad I'm not going mental.
Thanks, I've sent an email to Victor about the relay size byte.
The relay service seems to be down. I can't connect to ws://isrelay.lfs.net:47474/connect and it even shows an error in the InSim Relay tab on LFSWorld:
Attached images
Screenshot 2023-03-18 at 22.29.51.png
Thanks Flame, Victor says that is running again.
It has been down again since last Thursday. I already sent an email to Victor with a possible cause.
Relay seems to be down. I think. I'm really tired and might be hallucinating.

On LFSWorld.net I'm seeing this https://imgur.com/Dnse97E

Locally I'm also unable to connect.

InSim Relay client information
(63 posts, started )
FGED GREDG RDFGDR GSFDG