Click on the "download snapshot" button here for the latest code.
https://sourceforge.net/p/quakespasm/quakespasm/ci/master/tree/
Sorry, but i don't know much about it. It's possible in some world editor CR/LFs can get inserted into level names ?? Oz said he's seen this bug/little idiocy before, but wasn't until yesterday he'd tracked it down. 

I think I've seen embedded " characters in strings cause the same error sometimes, but that's off the top of my head... 

Because that seems to be the common theme in the case of retrojam1_skacky and autumn_sp.

Still wouldn't explain what's happening with retrojam6_danzadan on my end; I checked the source and there are no odd characters, hidden or otherwise, in the worldspawn message. Or did you mean something else?

Thanks for the link to the latest build, stevenaaus. 

If you could share a copy of your save file somewhere it would help. At this stage it's not something obvious, nor is it easily guessable. 

Sure, here you go: https://pastebin.com/Ru2G5SiK 

That save file is corrupted and missing most of the save data, so it'll never work. 

Yeah, I gathered as much. What I was wondering was why Quakespasm consistently generates corrupted save files when I try to save while playing retrojam6_danzadan (whereas other maps save/load properly).

But never mind; I seem to be the only person experiencing this, so I'll just put it down to some weird anomaly on my system. It's definitely not a serious problem for me. Thank you taking a look and thanks again to everyone else who responded. 

Thank you FOR taking a look, I meant to write. 

No problem.

It's interesting that it failed at the "WAD" key in worldspawn - I wonder is that part of it consistent too? 

The wad key for that file is

C:\Program Files (x86)\Webteh\New folder\quack\Textures\Repacked\quake.wad;C:\Program Files (x86)\Webteh\New folder\quack\Textures\Repacked\BlueQ.wad;C:\Program Files (x86)\Webteh\New folder\quack\Textures\Repacked\CopperQ.wad;C:\Program Files (x86)\Webteh\New folder\quack\Textures\Repacked\MedievalQ.wad;C:\Program Files (x86)\Webteh\New folder\quack\Textures\Repacked\MetalQ.wad;C:\Program Files (x86)\Webteh\New folder\quack\Textures\Repacked\RockQ.wad;C:\Program Files (x86)\Webteh\New folder\quack\Textures\Repacked\WizardQ.wad;C:\Program Files (x86)\Webteh\New folder\quack\Textures\Repacked\WoodQ.wad;C:\Program Files (x86)\Webteh\New folder\quack\Textures\Repacked\AncientQMP.wad;C:\Program Files (x86)\Webteh\New folder\quack\Textures\Repacked\BaseQ.wad;C:\Program Files (x86)\Webteh\New folder\quack\Textures\rmq_darkmet.wad;C:\Program Files (x86)\Webteh\New folder\quack\Textures\Repacked\ABrutTx.wad;C:\Program Files (x86)\Webteh\New folder\quack\Textures\AB\abEgypt.wad

So it's 983 character long - is it overflowing a buffer somewhere? 

Could it be the combination of a long string and needing to escape loads of backslashes? Perhaps the buffer overflow is in the string escaping part of the code? 

That's probably it. Edict writing to a save file goes through PR_UglyValueString which is 512 chars by default but which QS at some point increased to 1024. 

I keep receiving a noreply.com on my email, even when using no addons. your email was bounced
You're having quiet a restriction on your box. 

off topic 

I haven't done anything like that myself! I can only think that it's something automated the email service has done, possibly a spam filter malfunctioning? Or if you're emailing with an attachment it could be a false positive on the virus protection. I've added you as a contact now so try again and see if that helps. 

It's interesting that it failed at the "WAD" key in worldspawn - I wonder is that part of it consistent too?

Yes: I checked again by creating a few separate saves and they all fail at "wad".

And after reading #3686 - #3688, I tried a little experiment where I extracted the textures from the bsp into a single wad and then recompiled the map with a short and simple path/to/wad. That solves the problem: saving and loading work as expected now. So I'm guessing that confirms your theory, Preach? 

i love xinput support for sp quake, but i have one question. there seems to be no forgiveness on the sticks regarding input on the x axis. what i mean is, whenever i take off forward in game, if i dont hit dead center with the stick i immediately begin strafing left or right. its almost a dealbreaker for being able to use the controller. ive tried adjusting all the variables, deadzones etc. is there any remedy for this? thanks so much in advance. 

Hmm kinda weird that changing joy_deadzone doesn't fix that. 

@ joel

my impression is that while im within the deadzone there is no input (obviously lol) but as soon as i leave the deadzone and the game registers the y axis input it also begins the x axis input. as it currently is ranger is constantly failing the sobriety test.

the way i visualize it is like a clock and if the stick isnt right at 12 i get sideways motion. it would be a big improvement if there was no x axis input between say 11:58 and 12:02. some type of cvar buffer zone to forgive frantic play. 

Is there a setting/cvar to control if the music track is restarted when the same level is restarted or a save game is loaded? In DOOM (at least in modern sourceports) the music is not restarted if you restart/load the save with the same level and it's so much better this way.. 

why is it better? is it because you want to play your own music and it keeps getting overridden by the engine? 

No, when playing tough maps it's often frequently saving-loading or dying-restarting :D and every time that happens, music restarts. I'm talking about the original NIN/Reznor's soundtrack (though I am using OGG/MP3, not CD).

I do realize that's the "proper" behavior like the original game had, though. 

In general the problem with this kind of request is that for every one person who wants it one way, there will be another person who wants it another way. Unless it's very obviously broken (I don't see too many defending how GLQuake drew skies) it can even be impossible to get agreement on what the default for a switchable behaviour should be. Sometimes "when in doubt just do what the original engine did" is the only sensible approach. 

Understandable. Make the "original engine way" the default one, and introduce a cvar/option to have alternate? There are many such cases in general in sourceports anyway... 

I know what you're talking about... a lot of the background tracks evolve over the minutes, and it feels a little weird if you reload to a super-recent savegame and the music resets all the way to the beginning. That's especially true with a lot of the recent custom music we've been getting which is less "ambient" and more melodic.

I dunno what the ideal behavior would be, but this probably isn't it. Anyway yeah there's currently not any way for either the player or the mapper to choose a different behavior.