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. 

Hey, so ... Is there an easy way in QuakeC to determine that the player has seen an entity for the first time? Like, an ammo or health pickup for example? 

hmmm not exactly.

you COULD just make a function call that continously runs every frame that checks all entities and marks any items it finds as seen, but that's pretty wasteful and might even cause slow down if there are enough entities in the loop.

Alternatively, you could create a one time, on map load function that builds a new list of only items and then the previously mentioned loop could only iterate through that list.

A simpler, but more manual method would be to just have triggers that mark entities as 'seen'.
This is the method I used in ne_ruins for a few ammo boxes. They are dynamically changed between small or large when the trigger fires on them but only once, so if the player has triggered the check when they had a lot of ammo and the boxes are small, they won't become large boxes later if they revisit the area with low ammo. 

Yeah, that's what I wanted to do ... dynamically scale health and ammo to the players needs. But I guess I won't. That sounds like a lot of trouble and really too much work for what it is...

Thanks!