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