Closed Hexaae closed 2 years ago
Try integrating the progs.dat files into the corresponding pak files of the mod with Pakscape or Slade. The ports you mentioned cannot read external progs.dat files, only when they are inside of paks. This way you won't get ANY fixes provided by those external files.
Please also note progs.dat fixes are bonus features and not part of the core mod. There can't be a release with those progs.dat files integrated since they will cause conflicts with mods. Users must be able to dispose of them easily without having to delete the entire mod.
A compromise solution could be to place the progs.dat files into separate paks which can still be removed easily. I may consider that for a future release, if there will ever be any.
Confirmed it works that way, and no need of additional mod to fix this bug 👍
Alright. Guess I'll put the dat files into separate pak files at some point, then.
P.S. I'll see if I can fix the bullets of nailguns properly, since also the known fixes (and the fix in this package) are not perfect as you can see from the pic below. My goal is to move the origin of the Z axis to make the bullets appear in front of the nailgun and not just "in-line through the 3d model" ...
I've a long experience as a Skyrim and other games modder but the problem is I don't know how to do this for Quake and what tools are available... 😅 I'd like also to fix the "solid skybox" issue (you can see bullets "hit the sky").
If you find good tutorials/tools please let me know! Thank you.
You will need to learn QuakeC. Anyway, I have included the source code for the modifications, carefully commented. You will see which parts of the source files are responsible for projectile adjustments.
In case you are lucky, it might just be a matter of changing some values, but I wouldn't know which since this is something I just took over from Seven's mod. And again, these code fixes are just a bonus part of the mod.
I'm not a programmer but it seems I've found how to fix it!
Hipnotic:
But ID1 sources package seem incomplete: there is no subdir named "/fixed" with modified files...
Yeah, I must have forgotten to include the folder (which is the essential one since it contains all my changes, lol) with the last update.
It is fixed now, source code is complete again.
Ok, please test https://gofile.io/d/gncSp5 and let me know... In particular while strifing left-right you'll notice a big difference (before it was clear the various projectiles were misplaced yet, even with Z axis corrected).
I've fixed the following distances (forward axis): ID1: nailgun, super nailgun, grenade launcher HIPNOTIC: nailgun, super nailgun, grenade launcher, proximity grenade launcher ROGUE: nailgun, nailgun lava, super nailgun, super nailgun lava, grenade launcher, multi-grenade launcher, plasma
EDIT: updated also plasma shot (ROGUE) as it was too high and too backward
OK, it's kinda hard to see at first, but I guess there are improvements with this - even if you have to pause the game at the right time while firing.
If you provide your source code changes that you made, I can integrate this into the official release.
Sure: https://gofile.io/d/l5VuMs There is one strange thing though looking at weapons.qc files... They seem to include the "solid skybox" bugfix (search for CONTENT_SKY) to disable projectiles collision with the sky, but it doesn't seem to work when in game... P.S. There is also a "(pointcontents (self.origin) == CONTENT_SKY)" while I think it should be "(pointcontents(self.origin) == CONTENT_SKY)"
I have implemented the weapons projectile alignment adjustments.
As for the skybox fix: For me it seems to work just fine. Nails are going through the sky and grenades as well. I have made that minimal code adjustment you suggested, but that wouldn't matter during compilation, anyway. It's the same before and after.
You also seem to have some part in weapons.qc that I don't, and it's not part of the URQP fixes. It's this part in T_MissileTouch:
surfacenum = getsurfacenearpoint(world, self.origin);
if ((surfacenum >= FALSE))
{
tex = getsurfacetexture(world, surfacenum);
if (((tex == "sky1") || (tex == "sky4")))
{
remove(self);
return;
}
}
I have no idea what this is supposed to do, but I didn't include it since it's neither part of the original code nor is it listed in any of my fixes that I am using as templates. My QuakeC knowledge is limited, and if I don't know what some part of the code does, I better leave it out.
Ok... will try the new version and see if skybox bug is ok. Ooops I think I added it from SMC fix in the last attempt to fix sky issue and forgot to remove it from the file...
Mmm... doesn't seem to work here (Ironwail, hipnotic MP1, New Game first room + cheat "impulse 9" to get all weapons). Tested with vanilla paks + this fix only, no extra mods or whatsover. Are you sure you don't have other fixes enabled doing the same fix?
I am using Quake Kex paks. But it shouldn't matter since a custom progs.dat overrides any other if loaded on top of it. Otherwise, I am loading the model pack and the progs.dat pak on top, nothing else.
I checked this on the ID1 start map, not the mission packs. Maybe the mission packs do things differently and the ID1 fix doesn't work in them. However, the code is pretty independent and should integrate just fine.
Does it work in ID1 and/or DoE?
Yep. Also with ID1 or Rogue.... Will now test with MarkV_winquake...
EDIT: confirmed also with MarkV_winquake:
Could you please check with Ironwail https://github.com/andrei-drexler/ironwail/releases ? Maybe it's really an engine problem...
That's what I am actually using. The rockets go straight through the sky. Swoosh. Like that. No premature explosions. If I knew how, I'd make a video of it. No clue how it's possible. I will do some more testing tomorrow. But yeah, I got the feeling some ports may not like some of these fixes, for whatever reason. Maybe I just tempered too much with everything and stuff got screwed up. Only because it compiles doesn't mean it works without problems. Even though it should, since I was extra careful to not insert the fixes in the wrong places.
Otherwise, there is a fix I implemented which causes an issue at least on the last ID1 map. Shub-Niggurath for some reason has a passive AoD, making you or monsters (like a Shambler) take damage when you get too close. I know which part of the code is responsible, but I dunno why it's happening since the code is flawless as far as I can see. One of the mysteries I need to solve before I can make another release. Haven't tested in Ironwail yet, but it's screwed up in QSS for sure. Then again, that port is acting weird lately in general, so...
Ok, to clarify some stuff. In some of the original id1 maps, skies were set with only a single surface on a brush in a few places, instead of the whole brush. This way the sky brush has no way to turn into a volume, so it cannot be checked through the engine's pointcontents built-in because its faces function like solid walls. tl;dr it's a map issue, not a mod issue.
For the rerelease, id corrected all those instances in the original maps, and that's why the shots disappear at the sky like they should when using the rerelease pak.
Another thing: those "getsurface" functions aren't part of the original built-ins and will only work in some ports - if I'd guess, I'd say only in QSS, FTE and DP. That being said, that code snippet should* work tho - given the sky texture name is either "sky1" or "sky4", and you're using a supported sourceport.
Ok thank you. So the "fixed" sky is available only with the rerelease ("Quake Enhanced") paks... EDIT: ...and only for ID1 and HIPNOTIC revamped maps.
This explains why the projectiles go through the skies in ID1 and HIP in the re-release, but not in ROG since they didn't edit the maps there due to lacking the source files.
Those fixes were part of the URQP project, which is definitely from a time before the Quake Re-Release. Hexaae's extra code from above wouldn't even compile in FTEQCC. If it's from Seven's mod, my educated guess it's exclusively meant for Darkplaces.
In the meantime, the other thing I am worried about: The hurt_touch fix in triggers.qc which is supposed to make every player in the entity getting hurt every second, not just the first one. This code apparently makes Shub cause passive area damage on map END, which causes the Shambler standing next to it getting hurt. Very weird. (Goes for the Re-Release again, dunno about vanilla.)
Original code (triggers.qc):
void() hurt_on =
{
self.solid = SOLID_TRIGGER;
self.nextthink = -1;
};
void() hurt_touch =
{
if (other.takedamage)
{
self.solid = SOLID_NOT;
T_Damage (other, self, self, self.dmg);
self.think = hurt_on;
self.nextthink = time + 1;
}
return;
};
My code replacement:
.float dmgtime;
.float attack_finished;
void() hurt_touch =
{
if (!other.takedamage)
return;
if ((time != self.dmgtime) && (time < self.attack_finished))
return;
T_Damage (other, self, self, self.dmg);
self.dmgtime = time;
self.attack_finished = time + 1;
};
After restoring original code, behavior is back to normal, so something has to be wrong with this.
@fabiolimamp Do you know a fix for the text message string issues when using the rerelease pak0.pak from Steam with ports like Ironwail? Messages like "$map_hipnotic_skill_select_normal" placeholder instead of the usual string...
EDIT: ok found by myself... For those interested the strings are in the "\Quake\rerelease\QuakeEX.kpf" package (zipped file). When you extract the "localization" folder into Ironwail.exe dir this will fix placeholders with real strings. EDIT2: it seems Ironwail supports also the QuakeEX.kpf directly.
Technically, you won't even the entire QuakeEX.kpf. All that is needed is to extract the localization folder to your Quake root directory, parallel to the id1/hipnotic/rogue folders. And only _locenglish.txt is needed. But I guess for most users it's still easier to just place the entire file in the Quake folder, even though 99.9% of its contents won't be used.
Anyway, back to topic. The hurt_touch problem! It hurts indeed...
Found some kind of workaround for the END map. Looks like the island on which Shub is located is kinda exploiting the hurt_touch bug that I fixed. Therefore, I have coded an exception which makes the game use the old code just for that specific level. Not ideal, also since I can't tell if any other (user) maps ever did it the same way, but right now, it's better than not addressing it at all.
I've seen the bullet of the nailgun in the original game (with MarkV and Ironwail at least) won't come out of the nailgun barrels, as explained in this topic on GOG https://www.gog.com/forum/quake_series/quakespasm_bullets_come_not_out_of_weapon Would be possible to include a fix in quake_authmdl?