Finny

mashed draugr legs onto the hierophant. looks goofy, dunno if i'll keep going with it. EDIT i think i like it a bit more animated

i did something like this ages ago with decorate, using a combination of SkullAttack and ThrustThingZ, and just gave it a Stop frame after so many tics to return to chasing. nowadays i'm sure there's a way you could make it check for when it lands to end the attack instead. you can assign multiple actions to a single frame. in decorate you'd just use a series of 0 frame actions, and i believe zscript lets you just put multiple functions in a single frame. LeapAttack: BLDM X 10 A_FaceTarget BLDM Y 0 A_SkullAttack(25) BLDM Y 16 ThrustThingZ(0, 16, 0, 1) BLDM X 6 A_Stop Goto See

tried to do a running tackle animation for the satyr. looks more like he's trying to give you a big fat hug. doubt i've got the gumption for it, but i feel like the idea would work better if i edited some large horns on to the fella and gave him a bull charge attack like the hexeheretic minotaur. satyr tackle.zip

the file i posted on the last page will eventually crash that way if you keep playing around with paladins (shield & rocket launcher enemies) for long enough, but i threw together something that should get you the crashes pretty quickly & consistently if you want to see for yourself. get it here. that's a much more straightforward test where lost souls are modified to go straight to Stop after SkullAttack. the map is a mix of lost souls and imps, and the lost souls are grounded - seems much more likely to induce the crash this way. you should be able to run around the mob with your weapon of choice and in a few seconds you'll get the crash, where crispy just exits and prboom+ spits out a signal 11 error. while you're here, i was also wondering if this was a bug or just dehacked funkiness: when you set a weapon that fires something, hitscan or projectile, to use infinite ammo, it ends up using total shotgun ammo instead, like your pool of shotgun ammo depletes. i found that manually setting the ammo type from 4 (what whacked uses for the infinite ammo setting) to 7 will use each type of ammo's total amount. this is another thing that happens in both crispy and prboom+, so i was assuming this was normal behavior that some port authors specifically adjusted. newer test version? i'm assuming you've whipped up some test stuff of your own because i haven't uploaded anything since the 10th until now... anyway, the file linked above is pretty much guaranteed to crash pretty quickly, and uses a 0 duration on SkullAttack before the Stop call. you can increase that and it'll make it take longer to crash, but it should still eventually crash provided you don't give it a ridiculously large duration to where the lost souls can't call Stop before running into something anyway. i tested with a 4 frame duration and still eventually got a crash. initially i thought adjusting the duration of the Stop frame itself didn't affect anything - the actor would immediately return to the Spawn state without even waiting the entire duration of the Stop frame anyway - but it seems setting the Stop frame to something extremely high (i tried 100 frames) is somehow preventing crashes, even though in testing i don't see any notable visual difference between having that set to 4 frames, which is what its set to in the file above. 0 frames seems to make the crash darn near instant.

mmhmm, sometimes it just gets annoying fighting between specific engine quirks & how they handle dehacked stuff. in this case, eternity & zdoom don't seem to have any problems with it, but prboom spits out an error, and crispy just says fuck you and closes without warning. it was a similar situation with testing the BrainSpit turret, where different engines handled SkullAttack in slight ways that introduced frustrating inconsistencies in how the whole thing worked between different engines.

lol yep, that's pretty much the idea. funnily enough i was working on that when i noticed the crashes, and originally assumed that it was related to the shield ability. the suggestion ended up being helpful in finding an unrelated problem.

looks like calling Stop during SkullAttack is a Bad Idea. by itself it doesn't seem to cause any issues, but when mixed in with a bunch of projectile-launching enemies, it will very occasionally cause a crash in prboom+ with a signal 11 error. just to be sure, i whipped up a bex with just a lost soul who immediately calls Stop right after SkullAttack and made a mini-nuts map filled with imps & modified lost souls, and sure enough it eventually crashed with the same error. so, guess i'm ditching the shield charge attack after all, heh.

aaah, yeah it should run fine with 2.5.1.4, so looks like that's sorted. ...though now i'm actually surprised it isn't crashing. it looks like i forgot to set the null sound for the guardian's attack sound, which usually causes things to explode when it tries to call BetaSkullAttack without an assigned attack sound. the issue is that this type of attack will hit a target even behind cover, so once the guardian initiates its attack, taking cover is normally useless; it's guaranteed damage aside from pain stunning the enemy. my workaround for this was to have it used SpidRefire to check if the player is still in LOS before completing the attack, but this meant that if the attack didn't complete, it wouldn't make any sound which just didn't feel right. i would've just used one of the guardian's attack frames to play the sound, but playing the assigned null sound afterward causes it to stop the attack sound early. the solution then was for it to spawn an object that simply plays the attack sound so that the sound isn't interrupted by the guardian playing the null sound. i also adjusted the machinegun to have FireCGun on frames 52 & 53. even if it wasn't crashing the ports i was testing on, figure better safe than sorry, so why not. (other than annoying me that the frames are shuffled around now, bleh)

either way, it's not like i have any desire to go back to the detonation method since this is so much more consistent and functional. plus it means i don't need the grell to hog the spiderdemon slot for the splash immunity, so the hades elementals can take it instead so they stop blowing themselves up all the time, hehe.

rather than look, a chase frame helped it properly target the player. so far it looks perfect for the gas attack. thanks for the idea, this is a great improvement. my only question now would be how this would work in co-op, since i'm assuming the gas will just want to attack one player at a time. wonder if putting an additional chase call in the damage loop would help it switch targets.

oh derp, i misread your original post. it's up for changing, but i figure it's something that i'll get a better feel for once there's some actual levels to play. doesn't seem to do anything with a quick test, but i'm probably just doing it wrong. i'll play around with it to see if i can make it work.

thanks for the feedback y'all. been a bit of a pain getting the grell's gas to feel right. wish detonate had been parameterized for separate damage & raidus, but alas. that's actually kinda brilliant for shielded enemies. wish i'd seen that idea before implementing his shielded charge attack, but i'm rather fond of the charge now, and i'm not sure about having the shield be used for both since it might confuse players as to when he's vulnerable. hmmm... were you using the flamethrower? the true bfg-tier weapon replaces the chainsaw. it's supposed be infinite ammo (it damages the player when fired), but setting projectile-firing weapons to use infinite ammo causes them to just use total shotgun ammo instead. it's really goofy. you posted those bruiser afrit sprites at a really good time. i'd had another idea for an enemy fall through and was looking for a nice hell noble-tier enemy to put in its place when i saw those in the spriting thread. the item randomizer is more-or-less straight out of batman doom, heh. that's another great mod for looking up advanced dehacked hijinks. the revenant tracer's homing behavior is determined by the duration between calls. you can read up on more details here. the 0 duration frames in the vore's projectile are just there to further improve the homing behavior. were you using the latest version of prboom+? i've tested it with that and had no issues with the machinegun or the guardian's wake up sound. i did test with the old prboom and while it did have many issues, funnily enough the guardian sound wasn't one of them. the machinegun did crash though, so i might play with that to make sure there aren't problems in some other ports. at this point i'd just assume anything that heavily relies on dehacked probably wont correctly work in gzdoom. it would be trivial to whip up a zscript alternative for compatibility's sake down the line.

fellow dehacked enthusiasts, i've been working on a dehacked-based mod. got weapons and enemies generally finished, aside from future fiddling and tweaking of course. now i just need to make some maps for 'em. i figured at least the base package might be of some interest to folks in this thread. it's designed around mbf compatibility, specifically tested with crispy doom and prboom+. eternity seems to work fine too. gzdoom doesn't get along with dehacked so avoid that one. download here only other thing to note is that i had a BrainSpit-based turret creature, but ultimately couldn't make it work in the end. it's probably fine for a very controlled, enclosed environment like in the example wad in the op, but start adding variation to terrain elevation and things get really unpredictable, especially between different engines. i suppose it could've worked with some very careful level design, but i figured it's less of a headache to just move on from the idea.

so i've been playing around with using BrainSpit for a projectile attack, trying to make it work a bit more reliably. using Chase for the moving target ai seems like a bad choice because it will eventually decide to just leave the map completely, resulting in the enemy launching the projectiles becoming comically inaccurate, eventually even crashing the game outright if the target gets too far away. had this problem occur with crispy doom & prboom+. it also has an annoying tendency to open doors near the player, though maybe a mapper could say their level is haunted by a spooky ghost. switching the moving target ai to use SkullAttack seems like it has potential so far. main thing to note is that the frequency that SkullAttack is called and its overall effects on the attack. having it called every frame makes for an attack that's extremely precise but terribly inaccurate - when trying to attack close to the player, SkullAttack seems to cause the user to jump up a bit, so when its being called every frame on top of a stationary player, the target ai floats inside the player, causing all the projectiles to fly over the player. this might be resolved with a bit of specific positioning of the attacker, but overall it's not ideal. now i'm using SkullAttack with a bit of a delay between cycles - currently at 21 frames, but basically anything long enough that the target ai isn't constantly launching itself upward seems to be fine. the only gripe i have is that using SkullAttack repeatedly causes the ai to do a consistent zig-zag around the player once they stop, with the motion based on the direction the player was last moving. probably not a huge deal for actual gameplay but it bugs me in testing, heh. otherwise, it seems generally fine for a projectile barrage attack.

doom gacha thing. inspired by batman doom, yoinked the handle from there. doomgacha.zip