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
Monster Barriers... 
A trick I use is even simpler -- players can cross any gap in the floor that is 32 units or less across, becuase they have a 32x32 bounding box and use hull1 to do their collision.

Monsters, on the other hand, use hull1 or hull2 for collision, BUT they use hull0 to do their pathfinding. Since there's a gap in hull0, they think they can't cross it. So just like cattle guards at the entrances to pastures, you can simply put grates or other gaps where you want the monsters to be blocked.

Gratuitous cattle guard picture: http://www.3rf.org/album/ComancheSprings/slides/cattle%20guard.jpg

And an example in antediluvian: http://www.celephais.net/shite/ant2.jpg 
Nice Metl 
That's pretty nifty. They will come at you one the floor is "filled" like with a func_door, right? 
Killable Chthon With Map Ents 
http://forums.inside3d.com/viewtopic.php?t=475

FrikaC explains how to make a Chthon that can be killed by the players weapons rather than electrodes, without doing any qc coding or using another progs.dat 
Cool. 
very well written, too. Helped me understand certain aspects of the coding process more intimately (though we're still 'just friends' at this point).
But since I can't test it, I'd like to clarify one thing... he won't pop out and start going? almost immediately after starting the map he'll begin tossing his loud fireballs around? or am I confused? 
Also... 
is there a way to make a monster invulnerable until a certain point, at which he'll become vulnerable to weapons/lighting/smooshing? 
Temporarily Invincible Monsters 
this is possible. simply add a "invincible_finished" "#" field.
the awkward thing is that the # seconds start counting down when the map starts, so events involving such monsters have to be carefully planned. 
Hay Guys 
i hear that FrikaC has a way to make a killable Chton without quake-c? or was it marcus sklar. . . 
No No... 
you're thinking of that level from 1997, called "THEFLY" or something... I think it was by this guy Marcus Klar... 
Huh. 
no way to trigger it huh? that takes alot of the fun out of it... 
 
I know this is probably getting annoying, but how do you get monsters to drop weapons/ammo? when making a floating weapon, do you simply place it on a func_wall and then kill it upon starting the map? Any other "widely known" hacks? 
Drew: 
as far as i know, you trigger this cthon the normal way. I'd have to re-read the tutorial to be sure, though.

And yes, you kill the func_wall immediately after map load, using a trigger on the start point or something. At least that's the traditional way to do it. I wonder if this would work instead:

"classname" "func_wall"
"nextthink" "0.1"
"think" "sub_remove"


or would that not work because func_walls already have a think function? 
Metlslime 
A func_wall has no think function, so that would almost work as it stands. The problem is that the items will not have been dropped to the floor by 0.1 seconds in, so you'd remove the func_wall too soon. Setting nextthink to 0.5 would be safe(items drop at 0.2 seconds in), and probably won't be seen by the player anyway. 
Preach: 
Cool, so that would work.

I much prefer a clean hack to a messy hack. 
Sound... 
...hiya, I'm at the stage where the only thing left to do in this map before release is to enable a switchable ambient sound (ambient_drone). Is this doable via an info_notnull hack? It only needs to go from 'on' to 'off' once. I can't really afford to use brush entities as I'm a bee's thingy from the markedgesurfaces vanilla limit.

Thanks in advance. 
Not So Loud 
Yeah, it's fairly doable. You won't get the same sound attenuation as with a normal ambient sound, it'll just be like a door or platform, but other than that it works well. These fields on an info_notnull:

noise1 ambience/drone6.wav
noise3 misc/null.wav
think plat_hit_bottom
nextthink 2
targetname noisebegone
use fd_secret_done


plat_hit_bottom and fd_secret_done are functions that play noise1 and noise3 respectively and not a lot else. The usual notes about making sure something precaches these sounds apply - ambience/drone6.wav is precached by an ambient_drone and misc/null.wav is precached by a platform or door with sounds set to 0.

If you don't have a door like that already and can't include one because you're close to the limits, then you can terminate the looping sound with any other non looping sound. So if this represents the power going out, you might want to have an explosion to punctuate it. enforcer/enfstop.wav and one of the lightning gun sounds would also probably work nicely here. Otherwise just try and find a short, quiet sound like a ricochet so it's not noticable. 
Many Thanks Preach... 
...you are the bomb. Now, are we going to progress that Mechanised Enforcer Weapons Platform any further? Asaki is finishing up the code, I just need to know if you are going to make the wish list of skin and model mods. 
MEWP! 
err 
Found By Accident 
while searching for a way to let Shallrat breach some vorebabes I thought it might be good to look for the multigrenades qc
They have the same second subroutine I need.

I saw the earthquake.qc and wondered if it wasn't possible to fit it in Quake1 without the DOE pak.
And to my surprise it worked.
There may be a strange target t2 in the map but for I can see it works.

http://members.home.nl/gimli/Q1EarthQuak.htm 
Madfox: 
nice work, but this thread is about NOT changing qc code, but instead using the bsp file to create ususual features. 
Alright 
out of toppic, sorry my enthousiasm.
I'll try to relate to the general abuse.

Maybe better then creating a new toppic.
Sometimes it harder to find the wrong toppic with a right idea then,

nevermind. 
Objects That Selectivly Clip 
We're going to learn a new field we can add to almost any entity to change how it blocks other entities in the game. And that field is

owner n

Where n is the number of the entity that you want to "own" this entity. What does this mean? Well, it's easiest to understand by example. When an monster/player fires a projectile, the owner field of the projectile is set to the firing entity. This means that the two object will no longer clip or touch, they ignore each other for all collision purposes. The purpose is so that your own rockets don't explode on you as soon as you fire. Side effects include that you can't use a vore's own voreballs against it(directly).

So, what can we do with this? Well, you can set it on almost anything(doors being the big exception that already have owner specified in their own code). If you set, say, a monster's owner to 1, then it'll be noclip to the player. Kinda stupid, but cute, especially if you do it to a knight as it leaves them incapable of attacking you. You can't hit them with hitscan weapons, but you can get them with nails. This is because a traceline is in some ways a collision between yourself and the target entity.

So that's neat but not all that useful. A better use would be to have monsterclip that only clips selected monsters, like I suggested in mapping help. But surely you can only set the monsterclip to have one entity as it's owner? Yes, but that's the wrong way round to do it. What you do is make it so that all of the monsters you don't want to clip against it have the monster's owner set to the monsterclip. It's a symmetric relationship, so now all those monsters will disregard that one entity. Of course, they'll still hit all the other monsterclips in the map equally. You'll have to place them so that all the monsterclip they are likely to encounter that you want them to ignore is grouped as one entity.

The owner field might suggest that there's some kind of hierarchy going on here, but it's not the case. If the ogre has the player as an owner, and it's grenades have the ogre as their owner, the grenades still clip against the player. So you're basically limited to one link per object, it can be noclip to one entity of it's choice, and as many entities as you like can be noclip to it. The trick is to use the limited resource as creatively as possible.

What else could you do with this? Well, probably some good(evil) traps, shame this wasn't about for the speedmap pack last week. You could add HL2 style combine force fields that the player can't move through but the monsters can. I'm sure other people can think of things I can't. Maybe you could do something really clever for a coop only map, where player 1 and player 2 (entity 1 and entity 2 on the map) aren't treated symmetrically? It'd be cool to hear people's ideas. 
Sounds Awesome 
Preacher, you are the don of hacks. That one sounds particularly prime though, and it will get used. 
Levitating Enemies 
how about a shalrath (or shambler?) stood on an invisible func_train that only it can touch - either flying around a room and landing now and again to use its normal walking movement or else with a series of func trains causing it to jump around like in nehahra or the end of azure agony. 
 
MONSTER_FISH FRAG COUNT FIX !!! (sort Of) 
Here's something I just came up with.

Don't you hate not getting 100% kills due to the infamous monster_fish error? Well this doesn't stop the fish being counted twice, but you can manually increase the killed monsters count. Create an entity with these properties:

classname info_notnull
use boss_death10

Trigger it and the killed monster count will magically go up by one. BTW this method also kills the info_notnull, so you'll need one for every fish in your level. I suggest making each fish target one so they automatically call it on death. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.