JPG was created for photographs. If an image is not a photograph then JPG is probably not the best format. In particular, JPG is a poor choice for images with large areas of the same continuous color, such as many web page graphics.

JPG is not intended for images which will require additional editing, but for an in-game snapshot is probably fine. The option for a higher quality image would be good to have, but I would not consider it a necessity for a game. 

Hi!

While playtesting a map I'm working on, I got a stack overflow bug: First, I pick up the quad damage, enter the door to the left and then aim somewhere between the Enforcer and the radioactive container in front of him. I could fairly reliably get the following stack overflow:

CALL4 1705(T_RadiusDamage)T_RadiusDamage()
misc.qc : barrel_explode
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
weapons.qc : ApplyMultiDamage
weapons.qc : AddMultiDamage
weapons.qc : TraceAttack
weapons.qc : FireBullets
weapons.qc : W_FireShotgun
weapons.qc : W_Attack
weapons.qc : W_WeaponFrame
client.qc : PlayerPostThink
<NO FUNCTION>
stack overflow
Host_Error: Program error

The map can be downloaded below:

https://www.dropbox.com/s/i43hcljprz3c45f/bugmap.zip?dl=0 

I've reliably reproduced this too.

Increasing MAX_STACK_DEPTH in pr_exec.c to 64 is sufficient to resolve; a lower value may also do but I didn't bother testing.

It's caused by a large amount of exploding boxes in close proximity setting each other off. 

I remember running into this issue myself once many years ago. I was under the impression it's simply a common Quake bug/limitation, but I can't seem to reproduce it in Winquake/GLquake using Esrael's map. Does it occur everywhere or is it actually something introduced in and carried over from the Fitz code? 

It's a hangover from the original ID code.

You need to be very specific about this because it's the chain of effects that sets off the stack overflow. Hence you need the Quad and you need to be in the very specific situation where there are 6 or so exploding boxes in close enough proximity.

You shoot near one box, the Quadded shotgun explodes it, it triggers the next box to explode, which triggers the next box, and so on.

Each explosion is 4 function calls: barrel_explode for the explosion, T_RadiusDamage from he explosion, T_Damage to the next box, then Killed which kills the next box and in turn sets off another barrel_explode.

Removing one of the boxes should be sufficient to prevent it ever happening.

I also have engine code somewhere that effectively gives you an infinite stack (at least until you run out of memory) which would also more robustly fix this and other similar issues. 

findradius is just all kinds of evil. its possible for exploboxes to be skipped entirely too, depending on how .chain gets clobbered by the different explosions.
Frankly, calling T_RadiusDamage inside Killed/.th_die should be considered a bug, fixable by delaying it to a think function. This also fixes the above crash, too. 

While playtesting a map I'm working on, I got a stack overflow bug ...
This is a bug in QC that happens on anything with a call to a radius explosion function within a death event.

This is why tarbaby.qc (line 172) delays the explosion to the next frame. So that you cannot get a chain effect and stack overflow.

The misc.qc - barrel_explode function is broken. It should delay the radius explosion one frame and it would be fine. I fixed this in AD QC if anyone wants an example of this. 

 

But yet ID1 progs does it. If ID1 does it, is it still a bug? 

... yes?
findradius cannot reliably be used recursively like that. there are other symptoms than just the stack overflow.

is it time for eg quakespasm to throw a new progs.dat into its .pak?.. 

Some mappers use extremophile abuse of functions (see Teaching Old Progs New Tricks).

There are plenty of maps that use "BecomeExplosion" and an array other nuances in the original progs. As a result you can take a map like dm3rmx and run in, say, ezQuake which supplies its own single player progs that was written more efficiently and then it goes to console with a QuakeC error when a tricky map calls something by name that was written in a slightly different way.

It is quite possible to make a cautiously "improved" progs.dat that breaks existing maps.

Situation where the progs.dat is the worst possible progs.dat except for all the improved ones where some of the "bug fixes" and "code cleanups" are not bug fixes but bonafide behavior changes.

It used to be common for a number of QuakeC coders to have their own "cleaned up and better" progs.dat. I have seen the source to about 10 of these from the original CleanQC to ScratchQC to public ones coder [insert coder X, coder Y, coder Z] made for a QuakeExpo and such.

I have not seen one without random arbitrary behavior changes, although sometimes it is incidental, but most of the time it is apathy or indifference.

Often the guy that only knows deathmatch breaks something in single player, the guy that only knows single player breaks something in deathmatch, or someone corrects a "bug" by breaking something not important to that coder or "fixing" something that shouldn't be fixed or that they didn't understand is a behavior change.

It also doesn't take much to make save game files incompatible with an "improved" progs.dat.

(No I haven't looked at the source code for gnounc/jonas 1.01 one so I wasn't referencing that one anywhere above. Can the 1.01 version load a real Quake progs.dat save game? I don't know.)

/Possibly preventing rarely known issues. But it was boring typing that. 

It also doesn't take much to make save game files incompatible with an "improved" progs.dat.

Like what, any example? 

imo the right place to fix this is in "clean qc"/"bugfixed id1 progs" type of mod.. and maps that need the fixes would target that mod 

he means different precache_model+precache_sound calls, which is why dp+fte+qss save the sound+model precaches into the saved game.

Next Baker will be arguing to leave all the segfaults in... 

if its so important that everyone have the exact same progs, then maybe quakespasm should include a copy of progs 1.06 for all those people with cd versions that came with 1.01

throwing in some extra things that mean we don't need more absurd+awkward function hacks can only be a good thing. 

My monster randomizer for the speedrunning community breaks the save files... and breaks it hard. 

Now I wonder what code have you added :) 

Looks like I had stirred up quite the discussion touching on the very fundamentals on what to fix/improve/modify and where.

How about I just remove that one explobox from my map to remove the stack overflow, and we all forget this ever happened, shall we? ;D

But in all seriousness, it's good to have this discussion. Seems there really is no clear-cut right answer for it. @~@ 

Start a map, pick up some guns, shoot some monsters leaving some alive, open some doors, turn on some lights and save.

Now open the save game file.

Look at the monsters and the doors, etc. in the save game file.

Now realize if you change the names of any of that stuff in your progs, it can't load that save file.

Go to the Teaching Progs New Tricks thread, realize if you rename any of that stuff or rewrite how it works, any of the maps using those tricks are now broke with your progs. 

Ahh, ok. Just opened saves and now I see what you mean. Idk why I never opened Quake saves. I probably thought they are binary...

So if I keep names intact and just add new stuff, it should work just fine. Only problem with this approach might be when there is a new field added to some entity and it's not available in save file. This field will become null or empty after loading. 

Exactly. Breaking things would simply be normal. Someone would have to set out to deliberately not break things.

Adding fields? Well, now you are making a mod, not bug fixing the original progs.

Makes as much sense as saying "Hey everyone! I created an different flavor of vanilla ice cream!"

If you see my point. 

Adding fields? Well, now you are making a mod, not bug fixing the original progs.

Yes, I was thinking more about mods compatibility, so they don't break vanilla behavior etc. That's why I was curious about saves.

But speaking of vanilla patching, I agree, it needs to be made carefully, with lots of testing and solid code review, with attention to backwards compatibility.

It might be a little tricky to refactor vanilla progs, but there are many smart guys in this community, so I'm optimistic :) 

http://imgur.com/fCG3ovD

What causes this "Host Error" ?

Im using the newest version that was released with ad_sepulcher 

that is "quakespasm-spike-admod"

it works fine in "quakespasm-spike" 

I got a few instances of older maps that don't load with the AD1.6 mod. In their case, I got some Host errors. Loading them with the ID's default goes well, though.

I wonder what may brake some maps with the AD mod ?