Noted! 

interesting. maybe because i refactored a lot of the impulse handling and renamed the W_WeaponFrame method to player_processInput?
what do you check for to determine that there isn't support? 

a) It looks for an ImpulseCommands function. If it cannot find one, assumes there is impulse 12 support.

b) Found an ImpulseCommands function. Check for a statement that checks to see if self.impulse == 12. If found one, assumes there is impulse 12 support, otherwise assumes there is not impulse 12 support.

ne_ruins apparently has an ImpulseCommands function but doesn't check for impulse 12 there. 

"sv_fix_no_impulse12_exceptions" drips off the tounge like "r_nolerp_list", but could the approach be a whitelist instead of a blacklist? That is, a list of the old classic maps that need it.

The reQuiem impulse 12 hack is missing a 'default' fall-through during switch. The prev weap crash seems to be solved by coding the default to axe. But now next weap will fail... because it's not really an axe, it's a book or something... 

Well, there have to be a finite number of single player mods without impulse 12 support.

And in theory, if someone had the entire Quaddicted archive, could code an engine to switch gamedir to each gamedir and if impulse 12 support was not detected, write it to a log along with maybe ...

a) the CRC16 (what Quake uses), the filesize in bytes and maybe throw in a MD5 (because GitHub uses MD5 for file comparison and Linus Torvalds seems to how versioning down to a science)
b) and the file date and time from the archive.

1) Koohoo
2) Stuff using CustEnts like about all of Fat Controller's stuff
3) Probably a few random ones where the author could write QuakeC but used a bad progs base

Then you have to determine what dumb progs exist like Quake Progs 1.01 --- or is it 1.02? --- but catch the ones that aren't 1.06.

So yeah, whitelisting would work very well --- eventually. And would be the best solution long term. 

Ok, I see, instead of checking is self.impulse == 12, i assigned self.impulse to a local float _impulse and then check that instead. :(

void() ImpulseCommands =
{
local float _impulse;

_impulse = self.impulse;

if (_impulse >= 1 && _impulse <= 8 || _impulse == 250)
W_ChangeWeapon ();

else if (_impulse == 9)
CheatCommand ();
else if (_impulse == 10)
CycleWeaponCommand ();
else if (_impulse == 11)
ServerflagsCommand ();
else if (_impulse == 12)
CycleWeaponReverseCommand ();
 

Stumbled on a strange glitch while testing a new palette.

http://i.imgur.com/m38oeEe.png

Re-entering the map didn't change anything, but after restarting the game everything was back to normal. Only the torches, flames and hanging zombies seemed to be affected.

The way the zombies looked like random lumps of gore, twitching and extending their "tendrils" in semi-random directions, actually was pretty cool.

http://i.imgur.com/R7zye7B.png

I think it's an interesting idea for a new decoration, or an environmental hazard. Only if properly executed, of course.

Version 0.91.0, non-SDL2. Nothing suspicious in stdout. 

Weird, I haven't seen that since the new mdl renderer was still being ironed out.

If you find a way to reproduce it that would be great, but I assume it's an unlikely combination of conditions to trigger the bug. 

Is there a way to turn them off? I think that those 1 hole decals are super ugly and don't look right in any way shape of form, so if there is a way to turn them off, that would be nice to know. (And if not, it would maybe be nice to include a way, though it might be a bit of a niche request) 

I agree that the SoA decals look rougher than a badger's behind, but they are purely QC-based so the only way to turn them off would be for someone to create a modified progs.dat 

or you could stamp over the sprite by making an invisible sprite with the same name, and putting in (for example) pak1.pak in the hipnotic folder 

That might actually be worth a shot. Good idea. 

Just did a quick replacement and it works like a charm. Here is a zip with the PAK for anyone who wants it.

https://dl.dropboxusercontent.com/u/15588722/post/func_msg/hipnotic_nobulletholes.zip 

 

Version 0.92.0 of QuakeSpasm is released.

http://quakespasm.sourceforge.net/download.htm
http://sourceforge.net/projects/quakespasm/files/

Changes since the previous version:
https://sf.net/p/quakespasm/news/2016/07/quakespasm-0920/ 

And thank you very much for your support in providing compatibility with oms3. I know its old news by now, but I appreciate all the steps you took to make it work. :) 

Couple of quick questions.

I'm trying to decide if I should add my IRC code to this version to release for QExpo rather than version 0.91.0.

Does it offer anything in the way of stability or bugfixes beyond what is stated in the notes?

Are you planning on releasing this for QExpo, and if so, do you want me to delay the official release of my code? 

The changelog is pretty much it: no other notable differences between 0.91.0 and 0.92.0. As for the qexpo thing, I have no interest in that. 

Hello, the latest quakespasm appears to be totally unresponsive to my controller.

Controller is a bog standard official "XBox 360 Controller for Windows", with up-to-date drivers. It also works fine on other games I use it for.

I have also done what it says in the readme and downloaded the gamecontrollerdb.txt file to the quake folder, but it does not help.

Any idea how I could troubleshoot this problem? 

@Kinn make sure to run quakespasm-sdl2.exe, only that .exe has controller support.

I have the same controller (wired version), tested it on Windows 10 and OS X so far.

Also, check for any "joystick missing controller mappings" or "failed to open controller" messages in the console. 

Cheers - that's it - mea culpa :}

Btw it's AWESOME - default sensitivities etc. are pretty much spot on - now I can sit back in a comfy chair and play quake and its the bestest thing in the world ever :D 

 

 

ur just jelli u don't have the gamepad skillz. 

>gamepad
>skills