I have a vague recollections that windings are to do with the number of sides a polygon has. Do you possibly have a face anywhere with more than 64 edges? Perhaps not intentionally, but if you had lots of adjacent planes that nearly meet at the vertices but actually cut tiny slices, that might create one.... 

I'm not exactly sure what you mean. How could a face have 64 edges? They are all triangles. Or do you mean one plane that has been divided more than 64 times? 

In fact in glquake they're still polygons when passed to OpenGL. Just for fun I checked start.bsp and it has a 20-sided poly somewhere!

So "r_showtris 1" is a bit deceptive; it shows you the polygons as they come out of the bsp, plus a bunch of lines drawn in to divide them into triangles, but you can't see which lines are which. 

r_drawflat shows polygons. 

Windings are used in a lot of places in the code, also for portal generation. I think mfx managed to find a version of your map in your house while you were sleeping online and it had a very large ring-like structure in it with a lot of side elements.

If a portal is generated inside this, it can easily go over the 64 point limit and cause this error to be thrown. 

Breaking limits since 2003! 

Once you've found places where that happens, shouldn't it be possible to use a hint brush to break that ring in half/quarters/etc so that can't happen? 

Necros, the file flew by on the TB issuetracker, had to grab it to reproduce the error.
I also had no luck with epsilon values being changed slightly, but the hint/skip support of the above mentioned compilers should be able to eliminate the error.
Without having to raise the max_windings of course.. I keep you updated.

Sorry for any inconvience caused:) 

Cool, ok, so it is fixable then... Yet flying around in the map didn't show me anything obviously having tons of edges. Some faces had maybe 6 or 7 sides, but most were split up to 4 or less sides.

and it had a very large ring-like structure in it with a lot of side elements.
Not sure which map you're talking about, but this is a new one with a very similar concept. It is a large ring of windows. So since I don't see any faces with a lot of edges, it sounds like it must be this case where a portal is being generated inside this ring. 

I've built a demo smoothing utility for DaZ, and even though I suppose it's of limited use, I'll post it here anyway in case anybody is curious and in order not to give any particular youtubers any unfair advantages!

http://mandelmassa.net/quake/demsmooth-1.02.zip

The binary is a 32 bit Windows build made with mingw32-gcc in cygwin. Source is here:

https://github.com/mandelmassa/demsmooth 

this is the method used to get the smooth camera movement? 

I think DaZ has used it in some of his latest Quake videos, for the intro bit. That's what it's intended for! Using it on regular play demos might render unexpected results since it's tuned for slow movement. 

I just converted one of my normal play demos with it and it looks like I'm drunk or stoned playing. 

It was made in response to the now classic january 1st W00tles post! 

That's a very cool utility! I thought he was placing waypoints or somesuch, but this method of doing a flyby camera is way more intuitive and simple! 

Fixed a bug with parsing Fitzquake spawn baseline messages - the program couldn't parse my own jam2_mfx demo so I just had to debug it.

http://mandelmassa.net/quake/demsmooth-1.03.zip 

Mandel, please write Quaddicted a demo meta data extraction tool for 15, 10002 and 666. Something that extracts statistics like kill/secret count, length, completion, skill, maybe even shots fired or distance tracked if that is possible. Thank you! bye! 

I just might! 

In triggers.qc:

void() teleport_use =
{
self.nextthink = time + 0.2;
force_retouch = 2; // make sure even still objects get hit
self.think = SUB_Null;
};

the purpose of force_retouch is clear, but I've always wondered why a teleporter had to have its nextthink set just to do nothing. Is that more obtuse secret qc behavior related to how force_retouch works? Or just cruft? 

beware of force_retouch! it breaks trigger_hurt!

anyway, the touch function:
if (self.targetname)
if (self.nextthink < time)
return; // not fired yet

it uses nextthink as a random timer for some reason. just weird code. there's no special engine magic needed here, just the sub_null thing to stop the engine complaining when it does try to do its think magic.

it should have used attack_finished... 

Has caused me a load of headaches - a lot of the code I ported used it in loops, some of them per frame (!) which was raping FPS. 

 

Not sure what the intention was with a lot of them.

One in particular was causing a batch of triggers to touch themselves every single frame, meaning the more of that type of trigger I had, the slower it got. 

I meant "duh" to the answer to my question, since I could have just looked at teleport_touch and noticed it myself without having to ask anyone.


Some people just write code in incredibly bizarre fashion. They get fixated on entirely the wrong approaches and then use them for everything. I wish I remember what game it was, but some high profile indie game's source was available on pastebin or one of those, and it was an astoundingly bad clockwork machine of almost 100% string manipulation, in one huuuge header file. Maybe someone else remembers? 

But probably wasn't.