by VolumetricSteve » Wed Jan 13, 2010 11:40 am
Well, thanks me. You figured it out, and here's how :
turns out, the file that was called default_shaderlist.txt is .....apparently there for fun, and doesn't have an immediate impact on anything. Thanks.
the file that actually tells NetRadiant what shaders it can load/use is not actually a part of the program....like...every other part, this one is cleverly hidden in /Applications/ioquake3/baseq3/scripts/shaderlist.txt and as far as I can tell, is only noted in the log files if something unusual happens. So I saw this file and thought "huh, shaders, I like those...while I can't assume this file does what I need, because it would make infinitely more sense to store this data internal to NetRadiant rather than in my baseq3 directory and thus this will probably be a dead end, I should mess with it anyway" Turns out that was the magic file, and looking up the list of shaders in quake 3's PAK0.pk3 file, and updating shaderlist.txt accordingly fixed all of my shader loading problems, now it loads shaders I didn't even know where there.
they don't look right in NetRadiant at all, but once the level is compiled, they come out fine. I'm still working on a way to force NetRadiant to load things.....correctly. It doesn't make sense....
NetRadiant loads the shaders, the shaders then point to textures, jpgs, what have you, the shaders clearly work because they compile into the maps, and they point to the same texture data that's seen by NetRadiant in other places.....so for one reason or another.....NetRadiant just doesn't care that the shaders i'm loading have textures. Until I can reverse engineer it enough to figure out why that is, I'm just using shaders as I go and keeping a list of what shader names look like what textures. Some of the shaders just don't work or don't do anything, so I'm writing those down too.
I imagine there's just an unknown universe, or some deep truth to quake 3 mapping/compiling on a mac, but it's painstakingly hidden and horribly undocumented. In my own tests, I've seen that GTKRadiant 1.4 only works on PPC based macs, 1.5 might have worked but I've never found it as useful as 1.4 at all. I know, at least for me, on my Intel mac, OS X 10.4 and 10.5, neither of those work......they just don't, no errors, no pop up messages, nothing, they simply do not function. So in a sense I've been cornered into using NetRadiant, though I like that it's smaller, faster, not as buggy as GTKRadiant, and hey, it opens! The key advantage being that it at least opens......but it doesn't come with Q3 compatibility built in, which is baffling considering it's a "Stabilized Q3 level editor".
I was told I could just use the q3.game file from GTKRadiant to make it work, that was an outright lie. I had to find someone's specialized NetRadiant-compatible q3.game file to make it save quake 3 maps. Even that just barely worked, I've had to tweak it considerably since I got it.......just........does no one else use NetRadiant on OS X that such huge problems go unnoticed? Is it just me vs. someone's nightly unstable netradiant build? After hours of tweaking, looking through code, the program I have now is ALMOST something that I'd think is release-worthy.....which is ok......if the program is in alpha stages....saddly, not the case here.
I'm almost tempted to make a geocities site that mirrors the official build of NetRadiant, and says "well, here's the final program for OS X, but wait, just kidding, it won't work by default, you have to screw with it for a few days before it's actually useful" and meticulously document the changes i've had to make to it to make it work the way it's supposed to(kinda). Oh well, at least it opens.....a refreshing change. Someday I might just be driven insane enough to make a java-based Radiant.
I hope those notes and thoughts were constructive. - me
