Have been playing around with this since the release. Most of the usual player preference type of tweaks / cvar changes (they stuck around) can be applied via the console or kxengine.cfg file located in users\saved games folder.

However, the engine does not execute autoexec's, even though .rc's are still present in their respective .pak's with a few lines of their own added in tells it to. Still, any changes made to kxengine.cfg via the console or direct editing is permanent, until you go change the variable by yourself. However, even though there is an alias cmd, aliases do not get written permanently to the config file, using either way. So I went ahead and added my aliases to .rcs in the paks to get them permanent. Querying returns the default values for all of the cvars and cmds and short descriptions for most of them, which is a nice addition.

I'm used playing with headbob, underwater warp and weapon kickback toggled off. Headbob and kickback has the usual cvars for them. Underwater warp has four related ones. However, there are also newly-added single cvar toggles in there for the bob (which the menu option uses) and the warp. I bet they were also planning to offer the latter as an option through the menu, but somehow forgot about it for the initial release (just like the modified backspeed). Menu options for kickback and warp would be nice, considering this update's also released on the consoles.

Curated mods (which is only Q64 at the moment) get placed in their own folder, as a .pak under the related \Saved Games folder and are activated via the menu. Q64 has its music stored in the .pak, so it looks like that's a feature too (does not read .flacs however, and all the .oggs on offer are sadly lacking in quality).

The biggest problem here is that kxconfig is shared. ie, want to play Q64 with filtering on, in lo-res mode, with a lower FOV than usual, etc. Those changes are written in the same config file the base game uses, so you have to revert them back one by one upon deactivating the mod. I think the only way to overcome this right now is to create an .rc with those values and stick it in Q64's pak. But that's advanced editing with which most of the users won't bother. I think it would be better to have autoexecs back.

Loved the Machine though. They clearly put their heart in it. Though E1 and E3 are mostly of run-of-the-mill corridor-crawling fare, E2 and E4/5 more than make up for it. Lots of new textures and skyboxes, different and nicely merged themes, faultless and detailed brushwork, tasty use of colored lights and fog, even bits of environmental storytelling and progression reminiscent of modern community content. Overall, it was a nice surprise that is handled pretty well on all aspects and a welcome addition to the official content imho. Looks like 'returning for nostalgia after many moons' folks are getting impressed by it too - so, it will hopefully serve well for the longevity of the game. 

It does execute them at least to some extent, as dropping my autoexec.cfg into the correct id1 folder (not the original one, the re-release one) changed my fov and playername. 

Thanks for the clarification, Jago. Of course, I was working within the rerelease's \id1 folder. It wasn't a full-on autoexec on my end though. I just put in my aliases to see if I can get them working that way, to no luck. So I went for the .rc. 

are changed and if you are used to QW-style "go through weapons 1, 3 and 3 and then fire the weapon selected" aliases, broken.

The gist of the issue is that:
1) The "fire" is now *in_attack
2) *in_attack cannot be chained together with things

You can bind *in_attack to a key, but you can't use it in an alias. Going through weapons is different too. You can do something like this:

unbindkey 4
alias quickswitch_nails "switchweapon 3 2"
bind 4 "quickswitch_nails" 

Yeah, I've figured those out through the config file, have seen the quickswitch in the .rc too. Rather than gameplay-related ones, I'm used to have some in my QS/QSS setup for toggling things on and off, in conjunction or by themselves. A liquids transparency one, a lightstyles one, a track cycler, a screenshot mode toggle, a contrast cycler and a gamma cycler. I don't need all of them right now, I was just trying to get my shot alias working. Had to split it to two buttons tho', since bind was returning a 'it is already bound' type of message.

While reading your post, I've remembered those unbind / unbindkey key cmds. Thanks, think I figured in this instant how to get it working on a single key. Will check. :) 

Even though the original maps all have built-in water transparency support due to them being recompiled, the related variables all default to 1. I guess they wanted to have the authentic look on that part, but still wanted to support transparency in case anyone wants it so.

Something's funky with the teleporter texture tho' (I'm sure it was also mentioned before in this thread). It defaults to "1.0", which should equal to "1" of course, but still has transparency enabled with that value. Reinforcing the r_telealpha cvar with a value of "1" makes it solid as it's supposed to be in the instant, though it still reverts to its original value and wrong looks upon the next launch. Guess this needs to be fixed on their part. 

Yeah, the teleporters look like shit with transparency. Gotta put that in my list. 

The "censored" health .lmp's are located in \steamapps\common\Quake\rerelease\id1\pak0.pak in the "progs" folder. They even have animation for the non-rotten packs. It's strange they weren't used. Maybe it's as you say, the lack of white background turned out to be "good enough."

Yeah, I remember when almost all games had the Red Cross on their health packs. Funny how things change. Nowadays, it's not uncommon to see the Swiss flag being used instead. Ridiculous. 

The maps store wateralpha/slimealpha/lavaalpha/telealpha in the worldspawn key, and the engine reads them and uses them as overrides for the cvars.

The maps also have their fog settings in worldspawn, including sky fog. 

The new sound files are 44khz files but the sound data in them is lowpassed at 22khz, so the files are actually twice as large as they need to be. That's probably not worth patching. 

The remastered sounds sound a lot better in Quakespasm with sndspeed 44100. Nice find! 

Yeah seems they found all the 22kHz sounds they could (some of them they didn't) and just batch-converted them to 44100. I tried the new ones in Quakespasm, it sounds better than in the KEX Engine Enhanced version, less clipping, but it's still there. I think it's mostly due to most of the sounds being super loud and compressed (meaning dynamic range) themselves.

They also have couple of unused Fiend sounds in the rerelease sounds. After playing Quake for all this time since '96 the new higher quality sounds just feel "off" for me, so I'm gonna stick to original muffled noisy 11kHz ones.

It's awesome to get the higher quality sounds anyway, I use HEALTH1.WAV as my message tone and PROTECT.WAV as ringtone, time to upgrade :) 

One of the involved people who's is present on Quake Mapping Discord confirmed it's because there's no white background:

> its not a problem in quake because it's not on a white background, it's a plus on a bunch of green techy stuff 

https://www.quaketastic.com/files/screen_shots/MD5_1.jpg

https://www.quaketastic.com/files/screen_shots/MD5_2.jpg

Note that this is in a regular source port, NOT the Quake 2021 Kex engine.

Note also that these are the actual source MD5s copied over, NOT conversions. 

If you want to see some MDL conversions in action, we have already added those we wanted to the AMQ. Check latest dev build on Github. 

Had a look at an Ogre in e1m3; the first one you encounter in Normal skill (around the corner to the right, not the one behind bars), looking at it with notarget on and viewing it's idle animation.

This I guess is a case of different things annoying different people in different ways, but I see some very extreme vertex wobble in it.

This was with frame interpolation on. Maybe it's less pronounced if you switch off frame interpolation? 

I have interpolation on in QSS and tbh it looks just fine to me. 

I agree with mh. Vertex wobble is very noticeable. Took a short video of it in QSS.

https://youtu.be/VoxHGqptqFM 

Heh, reminds me of Kingpin! 

In an ideal world QuakeSpasm and derivatives would just load and use the MD5s directly. Now that they're official, and now that MD5 is an official MDL replacement format, this makes sense to do.

I know that QS hasn't released in a while, but cruising by it's Github page I see that it's still being actively worked on, and is starting to take up changes for the Quake 2021 reissue. Same with VkQuake. 

The new Quake Kex assets are NOT in any of the official AMQ releases yet. Your video footage does not show our latest models, I am afraid.

You must download the dev build from the Github page. To do so, click on "Code" (green button), then "Download Zip". THAT'S the way to get the new stuff right now since we aren't fully ready for a release yet, so it's NOT to be found under "Releases".

I admit that Github navigation can be confusing to people who aren't used to it, but that's the way it works. 

I admit that Github navigation can be confusing to people who aren't used to it, but that's the way it works.

It's confusing even if you are used to it (18 repositories and I still get lost).

Anyway, that is significantly improved, although I'm still seeing wobble compared to the source MD5s.

That's not a criticism of anyone's work, by the way. Vertex wobble is a "feature" of the MDL format caused by compressing positions to 8 bits, and that's just what it is. 

Has anyone done a detailed comparison of how the remastered version is implemented versus vanilla/derived? For instance, does the remastered still use QuakeC with progs.dat, or does it use something else? If it uses progs.dat, is there a formal source dump? Are the assets the same format or different?

I'd love to see a tabular breakdown/comparison. 

@mtp I agree. I'd love to eventually see some community documentation of the technical changes that are relevant for mappers, modders, and engine coders. Things like changes to the protocol (e.g. svc_achievement), new file formats (e.g. md5), new console commands or cvars (e.g. menu_credits), changes to how autoexec.cfg is handled, etc.

@mh, the work you are doing for md5 would be great as a sample implementation, unless it depends too much on each engine's model renderer. 

I could release my MD5 code publicly but I fear it would be of little use to people. It's all D3D11, buffers and shaders, that kind of stuff.

The code at http://tfc.duke.free.fr/coding/md5-specs-en.html is probably more useful to the Quake community. That's a working implementation that uses GL 1.1 code and that my own is based on.

The main thing missing from that code is generating normals. There is code in modelgen.c for this and that can lift over clean enough.

It also does it's skeletal animation on the CPU at draw time, whereas I've used the bones and frames to build keyframes instead. My way takes more memory but it's highly compatible with my MDL renderer.

An option is I could port an implementation to QuakeSpasm. Last time I publicly fiddled with QuakeSpasm I did have needy, demanding people descend on me practically ordering me to do Linux builds just for them, so I made the project private and I'm really reluctant to go there again.

I don't know, do people want the MD5 stuff?