Game Development Community

Strange Material Conflict

by Cliff · in Torque Game Engine Advanced · 08/07/2006 (9:22 pm) · 9 replies

OK... I've been hacking at this for several days, and I finally managed to get it down to this. I have two materials in my project, like so:

new Material(gridTex) {
  mapTo = "grid_texture";
  
  baseTex[0] = "data/assets/textures/grid_texture";
  glow = true;
};

new Material(beamTex) {
  mapTo="satellite_beam";
  
  baseTex[0] = "data/assets/textures/satellite_beam";
  glow = true;
};

When I try to run my program with both these materials enabled, the client ignores all commandToClient calls. However, if I comment out either one or the other, then my program works fine.

I'm at a loss, I don't see a conflict here... I've even tried commenting out the glow, to no avail. I also tried changing the value in the mapTo so that it's not the same name as the filename in the baseTex, and I tried forcing the baseTex values to end in .png.

The strange part is that it causes my network layer to barf, rather than just giving me a "no material" error. Very peculiar.

#1
08/08/2006 (9:28 am)
Perhaps the real issue is the quantity or number of materials, and that last one pushes something over the edge causing ripple effect errors? Are they by chance the last two materials processed when the game is run?

If you go and comment out other materials and leave these two alone, does it have any effect?
#2
08/08/2006 (10:30 am)
These are the only two materials in my game, other than the ones that included as part of the TSE code base. Even counting those, I think that brings my total up to, what, about 5 or 6 total materials.

The textures themselves are also 256x256 so I'm positive it's not a texture memory issue... though I can't imagine running out of texture memory killing my network pipe anyway.
#3
08/08/2006 (12:16 pm)
Thats an interesting problem... Have you done a trace via console in game? trace(1); via console... Then you can at least tell if it is going somewhere it shouldn't or not hitting the proper script call..

Although, it sounds like something might be wrong within the C++ portions, but the only Material issues I know of are possible conflicts in naming Materials the same as other Objects in the game.
#4
08/08/2006 (12:21 pm)
I have trace(1) turned on all the time, it's not reporting any errors at all.

I've started using the step debugger in VC++ to try and suss where the problem is in the engine, but I haven't tracked it down yet. Most of last night's development effort was spent trying to track down the specific cause of the problem and getting it to where it was 100% reproducible. Now that I can at least reliably reproduce it, debugging will become somewhat easier.

Let me tell ya, while I was still trying to track down a problem in the network stack, I was tearing hair out over finding nothing wrong at all.

Wait... I just realized... I had to turn off trace(1) on the client because of the volumes of output I was getting. I'll give that a go tonight and see if it tells me anything additional, but I'm inclined to think it won't.
#5
08/08/2006 (3:18 pm)
Its an odd problem, if I could replicate it on my codebase then I'd try to see what is going on... but it could be anything lol
#6
08/08/2006 (3:26 pm)
Yeah... I posted more in the hopes that somebody has seen something similar. I'm sure most of you would understand my reluctance to share my entire code base. Once I've figured out what's wrong (and I will, just might take a little while), I'll post the solution.

In the meantime, has anybody seen anything like this?
#7
08/08/2006 (8:43 pm)
OK, this is... urhm...

This is.

I suspect something deeper going on here, but get this... it was my code formatting. Apparently, Materials don't like it when you put your opening squirrely brace at the end of the new Material() line... when I reformated my code like so:

new Material(gridTex) 
{
  mapTo = "grid_texture";
  
  baseTex[0] = "data/assets/textures/grid_texture";
  glow = true;
};

new Material(beamTex) 
{
  mapTo="satellite_beam";
  
  baseTex[0] = "data/assets/textures/satellite_beam";
  glow = true;
};

...my network layer stopped crashing.

Now, like I said, I'm sure there's something else going on, and I'm pretty convinced it's going to bite me in the tail later, but this simple little change fixed it for now.

Very strange.
#8
08/08/2006 (9:04 pm)
Finally!

I've sussed it out to where it makes sense. Don't ask me why the formatting of my materials caused the program to exhibit this behavior, but I've managed to remove the behavior itself.

The issue is simple... My client is changing servers. After issuing the disconnect, it should schedule the next connect, rather than immediately trigger it.

I suspect others are probably already familiar with this necessity, but ya gotta at least admit - what a weird way to exhibit the bug. If I format the material one way, or comment one of the materials out, no problem...

I love being a coder, I love being a coder, I love being a coder...
#9
08/08/2006 (10:35 pm)
Putting the squiggly brackets at the end of a line looks messy.

The coding gods punish you.






Just kidding, of course.