then everybody agree? 

Just a question: if fortunately I have time to make a map for this pack, is Doom3 texture set use forbiden, or not ? 

i dont now i�m not leader of project i just sugests!!! my English is total crap :\ but i think is base stuff related... lets see what other people think! 

I personally thought it was idbase only, but there is no rule saying you cannot use other base textures at all. If it means we get another map in the pack then I suppose any base themed texture set would be ok. 

rubicon2 textures -- yes, �o no? 

no, use idbase. 

i�m using idbase the pack that biff and than have! 

and/or limited use of other textures to complement the idbase ones? 

http://daz.quaddicted.com/

2 new pics for you all, just finished off the lighting and rocks, and added a cool skybox by Kell.

Gotta crash and burn now, shall carry on tomorrow though :D 

idbase only please, with perhaps a mite smattering of other complementary textures.

Again, if all maps use idbase only, then they will work nicely with Starbuck's texture replacement pack. 

Starbuck's texture replacement pack only works with textures that have already been used... people making new ones (biff, me, gibbie, etc) will get a shoddy mix of such textures.

It's a base pack, do what you want. I see no reason to stifle creativity with this monster of a project! 

If it's idbase only that would suck, since my entire map is in speed_bz, and I'm sure as hell not gonna retexture everything. I think since the topic was "Base Pack" and not "idBase Pack" it should be open for all basey-type textures, not to mention that it would just add more variety between levels. 

Is there a common progs.dat provided here, or somewhere else, or are we allowed to use our progs.dat....

Sorry to come back maybe with already discussed point, but I just try to check the coherency of this pack... and if I have a chance aligned my current project and produce something for Xmas.. 

I spoke about this with Trinca at some length and we may have a solution that will satisfy purist and modsters alike. Though, this post represents my understanding of it; I don't wont this to sound like Trinca has agree to something that was kicked around but no real decisions were made.

Okay, here it goes: Mappers provide maps that are 100 percent compatable with standard Quake. If the mapper's would like additions -- base monsters, zer weapons, rotating brushes and the like, send a second .map file with those entities that can be used to override the unmodified Quake bsp by coding them into a progs.dat.

If this is what the mappers want, I will be glad to figure out how to put it together, and
put together a progs.dat including whatever resources are agreed upon.

Though, if you do decide to go in this direction, I will not include any Quoth material in the progs.dat without Necros'and Kell's explicit permission (I point this out only because previous post suggest mixing and matching Quoth material with material from other mods and it is bound to come up as an issue). 

Well, it effectively sounds interesting. however, how will you manage it with 2 different progs.dat that have "inverted" features. As example, spawn64 based progs.dat and standard progs.dat ? It create some conflicts I heavily suppose to be very difficult to solve, unless by a massive map (i.e entity flag) change... What do you think. 

since the topic was "Base Pack" and not "idBase Pack" it should be open for all basey-type textures

that's the same impression i had.
therefore i don't see why doom3 textures shouldn't be allowed - they are strongly differing from the other sets, but then again the maps won't be played in order anyway. imo you could also mix some metal or medieval textures in as long as the base setting is kept... 

i think could make the pack less boring with maps all in same textures i guess :\ i�m just using the biff and than base textures... 

we should just use the quoth progs.dat if we go the custom progs route, otherwise standard progs are best.

I do like the Mega Enforcer though.

I really want to make a heavy weapons guy style grunt (from scratch, not a modification), but it doesn't seem likely to happen thanks to my wrist problems from overwanking... erm, overWORKing.

Note that for this reason, I haven't even started a map for this yet, but I plan to when I have gotten a bit better (probably in a few weeks). 

DaZ: Wow, just fucking wow.

I would hope that we wouldn't get the differences in textures out of hand, so at least to have a cohesive pack of maps by that alone. Speed_baze is an excellent alternative to idbase, and maybe ikbase, but I would think using redone d3 stuff would be a bit out there, myself. Just my two cents.

I also think using the Quoth progs.dat is the best solution for any custom features, since that was what it was intended for, and would be nice to use.

And get well, than! 

a mix of metalbase, medeivalbase, wizbase, q2base, q3base, kingpinbase, doom2base, zeldabase, and mariobase textures. 

and unmodified Quoth progs please! So one has not to install another mod but just some maps.

I wish Quoth becomes some kind of standard. 

Quoth got red and green enforcers aren�t bad one shot grenades and the other rockets 

 

So many fingers, such a small pie... 

would likely yield the most interesting results, IMHO, and given the hard work Nec&Kell put in it, Quoth should be used more. My proposal is there if a major split comes up due to mappers wanting different things.

There has been talk of keeping the maps free of modification in order to make them QW compatable. I assume this must be for some kind of coop play that is done through the servers, but I'm not sure. The QW progs.dat has the monster code removed so I don't really
know if it is a relevant request or not.

JPL, that would be done through exception handling (if this & this happens than this doesn't). In the progs.dat I created for trsp3.bsp there was some serious compatabilaty issues due to one set of monsters being from LTH code which uses a unique touch function and the other set being tied to the Scourge of Armagon code which extends some basic Quake features. I had to split the functionality right down the line using exceptions so that the two code bases didn't interfere with one another. I can see using similar branching methods to keep custent/OUM/SoA from choking one another.