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
 
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... 
This Is A Public Service Announcement... 
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 
Very Fair 
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... 
A Fair Point 
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. 
Cause And Effect 
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. 
Something To Ponder 
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. 
Wow!! 
Thats a doosey of hack Preach (and another two-fer no less). I see more awesomer puzzles in the future. 
Random Numbers 
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... 
The Most Unpredictible Follow-up Post 
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! 
Semi-related 
QC support for Notepad++, including Function List support and syntax highlighting: Tutorial & download
Have A Semi-working Hack That I Need A Little Assistance With 
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? 
Possible Tweak 
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. 
Awesome 
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 
Existing Practice 
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... 
Teaching Old Preach New Tricks 
 
Preach.dat 
 
Mankrip - Thanks! 
 
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.