Does anyone use this to check their maps and if so, can you tell me if the output from running a Quake1 map through it gives accurate information.

In other words is it exclusively a Q2 utility? 

Yes, I do use it for Q1 on occasion. And only part of the info is useful for Q1 maps (e.g. bad brush output). 

aguirRe, you are, without a doubt, THE MAN. 

Although if you added coloured light you would be THE MAN x2 

 

kind words guys! Although I'm still a bit unsure of what it is in this release that you seem to like so much ... 

I think it's just the overall support and improvements that you have made over time, and not just this release. I think the auto converting from Q2/Q3 format to Quake is very nice. just takes that extra step/prog out and makes it a more complete package 

The Q3 support.

I've been wanting to use your BSP compilers for a while now, for the better error reporting etc... but since they did not import Q3 map files directly, I used DuBSP instead. (Got to thank Riot for his tools, too!)

I could have used a map converter before, of course, but you know how it is (ohm's law.. path of least resistance... )

Now that your BSP(s) have the same q2/3 importing as DuBSP, I can have the best of both worlds. 

I'm building a map for quake 1. After adding some new monsters and brushes I get error after launching the map in quake (winquake, joequake). The error is "SZ_GetSpace: 8024 is > full buffer size". I get this error only after switching skill to 2 (means more monsters). Please help! Do I have to remove some entities? I wouldn't like to. 

Take a look at my engines and the readmegl at http://user.tninet.se/~xir870k , they're specifically modified to fix this issue (and others).

AFAIK, the error is caused by having too many entities and events happening which cause the protocol between the server and client parts to overflow.

Typically this happens on higher skill levels since there are more action going on. The recently released Menkalinan had a similar problem.

I believe that either you'll have to cut down on entities or require a custom engine that has a higher limit. 

Found a serious bug in Light 1.36 that invalidated light data when using -onlyents option.

I've uploaded a new version 1.37 to http://user.tninet.se/~xir870k that hopefully fixes this.

Sorry for the inconvenience. 

Ok chaps, I'm having a spot of bother when it comes to deciding whether or not to scale up my terrain textures for performance reasons.

I'm aware that the whole issue of scaled textures is a bit of a salty subject around here. Should I go with the aesthetic and keep the rock textures at 1:1; or should I use *gasp* double scale and maybe squeeze a bit of juice out of the old nag? 

i really depends how carp it looks at 2x scaling... some textures scale better than others... best bet would be to experiment a bit... 

Also, it depends on how close the player is. If the player is kept 512 units away, then you would be more likely to get away with a scale of 2.

Also, I don't think you would get many complaints if the change in scale was appropriate and well thought out. Doing it randomly or on a global scale is a bit different. 

that I can't gauge an accurate reading of the wpoly's until I've fullvised the map (which I won't be doing until I've completely finished the map) so my question refers to a sort of "general case" scenario really. Those of you who have seen the early screenshots should have an idea of the extent of the terrain involved. 

Thanks. I guess a logical compromise would be to keep the flat ground texture at normal scale and apply double scale for the mountains - the problem is though, the player can walk over the mountain terrain at certain points, so I can't really avoid contact with the scaled textures all the time.

Worth bearing in mind though is that my only real problems with scaled textures are: a) the dynamic lighting issues, and b) the ugliness in software mode. Some custom engines have fixed point a), and of course in that case, point b) is irrelevant anyway. 

I'd say go for the scaled look, it'll reduce the effect of tiling if the faces are large. A good rock texture should tile without looking especially odd, but over enough repeats the human eye is good at noticing the pattern. I'd say that combine that with the performance boost and the positives outweigh the negatives. 

the best way I have found to avoid the pattern issue is to fire up Photoshop, use the filter/distort/twirl, and I recommend twice. Once clockwise, a second counterclockwise, so you will have three seemless textures that fit together to avoid repeats.

I would have just e-mailed you an example that I was working on over the weekend, but I have been having some problems with my e-mail. 

you want a rock texture to repeat over a large expanse, try making a larger rock texture. Say, 256x256. 

256x256 is still repeated 16 times over a 1024x1024 surface. 

oh, right, so i guess the solution is to make it 65536x65536. What was I thinking? 

No, that's just silly. The Quake map bounds only go to +/- 4096. 

I appreciate the comments :)

My rock texture is pretty big anyway (512x512) and I have decided to scale it 2x. I think it looks good even at close range actually :) 

I always thought that this was related to the number of sounds that were being generated at the same time, and that when the maximum was breached, packet_overflow occured and the sound did not play.

I have areas of my map that are not generating large numbers of sounds but I get the PO message. I have a constant sky(?) howl, I have some water, no live monsters within the map (I have killed them all and have plenty of bodies), no doors/platforms operating, no nearby secrets, and I am not shooting at anything.

I am using Fitzquake. Any ideas? 

... and I have not yet done a full vis.