Handling More Ghosts

#1 are all 50+ active on the screen at the same time or are there 50+ in the area? this might help you or get you started in a direction at least.

www.garagegames.com/community/resources/view/21756

i know you were wanting to increase the number, but this way may at least help if you dont have all 50 mobs on top of each other.

#2 Thanks for the reply Paul. I have looked into that resource, and it is something I plan to implement to keep the network strain to a minimum as I do have a zoom feature, and a nice big map.

The 50 would be unlikely to be all on screen at one time, but definitely in the area. I'm imagining, a group of players traveling around, then fighting off a bunch of small enemies. All of this would be well within the ghosting range of each client.

I can get the updates the I want by increasing the numbers (at least the net graph says I am). My problem right now is that the chat breaks, and only the chat. It is an important part of the game, so I do need to have it in there. Everything else in the game works with no issues.

I should mention that it only doesn't work on a dedicated server, or playing on a server that isn't built into the local game. Hosting my own single player game allows the chat to work fine.

#3 Most likely your exceeding you max ghost cap which I think in stock is like 4k. You need to bump it up.

Around line 822 in netconnection.h

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

#4 Hi Vince, thanks for the reply. I doubt I'm hitting the max ghost cap, since I don't even get close to having even 1000 ghosts in my project. I'm still just running some tests with dummy A.I..

The only thing that isn't working for me (from what I can tell) is the chatHud. Messages players send to the built in chat system are sent through the network, and to the clients. I can print them out to the console client side with no issues. However these messages won't display to the actual chatHud.

It seems like somewhere in the chatHud there is something using one of those variables. The chatHud won't even display locally created strings, so I'm really starting to get confused here.

#5 If it is making it to the console then perhaps it is an issue with the HUD itself. Have you done a full recompile to make sure there are not any lingering compiles against old values?

#6 could be your messagehandlers?

#7 @Demolishun - I have done a full recompile, a couple of times, since I've noticed the issue. I got it to work once in a debug after triggering a break, but haven't been able to replicate it since.

@Vince - How/where could I check those? Do you mean where its processed in the script or in the engine?

Thanks.

#8 I've had over 450 AI on a dedicated server and no problem with ghosting. This has to be something else - I've noticed that the chat hud has always been a little screwy, there might be something there - either in the script or in the engine as far as message handling.

#9 I've been trying to follow the strings insertion into the chat hud. It seems it makes its way into the engine with no issues, but they aren't being displayed from there. Almost like, the render call is just ignoring them?

I've tried specifying a custom string in the engine, prior to setting it into the chat hud, but I've still had no luck. I really don't get whats going on, I can't imagine where I messed up.

EDIT:
When I dump the HudMessageVector to a file I get this:

2
0 \c2Welcome to The Project \x10\c8pwebbz\x11.
0 \c4\x10\c8pwebbz\x11: hi

#10 I've figured it out (although I'm not sure what caused it). The ChatHud wasn't rendering the text, because for some reason the HudMessageVector wasn't attached to it.

void GuiMessageVectorCtrl::onRender(Point2I      offset,
                                    const RectI& updateRect)
{
   GFXDrawUtil *drawer = GFX->getDrawUtil();

   Parent::onRender(offset, updateRect);
   if (isAttached()) { //<- it wasn't getting past here

Calling

ChatHud.attach(HudMessageVector);

fixed it.

Thanks for everyone's help!

#11 I don't see how the GuiMessageVectorCtrl could be affected by network settings. If the issue crops up after adjusting "$pref::Net::PacketSize" and "$pref::Net::PacketRateToClient" then that is really strange. I see nothing in the gui object that could possibly be affected.

It looks like the messages are in the vector as indicated in the dump. So something really strange is happening. If the messages are in the vector of the GUI object which is a client side object then it should be displaying the data. The only thing I can think of is that "detach" is being called on the GuiMessageVectorCtrl in script. Perhaps searching for detach might dig up some faulty networking script?

After looking at the C++ code I am at a loss of how this could happen.

#12 Hey Demolishun,

I ran a project wide search on the scripts for "detach" and found nothing. It is really strange, that it would work 100% fine before changing those variables, and then break a second after. I also did a quick look through the engine code (the detach references), and didn't see anything that would suggest a problem at first glance.

I have made slight modifications to the engine though (mostly following resources on this site), so I might have broken this myself. I haven't change anything related to network, or chat gui though...

#13 Guys you rock! an interesting thread

#14 Are all of your text messages sent as tagged strings? It's something to think about - tagged strings are sent once, assigned an index and thereafter only that index is sent across the wire and interpreted on the respective machines. This saves bandwidth and coincidentally limits the effect on packet size changes since it's always just an integer after the first pass.

#15 I haven't touched the built in chat code, I don't have a very good understanding of how the networked half of it works. The messages that are received are run through detag in the script:

function clientCmdChatMessage(%sender, %voice, %pitch, %msgString, %a1, %a2, %a3, %a4, %a5, %a6, %a7, %a8, %a9, %a10)
{
   onChatMessage(detag(%msgString), %voice, %pitch);
}

I never had an issue with the messages not getting through the network though. Somewhere out there, the HudMessageVector got detached when I changed those variables.

#16 @Patrick,
I did not find it in the 1.2 scripts either (current base I am working from).

However, I did find this:

//--------------------------------------------------------------------------
bool GuiMessageVectorCtrl::onWake()
{
   if (Parent::onWake() == false)
      return false;

   if (bool(mProfile->mFont) == false)
      return false;

   mMinSensibleWidth = 1;

   for (U32 i = 0; i < 256; i++) {
      if (mProfile->mFont->isValidChar(U8(i))) {
         if (mProfile->mFont->getCharWidth(U8(i)) > mMinSensibleWidth)
            mMinSensibleWidth = mProfile->mFont->getCharWidth(U8(i));
      }
   }

   AssertFatal(mLineWrappings.size() == 0, "Error, line wrappings not properly cleared!");
   return true;
}


//--------------------------------------------------------------------------
void GuiMessageVectorCtrl::onSleep()
{
   if (isAttached())
      detach();

   Parent::onSleep();
}

It don't see it being reattached when it wakes up. I don't know if it is doing it somewhere else, but it detaches when it sleeps and does not have a corresponding attach in OnWake. Could be part of the issue?

#17 @Demolishun - That's a good find. (I found the same thing in my T3D 2.0) Its certainly one potential issue. I do hide the chat a couple seconds after a message comes through, so that could have been the issue. I still don't get why changing the network variables would break it though, as I had the same chat hiding prior to the network change.

#18 @Patrick,
It is all weird. All I can think is you have to launch other stuff which requires you to do something else on the desktop. Then the app goes to sleep or something. It might be interesting to put Con::printf's in the attach and detach methods and see if that is happening. If not I think you can rule out that scenario.

Edit:
Sorry, OnAwake and OnSleep methods. The other would probably spam a lot, but might be useful.