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:
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.
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.
#2
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.
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
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.
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
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.
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
In the meantime, has anybody seen anything like this?
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
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:
...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.
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
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...
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
The coding gods punish you.
Just kidding, of course.
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.
Torque Owner Tim Holt
If you go and comment out other materials and leave these two alone, does it have any effect?