Thank You Preach
For your continued effort to make the life of Quake mappers easier, and mine harder.
Great work Preach!
Re: Negke's Comment
and mine harder
Why? Does this break Skinny Norris?
Also: what the others have said -- thank you, Preach.
Thank You Preach!
Congratulation and thank you!
That tutorial is awesome indeed!
excited to check it out :)
Getting now -- know what I'll be doing this evening ;D
Awesome Sauce, Cont.
Is the external models stuff recent or something Quoth has always had? If so, I've been a cludge for some time, now...
this is cool!
That feature got added in 2.0, but it wasn't well documented at the time. I think there are some rotating entities which show the feature off in e1m5quotha (rotating entities benefit a lot from the feature).
It's interesting to see how the tutorial has got as much traffic in the past 12 hours as the main Quoth page. So it's certainly helped promote that side of things!
will check it later
Quoth included the fixed up dog model that was created by capnbubs (and I'd say the nicer player model and soldier model), plus I would also prefer slapmaps plasma gun to replace the dildo cannon.
All in all though it's nice to see Quoth get continued support.
Kudos in general on it Preach, especially the tutorial, which I am sure to be revisiting innumerable times in the future.
That fixed player model has a weird face. The dog is very nice though. If I'm not mistaking them for some other replacement models.
I'm only waiting for the glitchy fullbrights to be fixed, because it's a little inappropriate for a project of such significance.
Thank You A Lot
for both the release and the tutorial.
For 2.3, you could please put a melee air monster, to complete the bestiary.
I wish I had the first clue about making models (I can do textures, just models I'm not sure about)... anyone got any good advice or tute's on making quake 1 models?
I love the fixed player model, face seems great toe me. My only gripe is the pockets on his ass are a little big. ;)
anyone got any good advice or tute's on making quake 1 models?
Qexpo Tutorial And Overriding Models
I've just finished working my way through the qexpo tutorial adding some annotations on the things I think are out-of-date in there. So a great time to check it out!
On new models: Quoth takes a very softly-softly approach on new models. Some people like the replacement skins they've installed for models, others are religiously devoted to the originals. So we try not to mess with anything that isn't needed for functionality. On that note a quick detour into one feature set:
One of the things I did for 2.2 was go back and recreate all the "combined weapon models" to make them more true to the original v_weps. The 2.0 versions were a bit sloppy in places which may have discouraged use of the feature. The new ones are interpolation friendly, power-of-2 skin size, and have front-back skin maps so QME still handles them correctly. I think they top the originals.
Now, the pains taken to not change a single pixel on the skin but only move some triangles about does make it easier to adapt a replacement skin to these new models - it's just a cut and paste job. However, that's not automatic. If a map turns on the combined weapon models then custom skins for the originals have been disabled. Didn't we say that was bad?
Enter the scratch1 cvar. Setting this cvar gives you veto rights over the way a map uses combined models. If you set "scratch1 1", then even if the map requests combined models you get the uncombined versions. Usually the mapper would do this if they are close to the model limit, so it's recommended to only do this if your engine has increased limits.
Conversely, set "scratch1 2" and even if the map doesn't set any combined model flags, you get all the combined models! This is intended for testing purposes, but if you really like the .mdl ammo packs and the new combined vweapon models you can force them always on. Why not use the new quoth.cfg to set this up? You know you want to...
Lost No More...
Sorry for the double-post, but here's a little bonus for the func_ crew. I've repackaged some Quoth maps from before there was Quoth - it's The Lost Chapters!
As usual, save the pak to your hard disk then drag-and-drop onto launch.bat to play. This was surprisingly easy to port - all the necessary changes stemmed from renaming the hub to chapters.bsp.
Md3 To Mdl
I thought there was a way to make direct to mdl using blender??
dude, using the console, I'm unable to launch half the maps from your pack :
I can launch the other maps (using the console), while in the usual Quoth default start map. So WTF ?
And why are these superb maps (kell, vondur, zwei) not part of the official Quoth distribution ? There's only one map in Quoth ! W-T-F !?
Renaming the chapters.pak to pak4.pak solved the issue. But what the hell with the name !? And I lost the path to the default Quoth start map and its nice default level. What gives ?
you mean the hub map? preach says he renamed it to chapters.bsp
Yeah, the pak's meant for the launcher, if you drag and drop it on launch.bat (new in 2.2!) then it "installs" the pak and loads the hub for you. You can do it the manual way as you saw, but you need to know one trick: the name of the pak tells you the name of the map to run.
PS: If anyone else would like to have their map added to the map paks page give me a shout. The 9 which are up there were maps that tested the feature best as they came with lots of added resources, but I'll add Chapters and any others people want to include in a "second wave" sometime soon.
Now that it's able to "spawn awake". I tied it to func_rotate_train. Set targetname to the train and targetname2 to activate. Works!! I can move the spawning along the train route. Might be helpful for arena settings.
Strange Weapon Behaviour
hello, i tested quoth 2.2 with darkplaces engine and encountered one strange thing. everytime i walk my weapon is shaking a little. it's anoying as hell. everything is fine as long as i stay still, the moment i start to walk weapon starts to shake/jitter. it happens only during gameplay, weapons are ok during menu demo loop. i tested the last official dp version with the new quoth 2.2 as wel as with the last one and it's not engine related. qouth2 works just fine. any idea what may cause that?
It's a darkplaces specific issue, you can read some posts from when I investigated it here:
Essentially sv_gameplayfix_nogravityonground 1 is applied in Quoth 2.2 because it appears to make darkplaces behave more like standard engines in player to BSP-model collusions. The sliding issues I mentioned in that link have been fixed by the latest release, but as you have noticed there is a strange visual head-bob glitch. It seemed safer to release with a visual glitch that will likely be patched than with a gameplay glitch that's probably by design in the engine.
Two known fixes: run in a different engine, or add
to your quoth.cfg file. Of course, the latter does mean you get the button-standing glitch back. It might also be possible to disable a bunch of the head-bob related cvars and have a stationary weapon, but I don't know which cvars it would take.
Thanks For Swift Answer
i tried to turn off mentioned cvar and it works. thanks. it's quite confusing because these gameplayfix cvars have been an issue for a long time and lord havoc stated some time ago that he dissabled them all by default. apparently not this one. i set it to 0 and suddenly the game doesnt feel like snowboard simulator anymore. that's a good thing too.
One More Thing
now i understand... sv_gameplayfix_nogravityonground is globally of, but you added that cvar into output.cfg in pak2.pak. i tested a few quoth maps and found no gameplay problems with that cvar set to 0.
Standing On BSP Model
The specific issue it fixes is how often touch functions run on brush-based entities. In regular engines the touch functions run repeatedly, so you can trigger a floor button multiple times without stepping off it, and continually take damage from spinning blades etc. Without that cvar on darkplaces will only perform one press/deliver one tick of damage. This issue wasn't discovered in released maps but in some of the unit test maps I've made for discovering bugs.
Quoth 2.2 crashes BJP's GLQuake?!
PR_LoadProgs9: statement 50737: bad opcode 80
This occurs when trying to load a map. Oddly enough, that weird new demo runs just fine.
Easy to reproduce, it does it on my copy, it happens as soon as you load the mod. Ho hum. I know why it's happening as well, it's an issue that happened in some older versions of darkplaces. FTEQCC uses extended opcodes to make arrays faster in supported engines, coded so other engines never reach them. BJPQuake checks for invalid opcodes, and won't launch a mod if it find them, even though in this case they're entirely benign as they can't ever be reached.
Really this should only be a engine warning on load, because of this case where unsupported opcodes are locked behind a barrier only supporting engines unlock - it should only be fatal when the engine tries to execute the opcodes. Anyway, I've uploaded a fixed version of the 2.2 patch (I'm not gonna bump the version for this) where I compiled with the fast arrays feature turned off (since the arrays in question are of size 4 there really isn't any need for speed). Download http://www.quaketastic.com/files/single_player/mods/quoth2pt2patch.zip
for working things.
PS: Spike, what's the command line to turn fast arrays off? I found it in the GUI but I'd like to add it to the build script instead...
It's -Fno-fastarrays for reference.
#pragma flag disable fastarrays
Uploaded a minor update to the fgd file for better compatibility with GTKRadient. The fgd parser for GTK is a little stricter than the worldcraft one - the two crucial differences I've discovered are:
* PointClass, SolidClass and BaseClass are case-sensitive and must be written in CamelCase to work.
* It is not permitted to omit the description string which follows the classname for a PointClass or SolidClass entity. In worldcraft this is an optional entry.
So the new version of the fgd complies with these two rules. Does no harm but makes no difference for Hammer/Worldcraft users, lets you load it in GTKRadient. Note it appears you must jump through some hoops to get it working in GTK - I had to rename it halflife.fgd and place it in a folder called "valve". Plus a few of the .game file settings have to be copied exactly from the half-life .game file to get things to work.
I'm sure there was a way to convert fgd into a def or ent file, but can't seem to find it anywhere online...
were not part of the fgd with trenchbroom, are they in this one?
...but they would be very easy to add. On the other hand you hardly gain anything over just manually typing in func_detail, because it's an entity with no key values, just a classname.
Found A Problem
I get this message when opening WC3.3 using the latest Quoth2.2 .fgd
error parsing c:\.....\quoth2.fgd line 1166 expecting '=' but found '.'
error parsing c:\.....\quoth2.fgd line 1310 expecting identifier
Is it important or can i ignore it?
Looks like there are some places where 3.4 is less fussy than 3.3. Both look easy to fix though, so I've uploaded a tweaked version. Give it a try and let me know if it sorts things!
Seems To Work
no messages this time.
Thanks for the instantaneous fix.
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:
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.
Ooh, I didn't know that. I have the full version so I'd better check it out.
No wonder I had so much trouble with the last jam.
Umm, you mean map jam 7, I suppose? The last one runs in AD.
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.
The full zip on Preach's blog still has the pak2 file from 2014?!
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/
Maybe some kind of caching issue?
Maybe is time for Quoth 2.3 since Quoth 2.2 can have so many different meanings.
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 ...
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 ...
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 ... so can't be an internet caching issue (like what CloudFlare does) because same file couldn't have upload twice with same name?
Replacement On Quaketastic
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?
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 did not click a wrong link, I assure you and I downloaded it twice).
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"
oh, but it does have a pak2.pak with a date of 11/11/2016
Ok, just me. Ignore me. Important thing is problem solved.
Maybe caching works with a database that ignores punctuation and hashes the alphanumerics.
Not Just You Baker
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
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:
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 .zip files.
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.
Alright ... Sensible "extend A Mod" And Quoth Versioning
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 ... so anyways ...
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"
-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.
I got your meaning. Thank you for the hashes, I'll check them against what I have.
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?
Probably Wrong But..
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.
@preach - Issue Example
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)
... if (startdemos != "demo1 demo2 demo3") then make it so
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.
So when's Quoth 2.3 coming out?
the same format and orientation for the skyboxes in the Quoth pak files? Or are some of the locations different? I thought I'd ask as I don't have a ton of time for trial and error. The one time I've tried it was a disaster.
I would like to do my own from Space3d
This is really more of an engine thing than a Quoth specific question, but I think I have figured it out. If you change the filename suffixes in the following way everything should align:
pos_y -> up
pos_z -> bk
pos_x -> rt
neg_z -> ft
neg_x -> lt
neg_y -> dn
lt+rt are flipped in relation to normal cubemaps, iirc.
this means that the other 4 images are flipped on various axis too or whatever, which means simple renaming isn't exact.
If you don't really care that your cubemap is basically inside out then whatever just go ahead and rename them, but if you want to map them exactly then you need to do more than just rename them. Probably for embedded space scenes you won't care.
@spike & @Preach
Thank you guys so much. I was just sitting down to do a simple number 1-6 cubemap in PS to see what could be flipped etc. This helps a lot.
pos_y -> up
pos_z -> bk
pos_x -> rt
neg_z -> ft
neg_x -> lt
neg_y -> dn
Tested in Quakespasm - this is the right configuration! Thanks again.