"//this is ugly as hell, WTF Carmack? "

Well, Carmack's reply would probably be something like, "We were trying to ship a game on new technology. This ugliness was maybe .00000001% of the workload. Unimportant." :) 

we've covered removing items from the inventory via a func_door function hack.

is it possible to co-opt sigil_touch() to remove runes from the player?

i was thinking if you gave built a trigger from scratch with a touch function of sigil_touch and gave it a spawnflags # corresponding to the appropriate rune (1, 2, 4, 8) except negative, it might be possible to subtract it out of the serverflags global variable.

except that the way they added the flag is in a form i'm not familiar with (and i don't know much about bitwise manipulation except what i've learned here).

serverflags = serverflags | (self.spawnflags & 15);

except that serverflags = serverflags | (serverflags & self.spawnflags);
would have seemed to me the correct way of adding the flag in.
what does the actual line do? will it prevent subtracting the flag off? 

serverflags = serverflags | (self.spawnflags & 15);

first, the & character is bitwise AND operator, which means that for each bit, the result is 1 only if both inputs are 1 for that same bit. 15 is 1 + 2 + 4 + 8, So self.spawnflags & 15 is going to only allow those first four bits in self.spawnflags to be used in the next step.

The next step: | is the bitwise OR operator, which means that for each bit, the result is 1 if either input has a 1 for that bit. So serverflags = serverflags | x is going to turn on any bit in serverflags that is in x, and leave on any bit that was already turned on before.

So basically, only the first four bits in serverflags can be turned on with a rune, and, you can't turn any bits off. 

damn shame, thanks though :) 

Just in, the latest discovery in the hacking business. A trigger_command in id1! Well, sort of.

As it turns out, it's actually possible to execute console commands from within the map by simply adding a linebreak followed by a string of commands in the "map" field of a trigger_changelevel. For example:

"classname" "trigger_changelevel"
"spawnflags" "1"�// no_intermission has to be set for this to work
"map" "\ngod; impulse 9"

The trick works because the trigger uses stuffcmd to change the level which we can exploit to run our own commands. However, there's a catch. In the engine, we have a hardcoded line that prevents the changelevel from being issued multiple times, which means this hack can only be used in this form once, and afterwards the player can't proceed to the next map after exiting the level normally. It will just stay in intermission mode forever - one might regard it as acceptable after a large map with no follow-up; or with a Shub ending.

Even in this state, the hack has a lot of potential, especially for mischief. You could, for instance, rename the player to "Asshole" and make his client connect to a server. :D Or mess with his entire config, unbind all keys etc. But since we're all nice and friendly people (right? :P), rather things like changing map-related cvars come to mind, e.g. setting r_wateralpha for the glass hack or adjusting fog values.

Luckily there's a sort of workaround for the changelevel/next map problem mentioned above. After changing cvars for map compatibility, you can add a "restart" or "map yourmap" command to the end of the string to reload the server with the exit trigger intact. Or, if you set any non-permanent stuff (e.g. cheat codes or gravity), you have to add commands to save and reload the game. ->

Following this line of thought, Preach came up with two very useful setups the hack allows us to use.

The first one is a kind of security measure to make sure all necessary commands are executed before the map is played. Set "serverflags 256" in the middle of your command string and use a func_episodegate with spawnflags 256 as a detector. If the episodegate doesn't spawn, the player (presumably) hasn't run the map yet and needs all the stuffcmd set; if it spawns, there's no need to restart.

The other one is an actual autosave option, albeit not a very transparent one. Place trigger_changelevel entities as checkpoints and set their map fields to "\nsave autosave; wait; load autosave" (you could also use "quick", or better yet, the mapname instead of "autosave"). This will save and instantly reload the game on each checkpoint - however, it's quite 'bumpy' and may even cause annoying delays in larger maps and engines with long loading times (DP). In this sense a button-controlled checkpoint system would probably be the best solution. 

Negke and I were discussing this last night for as long as steam would allow, and I think there are some exciting possibilities. However, I have just thought of a potential small wrinkle in the serverflags 256 detection code. Suppose that someone loads the map, instantly receives a string of commands including "serverflags 256;restart", and then begins playing the map on the second time round. Supposing they save the game, they might not load that saved game for a long time. If serverflags 256 has been cleared by subsequent playtime, then on trying to load their savegame they may end up back at the map start!

How did this arise? Well, when a savegame is loaded the engine does two things. Before it looks at the savegame data, the engine runs the first three frame of the lodaded map as if it had just been started from scratch, in order to get all of the precaches loaded. It then updates all of the entities and qc variables to match what was stored in the savegame file. If our hack runs during those first handful of frames, then the restart command will be sent before the savegame is loaded, and so you end up right at the start of the level.

It isn't the end of the world, because now serverflags will be set to 256, and so if you load the saved file a second time it will work correctly. It's just good to make people aware that this problem can occur though. The alternative design would be make sure that your hack trigger fires later than the first three frames, but this has two negative effects. One is that the restart will be more visible to players, as they will see frames rendered first. The other is that in the scenario outlined above, none of your essential console commands get executed when the game is loaded. If the serverflags cvar got reset, it's probable that some of the others did too. 

That reminds me of Zelda on the gameboy, where it was possible to steal from the shop and be called THIEF for the rest of the game. 

Cool trick: you can change the skybox while a map is running in most engines, via an info_command.

The command is "sky [skyname]" (works in Fitzquake, DirectQ, Quakespasm). Unfortunately Darkplaces uses a different name, "loadsky". I guess you could have a pair of info_commands with both commands, but then the player sees an "Unknown command" message for the one their engine doesn't recognize. :-/

This could be used for some neat effects. Maybe have a setting sun sky turn to night after spending some time indoors? 

This could be used for some neat effects. Maybe have a setting sun sky turn to night after spending some time indoors?
my lost map pack had this in there.

you can also string multiple console commands together like this:
sky void;loadsky void;fog 0 0 0 0\n
so there's no need to have multiple info_commands.

further, i think it's an undocumented feature, but if you set spawnflag 4, whatever commands are on that particular info_command will be run whenever the map is run or loaded from a save.
this stops the problem with fog/sky settings not being saved because they aren't in the worldspawn settings. 

This could be used for some neat effects. Maybe have a setting sun sky turn to night after spending some time indoors?

We did this in Travail too! We had to cheat a bit for people with older engines though by covering the sky with a non-solid black brush. 

Looking for a replacement teleportation effect (as spawn_tfog can't be used anywhere else than 0 0 0 - or so it seems), I came across two more things Chthon allows us to do. They are quite obvious, but I'm posting them just for the record.

Lava splash: Target an info_notnull entity with a "use" "boss_death2" field.
This might be useful for spawning a powerful monster or when lowering a platform into a lava pool. The downside is that this will increase the kill stats by 1, but it should be okay since it evens out the max count.

Meteor shower: An info_notnull with "use" "boss_missle1".
This will start an infite attack of lava balls from a fixed position aimed at the player - for an environmental hazard with a little more kick. Each missle will play Chthon's throwing sound, but that shouldn't be a problem, especially if the entity is high above or in some distance. To stop it, simply killtarget the entity.

Needless to say, a monster_boss has to be placed somewhere in the map for precaching. 

Use "boss_death9" instead for a more immediate effect, and killtarget the entity 0.1 seconds later to keep it from raising the kills count. 

Using the triggered respawn of items to repopulate arenas with items, but this is after the player has picked it up. Is there a way to despawn an item, so it only appears in the arena for a particular wave? 

Since you're using Quoth, the spawndelay feature (or however it's called) should suit your needs. 

sounds like he's asking to both add and then remove an item during play.

so you'll need to make your item spawn in and then, you should killtarget them to remove them when their time is up. 

It's not a massive problem. I can make little cages around the item, it's the problem of a fight taking some time to get going.
Feels crap to take it and lose half the time as you wait for the fight to ramp up, and I thought it would be neater to have an empty arena and just drop the powerups in as the particularly nasty monsters start flooding in :)
I guess the cage thing also has the advantage that they'd probably hear it better.

Another way round it would be increasing the duration of the powerup, so they just take it and don't have to worry about them missing the respawn. I guess that'll require code editing though :E 

you could create a variant of the trick i used in ne_tower with getting a quad damage after killing the two death lords.

create a number of of empty rooms with the powerup of your choice in them.
in each room, put a teleport destination on top of the powerups, but make sure the teleport destination is part way into the floor or ceiling so that the player won't fit when they teleport.

now, create a huge trigger_teleport that corresponds to each of the destinations and give them all targetnames.

what you'll do is start off a long train of teleports with delays after picking up the first powerup.

sure give each relay a delay of 30.

give all those trigger_teleports a targetname2 that is the same.

so you pick up the first powerup. that triggers a relay that will trigger the teleport trigger 30 seconds later that teleports you into the first room where you get a new powerup. the engine then pops you back to the old spot because you don't fit in the room. that new powerup starts another relay that, 30 seconds later, will teleport you into the next room. etc etc.

finally, when you kill the boss or whatever, killtarget all the trigger_teleports from the targetname2 which will remove them all and stop the chain. 

That's brilliant :D 

What determines the fixed point of the meteor shower - it is not the position of the not_null? It appears to be 0, 0, 0 

... what is the purpose of the '1' in 'boss_missile1'? 

boss_missile1 is actually chthon's animation (not the missile spawning function).
his attack animation is looped, unlike all other monsters. this is why he just starts firing and never stops.

the lavaballs SHOULD spawn relative to the origin of whatever entity you use.
specifically, one should spawn at 100 units forward, 100 units right and 200 up, relative to the origin and the other 100 units to the left. 

Oh, I didn't think about that.

However, it ignores the origin of the info_notnull and works off 0, 0, 0. Also in practice, it doesn't look right as the source of the lava balls moves i.e. they do not emanate from a fixed point as the player moves, due to the position of the boss (arms) being recalculated.

Changing "use" to "boss_missile" does have the lava balls coming from a fixed point but it is impossible to survive the onslaught.

If you could trigger it on/off and slow it down, it could be a good anti-player device. 

make info_notnull with 'use' 'boss_missile' and 'targetname' 'meteor'

now make a trigger_relay:
'targetname' 'meteor'
'target' 'meteor'
'delay' '1'

should now loop infinitely every second and shoot.

make multiple relays and start them at different times to stagger missile launches for a more natural effect.

if you have access to multiple targetnames, you can give a 'targetname2' that's unique to the relay allowing you to turn it off again without killing all the launchers as well. 

make sure 'delay' is set in the relay otherwise the engine will crash wtih an infinite loop error. 

Just playing with it now and using a trigger_multiple with "wait" set at one second. Three problems:-

1. almost instant death (100 - 120 hit points)
2. the first lavaball does not go anywhere, it just hovers until it disappears (subsequent balls do head for the player)
3. regardless of the position of the info_notnull, the source of the lavaball definitely remains at 0, 0, 0.

So although the position of the not_null is created in the map file, the code for the boss_missile ignores it and uses 0, 0, 0.

Pity, it seemed to have potential as a boss fight - e.g. carry out some task to turn the weapon off whilst whilst avoiding the lavaballs