fyi, figured out how to do what I wanted... MOVETYPE_PUSH is required for a train... but you can bypass the crash if you killtarget the train the moment the enemy you telefrag dies (shub removes the train as well as part of her death functions) 

Here's a map hack article that's been sitting half-finished for months. It's a general article on how to build a trigger_ type entity with very little restriction on the keys you can set.

http://tomeofpreach.wordpress.com/2013/05/13/build-your-own-trigger/

I think most of the regulars who read this thread will know this trick, but hopefully it's a good reference for newer mappers - and there might be some new ideas in the concrete examples of the trick. 

I didn't know that trick, cool! 

 

Could you clarify, are you looking for a hack which fills all the player's ammunition type (easy to accomplish with backpack_touch), or are you trying to increase the maximum ammo the player can carry (almost certainly impossible)? 

 

You'll want to write a short mod to do that then, it's outside what hacks will do for you. Also, be warned that not all engines can display ammo counts above 255 properly, which means the scope for expanding nail ammo is limited. 

can you dynamically change the gravity values?
or set a trigger to change a mobs .target value? 

I think one of the expansion packs has a way to do this but it doesn't work in coop 

You pretty much can't change the gravity with stock quake - there's a way to change it exactly once with a hack if you don't mind that you can't have an exit in your map. It's very common in mods though.

Not sure exactly what you're asking in that second question - you literally want to change the string stored in the target field? It might be better to do what you want with logic gates triggered by the monster instead. 

global sv_gravity cvar, if you have a trigger or some such to issue localcmds.
or .gravity field, if you have a trigger to apply that field to entities within its boundaries.

I've no idea how to utilise either of those without a mod to do it for you.

in some engines (ie: ones that always register custom fields, ie: fte+dp), you can override .gravity on a per-entity basis by just setting the gravity field. Of course, as this doesn't apply to players, projectiles, or movetype_step (unless you somehow manage to get them airborne), all it can really be used for is to confuse the fiend+dog+spawn attack code. Which might be amusing. 

 

the article text won't show up. 

stupid mediawiki can't handle the latest version of some library which I forgot to pin when I updated earlier. will be fixed tomorrow. 

Don't screw it up again... 

Earlier this morning, onetruepurple mentioned an idea for monsters following the player while he had the Ring of Invisibility. I didn't think it possible, but he mentioned that it was done in E4M1.

So I decompiled the map and discovered a trick that I didn't know about and think it's cool enough to share.

It's very simple, if you make a monster target a path_corner, and that path_corner has no further targets, Quake decides that that monster's next movetarget should be entity 1... which just happens to be player 1.

Here's a .bsp and .map showing this effect... don't shoot!
http://quaketastic.com/files/misc/followtest.zip 

I have no idea WHY that works.

self.goalentity = self.movetarget = find (world, targetname, other.target);

Is the relevant bit here, where self is the monster, and other is the path_corner... but why it decides on entity 1 when other.target is empty... it is a mystery? 

Find() must just return 1 if some of the values it's passed aren't valid? 

I wanted monsters to reach the end of their path and just stay there, and so left the target field blank.

But the same happened - they turned and followed the player, ruining the gameplay I was going for.

This is because their movetogoal becomes "" and the player is the last entity added to the server, with that exact name, aka string_null.

I fixed it by giving the path_corners where I wanted monsters to stop a broken target.

Props to Preach for pointing this out. 

 

It does odd things instead, depending if its func_train or a monster_whatever.

Just for RRP guys;

The path code in RRP is more advanced as well; I ported the advanced pathing from extras r4 so there are more control entities for trains, they can be reversed, paused and so on. Wait -1 will teleport a train from one point to another and can be set per path_corner. Additionally, giving a path_corner an event key will trigger whatever targetname it's pointed at, when the train reaches that path_corner.  

11:11:00 | <+Daz> gomap scampsp2! But not idbase kthx
11:11:20 | <+Daz> ikbase!
11:11:25 | <@onetruepurple> and not fucking dapakbase

5/5 bretty good, could use more Tarbabies though 

The reason is because other.target = "".

Find() always starts at the first entity in the list (1, the player).

It checks if the entity's targetname == "" which it does (because players don't use targetnames), so it returns the player. 

if you gave the player a non-empty targetname then the monster would find a different entity to walk towards... 

Thanks for clarifying the reason 

It's been like 6 months since we had a hack. Here's a hack for...Quoth?

http://tomeofpreach.wordpress.com/2014/09/15/quoth-required-message/

Now you can create entities which appear in your map when run under ID1, but not in Quoth. There's one simple application of this, plus the opportunity to go overboard with it instead! 

I was just wondering today how something like this would work. This should be mandatory knowledge for all future Quoth mappers. Thanks, Preach! 

Nice. A much smoother way than the Quoth detection in my levels. 

trigger_relay:
targetname "lava"
target "lava"
delay "0.099"

info_notnull
targetname "lava"
use "boss_death9"

why dis no work? :(
tested with a message on the relay, and it is indeed working, but no lavas. 

The function is not reusable. You might want to killtarget it quickly as well, since it increases the killcount at boss_death10. Note that while the function works without a Chthon in the map, you need to put one somewhere for the splash sound to be precached.

I had an idea for Jam6 that involved the lava splash, too. The opportunity is simply good enough to miss. 

Why is it not reusable? If you retrigger before 0.1 seconds it should just keep spawning particles. 

This thread is a treasure and should be pinned. 

that's a heck of a lot of particles! 

it would be glorious... if it worked. T_T 

Just use lots of tbaby_die2 

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! 

You better believe I'm gonna abuse that hack. 

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? 

 

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. 

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:

http://scampie.net/etc/ogrepath_wait.jpg

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 

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. 

Has it really been more than 3 months since the last hack? Well, good things come to those who wait.

https://tomeofpreach.wordpress.com/2016/02/10/high-fps-texture-animations/

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... 

Im not sure I know this one, can someone explain it or point to a resource that explains it? 

My intro to map hacks post uses info_notnull and mentions why we like it so much

https://tomeofpreach.wordpress.com/2012/11/18/triggered-explosions/ 

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. 

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. 

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! 

Nice one! 

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 :) 

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. 

info_notnull

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. 

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. :) 

 

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! 

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. 

So, which hack should I write up next:

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

or

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. 

Do b) 

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. 

 

// Try it...jump around on any map

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

};
void () worldspawn =
{

world.touch = test_touch; 

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. 

Another two-fer! 

So the fixed logic gates are up at

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

The updated portion is highlighted in yellow. I've also updated the example .map at http://www.quaketastic.com/files/single_player/maps/gates.zip 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...
https://tomeofpreach.wordpress.com/2016/02/21/reusable-trigger_counter/
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:

https://tomeofpreach.wordpress.com/2016/02/23/more-reusable-trigger_counter/

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. 

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... 

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 

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... 

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. 

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. 

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. 

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... 

Here's the hack:

https://tomeofpreach.wordpress.com/2016/04/23/the-randomiser/

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. 

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? 

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 

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... 

 

 

 

is this a thing that's possible? I want to use it as an acid drop in my mapjam 7 map (quoth). 

 

 

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

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

I beg to differ 

Preach!

"modelpath" "progs/w_spike.mdl"

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

my bad.
Thanks. 

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

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

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

I'm interested of the outcome. 

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

h2o 

 

fuck, I misunderstood.

I feel like fiddling around in the progs could get what you want fairly painlessly. 

I asked in mapping help but maybe here would be better for my question.

In AD I want the Golem to only have melee attacks, no projectiles. This is listed in his mon_golem.qc right before the range attack code:

if (!self.enemy) return;
if (self.health < 1) return;

Now if either of those are true he will skip the code for firing projectiles.

I tested a modified AD progs by the simple addition of a return; above the "if" statements and got a melee only Golem. But that's not really an option.

The function is called void() golem_rockstorm =

Any progs.dat tricks for this? Even if it's not an "old" progs :-P

Could he fire the doggie's attack instead!!! I still need him to STOMP though... 

It's a bad idea to use map hacks against a mod which is in development. In effect you're trying to apply a hack to a moving target - the mod may change that code in the next version and break your hack. The reason that id1 hacks are acceptable is because id aren't ever going to release another patch for Quake, so all behaviours (even unintended ones) are unchanging... 

I bet plenty of custom engines break certain map hacks. I don't have any examples to hand tho - know of any? 

You write: "I want the Golem to only have melee attacks."
Then you edited the code and write: "I got a melee only Golem."
That was what you want. So what is wrong?

If you want to give him a different behaviour for ranged distance, then all you have to do is edit his ranged attack code. There is no TRICK needed. Just do it.
The Golem code works like any other monster code.
You first have to know what you want. Then do it. Yes, its that easy. 

I don't think I should "fork" the AD progs. I'd see that as a nightmare for a map(s) release.

Requiring players to duplicate their AD directory, replace the progs.dat with "my" version and then install maps and not get confused is it a bit much, yes?

That's why I was looking for an alternate solution.

I'll just put it on the backburner for now.. 

I mean, in theory almost anything could be broken by a determined custom engine. One that I worry about in theory but haven't ever seen break is the high frame-rate animation from
https://tomeofpreach.wordpress.com/2016/02/10/high-fps-texture-animations/
This relies on a global timer on .bsp animations. Given that some engines have removed the global timer on looping .mdl animations (much to my irritation) it doesn't seem impossible that the same might befall the .bsp ones.

The thing with a lot of the map hacks is that they involve tricking the QuakeC - and engines tend to preserve QuakeC behaviour pretty well. Most of the stuff that happens in a map hack is legitimate QuakeC, just unintended. I suppose any hack which involves the order of the list of entities would be vulnerable to an engine which changed the order to be non-deterministic, but again I've not seen it in practice. 

Was intended as a toolkit. That includes making your own stuff 

You mind if I send you an email with the map setup and why I want this?

No worries if you don't ant to bother. 

 

My email addy is strange, begins with uw_ Don't ask, hehe 

 

Kinn was complaining that you can't have disabled triggers in id1.

Couldn't you have a trigger with SOLID_NOT (SOLID_NONE?) and then come up with a way to use the above to activate a trigger that started disabled? 

The sophisticated 'super logic gate' idea Preach is about to come up with!

Or perhaps at least an easier way to do things like the switchable push hack and the like? 

New hack is a respawning trigger_once

https://tomeofpreach.wordpress.com/2017/01/19/respawnable-trigger_once/

The twist is that the hack doesn't use that function. What it uses is the fact that the function is redundant, and exploits what replaced it in the code.

I have come up with a different hack that uses the function since, watch this space... 

That's a really interesting article and could help with the usual complaints of not having the ability to have inactive triggers change states.

Cheers to you! 

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 http://www.insideqc.com/qctut/#Scratch

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. 

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... :) 

Second: I wonder if you or anyone else has ever considered completing the "From scratch" tutorials that were so informative on insideqc http://www.insideqc.com/qctut/#Scratch

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... 

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.

https://tomeofpreach.wordpress.com/2017/01/22/respawnable-trigger_once-experiments/

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. 

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

https://tomeofpreach.wordpress.com/2017/01/29/rapid-fire-trigger_hurt/

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. 

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? 

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.

https://tomeofpreach.wordpress.com/2017/02/07/fish-fix/

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. 

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... 

...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... 

Hi all, big article incoming!

https://tomeofpreach.wordpress.com/2017/02/14/logic-gates-for-2017/

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? 

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. 

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.

https://tomeofpreach.wordpress.com/2017/03/05/masquerading-as-a-door/

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! 

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.

https://tomeofpreach.wordpress.com/2017/03/14/further-logic-gates-for-2017/ 

very nice article! 

Above and beyond Preach, the layout is very approachable! 

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. 

I'm a bit scared 

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! 

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... 

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"
 

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. 

He's the best. 

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. 

You need to use a func_illusionary hack. 

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
http://celephais.net/board/view_thread.php?id=37116&start=36&end=36
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). 

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... 

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. 

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? 

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;
else
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.