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 

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? 

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