Your sndspeed variable would have to be set to "44100" to profit from this. Mark V-WinQuake has a dedicated entry in config.cfg, while for Quakespasm you would have to add this line in your autoexec.cfg: sndspeed "44100" 

Please adjust the download link above (#25) from qvan_fixes-r3.zip to qvan_fixes-r3a.zip. I forgot to include the license from the Quake Remaster which seems to be kinda necessary to be able to redistribute the sound files. 

posted by NightFright on 2021/08/20 08:53:46
Timing is everything! QTest sounds out, Quake Remaster sounds in. Now not just a few sounds are replaced/improved, but all of them - including the mission packs.

Download Rev.3a (38.6 MB)
See readme for details
 

Sorry we don't have a way to edit posts, but i reposted with the correct URL and hid the original post #25 

I am really missing an editing feature here, especially since you cannot update d/l links in the OP like that. But well, that's the way it is. 

This is cool stuff!

Have you looked at this QC solution to the rune loss bug?

https://tomeofpreach.wordpress.com/2015/09/30/fixing-runes-and-restart-with-qc/ 

I have seen it, yeah. Never ran into a situation like that, though. 

Two progs.dat fixes:
- Losing runes when saving and restarting game
- Support for new DOPA ep.5 ending text from Quake Enhanced

Download Rev.4 (4.3 MB)
See readme for details 

I have one report that the silver key in hip1m4 (Research Facility) might not spawn reliably every time with these fixes.

Maybe someone could test that to confirm? Interesting would also be to test with original pak files vs those from the re-release. In general, I do not recommend using this with the re-release since maps and code have been significantly altered. Besides the fact that you simply wouldn't need any fixes, then. 

I just quickly tested this in vkQuake, Quakespasm-Spiked and also Mark V WinQuake. What I did several times was: map hip1m4, notarget, noclip and fly to the room with the silver key.

On Easy it spawned all the time. On Normal it sometimes does not spawn. On Hard it managed to not spawn three times in a row.

Since there's no .ent file for this map, issue is somewhere else? 

Doing the same with the rerelease's hipnotic pak0 file (and obviously without the QVan fixes pak) seems to not have this issue. 

There is a suspicion that QSS introduced this problem between Aug 20 and now in its dev builds, but if it also happens with other ports, the origin of the issue must be the mod. The QuakeC code, to be more specific, since hip1m4 doesn't have a custom ent file.

Maybe someone can check the included source files and see if there is any edit that could cause this issue? I am not aware of any change right now which could cause trouble.

Additionally, other SoA maps should be checked, also for gold key behavior, and DoE on top of that just to be on the safe side. 

- Does it only affect SoA or also ID1 and/or DoE?
- Is it only happening on this one map or in general?
- Is it only about the silver key or also the gold one? Or maybe even other items?

So far it looks like it's only happening in hip1m4 and only with the silver key, which makes the whole thing even weirder. That key might have special flags or something, maybe? 

I think I found the reason. On Easy the Silver Key always spawns without any problem, and there's a grunt or two in that room. On Normal and Hard, there's an Enforcer right next to the Silver Key, though not on top of it (I even opened the extracted .ent file as a .map in TrenchBroom to check) and this Enforcer is set to patrol that area using path_corners, as it's usually done.

By moving info_player_start into that room and restarting the map over and over, I noticed that besides the Silver Key not always spawning, this Enforcer is spawned somewhat differently, sometimes it looked like he was almost into the wall (but not really) and was not aggro'd by the sight of the player, and sometimes he was spawned kinda normally and was aware of the player immediately.

I don't know what causes this, must be something in QuakeC, because this problem does not happen in original or rerelease Hipnotic progs.dat.

However it can be fixed by finding this in the HIP1M4.ENT:

{
"spawnflags" "256"
"classname" "monster_enforcer"
"origin" "16 976 -120"
"target" "8200"
}

and changing it to something like

{
"spawnflags" "256"
"classname" "monster_enforcer"
"origin" "48 976 -120"
"target" "8200"
}

and it solves this particular issue. 

Alright, at least that means it's not an issue with progs.dat. Would have been a surprise, anyway, as it only affects a specific map, so if it HAD been code-related, this should happen anywhere, ofc.

Thanks for already providing a fix for the glitch! Will just make an ent file for this map as well, then. 

Forget what I wrote above. As you said, ofc it must have something to do with progs.dat since it doesn't happen without the mod.

It would probably make sense to search for what's causing this in the source files since it might also affect other maps, even though it seems to be a very specific case, possibly unique. We can't be sure, though. 

I don't know anything about QuakeC but in your fixes you included the sources. I compared stuff like enforcer.qc and items.qc between id1 and hipnotic and there are some differences. Shouldn't they be the same? I think SOA-specific stuff is in hip*.qc?

I know you integrated a lot of QuakeC fixes into id1, but did you also integrate them (or all of it) into hipnotic/rogue? 

I applied two different kinds of adjustments. First, I applied Maddes' QC fixes (by far not as many as for ID1, but most of those listed on his website), then I did a code cleanup to eliminate compiler warnings, which was often not much more than commenting out unused variables.

I did some first comparisons of the unchanged sourcefiles vs my first and second edits and couldn't find any critical deviations which could cause this. Natural suspects would be enforcer.qc or monsters.qc, maybe items.qc. You can compare original source with mine via WinMerge. Maybe someone with profound QC knowledge can do that.

Anyway, your ent fix works. Tested with it on skill 1+2, key appeared every time. I still feel a bit uncomfortable with it, though, knowing it just wouldn't happen in vanilla at all, without any map entity change. 

Yes, the mission packs share a lot of code with ID1, but there are still a lot of deviations even outside of the source files they added. Often they fixed flawed code or added some to make new features work. Under no circumstances can you just copy over ID1 stuff into the mission packs! You need to treat SoA/DoE stuff as something completely separate.

So far it looks like the hip1m4 is an isolated case. I am still curious which of my edits could trigger this. It would have to be something that makes enemies spawn at slightly different locations all the time, maybe to bypass a related problem with spawns in general. 

To identify the source of the issue. So it looks like items.qc is loaded too early in the compilation list. I will change that now and see if it fixes the problem without the need of a new ent file. 

Nice! 

Appreciate your work on this dude. 

It's not about compilation order of items.qc in progs.src. It has rather to do with adjustments to monster AI which also affect item spawns. By making them appear later, potential conflicts can be avoided. 

Hey, NightFright o/

There is something that has always bothered me about the armor code. If the player gets a yellow armor first, he can't get a green armor when his armor points are less than 100... is this considered a bug? 

Green, Yellow and Red armor have different damage absorb percentages. Green has 30%, Yellow 60% and Red is 80%. That's why they also have different armor points values, otherwise Red and Yellow would just disappear too quickly.

Players in Yellow Armor cannot collect Green Armor unless their Armor points are below 50. This sort of makes sense because 50 points of 60% absorb is basically the same as 100 points of 30% absorb.

Players in Red Armor can only collect Yellow Armor when their Armor points are below 113, and Green Armor when they are below 38.

Basically, the code (perhaps not perfect) doesn't let you pick up worse armor than you currently have.