Differences in Source Code

#21 Not sure which patch you are talking about to be honest--we (my core team) originally wrote one quick re-write, but it turned out to be just as bad as the original. We then spent 3 months designing and implementing an MMO-style VisManager that could handle multi-threaded and asynchronous unit movement updates, but it turned out that the engineer that wrote it put in one assumption that caused a severe loss of functionality, and the implementation was highly dependent on it, so we scrapped that as well.

Long story short, I'm not aware of any effective and performant patches to the vis system available publicly, either from my original team, or others.

#22 EDIT: Turns out this isn't a perfect solution. In fact it doesn't work if there are more than 2 players, so hold off on incorporating this until a more definite solution is found.

Okay, here are the changes I made to get visibility working:

First of all you need to follow the instructions here to restore sight to your units. The changes need to be made in RTSUnit.cc in the RTSUnitData::initPersistFields() method around line 146 after/under the range line.

After that, open up visManager.cc and add this just outside the for loop at about line 72 (changes in bold):

// U32 numProcessedUnits = 0;
[b]bool tempSetVis = false; // this is used as a switch later on[/b]

Then starting at about line 105 change the following:

if (client)
         {
            if (unitVision * unitVision > lenSqr)
               client->setUnitVisible(target);
            else
               client->setUnitInvisible(target);
         }

         if (targetClient)
         {
            if (targetVision * targetVision > lenSqr)
               targetClient->setUnitVisible(unit);
            else
               targetClient->setUnitInvisible(unit);
         }

         //numProcessedUnits++;
      }

To this (changes in bold):

if (client)
         {
            if (unitVision * unitVision > lenSqr)
               [b]tempSetVis = true; // This enemy can be seen by your unit[/b]
               client->setUnitVisible(target);
[b]//            else // Don't set the unit invisible until we know for sure it's not visible[/b]
[b]//               client->setUnitInvisible(target);[/b]
         }

         if (targetClient)
         {
            if (targetVision * targetVision > lenSqr)
		    [b]tempSetVis = true; // This enemy can be seen by your unit[/b]
	            targetClient->setUnitVisible(unit);
[b]//            else // Don't set the unit invisible until we know for sure it's not visible[/b]
[b]//                targetClient->setUnitInvisible(unit);[/b]
         }
[b]// All of the following code is new
		 if (tempSetVis) // if the enemy can be seen by one of your units
		 {
		    break; // stop checking to see if it can be seen by other units
		 } else if (k == (mObjectList.size() -1)) // the enemy can't be seen be your unit
		 {                                  // and we've checked all other units
			 if (client)
			 {
				 client->setUnitInvisible(target);
			 }
			 if (targetClient)
			 {
				 targetClient->setUnitInvisible(unit);
			 }
		 }
// end of new code[/b]

         //numProcessedUnits++;
      }

What this does is as it's checking itself against each of your units to see if it can be seen by any of them, as soon as it finds one that can see it, it sets itself as visible and breaks out of the loop. If it compares itself to all of your units and doesn't find any units that can see it, then it sets itself as invisible.

As I said, I don't know much about C++ so there may be some glaring errors in my code that need to be fixed. For instance, I don't know why it checks for client and targetClient but I left that in there in case it was important.

@Stephen: I'm not sure about performance since I just started up the default starter.RTS level with the default number of units that start at the beginning of a game. It ran just fine for me, and if anything it should improve performance since it stops going through the list as soon as it finds a unit that can see it instead of continuing on to check every single unit every time. But I haven't done a benchmark test or anything.

Oh, and the patch Novack's talking about is the one from this thread.

@Everyone:

There is still an issue about units that haven't yet moved not showing up until they do move. The hosting player usually starts the game a second or two before the client (which needs to be fixed!). This means that my host could see the client's units from the beginning of the game, since they were all added after the first unit that could see them. But the client could only see one of the host's units. I'm guessing that's because it was the only one added after one of the client's units that could see it. But once I moved all units on both teams they could be seen from very far away.

Too far away probably, almost the entire map. But I think that goes back to the unit visibility from RTSUnit.cc.

Questions? Comments?

On a side note about the units being invisible before they're moved: I think a simple hack to fix this would be to mark them as dirty a few seconds after the game begins so they require a recheck. That doesn't really solve the problem, but covers it up.

EDIT: for clarity

#23 Okay well as I was typing that up I thought about a possible reason why that wouldn't work, so I just tested it and indeed it isn't quite the solution we wanted after all.

I just tried it with 3 players and only the host could see everyone, since when Client 2 started the check and it found itself visible to the Host, it stopped checking itself against any of Client 1's units.

EDIT: And it greatly magnified the problem of some people starting before others, since it took my second client about 30 seconds to finish loading all the datablocks and things. So player 1 and 2 were in the game within a few seconds of each other, but player 3 was still loading stuff half a minute later. That gives a major advantage to players who start faster!

#24 Here's another difference between the two sources I have. In engine\game\RTS\RTSProjectile.h @ line 16:

Source by following TDN instructions:

#include "sceneGraph/lightManager.h"

Source by using Brian's Patch:

#include "lightingsystem/sglightManager.h"

Does one of those take into account that the TLK is included in TGE since 1.5 and the other doesn't? Which one is right?

#25 Can't keep up with you Deozaan :)

I've just gone through all of Brian's updates (I'm assuming that's the file your comparing to) and have compiled a list of differences that need to be qualified. I documented the one you mention above but I'm leaving it to Novack to figure out :)

On the visibility thing - I've been implementing the bug fix code referenced in the list that Novack compiled on TDN. That included the reference you make above. I'll be creating a patch with those fixes as soon as I can.

Question: Should I implement your visibility fix, hold off for a bit or make simply make it a separate patch?

By the way, well done :)

#26 @ Deozaan - Sorry for the separate post but would you like me to send you the word doc with the differences between the TDN patch and Brian's updates?

#27 James,

I'm not actually comparing just one file, I have two entire sources that I'm using Beyond Compare to find the differences. One was built by following instructions on TDN, the other was built with the patch made available by Brian. I'd be happy to see the doc with the differences. I have a Gmail account with the username of Deozaan. Thanks.

As for my visibility fix posted above, I did some more testing and found out it's not really a fix. It breaks down completely if there are more than two players. So definitely do not implement my "fix" as a final solution. It may be a step in the right direction, but it may also need to just be completely discarded. I keep trying to tell you guys I don't know C++. (c:

#28 I understand Deozaan - the document compares ALL the differences supplied by Brain's download and the TDN patch. I'll send it along.

Quote:I keep trying to tell you guys I don't know C++. (c:

and you keep fooling us by coming up with these possible fixes ;)

I'll hold off then :O)

#29 I sent it off to you Deozaan.

Do you have an Messenger account?