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
Follow Up: The Alternator 
Hot on the heels, the promised hack that lets us ignore the order the entities are placed in the map, but still dictate the order that triggers fire.

The article also includes how to make an "alternator" - a setup where a single input trigger switches between activating two different targets. 
Brain Teaser For Preach 
Imagine you have several shootable triggers or buttons and want to fire an event once a certain total amount of health has been depleted. The damage done to the triggers transfered to an independent source, so to speak. So you can shoot each a random number of trigger a random number of times and once the overall health depletion reaches n, the event fires. Basically like a counter based on "health" instead of "count". > W_FireAxe notnull hack
W_FireAxe hits a func_door. = 1000 or 2000 etc.

And voila, just add func_buttons. 
but, don't you want the player's actual weapon damage to matter? E.g. shooting it with 10 nails should cause less total damage than 10 rockets. 
Make as many "shootable buttons" that you need. Select all of them, turn them all into one func_door with a health value, give it a target, set lip equal to bounding box so it doesn't move. 
The sum of all damage done combined. No idea if it's possible, and the applications would certainly be limited. For the lack of a better example: a machine needs to be damaged by a certain amount in order to be charged or explode and there are several exposed shootable parts. You can focus on a single one, or shoot each of them equally - the event fires once its global health is depleted. 
Exactly was @ metlslime.

But yeah, turning them all into a single door or button should work. Though what happens if they are supposed to be spread all over the map 
yeah, will you exceed max efrags and it disappears? I think in modern engines the efrag issue is solved and it is always drawn maybe... 
Spread All Over 
Nothing as far as I know, so long as the lip is set right for whichever movedir is set. I can't recall if func_button has an option to be silent in vanilla, so a func_door probably would work better. 
One Doesn't Tease Preach's Brain With Trivial Matters! 
And yet, I have another possibly simple or already-answered-but-I'm-too-dumb-to-find question: how to spawn fully functional movers like trains, doors and plats half-way through the map? Basically invisible until triggered and then working like normal entities. Think "use" "func_wall" but without being thwarted by precache functions. 
I'm indeed stupid. It should work just fine that way as long as you override the sounds. Or is there anything more to it? If not, please delete me. 
inline models are implicitly precached, so those are not an issue for doors/plats/trains/etc.
while they'll have a model string set, their starting modelindex will be 0, which means they'll remain invisible until they're properly spawned.

regarding sounds, you can just have a second door/plat anywhere else in the map, its sole purpose being to precache the required sounds.

a bigger issue is that if you're using use+targetname, you'll have no way to clear said targetname before the use is called.
this means that plats will need to be triggered twice (one to spawn, once to activate them so that they can be used).
doors are more problematic - you'll need to manually create a trigger field around the missing door to allow it to open, and you'll need to spawn that trigger field the same way as the door otherwise they'll spawn the door when you walk through them the first time. 
Reaching back to this post from 2009 and trying to understand something.

Would this allow for a silent trigger_push? My set up is:

classname info_notnull
use InitTrigger
touch trigger_push_touch
speed 500
angle 90
spawnflags 2
targetname test

Mark V and Quakespasm are still complaining about not caching the ambience/windfly.wav sound file. I thought this was the whole point of this hack.

Just put a trigger_push out in the void and it will ensure that sound is precached and avoid the warnings. 
Yep, that's in the map off in a tiny room but the hack'd entity plays the sound in that case. 
Yep, that's in the map off in a tiny room but the hack'd entity plays the sound in that case. 
Different Intent 
The intent is to make a delayed spawn trigger_push. The sound precache is the reason we have to do something a bit different to the standard "classname as use function" hack, it's what we're trying to work around. But the lack of sound is not intended - I would pair this with a regular trigger_push hidden somewhere in the map to perform the precache and remove the warnings.

You'd have to be pretty creative to get rid of the flying sound, only thing I can think might work is finding an entity hack that sets fly_sound on the player to an impossibly high value using ltime shenanigans on a doctored movetype_push entity. Haven't quite cracked that yet.

On a related note, this has reminded me of an undocumented Quoth 2.2 feature: you can specify the sound a trigger_push makes using the "noise" key. You can create a boiing! noise for jumppads, or using "misc/null.wav" will prevent any sound being made. Will write that one up when I get back... 
Alright. I was afraid of that, but luckily it's for academic purposes not a real project. Great news about the noise keys in Quoth 2.2 That does open up some possibilities. Thanks for the response.

I hope you get a chance to play my 100b4 entry. Lot's of sound work went into it. 
Cool Beans 
The pack is next on my list, so I'll watch out for it! 
Func_breakable In Id1 
Hey everyone :) So earlier someone on the TB discord asked if it was possible to make a brush that acts like a HL style func_breakable so I did some fooling around and figured out how to do it! Now this is pretty easy stuff that probably isn't really worthy of going here but I'll post about it anyway lol. So here is how you do it, you make a func_wall as you would normally do, then after you've made it you add a few keyvalues to it. First add a takedamage key and set it to 2, that allows it to take damage, obviously. Then you add a health field and set it to however much health you want the breakable to have. Then when it's health reaches 0 it will try to call the function in the th_die field, if there isn't one the map will crash as I found out :D So add th_die and set it to SUB_Remove or any other function that calls SUB_Remove at some point, depending on what your needs are. Optionally you can add an armortype and armorvalue to give the breakable damage resistance so it can be broken with some weapons but not others. I haven't exactly figured out how to customize the sound it makes when you hit it or break it yet but I will keep trying and see if you can do it without needing a mod 
Previous Post Continued 
So after a little more discussion I've figured out how to add sound playback to the breakable, so the full setup looks like this:

takedamage = 2
health (whatever you want it to be)
armortype/armorvalue (whatever you want it to be
noise (whatever sound you want the brush to make when you hit it but don't break it)
th_pain = train_wait (plays sound in noise field whenever you hit it)
th_die = SUB_UseTargets (targets 2 separate info_notnull's that play the sound you want to play when the object is broken and removes it, respectively)
target = the name of the 2 notnulls

Notnull 1
targetname = whatever you put in the target field of the breakable
noise = the sound you want to play when the breakable breaks
use = train_wait (play the sound when triggered by the breakable dying)

Notnull 2
targetname = same as the first one
killtarget = name of the breakable
use = SUB_UseTargets (remove the breakable when this gets triggered by it dying)

Please feel free to correct me if something I put is incorrect, I'm still pretty new to q1 mapping and map hacks especially. But map hacks are really fun and I've almost become more interested in them than actual mapping at this point (but not completely though) :P I'm also trying to think of how to add rotation to a turret hack I made last week but I haven't really checked any of the quake c sources related to rotating functions to see which ones I might be able to use 
Hi Therektafire 
That's a really well constructed and described hack. Welcome to the thread!

In terms of rotation, a warning and two pointers. First warning is that standard Quake just doesn't do collision on rotation. The amount of highly specialised code that mods apply to get even crude approximation of rotating solids, I wouldn't expect a hack to be able to get anything like collision working.

If you just want visible rotation things are better. There are already suggestions in this thread about how to use avelocity for simple looping animations. If you're looking for something more triggered, you might want to look at SUB_CalcAngleMove. Although any entity which used the function got cut from the final release of Quake, it's still available for hacks to use.

Alternatively, you might want to look into the AI functions if you'd like rotations that follow the player. You need to set quite a few keys on an entity to trick the game into running some of the built-in AI stuff for turning to face an enemy, but it should be possible. More advanced stuff, but something to get your teeth into... 
Having your breakable also create some info_notnulls using external .bsp models for rubble and have a movetype 6 would be cool too. Can't remember a good way to give them starting velocity at the moment though and still be triggered on break. 
Thanks :) I got the idea for the armor from one of your articles I may add it to the turrets too if possible. Speaking of, I will definitely look into the AI turning/rotating functions to see what I can do with them 
How can I make worldspawn shootable and killable?
Perfect accuracy gameplay challenge... 
A Trigger Curiosity 
So, I was idly tugging my way through some of the vanilla QC files, and noticed functionality I was hitherto unaware of!

In the blurb for the trigger_once entity, it says this:

if "angle" is set, the trigger will only fire when someone is facing the direction of the angle. Use "360" for an angle of 0.

The code to do this seems to be in there, but I cannot recall a single time in the id1 levels where I noticed this behaviour.

Is this used anywhere in id1, and if so where?

Yours curiously... 
one place is on start.bsp
those 'this hall selects foo skill' centerprinting triggers only display their messages when you're facing towards the teleports. walk backwards into the teleporters and you won't see the messages at all. 
Two Custom Map Examples 
Rehashing Old Work 
I didn't bother to dig into the whole backlog of messages here, but I made a (fairly simple) hack that allows for killable "static" entities. I've tested this with flames, but not with other things, I suspect that light globes may work.

step one, make a trigger under the player spawn and make it target an info_notnull called "flame". Make sure this info_notnull is some distance from the player, as touching it too early will crash your engine.

Place a "light_flame_large_yellow" somewhere in the map to precache the model.

give the info_notnull the following keys:

targetname flame
model progs/flame2.mdl
frame 1
use func_wall
think PlaceItem
nextthink 2
mdl progs/flame2.mdl

This should now allow you to killtarget the flame entity. Note that static ents don't occupy the edict list, however this hack will. I guess it will also allow for a touch function to be run on it after this point too.

One final thing to consider when using this hack, touching this entity before its had its "nextthink" even by a monster will crash the game. Even shooting the flame will crash it. I suggest spawning them well away from players and monsters.

The nextthink function forces the notnull entity back to a non-solid non-bsp state whilst retaining the flame model. In the example above this happens 2 seconds after it spawns. 
(oh, the trigger should be a trigger once) 
those 'this hall selects foo skill' centerprinting triggers

Blimey, I didn't have to go far then to find one. 
That's a fair amount of work for a killable flame. Rather than messing with thinks and nextthinks and all that, you can just set the modelindex of an info_notnull to that of the spinning flame model (flame2.mdl, check in the console first to see which slot it takes of course) and have a simple displayed model that you can killtarget like normal, no extra futchery with crashing when touched or anything. The flame will automatically do its snazzy little spinning and burning animation, similar to a backpack, and the frame field changes the size with 0 being the smaller flame model (light_flame_small_yellow) and 1 being the larger version. Old example webm here
the flame models are static and don't appear in the edict list though? 
They're still given a modelindex, no different from the player or enemy models or worldspawn/brush models. Not sure how to find which model has what number in Fitzquake-derived engines but Darkplaces (ugh) has a handy modellist command that will print out every model currently loaded by the game in order. Worldspawn comes first, then count the list by one. Worst case scenario, experiment a bit until you find the right modelindex and remember to place things in the right order that enemies/health changing by difficulty won't break the hack. 
Worst Case Scenario 
You might have to make separate entities for different skill levels, with each having the correct model indices for the corresponding skill levels. :/ 
Move On Up 
Moving the static torch you're using to precache the model as near to the top of the entity list as possible will help to stabilise the modelindex across all the skill levels in your map. Also worth remembering that each time you add a brush entity, that adds one to all the precache modelindex values. So you want the map to be basically finished in that respect before you finish off the hack. 
Rotating Turret Hack Finished (mostly)! 
Hey guys, back for another update. My rotating turret hack is almost 100% done :D I just need to take a few minutes tomorrow to iron out some little kinks related to the offsetting of the body model in relation to the shots and it will be good to go and I can make a demo map and full write up on it. In the meantime here is a weirdly rotated screenshot from QuakeDroid showing it in action in a crappy little box room :) 
The Absolute Fucking Madman 
Eagerly looking forward to seeing it in action. 
Nice that a "newer guy" can make cool stuff! 
If what he's posted in #tf and related channels in such short time is any indication, rekta is a new maphax savant. 
I mean it's not that impressive, you can do it easily if you have basic programming knowledge and take the time to read the sources to know what fields and functions you can and cant use where... Or in my case, try and figure out why entire segments of code were replaced and moved elsewhere but still in the original files commented out, then get confused when what you want to do isn't working the way it should :D it's not like I'm making Quake Rally 2 or something like that... Though I do like racing games so maybe I'll give that a shot some day ;) 
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.