I think Than has the right idea here: if you cannot get consent to release the new content, use what you can -- even if it means scaling back some of the features in your levels. The original Quoth mod should be more than enough to work with and I can't see how dragging Kell's and Necros's names through the mud is really going to get things moving any faster. 

I don't drag them into mud, I'm just complaining they at least should have replied to the 2 emails I sent: I think it is not really fair. As I said I was asking for s simpele yes or no, and get nothing. I know they are really good mappers, it's a fact, but I'm just a little bit hangry about the fact they completely ignore the Base Pack now, while they provide something saying: "use it, we need you for the debugg"... and that's all.. there's no follow up, nothing, and we need all to rework our maps..." this is not really a fair attitude IMHO..
That's why I would like them to react now ! 

when the cat's away the mice ran the quoth seeds.

before tumbling down in discussion again about licenses from Quake or Quoth.
Fact is there are some people who liked a pak for quoth so there it goes.
Thinking of the enthousiasme in which this toppic has started we might as well beginn a discussion about flashlights again.

Following the thread I get a little concerned about the way it is developping.
Someone starts a toppic, others agree and start working, thirds come in with all kind of arguments, Then the Quoth thing starts, and finally Trinca blows his horn, leaving a bunch of mappers arguing the absence of the Quoth developpers, who won't give their blessing about the thing.

As long as I receive an update for Quoth I believe there is nothing wrong with permission.
Only someone who grabs the whole thing together to a well working Pak, not blaming himself to work without the help of Kell or Necros. I think there are enough posts that they could have answered too.

I started a start Quoth map and I'll send it to all participants, and I hope they'll get over to add a small start piece of their map. 

but do you need an updated Quoth? Couldn't you just use the "old" one? 

So, I just received an email from Kell this evening. I promised him to make public excuses concerning my lack of patience: he deserves it. Kell had a big personnal problem that needed him to quit the Quake scene for some time. He told me he will try to update Quoth as soon as he can, so he didn't forget us actually, he was just busy somewhere else, for very good reasons.
I propose to give him some time before releasing the Base pack...
Kell: I apologize a lot again... 

for these apologizes to Kell. I'm sure one of those who consume in waiting for the Base Pack release and I was in full agreement with your way to push it. I think it's great you finally got an answer to your e-mails. All the best for an updated Quoth version then. Quake quality first! - Don't blame yourself to much for your so called lack of patience. It showed more like enthusiam to me... 

Are we still planning for the end of this month, or are in in hiatus until Kell and/or Necros can be available with the updated Quoth? I'm pretty sure I can get my map ready by the end of the month, and could scale back the baddies for only the original Quoth stuff if needed -- but honestly, the extra time would only help the project. Just to let you guys know I'm officially on the fence, here... 

so patience is the best policy. I'm up on the fence too. 

I got your message; I'm gonna be on the road for a few days, but when I get back in I'll give the start map a good look over and tell you what I think, also, I'll give you the source to the cute little dome thing of mine I showed a screen shot to, if you would like to integrate it for my map selection area. 

.. Now, the thing is Kell seems to be quite alone on the project, as necros has other interest (with Doom3 maps).. so necros is almost out of Quoth project I guess (can I say that? ... nevertheless it has to be confirmed... hum...). So now, Kell would need a C programmer to update properly Quoth.c, progs.dat, maybe models... I guess he would be happy if a noble map would help him... Unfortunately I'm not really good in C code, so I cannot help much here... In anyway, I'm looking forward for Kell news onto Quoth update release... As I said, let's give him time, it is just what he needs.

Concerning the delivery by the end of the month, I think we have to deal with Kell's inputs about Quoth update progress... If it goes fast, we would be able to deliver this month, if not, I think we need his feedback, and then decide what to do... But as he is still on the scene, we can hope for a delivery (soon ?)...

Wait and see... 

you mean QC, right? 

I have one question,where can i download quoth source files (qc files) please? 

If Kell is still up for working on Quoth once he is ready then I think we should definitely wait until that time comes. Hopefully Necros will also respond sometime and either continue to work on Quoth himself or allow someone else to finish it off.

The extra time will also allow those who haven't finished their maps to get them done to a satisfactory standard and presumably not have to decide between their map and real life commitments.

Personally, I was getting sick of my base map and also feeling under pressure to either rush it and get it finished or just drop out of this project and release it separately. I'd really like time to maybe work on one of my other near complete maps and finish it off before hopefully returning to my pack map invigorated from releasing a map. 

Yes ;) 

oh wel i�m making another base map and i might use base quoth2... so i might have two maps ready... 

Worked for a starmap this night. I think it has to be simple, because of the compatibility to other adjustments of the mappers.

I will try to make my own part in it, and send this map to at least everyone who like(d) to collaborate. As far as now I have 7 entries and a skill setting. Except nightmare.

As I have no qc of the Quoth pak I can't be usefull to it. I only have the earthquake.qc and before the Quoth.qc isn't updated it is of less importance.
I tried the newvermis in my map, but it didn't appear.

the Quoth pak download is on Necros site:

http://necros.planetquake.gamespy.com/quoth/index.html 

Please send .map and corresponding .wad file... 

sorry , forgotten.
on its way. 

or am I whishfull mapping? 

I still didn't started my part, I'm sorry but my current projetc has some complex issues that I need to solve.... I'll send you the stuff when ready, don't worry, I didn't forget you ;P

BTW Kell, any news on your side ? Or does somebody know how things are progressing on Quoth front ? 

necros and I are in communication, have started working on the beta pak1 content to finish it off. Can't really say more than that atm. 

Great to hear you guys are working on Quoth again. I don't really want to throw a load of crap your way, but I figure that this stuff is worth mentioning anyway...

Is there any chance that the ammo boxes could be changed to require less precaches? At the moment it looks like they use 8 altogether, one for each type of ammo and size :/

It's only of importance to my non-basepack quoth map, which is very large, but it is possible that it could help other mappers who want to make large maps with Quoth in the future.

I suppose the problem with changing bsp models to mdls is that the lighting changes. Is there no way around that?

If there are any other optimisations on this front that could be done that would be fairly trivial and not make a big impact, such as the voreling using less precaches (currently 4?), do you think you might have a look at doing those too?

You might remember that I mentioned something about bounding box triggers before. If it is possible to implement an additional trigger type that uses a user specified bounding box (min/max keys) instead of a bmodel, then it would be incredible. It would sure solve a lot of my precache model problems anyway

Also, I don't know if I mentioned this before, but some enemies have a few fullbright pixels on their skin in places where it looks as if there shouldn't be fullbrights. The drole is the first example that pops to mind, but I think that maybe the death_lord and edie have some very minor problems too.

Finally, I'd be interested in seeing Necros' Doom 3 stuff. Has anything been released yet? There is currently nothing on his PQ site. 

I'm pretty sure Mindcrime added pure entity based triggers to Nehahra, where you specify bounding box size instead of using a brush (was to be able to modify maps without actually having to completely recompile them), so that's definitely possible. 

Good news: I'm glad to see you back on the Quake scene ! I am waiting patiently for the Quoth update :P 

Dammit Than, you pre-empted both my ideas there. Here's a bunch of mdl replica of the id ammo crates:

http://people.pwf.cam.ac.uk/~ajd70/ammomdls.zip

They are lit according to the light levels in the map, so you'd have to place them in well lit areas. Some of the skins have fullbright lights on them, ala doom 3. But since fullbrights don't work in some engines you have to be careful. Also at the moment there is one replacement for each model, none of them are combined, but with a bit of care you could get four or more models combined.


For point entity based triggers, there's a neat 4 line change that will give you every type of trigger at once:

Find the line

setmodel (self, self.model);// set size and link into world

and replace it with this chunk of code

if(self.model)
setmodel (self, self.model); // set size and link into world
else
setsize(self, self.pos1 - self.origin, self.pos2 - self.origin );

Then simply add a point entity with the correct classname(eg trigger_multiple). Set pos1 to the absolute coordinates of the minimum point of the trigger, and pos2 to the absolute coordinates of the maximum point.

Doing things so quickly, without making any new entity classes, does have one downside. In worldcraft if a classname is already defined as being a brush entity, it can cause problems making point entities with the same classname.
Adding some extra classnames like

void() trigger_multiplep =
{
trigger_multiple();
}

can help with this, as now you can make trigger_multiplep a point class. This has the advantage that if you need to make changes to trigger_multiple then you only change the code in one place and both classnames are affected.


Other model optimisations:

* Combine all the generic gibs into one gib with three frames, perhaps even combine the zombie gib while you're at it.

* To take it a step further, you could have an optional global flag for maps to disable head gib models(to be replaced by a generic lump of flesh). A saving of one model per monster it pretty good by my reckoning, even if it's a bit of a loss in visual terms.

* Combine the silver/gold keys into a single model with two skins. Only saves you one but it's a total waste right now.

* Combine the flames into one model with multiple sequences - Start with the flaming torch and shrink down/hide all the wooden bits for the other flame. Only a saving if you use both of them in your map, but gets you an extra model if so. This was better when I thought the large flame had a different model to the small one, but that optimisation is already present.

* Combining all the sprites into one large sprite could save you a few models if you're willing to do the work...

There's also a very desperate way to optimise bsp models if you have models that don't overlap in skill settings/coop. For example, you have a wall that appears only in coop, and a totally different brush entity that appears only in non-coop, so that the two are never loaded on the same map. I think I'm right in saying all of the brush entities in a map have their models loaded, even if the actual entity that uses that model is removed because of spawnflags. If you find an entity for which it's worth strictly checking it's in the map before precaching its model, then there is a way: Compile the model as a seperate bsp file, in the way that the original ammo boxes are bsp models. Then have the spawn function for the entity precache the external model.

This last tip is quite fiddly and it's most likely that it's not helpful for any given map. On the other hand, there might be some maps where it makes quite a difference, if the map is very different for coop than single player for instance. So it's worth a mention.