fuck, I misunderstood.

I feel like fiddling around in the progs could get what you want fairly painlessly. 

I asked in mapping help but maybe here would be better for my question.

In AD I want the Golem to only have melee attacks, no projectiles. This is listed in his mon_golem.qc right before the range attack code:

if (!self.enemy) return;
if (self.health < 1) return;

Now if either of those are true he will skip the code for firing projectiles.

I tested a modified AD progs by the simple addition of a return; above the "if" statements and got a melee only Golem. But that's not really an option.

The function is called void() golem_rockstorm =

Any progs.dat tricks for this? Even if it's not an "old" progs :-P

Could he fire the doggie's attack instead!!! I still need him to STOMP though... 

It's a bad idea to use map hacks against a mod which is in development. In effect you're trying to apply a hack to a moving target - the mod may change that code in the next version and break your hack. The reason that id1 hacks are acceptable is because id aren't ever going to release another patch for Quake, so all behaviours (even unintended ones) are unchanging... 

I bet plenty of custom engines break certain map hacks. I don't have any examples to hand tho - know of any? 

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...