 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Just noticed this: load kellbase1.bsp, and noclip to the orange room with the water pool, just behind the info_player_start. Kill one of the pyro enforcers.
DP spams the console with: "WriteDest: Tried to write to non-client" Fitz 0.85 and QS freeze for a second and then drop you at the console with this: CALL2 596(WriteByte)() : centerprint : centerprint_toall : counter_use : SUB_UseTargets : monster_death_use : Killed : T_Damage : T_PlasmaTouch <NO FUNCTION> WriteDest: not a client Host_Error: Program error Client ericw removed This is on quoth 2.2. Hi ericw. The log from the console tells me that the pyro is killed, the trigger_counter bumps the numbers, tries to broadcast the message to all players, picks an entity to broadcast to, and then crashes. The error is that the entity picked was not a player, and sending the message to a non-player is a no-no in Quake. However, there is already code which is meant to limit the messages to players, and I can't replicate the crash here with any of those engines.
If it's consistently replicable at your end, can you make a save game before you crash the game, and e-mail me that save game and your config.cfg/autoexec.cfg files, so I can see about fixing it. It turns out I was downloading quoth2pt2full.zip which had an older (2014) pak2.pak than quoth2pt2patch.zip (2015).
Preach updated both the full and patch zips (thanks!), so you may want to download the patch if your pak2.pak is modified in 2014. Someone just told me that doing -game warpspasm -quoth doesn't play the startdemos.
I know this wasn't on purpose. I wonder if there are any other standalone-like releases like The Living End or such that are also impacted. I'm just raising awareness of the change of behavior. /I will probably have Mark V block loading of Quoth 2.2 pak2.pak (just have it load up pak0 and pak1) for Warpspasm eventually, since you implemented a very organized structure for falling back to the previous version. Not for me, I just dl'ed it again and the pak2.pak is modified nov 2016. The link on https://tomeofpreach.wordpress.com/quoth/ points to:
http://www.quaketastic.com/files/single_player/mods/quoth2pt2full.zip Maybe some kind of caching issue? This file on that page
Has a pak2.pak dated March 2015. The March 2015 and Nov 2016 pak2.pak's are identical (just checked with 'diff').. so I guess March 2015 is the actual last modification date.
I re-installed Quoth 2.2 last week, my pak2.pak is same as negke's (May 3 2014) from Quaddicted.
And if you look at this page, and the file dates for the pak files https://www.quaddicted.com/reviews/quoth2pt2full.html There have been in effect two "point releases" of Quoth since 2014, each of which fixed one bug that occurred rarely but was troubling. They really should have been called 2.2.1 and 2.2.2 but it's too late now. Quaddicted has the original zip (2.2.0), the version on my site has the updated one (2.2.2). I think Quaddicted is the only major mirror of the mod, so if that can be updated then it should all be fine.
When I go to download this file
http://www.quaketastic.com/files/single_player/mods/quoth2pt2full.zip Which ericw says has pak2.pak dated November 2016, like negke the contents say May 2014 for me. So I open entirely different web browser than normal to make sure and download. Same problem. May 3, 2014 :( Dumb question: As I understand it, Quaketastic doesn't let you delete or replace As I understand it, Quaketastic doesn't let you delete or replace
It does, and that's what I did. Maybe your ISP has some kind of caching layer which is messing this up? Try http://www.quaketastic.com/files/single_player/mods/quoth2.2.2full.zip which has a different filename so should circumvent those issues.
Ok, you replaced it. That makes a great deal of sense then, very likely is network backbone-level caching. Which can be a real pain.
I just downloaded the file and it's May 2014 still.
Probably should have a couple of other people other than myself check it out because I'd feel real bad if somehow it is just me. Like negke since he reported the problem. I just downloaded the link in post #65
Inside is a text file called quoth2_2.txt Inside that is a legal notice including the date "May 2014" Ok, just me. Ignore me. Important thing is problem solved.
Maybe caching works with a database that ignores punctuation and hashes the alphanumerics. Just downloaded it for the 1st time with the link in #65 and got pak2.pak, 8.0 MB from May 3rd 2014 @05:24
http://i.imgur.com/VgWSpop.png So this REALLY is the most recent file though? Have you extracted the file and checked if it displays the same modified date? Perhaps there's some glitch with the zip if you overwrite the file within a zip which puts the archive goes out of sync with the actual file - and that might cause the displayed date to be OS dependent.
Then again, maybe the OS dependency will also appear on the extracted file. Here are some file hashes to check for pak2.pak: MD5: 69c2c4880ccb367cee1e338194d47184 SHA-1: e357e0b2b78703e2ebb32ab822911b77c4b0a37a Perhaps there's some glitch with the zip if you overwrite the file within a zip which puts the archive goes out of sync with the actual file
To clarify, because it looks like I've written this sentence in the second person. When I made the zip file, I didn't rebuild the zip from scratch. Instead, I too the original zip and overwrote the pak2.pak file from 2.2.1 with the 2.2.2 pak file, using Windows Explorer. I'm speculated that this could cause a glitch, especially one that isn't apparent from a Windows POV. Today I learned that there's still someone out there who uses Windows Explorer to handle
Considering that "proper" archive tools can sometimes struggle and choke up when making changes, I always choose to completely recreate my archives when I update them. Even if that means just extracting the old one, adding in the new files/replacing the out of date ones, and recompressing it, it's just a little peace of mind that I like to have when releasing content... I feel like a lot of the issues in recent posts could have been helped by keeping different versions of Quoth more distinct from each other in this manner. Another help might have been to keep unique file names, if it is some sort of web caching interfering with downloads. Preach, since you are only guy in universe with any experience maintaining such a mod.
I've been thinking this over off and on, and here's what I've got for raw ideas after considering bad factors. /Not that I am optimistic that anyone besides yourself (and on a good day) is going to be capable in maintaining a multi-game dir mod, but that's beside the point. But Sock also seems like a particular picky fellow that is set in his ways, which is a major strength for this Quoth - Indicate version -quoth:1 <--- load through pak1.pak -quoth:2 <--- load through pak2.pak -quoth:3 <--- load through pak3.pak If I recall, original Quoth had 2 pak files. And then Quoth 2 had 3 of them. Then Quoth 2.1 had 4 of them. Under this system, it would have been preferable for the names to be Quoth 1, Quoth 2, Quoth 3, etc. But the point is this would allow a single Quoth mod but allow version specific loading. Why a colon? Because it is an illegal character for Windows filenames, no one can have a gamedir named "quoth:1" Sensible Double-gamedir Examples: -game mapjam85 -arcane // Quake mod using "arcane" -game mapjam85 -arcane -hipnotic // Quake mod using "arcane" requiring hipnotic extensions -game mapjam85 -arcane:2 // Load thru pak2 The -arcane:2, like the Quoth examples, could allow your onion layer versioning and allow a prior version of "arcane" to be used. (* Since -quoth is known to require -hipnotic, would be the sole exception to the rule.) This would allow people to keep doing what they are already familiar with doing and everything works the same. Anyway, these thoughts provided for your feedback. The idea with the pak files was to allow simple upgrades from one patch to another without needing to download lots of stuff again (remember, this plan was invented in 2005 when people had to worry a bit more about bandwidth). So the idea was that you could upgrade to 2.2 straight from 2.1 or 2.0, and 3.0 would work in the same way, replacing pak2.pak, making an upgrade which works from version down to 2.0. Then 3.1 up to 4.0 would be pak3.pak, etc...
I have to ask, given how hard we work on backwards compatibility in the mod, why you think there's a pressing need for playing earlier versions? Is there a specific issue with a map we need to shim in the next patch? I think it's not so much about quoth specifically, so much as allowing mods to use a similar system, but in the event that they don't have that level of backwards compatibility, to allow easy loading of older versions.
a) For original experience at map release time as an option.
b) Testing and checking for a material behavior difference. c) Fallback if something if bug or issue with current version, without the user having to reinstall an older Quoth to work around it. I know some of the mild changes like changing the voreling health don't mean much to most people. But for instance, if I want to reply an old map that I liked, I'd like to easily replay it with exactly the same rules and behavior in effect that were there the first time. At least as an option. What if I want the voreling to be annoying and require 2 super-shotgun blasts to kill because when I played the map originally it had annoying vorelings? One irony is that certain releases are actually mostly exempt from Quoth upgrades because they have their own progs (Metal Monstrosity, for instance). Also what Pritchard said.
You pioneer the incremental mod release idea with the additive pack concept. If others follow your lead, my above scheme is a way that full compatibility is always an option. 1) I take warpspasm.zip from Quaddicted.
2) I take Quoth 2.2.2 zip which I am assuming is current version 8,035,386 bytes (pak2.pak size, working on assumption that the date of May 3 2014 is error of the zipping tool). 3) Using the glwarp.exe provided with the Warpspasm download I do this c:/quake/glwarp.exe -game warp -quoth What I get when I startup *) I get Quoth demos playing. What I am supposed to get when I startup *) I should get the Warpspasm start demos playing. Basically, playing Warpspasm with current Quoth I can't get the intended Warpspasm experience. (I wouldn't have to use glwarp.exe, I could instead use Mark V or BengtQuake or the Requiem engine --- all which support the Warpspasm demos that are in protocol 10002.) So anyway, an example. I have responded in much more complexity than was perhaps necessary here
I think that is a cool thread.
Anyway, I think a "Touch of Evil" is going to be my in-engine short-term solution for the Warpspasm issue to make it so the presentation is right if (game == warpspasm && command == startdemos) You are happy. I am happy. Someone wanting the Warpspasm experience is happy. Somewhere an Evil God of Proper Coding is looking down at me with a frown --- but that happens all the time. /Quoth 2.2 at Quaddicted on last check is still 2.2.1, btw. I checked rather recently and the byte size of pak2.pak is not same as your Quoth 2.2.2.
|
|
|
Post A Reply: |
|
| Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors. |