[bf1942] Running more than 1 instance of BF1942 on same server

[Killing]

Doesn't work as far as I know u need to bind to separate ips atm
----- Original Message -----
From: "Fred of MPGamers.co.uk" <fred at mpgamers.co.uk>
To: <bf1942 at icculus.org>
Sent: 06 January 2003 14:39
Subject: [bf1942] Running more than 1 instance of BF1942 on same server


I am trying to get 2 instances working on 1 IP address...
Instance 1 is on port 14567
Instance 2 is on port 14568

When I look at in game browser or ASE I only ever see 1 of them.
I assumed ASE wouldn't see the 2nd one because it's on same ASE port
(23000).

Has anyone got 2 instances working using 1 IP ? (and you can see both
servers list in game browser ?)
Perhaps this isn't possible using only 1 IP, but at the moment I only have 1
IP on my server.
I have seen this work on Blueyonder servers but assume they use the windows
version of BF1942.

Any help would be appreciated :)

> ----- Original Message -----
> From: "Götz Klingelhöfer [KGN]" <tankmann at krawall.de>
> To: <bf1942 at icculus.org>
> Sent: Monday, January 06, 2003 1:33 PM
> Subject: [bf1942] New build question?
>
>
> Hey guys,
>
> Sorry 'bout that question but did not have enough time to chek it
> myself. Does the new build uses both CPU's if i'll start 6 instances of
> bf42 on (for example) a P4 Dual 2.4 ? Or does it only use one CPU?
>
> thx
>
> --Goetz Klingelhoefer
>
> > -----Ursprüngliche Nachricht-----
> > Von: Ryan C. Gordon [mailto:icculus at clutteredmind.org]
> > Gesendet: Montag, 6. Januar 2003 08:46
> > An: bf1942 at icculus.org
> > Betreff: [bf1942] New build.
> >
> >
> >
> > http://icculus.org/betas/bf1942/bf1942-lnxded-betaupdate-build
> > -1041834125.tar.bz2
> >
> > The crashbugs are driving me nuts, and I'm not entirely
> > certain they aren't race conditions. So I ripped the
> > multithreading out. There's a few benefits to this:
> >
> > 1) The binary is 1.5 megs smaller (!).
> > 2) Less latency due to context switching and mutex contention, etc.
> > 3) Less context switches.
> >
> > The end result is that the server might actually respond
> > better and eat less CPU (although I suspect the lag people
> > are seeing is unrelated).
> >
> > Most importantly:
> > 4) No race conditions.
> >
> > No, most importantly:
> > 5) No more complaints that there's three copies of the game running!
> >
> > You might get all the same crashbugs in this build as the
> > last one. We won't know until you try it, but it will let us
> > rule out a threading problem (and at least I can say with
> > certainty that you won't crash in
> > pthread_mutex_lock() anymore.  :)  )
> >
> > Other stuff:
> >
> > 1) The server status info (the little red dot in the server
> > browser) shouldn't be red anymore. That thing is based on
> > framerate, but since all the video stuff was ripped out of
> > the Linux server, the frames per second was always zero
> > (which, I guess, is really really slow.  :)  ). Now it
> > reports server frames per second, which in terms of a null
> > rendering device, is a more accurate term for the exact same thing.
> >
> > 2) I set the gamespy socket to "reusable", which is the ONLY
> > difference between the game's socket and the gamespy one...if
> > this doesn't fix FreeBSD's binding problems, I can't fathom
> > what's wrong with it.
> >
> > Ok, I'm getting on a plane for San Francisco now, but I'll be
> > checking email throughout the week. Please report success and
> > failure (and stack traces).
> >
> > Good luck,
> > --ryan.
> >
> >
> >
>
>
>
>