Vanilla Quake Fixes

[Seven]

Hello,

At least basic understanding of how the Quake gamecode works should be there when tinkering with QuakeC

If you ever wondered what those dprint messages in the source code mean, they are there to help you.
Especially in situations like these.
So, enable the developer console messages and you will see what happens.
And yes, it has something to do with the small changes Nightfright made.

The original source reminds you that Items should load last in order.
Nightfright made them load too early and that is why things like this happen.
Most probably other maps are affected as well.

Your options to fix this:
1.) Either remove the delay again
2.) Or add an even higher delay to items

Both ways will fix your issue.

If mappers would be more sensible in placing / positioning stuff, things could be avoided.
But they sometimes are in a rush and trust on original gamecode behaviour.

DarkPlaces for example has several dedicated cvars to fix these things.
Means, issues like this would not happen in DP. As it saves entities from falling out of the map.
But QS and the like doesnt; so the gamecode must remain how it was when these maps have been build.

Best wishes and have fun with QuakeC,
Seven

[LordKane]

It's not quite the fix I wanted since we still haven't figured out why that Enforcer is behaving like that. In theory, it could happen in other maps as well, provided there is no customized progs.dat. However, it looks like a very specific case and might really be an exception. I will keep looking for a code-based solution instead of a map-based one.

Might take another shot at that Enforcer telefrag fix for E2M1 while I am at it.

A code based solution would be superior, but its odd that it just suddenly shows like this, because technically it SHOULD be happening on vanilla too, unless Quake has some safeguards for certain things spawning that VFP somehow breaks or bypasses. How thoroughly studied has the Quake Source Code and QuakeC been studied? Perhaps it might be worth it to contact Carmack but who knows if he even still remembers.

[NightFright]

It's not quite the fix I wanted since we still haven't figured out why that Enforcer is behaving like that. In theory, it could happen in other maps as well, provided there is no customized progs.dat. However, it looks like a very specific case and might really be an exception. I will keep looking for a code-based solution instead of a map-based one.

Might take another shot at that Enforcer telefrag fix for E2M1 while I am at it.

[LordKane]

So... it seems it's an issue with monster spawns. On skill 1 or higher, there's an Enforcer spawning really close to the key. For some reason it sometimes spawns differently (only with my fixes) and can get in conflict with the key. I don't know why it doesn't cause an issue without the mod, but fact is it does - somehow.

Quote from Func_Msgboard:
"[...] 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."

It must be something I changed in the code, but I wouldn't know what it could be, tbh. If it's limited to this one situation, I guess it's OK, but if I am honest, I'd rather like it to be fixed. Good news is it can be solved with a rather simple ent file adjustment if we can't find what's wrong with QC. It's a matter of moving that Enforcer (which only spawns on Normal or higher) a bit away from the silver key.

*EDIT*
(Preliminary) fix available. Extract attached pak2.pak into your hipnotic dir and test HIP1M4 on Normal or higher. I will implement this for the next update, provided I don't find the real trigger in the QuakeC code. I tested it by myself and couldn't find any situation where the key did not appear. At the same time, I was also able to confirm your findings without the fix.

Thats great to hear! Interesting how it was the spawning? that is very weird, and the fix works I ran 3 tests on mark v and july 2021 QSS and everything worked as it should have at skills 0, 1 and 2, and it worked all 3 times for all 9 tests, and I did read the func msgboard thread about that is some interesting results gila had.

[NightFright]

So... it seems it's an issue with monster spawns. On skill 1 or higher, there's an Enforcer spawning really close to the key. For some reason it sometimes spawns differently (only with my fixes) and can get in conflict with the key. I don't know why it doesn't cause an issue without the mod, but fact is it does - somehow.

Quote from Func_Msgboard:
"[...] 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."

It must be something I changed in the code, but I wouldn't know what it could be, tbh. If it's limited to this one situation, I guess it's OK, but if I am honest, I'd rather like it to be fixed. Good news is it can be solved with a rather simple ent file adjustment if we can't find what's wrong with QC. It's a matter of moving that Enforcer (which only spawns on Normal or higher) a bit away from the silver key.

*EDIT*
(Preliminary) fix available. Extract attached pak2.pak into your hipnotic dir and test HIP1M4 on Normal or higher. I will implement this for the next update, provided I don't find the real trigger in the QuakeC code. I tested it by myself and couldn't find any situation where the key did not appear. At the same time, I was also able to confirm your findings without the fix.

[LordKane]

At this point I cannot confirm your findings and neither can anybody else. Also, the mission packs receiced significantly less QuakeC updates than ID1. Plus I didn't change anything about key behavior. Also, if it happens in just one map, my guess is it would rather be a map-related issue. We can exclude my ent fixes as a source since hip1m4 has not been altered.

It very well could be, which is unusual, as the same thing happens with Quakespasm, I havent tried Mark V or another engine, but thanks for getting back to me on it I will keep my eyes on the issue perhaps some detectable pattern will emerge and I am not I am using QSS and the pak files from the OG install of the steam version, IE the files NOT in the <rerelease> dir as I cannot even run Quake Enhanced on my system. I have sent a PM or message or something to you about what I think the issue is, after some testing I found that a older build of QSS runs fine with no issues the most recent QS however produces the same problem and I am in the process of testing mark V after I edit this post.

Still think its a port/map issue down below is information for those who are reading this that want to assist in testing:

Issue: Silver Key spawns inconsistently on HIP1M4

Affected Ports that I tested
July 2021 Quakespasm Spiked (QSS)
Mark V 1099 R 5
Quakespasm 0.93.2

unaffected ports:
Quakespasm Spiked Aug 2020


Testing Regime:

Map hip1m4
notarget

go to silver key location

repeat

There is an inconsistent pattern to how this works in my testing I did a battery of 4 tests in all however the pattern quickly changed with each section so example in one test

test 1 key would spawn
test 2 key would not
test 3 key would not
test 4 key would spawn

however this would never remain consistent and would change.
The only unaffected port would be the older aug 2020 build of QSS

Feel free to test this with your own ports I want to see if others experience this issue.

Also I am running this in its own directory, with the pak files taken from the steam install directory NOT from the rerelease folder with QVAN Fixes R4.

I can provide other info if you need me too.

[NightFright]

At this point I cannot confirm your findings and nobody else has reported issues regarding this. Also, the mission packs receiced significantly less QuakeC updates than ID1, key behavior certainly wasn't changed.

Also, if it happens in just one map, my guess is it would rather be a map-related issue. However, we can exclude my ent fixes as a source since hip1m4 has not been altered.

I hope you are not trying to use my fixes with any files from the re-release as that would be highly unwise and might lead to problems as the one you just described.

[LordKane]

I have noticed an issue with SOA with the fixes, the silver key in HIP1M4 (Research Facility) spawns inconsistently:


Battery 1 is done with loading the game via the MAP command and upon getting to the keys location doing the map command again
NOTARGET is set at start via binded key.

Test 1 SK did not spawn
Test 2 SK did spawn
Test 3 SK did not spawn
Test 4 SK did spawn

Note this is not a set pattern and in other tests using the same conditions I would get batteries of tests with no spawns or batteries of tests with spawns.
I assume the gold key is not affected by this but I did not really check that (I could upon request)

I do not know if the ROGUE pack has the same issues.

Without your fixpack the key spawns consistently as I ran the same battery of tests with the same conditions to establish a baseline and see if this was a port/og issue

The ports I used where QSS both 64 and 32-bit versions and VQF Revision 4 as supplied above.

[NightFright]

Maddes already took care of that back in 1998, I think. They fixed hundreds of vanilla bugs between 1996 and 2006, I couldn't possibly put them all in my changelog or theirs, so I just mentioned some VERY few highlights. I doubt there is much left they left unfixed, actually.

I have released a new revision, anyway, but for another reason.

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

<D/L link in OP>

[Totalitarian]

I have a seemingly long-overlooked important vanilla fix for you (and any other fixer-upper e.g Seven's brilliant SMC) from my Combat+ fork for Quake 1.5. I didn't see it in your readme or the info pool:

Problem: running over ANY ammo pickup while firing ANY weapon will reset its firing animation and fire rate cycling. This is jarring, looks weird, impacts gameplay mildly and is annoying.

Solution: items.qc. AmmoTouch() and BackpackTouch(). Remove calls to SetCurrentAmmo() (only if no auto-weapon switching takes place) as this is what resets the model and anim etc. However, the HUD needs updating to refresh ammo count in the absence of this call, so you need to add an if/else or switch statement to handle that:

if (self.weapon == IT_SHOTGUN)
    {
        self.currentammo = self.ammo_shells;
        self.items = self.items | IT_SHELLS;
    }
    else if (self.weapon == IT_SUPER_SHOTGUN)
    {
        self.currentammo = self.ammo_shells;
        self.items = self.items | IT_SHELLS;
    }
    else if (self.weapon == IT_NAILGUN)
    {
        self.currentammo = self.ammo_nails;
        self.items = self.items | IT_NAILS;
    }
    else if (self.weapon == IT_SUPER_NAILGUN)
    {
        self.currentammo = self.ammo_nails;
        self.items = self.items | IT_NAILS;
    }
    else if (self.weapon == IT_GRENADE_LAUNCHER)
    {
        self.currentammo = self.ammo_rockets;
        self.items = self.items | IT_ROCKETS;
    }
    else if (self.weapon == IT_ROCKET_LAUNCHER)
    {
        self.currentammo = self.ammo_rockets;
        self.items = self.items | IT_ROCKETS;
    }
    else if (self.weapon == IT_LIGHTNING)
    {
        self.currentammo = self.ammo_cells;
        self.items = self.items | IT_CELLS;
    }

There's probably a better method but I am new to QuakeC. Mind you this is how it is handled in SetCurrentAmmo() anyway.

WeaponTouch() also results in the same problem, but it is less likely to need any work as weapon pickups in general are much rarer, are rarely placed in combat heavy zones to just bump into while firing away, and lastly there's a good chance picking it up will switch your weapon and thus not be a problem anyway. Nonetheless it is technically a vanilla issue so up to you.

[vegetous]

Noice

[strangebit]

I just noticed that E2M6 in the remaster is also a merged version with The Lost Entrance. That's cool. I really like the coloured lit files from the remaster too. The colours aren't totally overdone like with the traditional community ones. They are more subtle which I think fits better. I think whoever made the lit files originally just wanted to show off the coloured lighting tech more, which was probably good at the time because they are more immediately obvious.

Anyway, just wanted to say that I also grabbed the coloured lit file for this version of the merged E2M6 here, where you posted it many years ago (I found it from the comment you made here). It seems to still work fine with this version of the map, so if anybody else is looking for that too I thought that I'd mention it here. Since I play with the coloured lightning on other maps it makes sense for me to install this one too for consistency, but I understand not including it in the pak by default because that would be inconsistent for those that don't use coloured lighting.

[strangebit]

Yeah I guess I see what you mean after comparing them with the original sounds as well. It does have a slightly different "feel" to it compared with the original sounds, which the Quake Remaster ones manage to retain, just with a higher quality.

[NightFright]

I tried that ages ago. These didn't strike me as very convincing tbh. Also, the remastered sounds apparently come straight from the source archives and are not just sent through the resampler, apparently.

However, should id drop a C&D on me, which I hope they won't, we can still consider this as a fallback option.

[strangebit]

Have you come across Quake Sound Bulb?
https://www.moddb.com/games/quake/ad...ake-sound-bulb

I think they sound a lot "cleaner" than even the Quake Remaster sounds. Also uses 44100Hz.

Check it out.