You write: "I want the Golem to only have melee attacks."
Then you edited the code and write: "I got a melee only Golem."
That was what you want. So what is wrong?

If you want to give him a different behaviour for ranged distance, then all you have to do is edit his ranged attack code. There is no TRICK needed. Just do it.
The Golem code works like any other monster code.
You first have to know what you want. Then do it. Yes, its that easy. 

I don't think I should "fork" the AD progs. I'd see that as a nightmare for a map(s) release.

Requiring players to duplicate their AD directory, replace the progs.dat with "my" version and then install maps and not get confused is it a bit much, yes?

That's why I was looking for an alternate solution.

I'll just put it on the backburner for now.. 

I mean, in theory almost anything could be broken by a determined custom engine. One that I worry about in theory but haven't ever seen break is the high frame-rate animation from
https://tomeofpreach.wordpress.com/2016/02/10/high-fps-texture-animations/
This relies on a global timer on .bsp animations. Given that some engines have removed the global timer on looping .mdl animations (much to my irritation) it doesn't seem impossible that the same might befall the .bsp ones.

The thing with a lot of the map hacks is that they involve tricking the QuakeC - and engines tend to preserve QuakeC behaviour pretty well. Most of the stuff that happens in a map hack is legitimate QuakeC, just unintended. I suppose any hack which involves the order of the list of entities would be vulnerable to an engine which changed the order to be non-deterministic, but again I've not seen it in practice. 

Was intended as a toolkit. That includes making your own stuff 

You mind if I send you an email with the map setup and why I want this?

No worries if you don't ant to bother. 

 

My email addy is strange, begins with uw_ Don't ask, hehe 

The function trigger_reactivate is defined in standard QC but not actually used anywhere. In full the function reads:

void() trigger_reactivate =
{
���self.solid = SOLID_TRIGGER;
};

Can you think of an interesting hack to perform with the unused function? 

Kinn was complaining that you can't have disabled triggers in id1.

Couldn't you have a trigger with SOLID_NOT (SOLID_NONE?) and then come up with a way to use the above to activate a trigger that started disabled? 

The sophisticated 'super logic gate' idea Preach is about to come up with!

Or perhaps at least an easier way to do things like the switchable push hack and the like? 

New hack is a respawning trigger_once

https://tomeofpreach.wordpress.com/2017/01/19/respawnable-trigger_once/

The twist is that the hack doesn't use that function. What it uses is the fact that the function is redundant, and exploits what replaced it in the code.

I have come up with a different hack that uses the function since, watch this space... 

That's a really interesting article and could help with the usual complaints of not having the ability to have inactive triggers change states.

Cheers to you! 

A shoutout and a question.

First thanks for your tutorials. I used two in my RetroJam pack to great effect.

Second: I wonder if you or anyone else has ever considered completing the "From scratch" tutorials that were so informative on insideqc http://www.insideqc.com/qctut/#Scratch

I have no coding experience and wanted to jump in with that tutorial but the author never completed it. Maybe you know of another tutorial that could be a 101 starting point for newbs. 

But, couldn't you just have a trigger multiple that targets a logic gate?

The gate then could be turned on and off to turn the trigger_multiple's effect on and off. I'm thinking like toggleable shooters that can be deactivated or reactivated this way by toggling the trigger_multiple's effects (gate targets shooters). 

There already is an inactive triggers hack in stock id1. I think it was Preach's who triggers the trigger. 

But, couldn't you just have a trigger multiple that targets a logic gate?

The follow up article will discuss exactly this, it's almost, but not quite that simple... 

If toggleable 0/1 switches are possible, where is your 'fully functional computer processor within Quake' hack like there is for Minecraft! 

Correct me if I'm wrong, but the only thing stopping that ATM is the entity limit.

Aren't most of the logic gates already possible in vanilla? Albeit with some hackery. 

These hacks save entities.

Plus I'm sure Preach can add something nifty in the process, like multithreading support... :) 

Second: I wonder if you or anyone else has ever considered completing the "From scratch" tutorials that were so informative on insideqc http://www.insideqc.com/qctut/#Scratch

I love the scratch tutorials, but the returns on them diminish steeply. The first one is a great way to show what's essential, how to go from a blank mod that doesn't work to the bare minimum that runs. By stripping everything back, it exposes at a glance what functions come built into Quake, which has a value beyond actually creating a mod from scratch.

The second tutorial is exactly what you want to follow up with - the lighting isn't an actual barrier to launching a map, but it is something that's broken in every map until you program it back in. But by the third, we're more or less reduced to straight copy-pasting the code we removed back into the game. It has stopped giving you things any conceivable mod needs, and started just copying Quake itself.

There probably is a way to continue the series of tutorials in a way that makes each instalment less about recreating Quake line by line and more about exploring what makes up all mods great and small. But personally I am not clever enough to pull that off... 

Yeah, the follow up you all saw coming is here, how to turn last week's hack into a trigger which turns on and off, in a slightly better way than previous attempts.

https://tomeofpreach.wordpress.com/2017/01/22/respawnable-trigger_once-experiments/

There's some bonus content here as well, the map features a better logic gate. I need to write this up into a proper article, but here's the deal:

In the logic gate post a few years back, the idea was to have two entities that attacked the gate itself. One used player lightning to inflict a high amount of damage, and "kill" the gate (provoking one reaction) and the other used the player axe attack to do less damage, only "hurt" the gate, and so cause a different effect. Last year I discovered that you need a 4th entity to aim the axe attack and make it hit reliably, and on top of the extra overhead you need to keep the entities in the right order in the map or it doesn't work.

For the example map in the new hack, I had the bright idea of trying to replace the axe attack with something that doesn't have this problem. It turns out that shambler lightning fits the bill perfectly - it works just like player lightning but only does 1/3 of the damage. It doesn't even need ammo! There's also something quite poetic about the idea that the logic gate is now literally powered by different levels of electric current... 

Thanks, good insights. 

It seems lately that each time I work on a hack, I discover incidental things which lead to another post. So hot on the heels of the past two posts, here's a hack that delivers something I'm sure was requested in the past: a trigger_hurt which isn't quite so slow

https://tomeofpreach.wordpress.com/2017/01/29/rapid-fire-trigger_hurt/

It's a two-for-one really, because there's a much better kill-trigger for void maps in there as well - a trigger that deals damage to everything it touches every frame. This fixes weird things where two monsters leap into the pit at once and one of them survives for a bit. 

how to break a trigger_hurt?...
easy! use a teleporter while its hurting.

the teleporter causes force_retouch, which relinks the trigger_hurt while it is solid_not, unlinking it. because its solid_not, it won't get relinked.
when the hurt_on function then gets called, its .solid field is set back to trigger, but its already unlinked, preventing anything from re-triggering it (other than by using a force_retouch somewhere, forcing it to relink).
loading a saved games should have a similar effect.
this doesn't affect all engines... 

In fairness, the hack is actually making that less likely to occur, since the trigger spends a shorter length of time in the vulnerable state.

Am I right in thinking that loading a save is another thing that can cause relinking at inopportune times? I had a vague idea for a hack based on that, but it did play on my mind that some engines would probably fix the odd behaviour it would be relying on, and I never followed up on it.

I suppose you could also set up an info_notnull hack that periodically runs teleport_use, so that every so often things which have been linked wrongly get linked back in correctly again. Or am I missing something there?