Since in C#, unlike Lua, there is a preprocessor that we can utilize, wouldn’t it make sense to define symbols CLIENT and SERVER for respective realms to be able to wrap code into #ifs?
Or can we already do that?
P. S. Checking the realm the gmod way via some global variable could be still left in, it’s useful sometimes to be used in boolean expressions, so you could give the developers both options.
You can do Host.IsClient to check if client etc.
One lesson Rust has repeatedly taught us is that pre-processors aren’t a good experience. You don’t want to only find out your code doesn’t work when you open it in the game.
Sorry for the necro, but on the server side will the server’s files (.cs) be networked to the client, if so is there anything we can do to stop that?
Wrong response.
@nosharp this is the right one: Networking Domains - #4 by garry
So, you can’t do anything about it at the moment, but he is aware of the issue, as he says here:
It makes sense for servers to want to hide sections of their code though, or at least to not send them to the client… so I imagine this will change.
The “not really” part is confusing here without context.
I asked garry if client compiles .cs files, to which he responded with “not really”. Since #sbox-general is gone I can not provide a screenshot with context
the client doesn’t compile cs files, it gets the compiled assembly from the server
The only reason I was confused, was because it wasn’t clear if the Server Side files get networked to client.
If that was the case it would discourage alot of the larger servers from moving over.
He’s got a point. If clients are able to intercept the server code, even if it’s already compiled, then it can be reverse engineered and stolen. That would 100% keep large communities away from the game
Being able to steal the server binary will at least allow anyone to join your server, download your server and host your server as if it’s theirs.
Doesn’t sound very fun, tons of time and $$$ can go to waste as soon as someone just steals your server and uses it just as you do.
Except you can disable sandbox whitelist to load code on serverside only
Regardless of that garry already said that you will be able to make serverside only addons
Quite sure garry has the plans of server-side only code, people would hack it in anyways. They’ve mentioned that the current method does not distinguish between client/server code, but we’re early in s&box development so that’s to be expected. I’ll be interested to know what method they end up deciding on, considering they do not want another preprocessor scenario like rust.
The way gmod does it currently would be suffecient. Or even just MyMod.sv.dll and MyMod.cl.dll would suffice.
Server-side code as in the addon is not sent to client and only is kept on server
But that means you will have everything broken up in a likely very annoying manner and you will likely have to jump between 3 different projects. It would be nice if we did not have to deal with client-side, server side and then common projects in order to do anything.
I’d honestly not care, aslong as it’s seperated.
I’m pretty sure it’s all one project and you mark things (methods? classes?) as serverside or clientside only - otherwise they probably default to shared.
There was some code on the Wiki that seemed to indicate that at least.
We are talking about compilation. Keeping Serverside code out of your addons so that they cannot be decompiled and rehosted easily. Yes, you can mark code to RUN clientside/serverside but not restrict compilation to be client exposed code only.