Multiple clients, single machine

#1 Multiple instances of torque only runs in debug mode. Try building your project with debug set, and go from there.

#2 It's however very trivial to enable it in release, too.

#3 Stephen: That's real encouraging and I retraced my steps. Sure enough I was in debug mode when it was working before.

The bad news is it seems to be broken in 14RC2 - doesn't work using debug mode.

In any case I retested with 1.3 code base and the performance under debug mode is so poor with mulitple clients due, I suppose, to all the overhead that it is unusable. I really need to figure out how to do this in release mode and with 1.4Rc2

Stefan: Since it is trivial :o) any guidance you can provide on getting this to work in release mode would be very appreciated. I'll try to it with !4Rc2 codebase.

#4 Stephen: That's real encouraging and I retraced my steps. Sure enough I was in debug mode when it was working before.

I retested with 1.3 code base and the performance under debug mode is so poor with mulitple clients due, I suppose, to all the overhead that it is unusable. I really need to figure out how to do this in release mode and with 1.4Rc2

Stefan: Since it is trivial :o) any guidance you can provide on getting this to work in release mode would be very appreciated. I'll try to it with !4Rc2 codebase.

#5 Why would you need multiple clients on one machine in a release mode project? In the example you give, that's basically the exact definition of "host multiplayer"--the ability to have your client play on your server, with the addition of others able to login to your game--and that's stock out of the box, without having two instances running.

#6 Well because, so far, I can't run my code effectively in standard debug mode becuase it is excessively slow and will bomb when it tries to load very large mission files. My mission has a mulitlevel building with a huge path object that tours the building visiting dozens of objects. I get an "out of range write" error in bitstream.cc @194, for example, when running in debug mode if I use the full set of objects.

#7 So in guiCanvas.cc, commenting out the excludeOtherInstances() fixes that issue.


#if !defined(TORQUE_OS_MAC) // macs can only run one instance in general.
#if !defined(TORQUE_DEBUG) && !defined(INTERNAL_RELEASE)
// if(!Platform::excludeOtherInstances("TorqueTest"))
// return false;
#endif
#endif

#8 On the whole your reasoning makes sense, but that out of range write error isn't something to ignore...it means that you have too may ghosted objects for the ghostIDBitSize you have defined. It asserts in debug mode as a warning that you have a problem.--Note: I -think- this is the area that assert indicates, it's possible that it is something similar but not exactly what I described...

You should look at increasing the number of ghostable objects in your project since this is an important error!

#9 Enum GhostConstants
{
GhostIdBitSize = 12,
MaxGhostCount = 1 << GhostIdBitSize, //4096,
GhostLookupTableSize = 1 << GhostIdBitSize, //4096
GhostIndexBitSize = 4 // number of bits GhostIdBitSize-3 fits into
};

Is this what you are talking about? If so it looks pretty large (4096) as it is. I have a 200 or so objects to deal with, mostly static scene objects, like cars from the car pack and a few from the urban pack and the adam pack, etc.

#10 Correction to my previous post: it's not the total number of ghosted objects that assert warns about, but the total size of the bitstream itself. I'm going to do some more research on this as to the common causes and get back to you!

#11 That agrees with my experience in that "my" bitstream gets large in debug mode.

#12 What I'm getting at is that your bitstream is large in both release and debug modes, it simply is reporting it to you in debug mode (that's what asserts are for!).

There is nothing whatsoever in DEBUG mode vs RELEASE that will change the amount of bits sent down the bitstream, so you have this problem in your release build as well, you simply aren't aware of it.

You may want to take a look at your pack/unpacks for your various objects, and make sure you are optimizing as much as possible (using the minimum amount of bits to send values, etc.) to help out!

I know that this is in no way related to your original question, but it's going to come back and bite you in the long run.

#13 Ya, it's warning you for a reason.

#14 I certainly agree with what you are saying, it's just that my focus isn't on that right now. Just need it to work right now so I can see the overall.

Later I will do the exercise of pruning the objects and AI paths down to see what the cause is.

Thanks for the insight you provided and I'll certainly follow it up.