News | Forum | People | FAQ | Links | Search | Register | Log in
Quoth: Expansion Mod Pack For Q1SP
The intention behind Quoth is to provide a large portion of content in as easily accessible form as possible for both players and mappers. The components are designed to be consistent with each other as well as the original id content. More is under development and updates will be released as and when they are ready. Yes we are mad, but ours is a madness brought on by divining the blasphemous truths of a terrible cosmos. Or something.

More info, download and images:
http://www.planetquake.com/necros/quoth/

Direct download ( FilePlanet, sadly ) :
http://www.fileplanet.com/dl.aspx?/planetquake/necros/quoth.zip (22 meg)

This pack contains several monster/weapon/power-up modificiations, and some test maps. Additional full map releases posted below...
First | Previous | Next | Last
 
i want to map for Quoth :( but still dont know how with Quark! 
Gargh! 
I was working on a Quoth .qrk addon file for QuArK but it turned out to be much too time intense for me. You can always just rename entities, triggers are whatever to what something is called in Quoth. Then add or delete specifics with the + and - smybols. Not a fast way but at least you can map for Quoth that way.

Let me guess... You want the hordespawn, eh? :D 
 
i just want to add some monster... if possible i whould like to add in this big map i�m making now! it feat very nice some of the monster�s :) 
Spirit / Trinca 
Don't forget to add the Quoth pack nt the tmpQuark directory where the map are compiled.. it's usefull to be able to launch correctly the map with all Quoth pack feature included... 
 
exploding wall code:

what do you want for this, exactly? i mean, if a bmodel disappears when triggered or when killtargetted, is there a difference? :P or do you want some kind of rubble spawning?
can you describe what the modified zer code does?
i suppose rubble spawning wouldn't be a bad idea. could probably get away with only using one precache, and having multiple rubble models in different frames with different skins. But then how do you make rubble to match different textures? have a billion skins for any possible texture colour on top of having different skins for the different rubble frames?
we'd have to look into this. kell has mentioned wall breaking stuff though, so there's a good chance.

about extra shooters, (even auto aiming ones) that shouldn't be too hard to do.

about the gug though, i'll be honest with you and say he's working pretty much as intended.
there is only one thing though, as we never considered that the player might be able to run from a gug and not get back to kill it. having the earthquake attack eventually time out and stop being used might be a good idea for those occasions. possibly even making it toggleable via a trigger, but we'd have to test something like that.
kell and i discussed configurable monster behaviour a fair bit, and we like to stay away from that as much as possible because we want behaviour to be obvious, and consistent, but your suggestion has merit.

amusingly, we have discussed the possibility of having the gug be able to earthquake at specific times and trigger off targets to break walls down and such.

on bob... well, for this i'm really not sure... Ai tends to break down into tears when it's forced to do anything 'non-standard' (remember the helper monsters in hipnotic? :P)
if something like this were made, it would be something general that all monsters could use, i think.
again, we'll have to discuss this, as i can sort of see where you're going with this, and the possibilities it might produce, but it seems to be moving a fair bit away from the quake 'feel' as helpers aren't really what quake is about.

one thing i definatly want to do, though, is some proper logic stuff. if:or/and... pissed me off that i had to build all those stupid lightning + door tricks in marb. :\

i will be honest with you here and say that i'm not sure when any of these changes can be made. kell and i aren't actively working on quoth at the moment. 
What Necros Said 
 
Thanks For The Reply... 
I wasn't sure if you were still working on stuff, sicne Kell mentioned something about a new boss monster earlier.

Anyway, the exploding wall code... I can email it to you in a couple of days. It's potentially buggy because I wrote it, but I never noticed any problems. Here is a list of features:

health: amount of damage to take
rubble: amount of rubble to spawn on destruction

various damage methods: either explode by trigger or taking damage. Optionally toggle one hit kill only, which causes the walls health to reset if it is not destroyed in one hit (i.e. for explosive/quad ssg only destruction)

BBOX or BSP clipping: either use a regular bounding box for clipping (as in Zer) or use BSP clipping (same as doors, plats etc.) so the players or monsters can walk on it.

styles: built in styles include brick, metal, wood and gib (maybe another I forgot) , but use 2 models I think. This could be modified into one model using three different frames easily enough I guess, but I don't know how to edit q1 models. Each style has it's own sounds.

In addition, styles can be overridden and any models or sounds can be used. e.g. set model1/model2 an/or noise1/noise2 (explode and gib bounce sounds) for custom effects, such as spawning gib explosions using quakeguy heads :)

Also, I think the force of the damage to the wall affects the velocity (maybe just speed) of spawned gibs.

There might be a few more options for it, but I don't have the code to hand, so I can't check right now.

Regarding the helper monsters in Scourge, I rather liked them. It was fun to have a Shambler spawn and do half my work for me :) The horn sound that summoned them was cool too if I remember it correctly. The early mod cujo was quite fun also, as was the axe of persuasion.

As for the Gug stuff, what you are considering is pretty much all I need really. I want the gugs to stop earthquaking after they haven't seen the player in a while, because I wanted to put one near the start of the level, when the player can't kill it. My current idea is to just put it well out of range, but I don't know exactly what the layout will be yet.

By the way, I don't particularly want the following features for my map, but they could be cool to have included in Quoth (for subsequent maps) if you have time.

Basically pox extras. Some of the coolest mods I have ever seen for Quake, yet nobody has actually used them in a map afaik. The main features are flowing water, advanced trains, and water that can be attached to func_trains (and behaves exactly as you would expect it to behave). There are some particle features that are quite interesting, although I'm not sure of a practical use for them, although the weather and dripping effects are quite nice.

Even if you don't want to include them, they are certainly worth a look. http://developer.chaoticbox.com/quake.php 
I Checked That Out 
some neat things there

another thing i've wanted to do is be able to bind movers to other movers like in d3 (ie: have a button and door follow a lift). i think that was mentioned for the func_switch ent, but it would be cooler if it worked with all movers. probably not for rotaters though, since rotation in quake sucks already.

for breakable walls, sure, send over the bit of code (the email i have listed in my profile should work).
It's potentially buggy because I wrote it, but I never noticed any problems.
that's fine, it should feel right at home alongside my own stuff. XD

also, i'm still not entirely convinced helper monsters is a good idea. i tend to think of it as a gimick, tbh. maybe if it was in a limited capacity... ie: the helper lives for 30 seconds, like a quad or pent, then dies after that time is up.

anyway, i'm not in the habit of promising anything, esp. at this point since we're on break. :P

kell and i are (usually) open to suggestions so feel free to post anything else. no promises though. ;) 
Necros 
kell and i are (usually) open to suggestions so feel free to post anything else.

I'm eating a salad right now, and I'm ready to move on to the main course: Gauntdrop! 
Oh Yes... 
...the legendary and long looked for Gauntdrop :) 
Breakable Walls 
i suppose rubble spawning wouldn't be a bad idea. could probably get away with only using one precache, and having multiple rubble models in different frames with different skins. But then how do you make rubble to match different textures? have a billion skins for any possible texture colour on top of having different skins for the different rubble frames?

Medal of Honor had a system where you actually made rubble out of brushes, placed it roughly in the right spot inside the intact wall, and then gave it an info_null to fly towards when triggered. The intact wall model would vanish, and the rubble would all appear in place, fly outwards and bounce around. Of course it used a lot of edicts, but it gave total control for size, shape, texture, and number of rubble pieces used. 
 
...and use up one precache slot for each and every piece of bsp model rubble. ;)

i'm not saying it's not cool looking, or that it wouldn't work well, of course. but it would only be feasible if you had a string of small maps where you could afford to chunk out quite a few precache slots. (since bmodels and model precaches take up the same slots, of which there are only 128, i believe).
normal quake without any monsters or items already loads up a fair bit (about 20 or so), a typical map might have 60 or so doors, plats, trains, triggers. Then monsters and weapons come in, another 30 or so. (at least 2 (usually 3) models per monster, body model and head, plus any projectile models)

the main reason something wouldn't be added is that it would end up using yet more precache slots. They're very low as it is, and in a typical map, you wouldn't even be able to place a monster of every type.

a last thing to take into account would be that bsp models wouldn't have proper collision. If a mapper made the pieces too big it would clip into brushwork, and if it was too small, it would float over the ground (unless they were set to have 0 size, in which case, anything larger than the chest gib model wouldn't look very good).

most probably, the MoH engine was modified to support more model precaches, or parts where explosions took place with that method of rubble were short areas where they could change map to get back those precaches. i've never played the game, so i wouldn't know how it was done. 
How Many Edicts And Precaches Can Fitzquake Handle? 
Just wondering, because fitzquake just shits on every other engine imho. I am using FQ as the main engine for my current map, which should end up being pretty enormous by the time it is finished. I would really like to know how many ents etc. I can throw in.

Didn't know that brushmodels used precaches either. I presume triggers use only edicts, right? 
Textures 
I think you made some more textures for quoth, right? Have they been released separately, or should I just rip them from the relevant maps?

Also, out of curiosty, who users hammer (pre HL2) for Q1 edting? I find wc1.6 nicer, despite the fact it doesn't have an accelerated 3d view and suffers from a weird problem where it sometimes confuses texture names with a _# extension. It's generally a lot more straigtforward to map with and tends to crash less (when it matters, 1.6 always crashes on shutdown after a long period of mapping). 
Triggers Use Up A Model 
The title really says it all. When quake loads the BSP, it precaches every bmodel in it automatically, before the QC gets a look in. So each trigger also counts towards the limit, which I'm pretty sure is 256, not 128. Still not that much. Now, it does seem a bit of a waste using up all these model precaches on models that are never seen. One way you can work around this is with a hack.

You can use the same bmodel for multiple entities in a map. So if you had several triggers that were all the same size(or could get away with being the same size), then you could make a dummy one of them in the standard brush based way, but centred on the origin. Then look at the entity data for the map to find out what modelindex it has, and at the same time delete this dummy entity. Finally make some point entities with
model *thatmodelindex
and all the properties of the trigger they replace. Because the dummy one was centred at the origin, you put the point entity where you want the trigger to be centred.

Nice idea in theory, but almost certainly a pain to actually do in a real map. At best, you'd want to test it in an engine that can handle more models, and then just reduce it down below the limit using this trick once it's finished. Even so, not fun to do. Perhaps a better solution would be to fix the QC that requires a model for a trigger. The model is largely a waste in the QC anyway. All it does is set the bounding box of the trigger to that of the model, collisions with the model don't happen at all. This is why all triggers are cuboids, regardless of how you build them in editor.

So I'm gonna go away and see if there's a way to make triggers without a model, I've got an idea, but I suspect it's a little more involved than what I have in mind. If I find a way I'll post it here. 
Ha Ha Ha 
There's me talking up the difficulty of a four line modification to the code. Oh well. Open subs.QC. Find the function InitTrigger. Replace the line
[q]setmodel (self, self.model); // set size and link into world[/q]
with
[q]
if(!self.model)
setsize(self, self.pos1, self.pos2);
else
setmodel (self, self.model);
// set size and link into world
[/q]

Then you can make any trigger a point entity simply by filling out the minimum and maximum points of the trigger in pos1 and pos2 instead of giving it a model. pos1 and pos2 should be the absolute world coordinates, not relative to the entity. Not tested this extensively, but I can't see it going wrong. Have fun! 
Ha! 
nice one preach...

I had one alternative in mind, like a few standard trigger entity boxes in quoth, something like a cube 128x128x128 and a thin plate 256x32x256. If you put them into the fgd, it's easy to place them since you see the bounding box in worldcraft. I don't remember if rotation shows though.
Anyway, then you can have 100 triggers and it only uses one bmodel. Of course, you'd still use brush ones for custom shapes.
I don't remember about radiant, if it shows entity bounding boxes. 
Reviews Posted. 
I have posted my reviews of all 3 maps. Along with some ratings & comments on the Quoth/lost chapters new monsters:

http://www.planetquake.com/underworld/index.html.

the gug is awesome. :) 
 
Than: 
fitzquake has increased max_edicts, but no increases to precache models or other related limits. 
Metlslime... 
precache model is 256 right? Sounds reasonable I guess, but maybe it could be increased in a future release of FQ? :)

Maybe it's ok then, but perhaps the next version of Quoth should feature Preaches additional code if it works - especially since triggers are AABBs anyway so the model is completely unnecessary.

I have never hit any model precache limit before, but I had ecit probs back in the old dosquake days. Presumably Kell and Necros have had probs at some time or another, but what about mappers making vanilla quake maps? CZG? 
Frankly 
my take on this is if you're making a map so large that you need to resort to ugly hacks like that, well, just split your map up. 
:( 
Is it really an ugly hack? Why does quake need to precache a model for something which can be definted by two points? Surely the code is ugly in the first place?

Still, if you think it's a crap hack then fair enough, I will try and fit it all into the regular number of slots.

Anyway, splitting the environment up will really spoil my design. I am really enjoying making the map atm, and I hope to make my "best map evar!" - at least in terms of layout, lighting and architecture (hopefully gameplay too, but god knows how that will turn out at this stage). It's supposed to be epic. The design is currently an underground city, but each building is like a separate level in itself. There are at least 3 of these buildings in a large cavern (which is kind of another level that links them) and some smaller buildings. I suppose I could split it, but then I couldn't have all the little links and secrets between sections.

Currently I have built about half of the library building, and that's pretty big already. I still have a long way to go, so maybe it's too early to go around asking about engine limits when I have only got a few thousand brushes placed, lit and textured. I am just excited because it is the first time in ages I have gotten into Quake mapping and started really having a good time.

I can send you some shots if you are interested (since it will be using Quoth ents when I get that far). 
 
it's nothing personal, dude. i just feel that the real solution to the problem is to change the engine itself, since that is the limit it imposes, not to try to work around the problem by shoehorning in a fix by making two seperate trigger entities.

on reflecting on it though, i guess it would be a good way to save on precaches, and isn't really hard to implement. since i know nearly jack-shit on engine code, i'll keep it in mind for later.
heh, maybe i caught a bit of the 'not invented here' bug. :P 
Polyp Skins 
is there a way to use the second polyp skin, as well, to have polyps in two different colors in a map? 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.