SP - flamethrower problem w q3map2

(kat) #1

[EDIT II] for help fixing the shader overflow bug read the following extensive info

[EDIT] oops - this is related to SP mappage

ok… there appears to be a nasty problem with Q3map2 that effects the shader/textures used for the flamethrower and the treasure item skull effect.

I’m still testing this out to make sure it not some thing I’ve done (usually is…!) but did a test compile of a current SP map using .36 & .37 versions of q3map2 and a ‘default’ comparison compile using q3map from GTK 1.2.10.

The base compile using Q3map doesn’t show this problem, everything shows up at usual - the q3map2 compiles show the problem on the flames and the skull (it’s the white-ish transparent texture on the ‘ghost skull’ (skull/skul2t.md3), the initial flame spurt appears to be ok, its the rest that’s fubar’d

A bit more info:

  • the base compile was done from the BSP menu in GTK 1.2.10 : it was a -VIS -LIGHT compile
  • the q3map2 compiles were done from Q3map2toolz with custom options : BSP = -meta -patchmeta; VIS = full; LIGHT = -filter, shade, patchshadows, -shadeangle 30, super 2

Everything seems to be compiling without errors except the problem outlined above.

anyone got ideas on this??

[EDIT] I’m just doing some basic q3map2 compiles to check it’s not one of the ‘extra’ options…

(U.S.S. Speed) #2

To me, it’s maybe a “/” vs “” error.

Don’t read what I said if it’s stupid. :smiley:

(kat) #3

not quite sure I follow you as this isn’t a custom shader, it’s a default one… unless the wrong / \ in another shader would have that effect… is that what you mean??

update:

  • a base compile of -full -light using q3map2 2.32 has same problem (via q3maptoolz)
  • checked shaders no / \ errors
  • swapped out q3map for q3map2 +dll’s in the GTK folder, compiled, same problem, so far it’s not the GUI (toolz or GTK)
(Old_Fellow) #4

Do a q3map2 compilation without the -meta and -patchmeta switches and let us know the result.

(kat) #5

just done… a -full -light
.32 = problem above
(.36 = not done yet)
.37 = problem above

GTK 1.2.1 q3map = OK
[a ‘base’ test as far back as I can go, also on a ‘clean’ *.map version of the same file above - I wasn’t re-compiling ontop of previous versions]
GTK 1.2.10 q3map = OK

(U.S.S. Speed) #6

What I mean, is that if I’m correct, Q3Map2 doesn’t support the wrong slash.
While Q3Map does.

The screenies look like polys with no shader tagged to it. So I tought it could have been a wrong slash error.

(kat) #7

ah ok, so if that was the problem the ‘/’ ‘’ error would be in RtCW’s default shader for that effect right?? hmmmm…

(U.S.S. Speed) #8

Everything is always possible, but it’s probably not that.

(kat) #9

just trying .38 see if that helps…
:???:

(RR2DO2) #10

I take this is rtcw SP? It looks like a bug that was fixed in the MP executable, but afaik is still present in SP.

(kat) #11

Yah it’s for SP (could have sworn I mentioned that…!! edited post above to reflect this).

What I don’t understand is why using q3map2 causes the error but not q3map? It doesn’t show any probs with this… it’s very wierd.

(demonspawn) #12

Kat I also had this problem quite a while ago with q3map…not sure if its the same issue but I corrected mine by removing unnessary shaders being loaded, something about too many shaders bieng loaded caused a the editor to use what ever shader it got filled up with and applied it all over the place…my tree’s were simple wierd.
Hope this helps, I thought it was fixed in q3map2 but I could be wrong.

(system) #13

I had this problem just a view mnths ago with my bismarck-map and it was suddenly fixed with a patch that came out.
I think it was some kind of shader-overflow (can’t remeber).

If you optimice your map or mabe make it smaller. Making my bismarck smaller helped.

(kat) #14

shaders as used by GTK on (loading a map &) compiling??.. Hmmm I’ll have to look into condensing them a bit… again what I don’t understand is why this problem only happens when using q3map2…!?

Fiesling : you mean make the map ‘physically’ smaller…? that’s a no go I’m afraid and based on it’s current size the VIS data could be made smaller but at 95k it’s hardly a braindrain for the game engine…

(kat) #15

just cleared out my scripts folder so I had the defaults only plus a condensed version of my scripts all in one file… that didn’t help so it’s not a ‘number of…’ problem.

(kat) #16

It’s a shame this can’t be fixed. I hadn’t realised going back to q3map would show up the big advances made in q3map2 especially regarding terran and ‘smoothing’ the lighting on those which is why I was using it. Going back to q3map means a bit of Heath Robinson mucking about to get good lighting on trisouped brushwork but it’ll have to do…

(Arno) #17

I had the same problem.
Adding the -nocollapse tag to the light stage fixed it for me.

(kat) #18

-nocollapse kinda worked, it removed the problem from the skulls but not from the flames.

(kat) #19

Whilst I’ve kinda given up trying to use q3map2 for this I’m still trying to track down where and what the problem is… just did a ‘giveall’ and tried the weapons, this error effects just about all of those using a weapons ‘flash’ as part of the firing animation - the explosives also show the same error - the only weapon that doesn’t is the StenGun (this was after using the new 1.2.12 GTK and a default q3map2 compile option -vis, -light -fast -filter)