The online racing simulator
InSim change for W45 - limit mods allowed on host
Allowed mods on host can now be limited by using the Hosting Admin pages. https://www.lfs.net/hosting/admin

Or you can do it through InSim. It's been a bit of a mad rush, so not everything is documented in all the right places. But if you look in the attached InSim.txt you will find:

ISP_MAL, IS_MAL, TINY_MAL

I hope you find that all makes sense! Anything unclear, please tell me and I'll update the document.

There are no text commands or in-game interface yet.
Attached files
InSim_W45.7z - 24.2 KB - 252 views
Hi, just tested it - works fine Smile
Just a suggestion: maybe Flags in IS_MAL could be an "operation" - add mod to allowed or remove.
It would be easier to call it from GUI or commands without having to update local cache first.

Another flag option could be "force-remove players with disallowed cars" - spectate those who drive with no longer valid cars after updating.
Is there a reason for the 120 mods limit?

The big packet could easily handle 253 mods.

Max packet size = 1020 - 8 byte header = 1012 bytes
1012 / 4 = 253
There isn't a hard reason for it, no. But I've currently kept all packets below 512 bytes, although as you say we could go up to 1020.

Ah yes there is *some* reason for this. I was reading up on what size packets will not suffer fragmentation on the internet, and if I remember correctly, fragmentation was extremely unlikely below some values that were around about 512 (can't remember the details, there were headers and it was about transport layers or something... can't remember). So I thought, let's keep it below 512 when possible, and keep our communications snappy. Smile

When originally discussing this specific functions, 120 mods was considered easily way more than enough.
Quote from Scawen :
Ah yes there is *some* reason for this. I was reading up on what size packets will not suffer fragmentation on the internet, and if I remember correctly, fragmentation was extremely unlikely below some values that were around about 512 (can't remember the details, there were headers and it was about transport layers or something... can't remember). So I thought, let's keep it below 512 when possible, and keep our communications snappy. Smile

Well, that would be the MTU for IDSN then Wink The MTUs for Ethernet is 1500 and 1492 for DSL connection because it prepends an extra header, similar to VPNS. But with 1020 bytes, there should be plenty of safety margin.

We have already whitelisted 30 mods and I log the usage to identify unnecessary ones. Here's a list if you care: https://world.city-driving.co.uk/?page=modlist
Just think of TCP as a stream and forget about individual packets. MTU is only be a problem for MCI packets via UDP.
Another suggestion: a server-controlled filter for players in mod selection - just like with regular cars setting allowed per player would be very useful in the mods page as well.

For example only show specific cars that player owns instead of trying to join with all the cars until insim allows to do it (JRR response)
There's already ~ 185 mods, so limiting this to 120 mods seems insufficient.

Will sending two packets cause the second to override the first, or will they cooperate?

As there is no flag to disallow, only allow, I think only the last packet will be active.

Maybe we just need to be a bit more selective in which mods we allow Big grin 120 is no doubt plenty for a non-cruise server, after all...
Well the join requests system is pretty simple to use if you have a controlling InSim program. No number of "allowed mods" is every going to cover 1000s of mods.

I do accept the point that moving to 240 instead of 120 is quite possible but I'm reluctant now to add incompatible features. I'm just about at the end of my endurance level after what must be my most extreme work year ever. We need to release the first official version of mods support early this week, in good time for the holidays. So for me, fixing show-stopper bugs is about all I can manage at the moment.
Yes, consider it potential future use of the currently unused flags byte, and leave it as is for now.

FGED GREDG RDFGDR GSFDG