Detecting a local vs ded server

[Cobalt]

[Spike]

why should the modder care?
imho, doing things that require a distinction are a bug.

the only thing that is useful is whether a specific client is the local client or not. you can check for that by its ip.

[Cobalt]

[Spike]

I don't really get fully what you're saying. are you saying that DP execs different configs if its a listen vs dedicated server?

learn how to use autocvars.
var float autocvar_mycvar = 4;

you can register cvars with a registercvar builtin or something (I think its in the 90-100 range, look it up).
cvar_set indeed expects the cvar to already exist. you can always do localcmd("set foo value\n") to set it if you really want (although yes, small delay).

hacking the timelimit cvar for things like that is hideous in the first place.
you can probably use the clientstat builtin to override it (but not globalstat because dp doesn't support that), so you should be able to cowardly avoid csqc that way. I've no idea which stat number dp shoves it into though.
then you can just use timelimit for match times, and some other cvar for vote times without hacking everything in a really clumsy-sounding way.

[Cobalt]

[Spike]

why would you want to?

[Cobalt]

[Spike]

so you need to know whether its running on linux, so you're instead testing to see if they used -dedicated on the commandline instead?
that's absurd.

if you really want to test to see if you're running on linux, use the cvar_type function and test for some linux-specific cvar. of course, due to the 'proper' dp builds all using sdl, you're screwed. you might be able to use strftime to see which C run time it was linked against, if the bug is caused by msvc or whatever.

but assuming that all and only dedicated servers are running on linux is stupid.

if both machines are under your control, surely you'll know which one you got the saved game from in the first place, so why do you need to set a cvar (which won't be shown in the saved game anyway)?


if you're seeing behavioural differences between linux and windows, then you should bitch at whoever is responsible. But probably you'll find out that its your own config issue.
If you're seeing differences between dedicated and listen servers, then its probably your own fault anyway. If you explain the difference that you're observing then maybe someone here will be able to point out exactly which part of the API you're failing to understand.

[Cobalt]

Right. I guess mostly its because as humans we sometimes are doing stupid things in code - experimenting, and might get ahead of ourselves and forget there is a difference in some things in a local environment versus a ded. I dont know like the back of my hand 100% all the differences as far as the engine goes, because I am not yet an engine coder...so my idea comes from a QC perspective, not the engine. It might be useful in some troubleshooting situations.

I understand your perspective, because your knowledge of the engine is at a level where if you were looking at my code, maybe right away you would say its because config.cfg gets done first , then autoexec.cfg ....then worldspawn() or something simple, where when I see the problem, my way is to do some tests with qc to determine whats going on behind the scenes in the engine that I do not 100% understand.

[r00k]

woudn't

if (self.netaddress == "local")

be enough?

I have seen issues with manipulating strings on the hunk to differ from windows and linux, so I could see how this would be
useful.

[Cobalt]

[frag.machine]

If I got your problem correctly, you want to mess with timelimit and later restore it to its original value, right ?
Wouldn't be enough to store the original value somewhere (maybe a global float) before changing the cvar and later just use this global ?
I must confess I fail to see why you took the confuse route of telling apart dedicated versus local versus Windows versus Linux...

[Cobalt]