Is there a way to skip the credits when pressing quit from the menu? It's a little thing, but after using QS for so long I'm not used to pressing another key to get out of the game. 

Type "quit" in the console or click "X" to close window or bind "quit" to F12. 

Alright then, binds it is. It'd be nice to have as a config option at some point though. 

I've the "install" so it can figure out .zip files arranged like retrojam5. In testing, never hit one setup like that, but so many packs out there.

/I always hit ALT-ENTER and then click "X" to exit. Or pull up console and type quit. Quake out of the box and most engines (like FitzQuake 0.85) show the closing credits via the menu route. 

I think you might have a typo in your command line or are missing -nehahra, because I already coded for this scenario.

yeah, i missed that additional -nehahra argument

but for some reason console barks on missed fmod.dll module, and i have one in my quake folder 

Try putting it in the nehahra folder. 

is it possible to fix nehahra's nomonsters command
there is a strong c++ guy needed tho 

nomonsters 1 - and they don't act so crazy

They still move a little funny, but not insanely funny. 

I seems like the func_illusionary mirror support doesn't work so far. I'll experiment more with that when I get from work. 

I'll be taking care of that. You need not worry about that. Haha.

Before the night ends in my time zone on the other side of the world, there will be mirrory func_illusionary.

When the guy who made Menkalinan, one of my favorite maps of all time, has an idea -- yeah, I think I want to play that map ;-) 

I thought about putting instructions on the proper way to run nehahra on the page for Mark V. Or even block / warn in the engine.

Then I decided against it.

The way I see it --- when knowledgable people like yourself encounter a small issue, it enables the knowledgeable crowd who read the discussion to help the newbies who would mess it up no matter how hard I documented it. And gets the less knowledgeable to read threads to expand their horizons.

Also: the awesome thing about func_msgboard is that the participants are expert level and through discussions in threads like this, it educates to create more knowledgeable users. 

You need that one. One in Spirit's very nicely repackage is not good fmod.dll. 

Done for next version, but no time to build on Windows and then the Mac and package and rebuild the installer version, etc. etc.

1) Mirrors for func_illusionary, mirror scanning moved to cls.signon == 2 (after all the static entities received, walks any statics too. Tested by turning an E1M1 door into a func_illusionary as a test)

2) IPv4 printing on Mac fixed
3) Mac startup fixed when Mark V isn't in a proper Quake folder
4) Autosave was saving as wrong name, fixed.
5) Installer can handle zips like RetroJam5 which had unanticipated structure.
6) Non-issue: Nehahra menu (already coded, lack of -nehahra caused issue)
7) Non-issue: Alpha channel 2D elements (already supported)
8) QMB reworked for gunter ... QuakeC originated particles either render via QMB consistently with expected appearance or if individually disabled, with QMB active, via qmb_particles_quakec 0 --- draw particle in the classic way. Results generally in a more mod friendly implementation of QMB, where its behavior is predictable.
9) Something else for the Mac. Forgot what it was.

Note to self: Update page with link to the codecs folder. Put a .txt in there that says name of parent site for each of the 2 and put the (slightly annoying) instructions to disable the XVID status window via the registry (i.e. Run regedit.exe and find key "HKCUSoftwareGNUXviDdisplay_status", set to 0.)

http://www.optimasc.com/products/vp8vfw/index.html
https://www.xvid.com/download/ 

any eta when I get to try out splitscreen w/ controllers? 

Yes, update! We are the test gorillas who want to beat on your luggage to see if it breaks!

https://www.youtube.com/watch?v=5b1aRop-UbU 

If you were ever interested either in upgrading the wrapper or writing a new one using Mark V, FitzQuake 0.85 or Quakespasm as the base...

OK, I've done the initial port of the wrapper to D3D9 with a Fitz 0.85 base (actually the original DirectFitz I made years ago). This is just the "do enough to get it working" stage, but it has established that (1) the port works, and (2) it's viable to move forward from.

If you have any requests for features to add to it, now is a good time. I'm thinking glCopyTex(Sub)Image and the full set of combine modes would be good candidates. Stencil. Fix polygon offset. Texture matrix stack. Vertex arrays. NPO2. I just mention these but without commitment to do all of them. 

If you have any requests for features to add to it, now is a good time.

1) Enough that I can do mirrors (stencil plus depth splitting trick - split range into 0 to 0.5, 0.5 to 1) .. Despite not having stencil, in theory mirrors should work in DX8 (without stencil, so glitches particular for the sky), but the wrapper hates me when I try and it doesn't work -- probably fighting an optimization.

2) 8x multitexture (which was easy, even for me), GL_TEXTURE_MATRIX (which I have zero chance of doing myself). "Combine".

3) The feature where you copy the screen to texture (FitzQuake's oldwater). Yeah, I know you aren't fond of that one. 

Mirror func_illusionary doesn't work for me in the latest release as well. I should have mentioned that these are AD func_illusionary, though I doubt they have any difference with the regular ones. I tryied both every side mirror texture brush and one face with with mirror texture and the rest covered by skip texture. Neither of them work.
I'll try to do that in vanilla quake and let you know if it works. 

No obligation and separate issue - but you've written controller support before and no one else does Microsoft Direct X type of coding on your level ... and XInput is probably similar ...

I've looked at the XInput tutorials from Microsoft and my head about exploded all the monotonous steps involved and not necessarily even understanding what is going on for sure.

Multiple controller support (hell even single controller) where each controller can be read separately once per frame.

-----
No obligation, but since that kind of thing falls in your wheelhouse, I thought I'd bring the topic up as an example of something nigh impossible for me, but that falls into one of your primary strengths categories. 

Haven't updated the version yet, got to audit the code, etc. I'll do I "New Version" kind of post after I update it. Might be 2 hours. 

I see. I've even made a special test map for it. Can upload it for you for easy testing. 

Exactly! Yeah, everyone's beta testing and the level of detail has been incredible. Best experience as an engine coder ever.

And your unique perspective as an active QuakeC coder running a server has been an invaluable contribution.

Very nice that everyone has been bringing some unique perspective to the table. 

Yes, do that! 

http://www.quaketastic.com/files/test_mirror.zip 

...XInput is probably similar...

It's not unfortunately; XInput is actually very different.

I'm not certain what tutorials you've looked at, but IIRC XInput is just 10 or so lines to initialize, then another 5 or so to read the input. Everything else is translating input data from XInput format to Quake format (i.e. button mapping, etc).

Quake's joystick code is NOT DirectInput - ignore what it says in the comments in in_win.c; it's NOT DirectInput, it's actually a totally different Windows multimedia controller API. DirectInput joystick code looks a little like the DirectInput mouse code.

I wouldn't touch multiple controller support with a 10 foot pole. You need support for multiple clients first, and that's not a light undertaking. I know you're getting requests for splitscreen, but it's not something you can just easily patch in. I think your time is better spent elsewhere.