Please use info_trap instead of a hack that we will unintentionally break with a future patch to Quoth. 

the scrag / wizard stuff doesn't work with info_trap :( 

I beg to differ 

Preach!

"modelpath" "progs/w_spike.mdl"

I thought that wizard / scrag magic was a particle effect.

my bad.
Thanks. 

I was using the scrag shooting function like one would with a info_null as in post #14.

Didn't even consider using the trap function as intended. 

has anybody made water with invisible(transparent) texture, just wondering because that might have some interesting uses. 

I'm interested of the outcome. 

But using q3map2, so probably not what you're looking for.

h2o 

 

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!