i don't think so. in order to take damage, an entity needs to have .takedamage set to a non-zero value and blood particles are spawned when .takedamage is non-zero. 

The problem is that spawning blood is a decision taken entirely on the part of the weapon firing code (since explosions spawn none, and lightning burns orange instead). In particular the shotgun and axe code will always spawn blood if they can damage the target, so any hack which prevented the blood appearing will necessarily set .takedamage to zero, and therefore make the entity shootable no more.

There are two interesting alternative though. One would be to make the button shootable only by explosions. For this you wouldn't even have a shootable button, just a func_door to give the illusion of movement. You add a point sized info_notnull next to the button and add the following fields:
"takedamage" "1"
"th_die" "button_killed"
"speed" "1"
"pos1" "self.origin"
"pos2" "self.origin"
"health" "1"
"max_health" "1"

Then make it target the "fake" button and whatever event you want it to fire.

This button can be refired after 2 frames, and you can't add .wait to extend this because the movement functions are intended for a BSP object. So you might need to add a trigger_relay between the info_notnull and the things that it is meant to trigger in order to introduce a delay.

The other alternative would be to make a button that is fired by touch. This would mean a number of compromises need to be made:
1) Anything that touches the button would activate it, like monsters.
2) The activator for the button will be set wrong, which matters if it's meant to wake up monsters or send a message to the player.
3) Hitscan attacks (shotguns, axe and lightning gun) will not activate the button.

If these are all acceptable then start by taking the existing button as a base. Read all the fields which are set in-game using the edicts command. Then change the button's classname to func_wall and add all the fields you read from the edicts command to it manually along with
"touch" "button_fire" 

Hopefully this should be a simple hack, but I couldn't find a clear explanation in the thread. I want to do an action similar to post #11, having lightning fire out of a point entity at a certain direction. However instead of lightning, I want it to be a grenade.

I attempted to do this using the keys and values but replacing them with rockets, but it did not work, as I expected.

So I guess to sum things up, can I have something similar to a spike shooter, that instead of spikes, fires grenades, or any other projectile I want it to?

If I can get a solution, I will post a few screenshots of my current map soon :) 

Someone tell him quick so we get screenies!!! 

post #14? ;)

presumably you could set up another info_notnull for the shooter to target, compile the map, get the edict number and add it in as the shooter's 'enemy' field... 

Is it possible to overload the model field for torches? Perhaps re-directing it to a custom bsp model for, say, a lantern while keeping its sound and light values in tact. 

Might be easier to use a point light and point trigger for the sound along your custom light model (illusionary for static). 

External BSP models don't light properly though... but I guess that for lanterns you could just light them fairly bright and say that it's the light from the lantern that's making them bright. 

To add the lightning sound effect to your map:

Go to the first page of this thread and read post #8 by Negke. If you want to use the sound which was included in the zip with your map, then precache it yourself in the spawn function for the info_tessla. If you want to use a sound which is already precached, then I recommend "weapons/lhit.wav". 

I will try that, I knew it was somewhere. 

the thing with grenades has already been done:
check sm129_efdat 

Is there any way to have a monster jump start deactivated and then switch on when a trigger fires? 

The usual way of creating a trigger, detailed here among other places:
http://tomeofpreach.wordpress.com/2012/11/18/mid-map-entity-spawning/

This works just fine for trigger_monsterjump. 

example map of healer stations
for reference

image
http://www.quaketastic.com/upload/files/screen_shots/healer.jpg

map
http://www.quaketastic.com/upload/files/single_player/maps/healer.zip 

has been added here: http://quakewiki.org/wiki/Map_based_hacks

I'm not really very knowledgeable about these hacks as I've only really used the explosion effect before, so please add and modify what I've written.

Also, do I need to get permission to quote stuff from here or even copy it wholesale? I wanted to use Preach's explanation of the explosion, because it is better than my own, but I wasn't sure if he would mind...

Anyway, like I said, please add more stuff to that page and improve what's there. 

there is some kind of trick to get particle effects to appear on stuff. I've seen it on keys in a couple of maps, and I think I even saw it on a monster before. It could be used to signify a high health monster using the armortype hack.

Anyone know how it works? Is it as simple as adding an effects field or is there something more to it? 

Is it as simple as adding an effects field

Yes-ish

"effects" "1" works well, a bunch of fireflys

"effects" "literally everything else" either makes a giant glowing flicker light, does nothing, or makes more fireflys and flickering light. 

I already posted this in mapping help, but I think it might be worth putting it in here to...

Quake logic gate tutorial:
http://www.quaketastic.com/upload/files/misc/tutorial_logic.zip

I will add it to the wiki with images soon. 

So I wanted to make a post about logic gates, dug up this thread and found the very last post was about...logic gates!

Than: I read through your tutorials and had two ideas. The first was a simpler construction for the "if...else" device - I think it's easier to understand as well as saving an entity, so I thought I'd share. The idea keeps two spikeshooters aiming at the if and else triggers. Set the two shooters up next to each other, then create a single blocking door just large enough to block one of the shooters. Have that door move up and down between the two firing paths, so it blocks one when it is up, and the other when it is down. Diagram:

Up
>.....|�����[+] (if)
>..........�[+] (else)

Down
>..........�[+] (if)
>.....|�����[+] (else)

The other suggestion I have is more radical: replace the trap_spikeshooter with an axe! Less obliquely use an info_notnull with "use" "W_FireAxe". Set the angle of firing with "v_angle" (although since you're free to build the firing range at any angle you might as well choose to fire due north and not bother setting v_angle at all!).

The axe fires an instant hit traceline which starts 16 units above the info_notnull and traces for 64 units. This removes the need to create a stream of spike entities and wait for some number of frames until they score a hit. The axe has a few advantages over the player's other instant hit attacks - it's quieter, needs no ammo, and doesn't require extra entity hacks to set up the angle of attack.

The big appeal of the axe over the spikes in my mind is the instant reaction of it - making the system much more tidy. This leads me onto the discussion I wanted to raise in the first place. For a few days I've been wondering about trying to find a better hack for the doors. The fastest reaction time a door can have is 0.1 seconds. You can get better reaction times turning an input on by having the spike shooter aim near the bottom of the door, which then moves quickly out of the way. However, this is traded against worse reaction time when turning that input back off.

Another issue with doors is that you might actually miss inputs, if a second input comes in too soon after the first and the door is still moving. This might destabilise a complex set-up which 'knows' how many triggers it takes to turn inputs on and off, essentially inverting subsequent inputs. So there are non-aesthetic, if obscure, reasons for wanting an alternative.

What I want to start with is clarifying the way quake logic gates work right now, compared to silicon ones, and make sure it's the right model to use. Silicon logic gates have a continuous stream of electrons pouring into the inputs, and the output stream responds to changes in the inputs with another ongoing stream. The streams from AND gates begin when both inputs are active simultaneously.

The first challenge in converting that into quake entities is that the triggering in quake is instantaneous, not continuous. This means that it doesn't make sense to talk about two triggers occuring at once: only one can fire at a time. So the model we have is that continuous streams are actually represented by entities with state - currently doors - being toggled to indicate a particular input is turned on or off.

That deals with the input. The output needs to work in reverse - a continuous state (the outcome of the logic gate) needs to be converted back into an instantaneous trigger. We do this by querying the current state of the gate - in practical terms by launching our spikes into it and seeing the trigger fire if the gate is open.

That's the theory as far as I can see it - is that more or less what everyone expects from logic gates? Or is there a better way for them to work conceptually - if only we could find the hack to use? 

I had no idea you could fire the player's weapons from an info_notnull. That sounds a little more streamlined, although the spikeshooter method works nice if you actually want the system to be visible to the player of course.

The time lag problem is a little bit crap, but it's not the end of the world, since you can move the spikeshooter closer to the trigger if there is too noticeable of a delay. Of course, the axe trick is better since it minimises the delay.

I had thought of the trick to save doors, but I don't think it works if you want a combination of IF/ELSE and AND. In any case, I thought of it after implementing in the tutorial map :/ 

While working on a new and improved logic gate contraption, I came up with something short and sweet:
http://tomeofpreach.wordpress.com/2013/05/11/trigger_damagethreshold-simulator/
A new hack to get a trigger_damagethreshold in stock quake. Not the most commonly used entity to be honest, but obviously someone went to the trouble of inventing it. Can you see a use for a logic gate? 

That is such a clever idea o_o 

This mostly what I did with my Q3 "Edge of Forever" map. I even wrote a long article explaining some of the logic I built using entities.

Logical Madness 

Okay, as promised, an alternate logic gate with the emphasis on instant response and being highly obtuse! There is another selling point on offer here though - it has separate targetnames for opening and closing the gate rather than a toggle. This may be desirable if you have many potential sources for the trigger to open or close.

http://tomeofpreach.wordpress.com/2013/05/13/new-logic-gate-design/

This one now uses both of the mini-hacks I've posted about this week. It also went through a fairly big rewrite in the past 24 hours or so. Originally it worked a lot more like traditional logic gates, so the wierd hacky solid-toggling entity only blocked attacks, rather than receiving them as inputs. It relied on a "touch" function for the off switch, which had a potential race condition. The new way with the unusual use of the damagethreshold hack avoids that, and does away with the separate detector entity as well! 

The second half, where we restore the logic functions to logic gates:
http://tomeofpreach.wordpress.com/2013/05/15/new-logic-gates-part-two/
The AND gate set-up is a bit lazy, I might try and think about a better way. The OR gate is rather cool though, if a bit more fiddly. Finally we have an IF-ELSE patterned after the OR.