Can new FTEQCC with "extend an existing progs" be used to fix Marcher Fortress coop?

In coop for Marcher Fortress, unlike any other Quake SP release, if you grab silver/gold key they vanish because key_touch function sets model to none whether or not coop is set.

In theory, using the "fte mod an existing progs" you could add a new key_touch function to the old progs, but would need to override the old one. 

I introduced a retarded bug in marcher that buggers up coop in more than a few ways IIRC

I meant to release a patch, but it's 2016 now and I have other things eating up my time.... :{ 

you *can* wrap the existing function, reverting the model back or whatever after the original touch function (or just replace it entirely), assuming you know the name of the function in question.
but its best to just harass Kinn for the source and fix it properly, or better yet harass him to provide a fix too, and then resort to function hijacks only if he's unable to do so.

extending existing progs is more useful in a general sense (like adding misc_model or trying to fix prevweapon stuff), or for mods whose source is completely unavailable.
you can use it for some really complex stuff, but the resulting code would likely be too hideous to work on long term. 

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.