Pros and cons?

Because obvious repeating textures annoy the hell out of me, I've been thinking about how one might automate random textures on a face.

Here is the best implementation I can think of:

Modify qbsp to divide faces along a specified textures edges. Brushes containing that texture have their textures replaced with with another that has the same prefix and different number.

i.e. original texture is $0brick_wall, is replaced by $4brick_wall, etc.

It is an idea I'm playing with, and hell, I'll probably never implement it, regardless, what are your thoughts? 

This could be interesting but IMHO only with slight variations of the same base texture, so as to avoid the grid effect. Any more than that and randomization will likely produce weird side effects. 

I think one way to avoid repeating textures using that kind of compiler feature wou, rather than multiple textures for it to choose from, it could use one perfectly seamless texture and rotate it in random 90 degree intervals. Subtle but as far as I am aware a pretty effective result. 

Yeah, but doesn't help with brick textures and such.

I had the realisation that this could also be implemented in editor. Which is probably the better option.

A third option (handy) but worst in my opinion, is decal support for quake maps. I think this is worst because it is engine specific, and the maps wouldn't be backward compatible. 

Would it be though? If the decals were baked on during compilation they wouldn't be. But you'd have to make some pretty big changes to the compiler so that it was able to combine the appropriate images. It would be a pretty powerful tool though.

Psst, someone suggest it to ericw 

the implementation required to make it work with vanilla would be really tricky, probably more complicated than its worth.

I think there is a maximum texture resolution, so if you were to decal over the edges of said texture, you can'd just make a huge mega-texture. In that case you would need to split the texture into separate parts to avoid that limitation.

Then it isn't just the one texture on the face anymore, so you need to split the geometry anyway. 

I think the way to go for brick is to do what czg's honey does, make a 256x256 (I think?) version of a 64x64 texture.

also: http://www.celephais.net/stuff/texturefaq.htm
There is no upper limit to height or width that I know of. The largest texture that shipped with the game is 320x192. 

well if it doesn't care about dimensions then I might make a little java app to randomise textures into a big texture then. 

Well, for the record I'd still like to see decals someday >_>

I'm imagining it would get pretty whacky though. You'd have to account for the palette for instance when blending the two textures, I get the feeling that with some colours you'd end up having to make some compromises. And compromise is never something you really want to automate... 

talk to mankrip re: colour blending with palettes, something tells me he's all over it. 

That stuff freaks me out. Some kind of voodoo magic I think.

If he could provide ideas as to how his implementation could be applied to low-res textures that are baked into a map, I'm all ears, but from what I've seen a lot of the quality seems to rely on the fact that he's working with a high enough resolution that the grain introduced by the super duper advanced and spooky dithering isn't too obnoxious.

And by "I'm all ears", I mean "I hope someone else is all ears because I know enough about coding to know that I can't code that" 

You'd have to account for the palette for instance when blending the two textures
Not if the decal is 24-bit, then it'll ignore the palette. One thing though: wouldn't decals exclude QS compat? 

Wouldn't be capable of using replacement textures, but I don't see why qbsp couldn't be extended to merge the decal with its underlying faces into a new texture. If qbsp then output these new textures with the names used such as <mapname>_dec1.pcx...<mapname>_decn.pcx then perhaps it could support replacement textures even if only manually. 

Any help in solving this issue?

https://github.com/muk0r/qompiler/issues/1

Im building a compiler. I want it to use profiles to load saved compiling setting. How can I load a batch file to assign values to the variables I've created in the first batch file?

The current version is in branch v0.75

https://github.com/muk0r/qompiler/tree/Qompiler-v0.75 

do any of you guys have access to the "team fortress" or "future vs fantasy" source codes? 

TF: http://upload.foppa.dk/files/tf_29src.zip
You should check out Custom TF too, cool stuff added there, like building your character. You could be a thief (invisibility). You could have a special knife and when you stabbed like 5 people you could summon a Shambler who was following and fighting for you! :D ...and other shit that people were adding over the years to their mods. 

Here you can read about some features: http://wiki.quakeworld.nu/Original_CustomTF_Version_File
You can find sources on SourceForge etc. 

thanks man, much appreciated. 

and

http://quakeone.com/forums/quake-help/multiplayer/2798-latest-fvf-2.html

tells me everything I need to know about fvf 

For people with coding issues. 

Was there already a long discussion at some point in the history of this board for why the Coding Help thread *shouldn't* be a permanent thread? Because it seems like it should be. 

QC Help [EDIT]
Posted by ijazz2 [125.17.68.26] on 2017/02/12 17:17:33
I am making a mod,but it wont compile.
I have spent one year making this plus correcting bugs,and on top of that school.So please,could someone help me? Fix fusion2.zip.

Quaketastic.com ,file in the QC Mistakes dir.

If anyone wants to use this then please put something like
modname/authorname_qc_date in DD/MM/YYYY .ZIP OR .7Z

THANK YOU,

-ijazz



Alos +1 vote for Quake Engines sticky, and Other PC Games thread sticky. Jury's out on CZG's Anus sticky but you can guess where my vote lies. 

So I tried to clean up my qc a little bit and moved all the precaches in the worldspawn into its own function:
void worldspawn() =
{
(...)
precacheSounds();
precacheModels();
(...)
};

But now FTEQCC spams me with these warnings, even though it obviously works and these sounds are being precached:

player_movement.qc:80: warning F210: Sound "misc/water1.wav" was used but not precached
note: suppressed 12 more warnings about precaches.
Compile finished: ../progs.dat (id format)
Done. 22 warnings

Any way to get it to recognize that the precaches actually take place or disable this warning? I've already removed all other warnings from the source, so it'd be nice to have an actual clean compile for once.

This is in FTEQCC: Feb 11 2017 

precache_sound() vs sound() calls go based upon string immediates that are passed in. if you're not using an immediate then fteqcc can't read/check it for you.
I guess you're looping through an array to precache your sounds (thus no immediates, so fteqcc can't see them), so either use the same lookup in your sound calls as in your precache_sound calls, or just '#pragma warning disable F210' to disable those warnings.