Hideous Destructor 4.7.1c

[Matt]

It's my salute to all those lovelorn VD haters out there.

EDIT:...oh, I get it now.

Ow.

Pain.

EDIT2: But then again, my original response was just as appropriate. o_O

[Ryan Cordell]

Any who, I'd have an idea considering it was already in the Duke Plus mod by DeeperThought, maybe you could utilize mainly ACS with a little bit of the Pythagorean Theorem [sic]?

How does it work in Duke Plus? What I'm aiming for is something that the player must do manually (ideally by going up to a suitable ledge and hitting the use key) - the main problem I want to get around being that, in the current system, by automatically climbing the ledge it becomes needlessly difficult to hide behind cover without suddenly exposing yourself completely.

A user switchable (On or Off through userplus.con) definition that triggers a set of codes. The codes use a pythagorean set of code to determine distance between the wall and such, and possibly a system for checking the difference between the floor and the wall. In the game, you could mantle onto sloped surfaces, I think. It does the mantling automatically, and pressing a button will edge you up so you can go onto the floor.

It can also save you from long distance falls in the game. Primary example is E1L1.

[Matt]

Sounds a little bit much for DEC/ACS. What I had in mind was to A_FireCustomMissile an actor that then A_SpawnItems a second actor before disappearing (if there's no room, it doesn't spawn). If the spawn succeeds, the player is thrust upwards. I should be able to emulate hanging on to the ledge with a few additional steps.

Haven't tested whether the spawn would occur on a very high ledge anyway, though. If it does, I'll have to rethink this.

[Ryan Cordell]

---

Code: Select all • Expand view

state checkwall // checks to see if there is a close wall to grab onto

// mantling will be set to 1 if the answer is yes, 0 otherwise
setvar mantling 0


// we start by checking for the dreaded slope at feet problem

getactor[THISACTOR].z z
getactor[THISACTOR].x x
getactor[THISACTOR].y y
getactor[THISACTOR].sectnum mysector
getactor[THISACTOR].ang angvar
setvar zdist 0
cos mycos angvar
sin mysin angvar

hitscan x y z mysector mycos mysin zdist hitsector hitwall hitsprite hitx hity hitz clipmask
state pythagoras
setvarvar xydist2 xydist // saves the distance
subvar z 1536
hitscan x y z mysector mycos mysin zdist hitsector hitwall2 hitsprite hitx hity hitz clipmask
state pythagoras
ifvarn hitwall -1
ifvarvare hitwall hitwall2 ifvarvarg xydist xydist2 break // it's one of those slopes...

subvar z 1536 // now we do the first "real" hitscan
hitscan x y z mysector mycos mysin zdist hitsector hitwall hitsprite hitx hity hitz clipmask
state pythagoras

ifvarg xydist 384
{
   subvar z 3072
   hitscan x y z mysector mycos mysin zdist hitsector hitwall hitsprite hitx hity hitz clipmask
   addvar z 3072
   ifvarg xydist 384 break
}
ifvarn hitsprite -1
{
   getactor[hitsprite].cstat temp
   ifvarand temp 1 nullop else break // a non-blocking sprite will prevent mantling
}

//ifvare hitwall -1 ifvarn hitsprite -1 setvarvar hitwall hitsprite // treats sprite as wall

// now a second hitscan to see whether the upper body is above the wall

subvar z 7168
hitscan x y z mysector mycos mysin zdist hitsector hitwall2 hitsprite hitx hity hitz clipmask

//ifvare hitwall2 -1 ifvarn hitsprite2 -1 setvarvar hitwall2 hitsprite2 // treats sprite as wall

state pythagoras
ifvare jumped 0 setvar tempb 384 else setvar tempb 256
ifvarvarg xydist tempb ifvarvarn hitwall hitwall2 setvar mantling 1 else // ifvarg xydist 384
{
   subvar z 3072
   hitscan x y z mysector mycos mysin zdist hitsector hitwall2 hitsprite hitx hity hitz clipmask
   ifvarvare hitwall hitwall2 break
   state pythagoras
   ifvarl xydist 384
   {
      // there's still the possibility it could be a duct...
      ifvarn hitsprite -1
      {
         getactor[hitsprite].picnum picnum
         ifvare picnum BGRATE1
           setvar mantling 1
         ifvare picnum FANSPRITEBROKE
           setvar mantling 1   
      }
      break
   }
}

setvar mantling 1

ends

state mantlingcode

ifonwater nullop else
{
   getplayer[THISACTOR].jumping_counter temp
   ifp ponsteroids setvar tempb 901 else setvar tempb 721
   ifvarvare temp tempb setplayer[THISACTOR].jumping_counter 0
}

ifp ponground ifvare jumped 1 setvar jumped 0
ifvarl mantling 0 addvar mantling 1
ifvare mantling 1 addvar mantwait 1 else setvar mantwait 0

ifvarn onladder 0 break
ifvarg dodge 0 break
ifvarn holding -1 break

ifvare mantling 0 ifvare jumpadxvel 0
{
   getplayer[THISACTOR].posx x
   getplayer[THISACTOR].posy y
   getactor[THISACTOR].z z
   getplayer[THISACTOR].cursectnum mysector
   getflorzofslope mysector x y mz // mz is the return var
   subvarvar mz z // mz is now the distance to the ground
   ifvarl mz 6144 nullop else   
   {
      getplayer[THISACTOR].poszv temp
      ifvare jumped 1 setvar tempb 0 else setvar tempb 1536
      ifvarg underwater 0 setvar temp 2048
      ifonwater setvar temp 2048
      ifinwater setvar temp 2048
      ifvarvarg temp tempb
      {
         state checkwall
         ifvare mantling 1
         {
            getplayer[THISACTOR].posz mantz
            ifvarg underwater 0
            setplayer[THISACTOR].sound_pitch 0
            sound DUKE_GRUNT
            wackplayer
         }
         
      }
   }

}

ifvarg mantling 0
{
   
   ifvare mantling 1 // hanging there, possibly strafing
   {
      setplayer[THISACTOR].falling_counter 0
      getplayer[THISACTOR].posxv xvel
      divvar xvel 2
      setplayer[THISACTOR].posxv xvel
      getplayer[THISACTOR].posyv yvel
      divvar yvel 2
      setplayer[THISACTOR].posyv yvel
      setplayer[THISACTOR].posz mantz
      setplayer[THISACTOR].poszv 0
      state checkwall   
   }
   else
   {
      setplayer[THISACTOR].poszv -1024
      getplayer[THISACTOR].ang angvar
      cos xvel angvar
        sin yvel angvar
        mulvar xvel 64
        mulvar yvel 64
      setplayer[THISACTOR].posxv xvel
      setplayer[THISACTOR].posyv yvel
      getactor[THISACTOR].z z
      getactor[THISACTOR].x x
      getactor[THISACTOR].y y
      getactor[THISACTOR].sectnum mysector
      getactor[THISACTOR].ang angvar
      setvar zdist 0
      cos mycos angvar
      sin mysin angvar
      hitscan x y z mysector mycos mysin zdist hitsector hitwall hitsprite hitx hity hitz clipmask
      state pythagoras
      ifvarg xydist 384 setvar mantling -10
      addvar mantling 1
      ifvarg mantling 30 setvar mantling -10
   }
   
}

ends

The jist of the mantling code for Duke Plus in the CON language. Just incase you understand it and could get some ideas that way.

[Matt]

bleh.

Yeah, I'm pretty sure ACS doesn't provide for anything remotely like that, even if I wanted to use it instead of DECORATE.

I'll give it some more thought later.

[Ryan Cordell]

We'll see if Isle, LWM or Solar, possibly Waxy (Anyone else I'm missing? ), could provide a good ACS-ey way. XP

[Matt]

I should clarify now, though, that I'm actually trying to avoid ACS since I'd much rather keep the number of used scripts to a minimum.

Anyway, happy Saint Cyril's Day everyone!

New update:

- babuin now uses demon graphics
- restored playerclasses now that the desync bug's been fixed
- smoother pain effects

EDIT: Fixed a bug that wasn't apparent while Assault was the only class available.

[Scorch]

Didn't working on 1.0.30 and 32 -

Script error, "dcplayer" line 14:
"player.damagescreencolor" is an unknown actor property

On 1.1.02 -

Script error, "dcfunctn" line 142:
Too few arguments to acs_executealways

On Z 2.2.0 all working normally.

[Juan "JacKThERiPPeR]

Same here with 2.2.0 r841. The error:
Script error: "dcfunctn" on line 142:
Too few arguments for acs_executealways

EDIT: Fixed with adding a second argument with value 0 in each acs_executealways, which corresponds to the map of the script.

[Matt]

EDIT: Fixed with adding a second argument with value 0 in each acs_executealways, which corresponds to the map of the script.

Oops, I fixed this back in April and never uploaded it... anyway, it should be fixed now.

Anyway, this updates just gets rid of some spaghetti code now that A_SpawnItemEx lets you inherit ambush flags.

Also confirming that yes HD does work as intended on multiplayer, though it is a bit slow.

Say, does anyone else get occasional 30-second-ish freezes when playing this with the newer subversions (around 900ish)? I've noticed this for both HD and a couple other wads...

[Unknown_Assassin]

Say, does anyone else get occasional 30-second-ish freezes when playing this with the newer subversions (around 900ish)? I've noticed this for both HD and a couple other wads...

For me, I sometimes get a 1 second freeze. I haven't experienced any freeze longer than 1 second.

Also, there is a little annoyance I find with this wad (I never noticed this during the previous version, either that or I don't have a very good memory). Whenever you move forward you look up gradually. The BFG might make some sense...I guess, but with a fist?

[Matt]

Also, there is a little annoyance I find with this wad (I never noticed this during the previous version, either that or I don't have a very good memory). Whenever you move forward you look up gradually. The BFG might make some sense...I guess, but with a fist?

o_O

.......huh.

That is so weird.

I'll have to take a closer look at this later...

EDIT: Erm, whoops, what I saw turned out to be a perspective effect.

Does this upward drift only happen with certain weapons? Does it happen whether the player is hurt or not?
There should be a slight sideways wobbling when you move. (I might take this out for when the player is at perfect health.)
When you're hurt, your view should be bobbing while standing still and jerking a bit when you move.

[enigma.rain]

This mod is great. After playing mod after mod of "Blow Sh*t Up and Find the Exit" type gameplay, this provides a great new challenge.

I do think that somethings could be a little bit different.
Firstly, movement speed for Doomguy is good, but having almost all of the enemies like 20x faster than him just doesn't feel right. For monsters like Imps and Demons (can't remember your names at the moment) it fits, but to have the human-esque monsters move so incredibly fast is unfair and panick inducing.
Weapons are awesome, but I think it would be awesome with new sprites, if you could find someone good at that to help. Same with monsters. I'd suggest adding a sidearm (a decent pistol) for emergencies. When you're holed up taking on a horde of demons, you tend to run low on ammo, and an extra gun could help the situation.

Also, whenever I die, GZDoom has a "Very Fatal Error" Saying something about trying to write to address 0000000. Not sure what that's about.

[Unknown_Assassin]

Does this upward drift only happen with certain weapons? Does it happen whether the player is hurt or not?
There should be a slight sideways wobbling when you move. (I might take this out for when the player is at perfect health.)
When you're hurt, your view should be bobbing while standing still and jerking a bit when you move.

No, it happens with all weapons. Everytime you move back and forth, even at 100% health, you still look up for every movement.

[Matt]

Oh hey, there is a newer version of GZDoom that fixes the fmodex thing. ::downloads::

...yeah, I have no idea what causes that crash - HD's had crash problems with GZDoom for ages to varying degrees of severity. Doesn't seem to happen all the time, though, and ZDoom works just fine.

Do the zombies really seem that fast? They should be slower than the vanilla Doom 2 archvile (which admittedly is pretty damn fast), but given I can't make anything take cover or pin a target with suppressive fire there's not much else I could do to make them harder to kill. (I'd really rather avoid giving them more hitpoints, which just makes it aggravating when you eventually do get a good shot at someone.)

I'll give a thought to adding a sidearm. I've avoided it on purpose thus far because I felt that the rifle was enough... but after getting hosed a few times for starting on a zombieless map with a big weapon and no CQB capability I'm starting to reconsider.

No, it happens with all weapons. Everytime you move back and forth, even at 100% health, you still look up for every movement.

Sorry, I just don't see it. A friend I tried this mod with complained that the movement was "jumpy" somehow and this might be related. Could you post a video or something so I can see what you're referring to?

I'm trying this on Map12, looking at the corner of the raised tan area and then moving back and forth with the keyboard, trying both r908 (latest SVN available on the Sourceforge site) and GZDoom 1.1.4. No change in pitch.