News | Forum | People | FAQ | Links | Search | Register | Log in
Teaching Old Progs.dat New Tricks.
You know about the info_notnull explosion hack. You know about making monsters drop weapons or alternate ammo using the .weapon and .ammo_whatever hacks. You know about making items float in the air by spawning them on a temporary platform. Let's have a thread where we talk about new ways to use existing behavior and get novel gameplay. If you're a "retired" mapper, this is a great time to do some armchair level design and suggest ideas you'll never have a chance to use yourself.
First | Previous | Next | Last
Rotating Objects Hack! 
GREETZ hax fans! Let's make things spin right round like a record baby.

This entity hack is actually pretty easy, it lets you make a rotating object in stock /id1/ quake, but is somewhat limited in what you can do. What we are going to do is make some non-solid, non-interactive rotating objects. Good for things like a ceiling fan that you will never interact with and just spins forever. I've actually used it before in my sm170 speedmap quite awhile ago, but it seems went unnoticed (negke hadn't heard of this method when I told him about it last night).


Ok, so first off, you need to make a func_wall fan object at the origin of the world. Make it's center at (0, 0, 0) in the world, this defines where it will rotate around. You'll need this entity's modelindex, so it may be best to make sure it's the first object in your .map file. As explained by some other hacks in this thread, the modelindex is a number given by Quake to each model in a level and lets us instance those models to other entities. The command 'edicts' in Quakespasm/Fitz/etc will help you find this number on entities in your level.

Now, where ever you want to have a rotating fan, place an info_notnull with the following properties:
"classname" "info_notnull"
"avelocity" "0 256 0"
"movetype" "8"
"model" "*1"
"modelindex" "2"

That's it! Obviously, use the modelindex of the func_wall fan you made. avelocity is the part that makes it spin, is the same thing that makes weapon items spin. Here we are spinning around the Y axis at 256 somethingspeed, this is good for a ceiling fan but you'll want to experiment with what is right for you! You can use negative values if you want to spin in the opposite direction.

Another key aspect is the movetype key being set to 8, this means MOVETYPE_NOCLIP in .qc, which is a movetype that allows objects to be rotated with avelocity.

Example .map and .bsp Enjoy! 
Thanks! We need fans in these hot, hellish environments! 
Really Cool! 
That Is Genius Scampie 
You better believe I'm gonna abuse that hack. 
Cool Stuff 
I just fiddled around with the rotation thing and you can totally have multiple objects, as long as they do not necessarily need to be shadowed. Even if you need 2 shadowed objects you can still do it with a bit of a caveat.

The source func_wall does not need to be at 0 0 0.

If it will only rotate on the z axis (world, which is y for the object, why is this shit mixed up, btw?) you can move it up and down on the world axis ( and if we want rotation on another axis of course that would work too, just move on the according axis) so that it does not overlap with another object there that needs to be lit.

Now you only need to move the info_notnull up or down counter the direction you moved the func_wall. For this to work the properly the info_notnull still has to be inside the world and ideally visible from all the points to the player where it would be would it not be shifted around. If that happens the object might disappear. That in itself could be used for some weird effects too though.

I was wondering if it might be possible somehow to give the info_notnull or the func_wall some kind of offset modifier so that the info_notnull can actually be at where the object should appear, without being shifted if the origin is not 0 0 0. 
is it possible to use it in conjunction with a func train to make a moving spinning blade trap thing? 
No :( 
the rotation values are odd because I'm pretty sure it's using Pitch, Yaw, and Roll, so rotation around the Z ends up as the second value. 
Yeah, I think that is right. 
I just made a clock in my map using this method. I noticed that the further away from 0 0 0 your func walls are the bigger the arc they travel in.

Also, there are other movetypes that also work, some that rotate as the object falls to the ground. Could be interesting to play with on a low gravity map.

Some more ideas for this, moon / sun / planets orbiting your map. A scale model of the solar system. Gears, or clockwork in maps. A fully sick car with spinning wheels. A spinning leek... I'm sure there are more. 
Back To The Future!? 
Here's a "hack"... in the id maps!

I was zooming around e1m4 when I noticed a funny looking block with an Ogre walking into it... Using sock's mod with path's visualized to show what is up:

Turns out, that block is a func_door on top of the first path_corner in a sequence the Ogre is trying to walk to... so it can never reach it and ends up sitting there forever!...

Until a trigger lowers the block out of the way. The Ogre can continue to walk out the door and eventually gets placed into a path_corner loop on the dock over the water. The end result is like a scripted sequence of triggering the ogre to walk out of the door on demand!


It's odd because it's very unlikely a player will ever notice this happen, the ogre walks so slow and the trigger that lowers the block is right at the edge of the water... In all honesty, if this were me, I would've just teleported that Ogre onto the dock when the player was out of view. But what id did here was make a basic scripted sequence with their primitive tools that only a few % of people might notice... But you might just hear the door open, and see the ogre lazily walk out and it makes the world so much more alive. It's wonderful :D 
That's Pretty Cool 
and the way monster teleporting works in vanilla is only slightly less of a goofy "hack" really. 
yeah, and mods as early as zerstorer 'unhacked' it and added progs functionality to just trigger a monster to make it appear.

id may have just never bothered developing anything better than teleport boxes because that's what they had in Doom. You built a long tiny tunnel to propagate sound into a room full of monsters to get them angry, then tagged a door in the room to open and reveal a teleport linedef and then just hope all the monsters eventually crossed it as they wandered angrily around said room. id probably thought having the 3rd dimension on their side to make monsters fall directly into the teleport brush was high technology. 
High Framerate Animated Textures 
Has it really been more than 3 months since the last hack? Well, good things come to those who wait.

Today's hack offers a trick to upgrade the 5 fps animated textures into 10 fps animated textures instead. This should benefit maps with waterfalls and lava flows a great deal... 
Notnull Hack? 
Im not sure I know this one, can someone explain it or point to a resource that explains it? 
A Primer On Info_notnull 
My intro to map hacks post uses info_notnull and mentions why we like it so much 
Awesome Preach! 
Thanks for posting this Preach! It will be interesting to look into at some point. Your waterfalls are already at a pretty high fps so I take it this wouldn't' do much/anything for them correct? 
abutton1, bbutton1, cbutton1....mind blown!

Whoa! func_wall.use changes texture...mind blown again!

Double wammy there Preach. 
Don't Go Chasing Waterfalls 
Thanks for posting this Preach! It will be interesting to look into at some point. Your waterfalls are already at a pretty high fps so I take it this wouldn't' do much/anything for them correct?

This trick is really for animations on BSP object, things made out of brushes. My waterfalls are in .mdl format so they aren't applicable to this trick. However, I think this will be great for making waterfalls in places where my model can't be used, e.g. in vanilla maps or spots where the waterfall has to be made to fit. 
I'll Stick To The Mdls I'm Used To. 
Ah okay I was figuring that was the case. Always excited to get a new map hack from you. I already have numerous ones from the past implemented in my current project! 
That's Deviously Clever 
Nice one! 
Could Make It Even Higher Framerate 
In theory you could go higher framerate and double it again for the framerate hack. just need to add another 2 layers of meshes switching at .25 and .75 seconds delay. I think I will have to give this a go at one point as well :) 
Monster Only Teleports 
Neat trick I found. If you place a trigger push with a velocity of 100 right in front of a teleport the player won't be able to use it (if its angles are right, you could always suck the player in for a neat trap!). If you then place a trigger_monsterjump a hair bit in front of it and give it the same forward velocity of 100 but an up velocity of only 1, it will negate the push and let the monster teleport. You could reinforce the concept by putting a func_illusionary in front of it with a unique teleport texture. If you want to make the teleport useable later such as after a fight, you can killtarget the trigger_push and the func_illusionary. 
Sort of a neat trick as opposed to TE_TELEPORT effect at either side of the ent being teleported is if your engine has a .alpha field you could "fade" him out while non solid, hijack his think to be the fade function until hes perfectly transparent, then transport him, and fade him in using the same function in reverse. If done with the right timing it could look pretty good, and you could throw in a EF_BRIGHTFIELD at the end for maybe the last few frames while transporting, and the first few while "rematerializing"....

If the engine has EF_ADDITIVE for blending, I think it looks even better. 
Invisible Teleport Randomizer 

targetname movingteleportdest1
target path1wp1
speed 200
avelocity "100 200 300"
solid | 0
movetype | 7
use train_use
nextthink 0.2
think func_train_find

Borrows code from the misc_teleporttrain to create a moving teleport destination that is invisible. Use in combination with a monster teleport box whose targetname is movingteleportdest1. Give a nice path above an area to drop in monster in a randomized locations. Put multiple monsters in the same long teleport box with only one teleport and you can cut down on trigger_teleport requirements, and add randomization. 
Oh And... 
make sure something targets it or else it won't move.

As an extension of this idea, you could have a teleport that changes destination by having it target this entity and giving the 2nd path_corner a wait of -1. 
You can teleport to monsters, even dead ones. :) 
And Items 
Fiends Hatching From Grunts 
So you give a grunt 'effects 8' and when he dies, he trigger spawns a fiend into his own location. 
Too bad you cant gib corpses this way... have a grunt spawn a zombie or fiend in a spray of gore! 
You Could 
Spawn a zombie, then after 0.05 seconds spawn a fiend at the zombie's position.

Best way would just be to use qc though so as not to inflate the monster count. 
Would be unwise to spawn large monster from small monster due to bbox Size difference. 
Yeah, qc would be good again to check for !walkmove. 
Public Polling 
So, which hack should I write up next:

a) A trigger which randomly selects between triggering "event_a" and "event_b"


b) A trigger_counter which can be reset and used over and over again.

I mean, eventually I'll get round to both, but which one should I do first? 
a, though b sounds more interesting. 
i can do a) myself already VERY hacky, i'm most interested in hearing your solution. 
A Is Just A Logic Gate Shooter With A Func_train Oscillating Rapidly 
Do b) 
You'd Think That 
but im sure there is a much more clever solution to it. 
Preach us probably accessing the video buffer for the screen and using the pixel colours as random numbers with 3 info_notnull entities. 
I Vote B! 
For I Have Touched The World..... 
// Try it...jump around on any map

void () test_touch =
if (other.flags & FL_CLIENT) bprint ("OUCH !n");

void () worldspawn =

world.touch = test_touch; 
Reusable Trigger_counter It Is 
From what I can see, there's been more discussion about the randomised trigger, but more explicit votes for the reusable counter. Since we live on a democratic message board, we will ignore the prevailing enthusiasm and go for the winner instead.

I've been playing around with the idea over the past week, trying to come up with the simplest implementation of a reusable counter. I think I'm basically there now, but one of the features requires a logic gate, and a flaw in my previous article on those has become apparent, so I will fix that first, and then the new hack will follow. 
Oh Goody 
Another two-fer! 
The Ol' One-two 
So the fixed logic gates are up at

The updated portion is highlighted in yellow. I've also updated the example .map at both to incorporate the update to the article, and to make the example map playable. All four gates are hooked up to example entity systems and can be tested in-game.

Now for the new stuff...
Not only featuring reusable triggers, but also triggers which you can interrupt to reset during their count.

Bonus content: What went so wrong in the original logic gate post to make Preach miss out a vital entity? I often use a "clean" copy of the QC source to test things out. Unfortunately, this clean copy is not quite 100% identical to the basic Quake source, and W_FireAxe is one place they differ. My "clean" version has a call to makevectors which the original Quake progs is missing. This doesn't affect the player code which has some redundancy, but the axe hack entity is not so lucky and started firing in a random direction. The changes to the article work around this. 
When you ask a question and then answer it before anyone had a chance to say something, that's usually a rhetorical device. Not today though, I just happened to crack the puzzle I set myself last time, and made the reusable counter work without a logic gate. Read the follow up article here:

Still not enticing enough? Well, the post links to an example .map file, so you can copy-paste the hack without the need to understand it! You want more? Well, the article even invents the anti-counter - an entity which acts like a trigger_relay until you've used it n times, rather than one which only acts like a trigger_relay after you've used it n times. If you want a crusher or trap the player can only activate a few times before recharging it, this does the job. 
Preach You Mad Man! 
All shall bow to the Quake hacks of the one they call Preach. This is Preach's world full of logic gates, high framerate clocks, and waterfalls (That only spawn on nightmare.)

Countless possibilities with this addition, thank you sir. 
Preach, I am in awe. 
I can't even comprehend any of this madness... You're basically the gandalf of map hacks 
or the map hack of gandalfs. 
or the enemy of compatibility... 
This Is A Public Service Announcement... 
or the enemy of compatibility...

Oh believe me, I spent a long time working round map hacks in Quoth - there are specific "shims" for maps which use hacks that subsequent version broke. It's also something that I do bear in mind when making changes to the code base - e.g. renaming OgreGrenadeExplode to MonsterGrenadeExplode would be appropriate in Quoth because Defenders fire the same grenades, but that would break a basic map hack which outweighs the benefit.

For everyone else I think it's worth repeating the standard reminder: Map hacks are for standard Quake only. There is no compatibility guarantee for any other mod. Do not use them in Quoth or AD or anything else. 
Sock had a strict rule that we couldn't use map hacks in AD. Made sense 
Very Fair 
I figured it was for vanilla Quake. The only hack that I currently readily use is the nightmare hack. I am currently mapping using AD and the hack works wonderfully. Actually, with triggers like monsterkill I can fix the kill count totals when playing on hard!

I know I use them at my own risk though. ;) 
Well, if you are mapping for a mod in development, that makes sense since you could just code up whatever you needed. Map hacks are cool to add surprises to standard quake. 
I am currently mapping using AD and the hack works wonderfully.

What happens when sock releases a patch that fixes a long standing bug in the lightning gun and as a byproduct breaks the hack? There are a multitude of ways that could happen: renaming the function, checking the current ammo rather than the cells or adding a new parameter to the function to name but three. All perfectly innocent changes which happen to break your map.

The issue is that the map hacks are not forward compatible - new versions of the mod might break the hack even if it works on current and past versions. This isn't theoretical, it happened in practice on maps between Quoth 1 and Quoth 2. The safety of the hacks in vanilla Quake also depends on iD never releasing another patch, it's just that after 14 years it seems a fairly safe bet... 
A Fair Point 
Would the example be the same with the Shambler magic lightning?

Either way, I suppose if a patch came out and it broke the NM hack and I was fully invested in my current project...I'd remove the nm hack components.

I fully understand the risks good sir. :) 
The only real thing to say in this instance is that you'll have to package your project with your version of AD to retain the functionality. Or figure out a way to implement your ideas without resorting to map hacks, if possible. 
Cause And Effect 
Either way, I suppose if a patch came out and it broke the NM hack and I was fully invested in my current project...I'd remove the nm hack components.

But if the patch comes out after you release your map, you're stuck. Unless you want to keep patching your map.

For their part, mods ought to look at the most popular map hacks and see them as features they ought to offer in a supported way. I'd guess that was part of what the no-map-hacks rule for AD was about - code the needed feature instead for all to use. 
Sock didn't want us relying on map hacks as patches and stuff could break the maps. If the mappers wanted a feature in their map then Sock would just code it into the mod. 
Something To Ponder 
I appreciate the advice. I may remove the NM hack. Luckily, the current project I am on I have yet to implement it...and this particular project I hope to publicly release someday.

Hell, I could always make a seperate version of the map that supports the NM hack. For now, I'll worry about Easy, Normal, and Hard.

Thanks FifthElephant and Preach again. 
Thats a doosey of hack Preach (and another two-fer no less). I see more awesomer puzzles in the future. 
Random Numbers 
Now, I'm more into my stats than most people, I know that. So for my upcoming random switcher hack, I decided to check just how random it was. I made sure that the hack generated some loggable messages I could parse, ran with -condebug, generated 10,000 random events and loaded them into R.

The results were disappointing. Although the number of "Choice A" and "Choice B" generated were nearly identical, the chance of getting "AA" (an A followed by an A) or "BB" was higher than getting "AB" or "BA" (all four should be 25% probability if the system was fair).

I had spent several nights trying to fix this with various reconfigurations of the entities, but never managed to make significant headway. Then I decided to knock up a quick mod which would spit out A and B into the console using the random() function directly, just to check. And of course it turns out to have this same issue but worse. So I will be releasing this map hack shortly... 
The Most Unpredictible Follow-up Post 
Here's the hack:

Whatever will happen next? It's impossible to predict, because I haven't hyped it for months or even thought of it yet! 
QC support for Notepad++, including Function List support and syntax highlighting: Tutorial & download
Have A Semi-working Hack That I Need A Little Assistance With 
I am making a false train using func_wall and info_null. The purpose is to get a couple of overlapping entities that behave like a train (follow a path).

I have a func wall for the model, 2 path_corners with each other as their targets, a trigger triggering it and an info_null with the following values.

use train_use
think func_train_find
speed 20
modelindex 8
model *1
movetype 8
nextthink 1
target stop_1
targetname me

the odd behaviour is, that when it gets to the first stop, it spazzes out and jumps forward and back among the path corner locations, without traversing them first.

any ideas? 
Possible Tweak 
Hi Shamblernaut, can you try something for me and see if it helps? Change the movetype from 8 to 7. It's a hunch, and it'll take a lot of explaining which I'd rather only type up if it's the correct fix. Thanks, let me know how it goes! 
how just about trying to use a true train?..

and yeah, the SUB_CalcMove function, which is responsible for setting up velocities and nextthink for the various pushers to use, is explicitly tied to MOVETYPE_PUSH(7) on account of its use of 'self.ltime' rather than 'time'.

movetype_push and solid_bsp(4) are kinda tied together in many engines too, so be aware that separating the two will often give engine-specific results. 
That worked a treat, thanks preach. I still need to sort out the sound not being precached, but any victory is a victory and I'll take it.

@Spike, using a true train doesn't allow me to overlap my geometry, which is necessary for what I'm trying to do. Also, thanks for the headsup about engine pushtype handling, I guess I'll just require people to run the map in quakespasm =P 
Existing Practice 
movetype_push and solid_bsp(4) are kinda tied together in many engines too, so be aware that separating the two will often give engine-specific results.

Don't all engines need to handle it already because of misc_teleporttrain, which does exactly this? I mean, yeah, it probably shouldn't be written like this, but we work with what we have... 
Teaching Old Preach New Tricks 
Mankrip - Thanks! 
Static Entity Shooting Scrag Projectiles 
is this a thing that's possible? I want to use it as an acid drop in my mapjam 7 map (quoth). 
Post #14 
Cheers Man 
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 :( 
Trap Sprung 
Holy Shit 

"modelpath" "progs/w_spike.mdl"

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

my bad.
To Elaborate 
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. 
Invisible Water? 
has anybody made water with invisible(transparent) texture, just wondering because that might have some interesting uses. 
Just Try It. 
I'm interested of the outcome. 
But using q3map2, so probably not what you're looking for.

*waterskip Texture 
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 ( < 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... 
Don't Trick The Mods 
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.. 
In Theory Or Practice? 
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
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. 
Go For It 
@FifthElephant, Sent 
My email addy is strange, begins with uw_ Don't ask, hehe 
Fun Fact 
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? 
Yup, It Was Hype For A New Hack 
New hack is a respawning 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

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. 
More Shameless Hype 
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... :) 
Scratch Tutorials 
Second: I wonder if you or anyone else has ever considered completing the "From scratch" tutorials that were so informative on insideqc

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... 
Activating And Deactivating Triggers 
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.

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. 
Trigger_hurt Speed Control 
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

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. 
Here Be Dragons... 
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? 
Fish Friday...Three Days Early 
It turns out all that stuff from the last few posts can also affect hack logic gates, because the hack makes them go non-solid, and a teleport at that point unlinks them. I can rework a simple gate to stay solid the whole time, but it was an essential part of how the OR gate worked. So the promised logic gate article is on hold until I figure out a new way to make an OR gate...

In its stead is a way to fix the rotfish kill count bug in unmodified ID1, which I think is kinda neat.

PS: can you spot how to make a flying shambler? answers on a postcard... 
If you don't care about adding more entities, you can also target an info_notnull that has "use" "boss_death10" to increase the death counter by 1. 
Brain Teaser For Preach 
Gravity change by map entities, or a way to reset the changelevel function after using the cvar hack without the need to reload. Or anything related to this. What's the whacky stuff we can do by hacking worldspawn... 
Oscar Academy Award� Winner Gravity... 
...will not be screening tonight. I've looked for a way and I think it's impossible. One of the things about gravity in particular is that the QuakeC is actively working against you to reset it. It's pretty much the first thing that worldspawn does.

On the other hand, your one opportunity to put something arbitrary into the console is the changelevel command, and that's equally well locked down in the engine. The function which sets the changelevel_issued command does it unconditionally, and the one place it gets reset is starting a new level. So you can't get more that one command a map, and you need to save one to restart the map.

It really is the two working against each other that sinks the plan. There is just enough wiggle room to change sv_friction in the following way: call your map "my_map_name" then create a trigger_changelevel with the key "map" "my_map_name;sv_friction 0.05". When you hit that trigger you restart the level, but with sv_friction set to 0.05 (getting the player to hit the trigger at the start of the first visit to the map, but not on the second visit, is left as an exercise).

Sadly, sv_gravity is the only cvar which this doesn't work on, because of the specific QuakeC code at the start of worldspawn preventing it. Unless you can surgically remove the worldspawn from your map, but I don't like the odds of pulling that off... 
New Logic Gates 
Hi all, big article incoming!

It's the much hyped replacement logic gate set-up. These logic gates aren't vulnerable to being broken randomly by using teleporter at the wrong time. If that's not reason enough to start using them, they support an unlimited number of outputs which you can switch between! If you want to be able to switch a button between 8 different targets, this is the hack for you.

Thanks to Newhouse for his proofreading and feedback in writing this one up, I think the explanations have come out much clearer as a result. A follow-up with the OR gate, AND gate and XOR gate will be posted shortly. 
Seems really neat. Can the player here the LG explosion, though? 
I Don't Think So 
Because it happens on the first frame of the server, I don't think the player gets a chance to hear it. In any case, you can put the boxes containing the logic gates far from the main level if it ever becomes an issue. 
Crosspost: Custom Door Touch Functions 
Hard to imagine that anyone doesn't follow the Mapping Help thread, but just so this thread remains a complete archive, a new hack on how to create a door with a custom touch function.

I've had this masquerading idea bubbling around for a few weeks now, but I had something completely different in mind for debuting it. That may have to wait another week, this one has already bumped the logic gates follow up off schedule once! 
Preach is on a roll....I feel a maphack jam coming on! 
More Logic Gates 
Another week, another article. I like to think that the production values on this week's article are above the normal standards for a map hack post. The test map looks pretty decent, the article has screenshots, flow diagrams, and tables. Plus it's the second half of the new logic gates post, this time with actual gates, the AND, the OR, and the XOR gate. 
very nice article! 
Above and beyond Preach, the layout is very approachable! 
Most Advanced Spambot Ever 
I'm a bit scared 
He He He 
It makes sense if you're reading posts from about a month ago in the thread. And yes, that would mitigate the issue a bit (although depending on how frequently you run the function some errors might slip by). In 1997 some might have objected that it slows down the game a bit on weak PCs, because it removes one of the optimisations in the physics engine. Doubt anyone would notice any more... 
We may have talked about this, not sure. I want to reproduce the light globe sprite in an info_notnull, because I've hit the static entity limit, but can't seem to find the correct modelindex. Air bubbles and explosions, sure, just no globe. Strangely enough, s_light.spr doesn't show up in the modellist, either. All thanks to makestatic? Surely, there must be away. 
I don't know about other engines, but fte has a 'precaches' command that should show give you the index easily enough.
note that s_light.spr will only have a modelindex if it was precached (and the order should normally be the same for any engine), so if its missing then that's because nothing precached it yet.
So make sure you have at least one light_globe entity otherwise you'll not be able to get a usable index for it.

Do be aware that any other entity changes might change the order spawn functions are called in (depending on your editor). Creation/deletion of doors/triggers/plats/etc WILL change your modelindexes too.
So you should perhaps consider knocking up some find+replace tool if you're going to be making a lot of changes.

Or just use an engine with higher limits. fte+dp shouldn't have any specific limit, while ericw bumped the static ents limit in quakespasm recently though I've no idea if there's public builds for that yet (if not, qss has a slightly higher limit). No idea about other engines.
That said, protocol 999 or dpp7 will cap out at about 2048 max static ents due to the limited sv.signon buffer size. Less if you have many non-static ents too, because baselines contribute to the same buffer. I could rant about how fte servers are immune to that issue, but I'll save that for another time...

If it insists on being invisible still, you'll probably also need to figure out some way to make sure that the entity is linked into the server's pvs nodes. I expect Preach has a tutorial for that somewhere, probably involving triggering a teleporter... I'm not sure if its actually needed though. 
Thanks, got it! 
Sleeping Zombies 
Do you think there's a way to make zombies start off lying down and only "wake up" after certain conditions are met? Something smoother than a hurt trigger keeping them incapacitated (not least because of the pain sounds). I was just wondering considering that freak glitch where zombies sometimes don't get up again but can't be gibbed, either. Something to make use of? 
zombies use walkmove to get up, so while you could probably create some sort of crusher that squishes into them for 50 damage at a time and then stops above them, that'll both knock them down and prevent them from getting up. you can then killtarget the crusher and they'll be able to move again.

however, walkmove also includes a down-tracebox from 22qu above so you'll need your crusher to sit at least 24qu off the floor, which is also more than the player can step.
so you might need to make your crusher as a stepped-pyramid so that your player can still step over the sleeping zombie.

make it out of clip brushes and it'll be invisible. many qbsps complain at that though.
a train that moves to a single path_corner will do it (with a really long/infinite pause), there's probably some better way.

obviously it'll still keep playing zombie/z_idle.wav every 5.1 seconds... and flicker between $paine11 and $paine12 at the sameish time.
alternatively, AD has some proper feature for it... 
Other Hacks 
There's a way to make a silent zombie corpse which can be triggered to wake up using SUB_CalcMoveDone. The problem is that it's always solid, and also wakes up (without playing the animation) if you shoot it. So you'd need to build a skip brush shield around it which you killtarget, which is pretty much the same as putting a zombie inside a skip shell then hitting it for 25 damage at the start of the map. The skip shell prevents it from standing up, so you don't need to keep injuring it.

Anyway, if the marginal benefits of silence and waking up the instant you trigger it are worthwhile, the entity goes like this:

"classname" "SUB_CalcMoveDone"
"origin" "240 -64 56"

//finaldest must be the actual origin
/you want the monster to appear at
"finaldest" "240 -64 56"
"think1" "monster_zombie"
"use" "zombie_paine12"
"targetname" "reanimate"
"frame" "172"
"yaw_speed" "20"
"view_ofs" "0 0 25"
"flags" "32"
"takedamage" "2"
This Thread Delivers 
Thanks, guys.

Ineed, this only works in certain special situations due to the clipping/skip box thing, not for zombies lying around in openly accessible areas (=on the floor). For the spot I have in mind, however, the hack is just perfect. 
Preaxch Delivers 
He's the best. 
Custom Bmodel-type Entity 
Another noobish question that I feel has either been answered before and I'm too dumb to find or can't remember.

I know how to create custom stuff based off other entities using their model/modelindex values, but how do I make an info_notnull brush entity appear in the first place - visibly, that is. A function to get it started on the actual bmodel, like InitTrigger for trigger volumes.
Thought I could make a simple nonsolid prop that's doing something or nothing depending on the touch function. Problem is nothing shows up in game. 
I Believe 
You need to use a func_illusionary hack. 
Displaying A Model 
func_illusionary has the problem that it makes the entity static straight after, so you can't make it interactive.

Probably the best thing to do is to use
to create a visible entity. If the "model" key added to your brush entity by the compiler is "*1", you need to use modelindex 2 (0 is no model and 1 is the world, 2 is the first "free choice" slot).

You'll probably need to handle any interaction in separate entities (e.g. killtarget this entity) - InitTrigger interferes with this trick, likely because it calls setmodel. 
What I mean is having a brush-based info_notnull show up in game like a normal entity would - instead of 'visually cloning' an existing entity in a point info_notnull. All in one edict if that's possible. It appears a brush info_notnull strips itself of its own model/modelindex properties unless if used as a trigger volume (the model=bbox part in this case). 
Trigger Volume 
The trick does work with a single brush-based entity (referencing the modelindex of its own model). It is - like you suggest - when you turn it into a trigger that things go wrong, because the trigger is trying to do its own thing with the model code which interferes with the modelindex hack. If you didn't want a trigger, you'd probably be OK. 
To avoid a possible misunderstanding: I'm not using any trigger stuff, just mentioned it as an example.
I can't seem to get it working as a visible entity just like that, even if I make the info_notnull reference its own modelindex (unless I'm doing something fundamentally wrong and can't see it). That's why I thought perhaps there was some neat think function to run (in a similar way that InitTrigger that makes the bbox appear); sort of like "think" "func_wall", for instance, but without the hardcoded behavior this would add.

The weird thing is, I'm under the impression that for a while I had some floor bits show up just being brush info_notnull without any extra fields, but at some point during development this ceased to work. IIRC, anyway... 
Brush Based Entities 
If you add a brush entity with classname "info_notnull" it gets translated by the compiler something into this:
"classname" "info_notnull"
"model" "*1"

What may vary is the number after the * in the model key. What you want to do is add keys to that brush entity so it ends up like this after compilation
"modelindex" "2"
"mdl" "progs/player.mdl"
"think" "SUB_regen"
"nextthink" "0.1"
"classname" "info_notnull"
"model" "*1"

The tricky part is that you need that modelindex key to be 1 larger than whatever number the compiler decides to put into the model key. The numbers are given out in order by the compiler but if you delete other entities or do something to reorder them in the .map file it may change.

If you do all of that, you should get a visible entity which is only different from a func_illusionary because it is non-static and so can be killtargeted or given a use function. You can probably move SUB_regen into the classname slot and use a different think function as well. However, bear in mind that many other hacks (like the aforementioned trigger stuff) does break this hack, it's pretty fragile. 
Timed Power-ups 
We know its possible to make any item respawn, but is it possible to make power-ups last longer or shorter than the usual 30 seconds? For example a biosuit that lasts a minute, or a quad damage that's only 20 seconds. Can this be accomplished? 
Thanks Preach 
Finally got it to work. Apparently the "mdl" field is crucial whereas "model" doesn't have to be specified in this case. This is different than with point-based cloning which got me confused. In game, whatever is referenced in "mdl" is copied over to "model" as well, so I set it to "*1" (or rather the respective number of the model) instead of player.mdl; either seems to work as long as the modelindex is correct. However, the hack also required me to set "mins" and "maxs" for the entity to be drawn. The "think" function, on the other hand, seems only necessary if the entity is supposed to be used further, e.g. for a touch action.

Playing around with mins/max/size/origin made me curious as to whether it's possible to customizable trigger sizes from point entities like in Quoth...

Orl: I briefly tried it a couple of years ago. If it is possible, then at least it has to be more complicated than simply calling "powerup_touch". You can replicate the visual effects like that, but not the actual powers. 
@orl, yes increase the nextthink to respawn,
if ((self.classname == "item_artifact_invulnerability") ||
(self.classname == "item_artifact_invisibility"))
self.nextthink = time + 60*5;
self.nextthink = time + 60;

and for each pwoer up theres a *_finished timer

this is in items.qc 
Thread title "Teaching Old Progs.Dat New Tricks" means needs to work with original progs.dat, typically via entity/think/field abuse.

It's a shame you don't play single player maps, some like negke manage to do seemingly impossible things in maps that work in original Quake. 
Is there a way to place a static corpse in vanilla quake? Like a 3D model of a killed grunt or something? Is there a way to add custom entities? if so is there a place that has models of dead grunts or enemies?

You can do a corpse in a map. Do a func_illusionary and set the model (like progs/player.mdl")and frame number (like 169).

In vanilla quake there is no way to add custom entities. 
Interesting, thanks. I'll have a play around :) 
So i create a brush entity, set it as func_illusionary, and then add the keys "model" and "frame" ?

Like this? 
Create a point entity, set the type to func_illusionary and yes change the "model" and "frame" (it *may* be "mdl" if "model" doesn't work).

Like if you were creating a monster. 
(There are differences between TrenchBroom and Jackhammer. In Jackhammer, you create a point entity and change the entity type. I would assume you can do that in TrenchBroom, but couldn't swear to it.) 
Ah yep it works! great. Is there a place that shows the various model names? like gibs for example? 
Open up pak1.pak in Pakscape 0.11 and look in the progs folder. To find out frames, you would have use QME to look at the different model frames.

Without opening a model in QME, it's gonna be hard to pick the frames for most models as all the monsters have dozens of frames.

You also may want to set "angle". 
amazing thanks, that should give me everything I need to make some nice corpses...

I tried setting angle as -1 and rotating the entity but it doesn't seem to change the angle it appears at. Say I want the player model to appear lying on its back facing upwards - shouldn't angle -1 do this? 
Also it seems like some models work and others dont. The soldier.mdl doesn't seem to work at all and the map wont compile.

Could this be something to do with quakespasm having less models in its pak0.pak and having them in a pak1.pak instead?

It seems to have the paks reversed compared the original quake paks 
It Has To Be Precached 
Include at least one monster_army in your map.

Set yaw like normal to rotate the corpse.

-1 won't do anything since that is a special case for doors. Set the frame correctly and the model will be in one of its lying poses. You may want to check out the qc files to see which frames are death poses. 
ok cool, thanks. I tried adding a monster_army but now I seem to be having a problem of the entities disappearing when I select something else. Using TB2. None of the entities I've created are visible (I tried show all in the view) and the map is still failing to compile and citing lack of precache)

Here's the map file:

as soon as I deselect the func_illusionary entities they seem to disappear... 
"angle" is typically 0-359 like degrees for non-door/non-platform entities and operates as yaw (like pitch/yaw/roll, the 3 different x-y-z axis in Quake). 
func_illusionary was only really expected to work on inline models (ie: those submodels baked into the map). As a result it doesn't bother to precache the model (these are implicitly precached by the server).

The exact set of models that are already precached depends on the order that entities are loaded. So for instance you can use progs/soldier.mdl ONLY if there was a monster_army entity preceding it. the player's various models (player.mdl, eyes, backpacks, projectiles, gibs, etc) are precached inside the worldspawn entity's spawnfunction which is normally guaranteed to come first.

while there are engines that will automatically precache stuff on demand (ie: dp+fte+qss), these engines will generally warn, so its not something you want to do other than as a last resort, plus people hate engine dependencies.

func_illusionary forces angles to '0 0 0'. You cannot change the angles without qc.
If you want that then there's a more complex way using info_notnull, but figuring out the correct value for the modelindex field is a nightmare. 
ah ok cool. That should solve the caching problem. Not sure why the entities are disappearing though... 
Also how do I work out which frame to use from QME? QME gives me frame names like "deathc11", but the frame key needs a number. Is there a good way to work out what the frame number will be - I tried counting down from the top but it didn't give me the frame I was looking for. Say I want to use frame "deathc11" from the soldier.mdl - which number would I enter in the frame key? 
QME: Bottom Left corner when you select a frame, it says "Frame: 005 walk1". You have to click on the frame otherwise it doesn't say, haha. 
Ah yep, perfect. thanks! it works.

Now I just need to work out why the entities disappear after I select something else... seems very strange 
Undefined Point Entity 
Maybe TB2 doesn't see func_illusionary in its fgd file as a point entity since ot is only defined as a brush entity...and deletes it! Protect you sillt users from yourself. Ha, no its probly just a bug...ask about it on the TB thread. 
Disappearing HexenMapper 
as soon as I deselect the func_illusionary entities they seem to disappear...

Check the View menu upper left side of 3d window. Make sure you somehow didn't accidentally uncheck func_liiusiionary. 
Combining Two Hacks? 
So here's a conundrum: there's two map hacks I'd like to combine, namely the one for delayed/dynamic entity spawning ( and the one for rotating brush models in stock id1 ( Both of them work properly on their own, but combining doesn't quite work as it means trying to turn an info_notnull into another info_notnull (to expand, the entity doesn't stay hidden until triggered like it should because it's already an info_notnull with the proper fields to act as a rotating, visible brush).

I even tried a number of hackier methods, like making a specific texture for the brush entity with the starting texture completely transparent and the secondary (+a) texture, then triggering the func_wall so it would change texture- no go. The original model will change but the 'cloned' rotating one doesn't copy it, and triggering the rotating model does nothing. Am I totally out of luck here? 
^To add on to that, after a bit of fiddling it turns out you *can* change the texture from the +0,1,2... set to the +a,b,c... set on the cloned model by adding 'func_wall_use' to the 'use' field on the info_notnull. That would normally make things very simple, as one texture set could be made transparent, but apparently animated textures with alpha masking isn't possible (at least in Quakespasm) due to conflicts between the required first character- { tells it to take color 256 and turn it invisible, but then ignores any other special character; likewise, + allows for an animated texture but doesn't allow alpha masking.

Back to square one, I guess. 
Delayed Rotator 
classname info_notnull
avelocity "0 90 0" //spinning the whole time
nextthink "999999999" //otherwise func_wall(read: movetype_push) will not spin/move. this persists through both spawn functions.
think "SUB_Null" //just in case someone leaves the map running that long. note that it'll stop spinning, but at least it won't crash.
model "*1" //not visible until func_wall uses it
modelindex "" //MUST be omitted/blank/0, otherwise it'll be visible as something BEFORE its triggered.
use "func_wall" //what to call when triggered
targetname "spawnit" //what to trigger

will give you an invisible info_notnull that effectively becomes a rotating func_wall when triggered, is the theory.
(if you killtarget a normal func_wall at the same spot, you can make it appear as though it simply started rotating).

note that if there are any entities inside your pusher at the time that its triggered then those ents will get trapped and maybe block the rotation.
due to engines that don't support proper rotation physics, you should probably just make sure the player can't walk through it with eg a clip brush surrounding the area. 
Works in theory but doesn't quite work in-game, unfortunately. Copied it exactly other than the targetname- it acts like a standard delayed func_wall, solid with no rotation at all; including the
'movetype' '8'
field from the rotating brush hack was my first thought but that didn't change anything. 
The problem with your current approach is that the appearance of your entity isn't caused by the info_notnull spawn function, it's caused by your hacks. So there's no benefit to delaying the spawn function. You would need to delay your hack, but there isn't a function which can turn the hacked values on or off, our only opportunity to set them correctly is the initial load.

Instead, we need to think laterally. Go back to the original rotating entity hack, and then add an "origin" key to the entity of '0 0 -4000' - this probably positions it a long way below your map (if your map goes that far down choose another coordinate which is outside the map). This way the entity is present, but the player can't see it.

Then we add a "use" function to the entity of "SUB_CalcMoveDone". The idea is that rather than spawning the entity mid map, it will always exist and we will just teleport it into sight when needed. You can use the "finaldest" to specify the coordinates you would like it to appear at.

Bonus hack: if you are using the rotator hack, but would instead like to stop the rotation at some point, you can use the "use" function "SUB_CalcAngleMoveDone" to do just that. You can't start it again though... 
Works Fantastic! 
Man, I dunno how you folks figure out this stuff. Way above my head. It works great, though; can't tell what position rotation-wise the entity will be in when the player triggers it and causes it to teleport, but that isn't a big deal at all and I'm sure a number of neat things could be done by loading up a bunch of entities and teleporting them in while killtargeting the previous in order- might be heavy on the entity count but I'm not worried about that right now. 
Neat. As a matter of fact, I tried to get the same effect (sun gem), but didn't succeed. Seems SUB_CalcMove* has some unused potential. 
Praise The SUB_CalcMoveDone 
I'm actually planning to write a whole blog post just on this function, it's the best! 
1 post not shown on this page because it was spam
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.