 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
There is decision to store /localisation/ in mg1 folder?
OUM: [img]https://quaketastic.com/files/screen_shots/loc.jpg[/img] I solve it by removing custom font, but?.. - Copy over the "mg1" folder from your Steam installation (default dir: C:\Program Files (x86)\Steam\steamapps\common\Quake\rerelease) into your QSS dir
- Open "QuakeEX.kpf" with 7-Zip (or another zip manager of your choice) and extract the "localization" folder into the "mg1" folder in your QSS dir - Start the game with parameter -game mg1 /localization/ should be stored off the Quake basedir - e.g. C:\Quake or whatever - rather than in any game dir. The localization text file contains localized strings for all mods in a single file.
Ideally that wouldn't have been the case, and each mod would have had it's own strings that are merged at startup time. This, and other evidence (*another* crusty plain text format to parse, yayy) indicates that the localization system was pre-existing stuff in the Kex engine rather than something specifically written for Quake. Removed QuakeEX.kpf from quake dir completely. But in AD the same thing: font lose translucentness.
https://quaketastic.com/files/screen_shots/ad_font.jpg Good point. Like that you are probably also able to use the new ID1/SoA/DoE pak files. Which is kinda necessary if you want to profit from the new MD5 model support.
You can export /progs from the new PAK files, drop it into your existing ID1, and using an engine that supports MD5s, just run them that way.
The new MD5s don't actually require a new progs or new entities lumps. The model names are the very same as the old ones (barring the extensions), and the models all have the very same number of frames as well, aside from some pickups and others where the original had 1 frame but the new has 2 (I've not been able to determine the reason for that). They work perfectly with a stock ID1 progs and maps, though. So in other words the MD5s were clearly and specifically designed as drop 'n' go replacements for the old MDLs, and they just slot cleanly into place with no messing required. if you have both mdl and md5 replacements, e.g. from the AMQ? Will md5 take priority over mdl automatically?
Asking because I saw that latest QSS has a toggle for model replacements which is set to "off" by default. Will md5 take priority over mdl automatically?
Depends how the engine coder handles this. Quakespasm already has a "path_id" solution for LIT files and the like that would seem appropriate for this too, so the scenario where: - ID1 has MDLs - ID1 has MD5s - MyMod has MDLs Would mean that when loading a model, the priority order would be the reverse of what I've listed: a MDL in MyMod takes priority over the same named MD5 in ID1 which takes priority over the same named MDL in ID1. That would seem to be the behaviour desired by content creators too, but like I said: this has been a solved problem for years. I think you're getting silly now, and I think you're deliberately trying to pick holes in any proposal to add MD5 support to engines.
It can be as simple as this. People who want to use MD5s can use them. People who don't can just delete the MD5 files and pretend they never existed. Your line of questioning fails an important test - what's to stop players doing the very same with their own preferred MDL files? How about rather than pick holes, you propose how you'd like to see it work? in few last builds of QSS. Alive falling on the base floor or sticks on floor. Dead bodies sometime floating down in void then up to its place. md5 models where disabled. Issue encountered in last pre-md5 suppurted release to.
This was happening on September 6th build for me as well. There's a new one from September 8th - I quickly tested it, and this bug is fixed.
on QSS from September 8th. But there is few time sicked alived on the floor. May be it is rather mapping mistakes where monster placed closer 4 point to the floor?
while scrolling up to choose the LG there is no v_light.mdl visible until pressing "fire". If choosing model replacement "off" issue is gone.
Lately I am finding more and more issues with QSS, with regular QS working just fine.
Latest QSS build (Sep 13, 2021) seems to have showstopper issues in some maps like: - Not all enemies spawn to lower the silver key platform in HIP3M3 "Limbo" - At least one SoA level (from Gotshun's "Lost Levels") has issues with func_train entities There might be more. I have already created tickets on Github regarding that. It seems that right now, regular QS is the better choice at least for classic/vanilla-style levels since it runs all maps just fine. I don't know what Spike changed in the last QSS release, but i played some custom maps with enemies and items placed in the wrong places, like "Putrid Pumps" (two ogres stuck in the floor), "Slime Factory" (three knights don't teleport to the final fight because they are stuck in the floor), "Squire of Time: Armored Nightmare" (rocket boxes stuck in the ceiling), the first map of "Cimmerian Night" (explode box stuck in the ceiling)... but the worst case is "Into the Dark" (three shamblers stuck in the floor, one fiend falling through the map, the lightning gun and two cell boxes floating in the void). None of these issues happens in quakespasm.
who found latest QSS releases to be quite unstable/unreliable.
In HIP3M3, I even found out what's happening. The two Vores which need to be spawned after the silver key platform rises appear underneath their spawn boxes, outside of player view. You can't kill them there, so the key will never come down. This happens without any progs.dat or ent modificiations. The same map works perfectly in QS 0.94.1, meaning it's 100% QSS fault. If it already cannot handle vanilla maps properly, I am afraid about general compatibility. This needs to be investigated and fixed before it gets even worse. What does it help if QSS can run even the biggest AD maps if you have to be afraid to run into showstopper bugs at any time? BTW, classic maps are also affected. In E2M1, there is an explosive box appearing on the way to the gold keycard, just at the end of the path across the large water pool. I thought at first this is a bug coming from the KEX port files I am using, but actually that box isn't there if you use regular QS. It's only f'ed up in QSS
Looks like latest QSS build (Oct 6) improved things a little again. HIP3M3 works again, but in E2M1 that misplaced exploding box on the path to the gold keycard is still there.
Can you check if the new build shows any improvements in the maps you mentioned in your post? THANK YOU, SPIKE!!!! \o/
Everything is fine now!!! And also thank you NightFright to tell me about the new release =D I checked those custom maps and all the bugs are gone! Oh, one more thing about the E2M1 explode-box... if you play the original map, the box isn't there. This error only shows up in the E2M1 that came with the "remastered" version of quake :P which exploding box it is. It's the one that should be close to the silver keycard, but it's falling through the map until it lands one level below. Yeah, I am indeed using the Authentic Models, but strangely enough, this still wouldn't happen in regular Quakespasm. It's a rather minor glitch compared to wrong monster/item spawns, though.
Good that Spike reacted so fast since it was a really annoying problem. They are coming in fast these days. Can't tell right now what changed, though.
Version 0.94.2 of QuakeSpasm is released.
Downloads: https://sourceforge.net/projects/quakespasm/files/ http://quakespasm.sourceforge.net/download.htm Changes since the previous version: https://sf.net/p/quakespasm/news/2021/10/quakespasm-0942/ - 2021 rerelease: Support for playing the latest update. - 2021 rerelease: Fix pitch black models in lit areas in DOTM. - 2021 rerelease: Fix black candles in the DOTM start map. - 2021 rerelease: Look for QuakeEX.kpf under userdir, too.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |