TGEA 1.7.0 Mission Lighting fail for connecting client

#1 This is probably not the best way to do it but this fixes the issue :

function correctMissionFile( %missionFile )
{
   %myTokens = %missionFile;
   %final = "scriptsAndAssets";
   %continue = false;

  while( "" !$= %myTokens )
  {
      %myTokens = nextToken( %myTokens , "theToken" , "/" ); 
      if(%theToken $= "data" || %continue)
      {
         %final = %final @ "/" @ %theToken;
         %continue = true;  
      }
   }
   echo("final path:" SPC %final );
   return %final;
}

then change the $client::missionfile line of function clientCmdMissionStartPhase3(%seq,%missionName) to this

function clientCmdMissionStartPhase3(%seq,%missionName)
{
   //...
   $Client::MissionFile = correctMissionFile(%missionName);
   //...
}

#2 I had this issue too. For some odd reason it fixed itself.

#3 This should probably be done on the server side before it's sent across

#4 Same problem, the level (one large dif) is entirely black when a client connects but looks just fine for me.

#5 The fix that I went with for the next version of TGEA is to add the line:

%mission = makeRelativePath(%mission, getWorkingDirectory());

near the top of function createServer() in common\serverScripts\server.cs. Should accomplish the same thing as the code snippet above but do it on the server before it is sent to the client.

#6 Yeah I knew that would be the proper way, thanks for looking into this, I'm still new to the inner workings of torque.

#7 This change actually broke mission loading on our build, because the path would end up getting cut off a bit...

#8 I ended up doing this in a different place for some of the changes we use with mission lists and it fixed our problem, but the full pathnames are just messy looking.

I mean even overwriting material errors and missing texture errors are using full pathnames which just look odd

#9 Well, I experimented some more, but in a dedicated server situation -

The above fix breaks the entire game if the mission is passed as ~/Data blah blah or Core/Data blah blah

Core/Data/Missions/Stronghold.mis becomes:
../ore/Data/Missions/Stronghold.mis

~/Data/Missions/Stronghold.mis becomes:
..//Data/Missions/Stronghold.mis


This isn't an issue for Hosting thru the GUI, but in a dedicated server situation, the pathing is a bit different initially. Why was pathing changed so much to use full paths and not relative

#10

Quote:
Why was pathing changed so much to use full paths and not relative

Most of the changes with pathing occurred because of the merge with TGB's code. Tools need to be able to reference full system paths for assets that aren't a part of the editor/game folder structures (like adding a new sprite texture). Unfortunately, this did have some unforeseen sideeffects which are working our way through.

I'll check out the dedicated server thing...definitely looks like a bug.

#11 Makes sense as there some moving to allowing access to more than just what the "Resource Manager" currently sees, so to speak..

Just an annoyance right now :)

I did get it all working within dedicated server scenario, but you have to pass the full path to the -mission command, so it might not be an issue for some, but then for others it might be.

I suspect we will just set the path as a pref somewhere and reassemble the proper mission path, at some point in the script