Hideous Destructor 4.10.0b

[Eric_]

The latest commit fixes the injector problems. They weren't autoswitching at all, and would even be auto-used if you held fire past the first injection, even though that's certain death whether it's stims or zerk.

[hideousdestructor]

I've added an extra "caller.player.mo==caller" check for these medikit messages and a few others which hopefully should address any further voodoo doll problems.

On that note: how many people actually use hd_helptext anyway? It's always been an arbitrary judgment call for me what is or isn't baseline necessary enough to skip the check and always show up, and I always leave it to show everything anyway, so I really have no idea what's good or not about the current setup.

[Eric_]

New problem with injectors: if you inject, then immediately switch to a gun, the auto-switch still kicks in and forces you back to fists.

[ASO3000]

Cheers Matt,

I'm currently trying to make remote detonators for the doorbusters and ieds. The items themselves work, but I just can't wrap my head around how to access the currently deployed devices' tags and then give a command to them.
Sorry if this is the wrong thread, I'm not really a regular and thought I'd just ask th' main man right away.

[hideousdestructor]

I'm currently trying to make remote detonators for the doorbusters and ieds. The items themselves work, but I just can't wrap my head around how to access the currently deployed devices' tags and then give a command to them.

You need some way to do 3 things:

1. Input the tag number.
2. Input the command.
3. Run an iterator looking for all relevant actors on the map, and for each one check the tag number and if it matches check the command and have the actor respond accordingly.

Here's where the commands are located. If you don't need console input, though, frankly it's actually easier to do everything in the weapon interface itself.

[Eric_]

Now the injector discard sound cuts off the player skin's medical sound.

Here's a bigger problem, though: enemies will completely ignore new and available targets in favor of their first acquired one even if they cannot see or reach it. This gets to a real extreme in co-op, where one player can just casually walk through and mow down every enemy with minimal resistance because they're all sitting around waiting for the player they've targeted to show up and won't react unless provoked.

[hideousdestructor]

The targeting thing is not a new problem though, right? IIRC that's also how it works in vanilla - and the last time I looked at it I didn't really have any good solution so I just left it alone.

If it was different previously I'd like to know so that flexibility can be re-implemented.

[Eric_]

Yeah, it's pretty old, I was able to go as far back as 4.5.0a and replicate it. It doesn't appear to be a vanilla behavior, though. The enemies in vanilla (or at least GZDoom's idea of vanilla)(edit: confirmed in Crispy Doom) correctly prioritize the target before their eyes over the one they heard but cannot see. I also found this to be the case going much further back to a 2015 build of HD. The enemies would wander around only for a moment before re-targeting. Since it's so old in HD and default behavior in GZDoom, I would hazard a guess that it's some inherent behavior of A_Chase that didn't make it over to HD's reimplementation?

[Abba Zabba]

Could this targetting revamp take scan turn into account, or at least give it a random timer before they wander? I know I've been a broken record on this but it hasn't been addressed, it flat out breaks many chaingunner teleport traps that occur later on in some maps.

[Caligari87]

Regarding the notes on commit ab0dd14:

Now when you use the inventory actor it turns into the weapon interface, and when you put away or throw away the weapon interface it turns into the inventory actor (or discarded spent injector actor).

On further reflection I could have turned the entire thing into its own weapon...

That's just what I've done with various UaS items like the trauma kit and laser sight. They live on the inventory bar and can be used like normal inventory items, can present a weapon-style interface if desired, and even have out-of-band effects when the object isn't selected. All done entirely without states too (because I hate state handling).

It's seems the current separation of injectors into the inventory object and the weapon interface probably stems from some pre-ZScript limitations?

[ASO3000]

...

At last I truly see. This has helped me a lot, thanks! Now I only have to make nice sprites lol.

[Eric_]

Had a strange incident with the Mancubus melee attack. Is it missing a Z check? I wouldn't expect it to hit me that hard from that far. I wouldn't expect the Manc to even attempt to melee from that range, but it seems like the previous issue where enemies would use their melee attack when first spotting you hasn't been fully resolved.

[hideousdestructor]

Had a strange incident with the Mancubus melee attack. Is it missing a Z check? I wouldn't expect it to hit me that hard from that far. I wouldn't expect the Manc to even attempt to melee from that range, but it seems like the previous issue where enemies would use their melee attack when first spotting you hasn't been fully resolved.

It is in fact missing a Z check, on top of BlockThingsIterator often catching things that seem to me to be far beyond the iterator's stated radius.

Also it turns out the mancubus isn't giving enough time for the target to be launched into safe shooting distance before checking melee range again, meaning that it always melees twice. This has been fixed (and an oversight in A_Watch addressed).

It's seems the current separation of injectors into the inventory object and the weapon interface probably stems from some pre-ZScript limitations?

I was going to do this with the healing potions, and then I realized that this would prevent me from using the Use+Use combo to cycle through bottles of varying fulness. As for the stims, it seems awfully wasteful to use an entire spareweapons array for a bunch of very simple single-use items.

I think I'll leave things as they are for now.

[Somagu]

I believe this is probably the thing Abba Zabba has been talking about for a while.

[hideousdestructor]

I believe this is probably the thing Abba Zabba has been talking about for a while.

Is that still happening in the current dev? I can't see any state where it could get permanently stuck like that (unless it's targeting something else) but I've added one more check.