[Beta][Cool] \m/ ~={ DEMONSTEELE }=~ \m/ - 0.9 desu~

[wildweasel]

is there any way to switch the fires (mouse 1 being shoot and mouse 2 being swing) without remapping the keys for primary and secondary fire?

You're probably going to have to do the workaround; setting up a trigger-flip is not a trivial thing to do, especially not to two entire arsenals and the input handler for special moves.

[SiFi270]

In GZDoom 3.7.0 and 3.7.1, things like torches can no longer be destroyed, but attacking them constantly lets your combo meter build up all the way from fearless to slayer. Do you think it's worth releasing a small update just for that and also the fact that the max amount of armor tokens seems to have been 3 instead of 4 for a while? I probably should have mentioned the latter sooner but I'd somehow convinced myself that someone else already had. (and maybe they did)

[TerminusEst13]

I don't have a copy of 3.7.0 or 3.7.1 and can't update from 3.4.1, so any glitches that pop up for recent builds I'm not going to be able to verify and/or fix.
It looks like DemonSteele's starting to break apart at the seams in 3.7.1, unfortunately, since that's not the only issue. But I'm not going to be able to really do anything about it.

Sorry.

[Zhs2]

FWIW that particular issue in the video has been encountered elsewhere recently.

[fakemai]

Just chiming in to say that this is wildly inconsistent. Punches work, lightsaber doesn't but without building combo, sword builds combo without hitting, and it seems most other weapons don't destroy torches. This is true with the JIT or without.

[phantombeta]

For a bit of context, the thing in that video is because you're calling action specials when the weapon has been taken away - this used to work, but between 3.6 and 3.7 it started causing crashes, so that VM abort was added.
As for the torches thing, that's actually fixed in the latest master, and will be working in the latest release. I imagine that issue was due to a bug with the NODAMAGE flag introduced when Major Cooke refactored DamageMobj to make it not awful to change. These bugs weren't caught in the dev builds*, unfortunately, but Major Cooke already fixed them.

* (probably because people took Graf's warning not to release mods for devbuilds to mean "don't use dev builds ever again")

[SiFi270]

Everything seems to be back to normal, but are two monsters of the same type supposed to infight? If so, I feel like a dummy for not noticing before.

[john190]

I am getting a weird error when I pick shinong bfg replacment.
Any ideas?

[wildweasel]

I am getting a weird error when I pick shinong bfg replacment.
Any ideas?

What is the error?

[john190]

I am getting a weird error when I pick shinong bfg replacment.
Any ideas?

What is the error?

VM EXECUTION ABORTED: 02VIPER. STATEFUNCTION. 267 CALLED WITHOUT VALID CALLER 02VIPER EXPECTED

[Captain J]

*ERROR - FALSE WARNING DETECTED. DOES NOT COMPUTE: AWAITING CLEAR SOLUTIONS*

... Or is this really the error message appeared on the Console?

[wildweasel]

It'd be appreciated if you could take a screenshot of the error instead, so that it can be seen exactly as it appears, instead of a loose transcript. Better yet if you can figure out how to reproduce the crash.

[Somagu]

This is a bug I was working earlier last month to fix locally on my copies of mods. Effectively, doing anything with a weapon on the same tic that it gets taken away causes a vm abort, but adding an actionless 1-line bit immediately after taking the weapon fixes it, among some other methods. Although I'm sure this isn't the correct way of fixing this, it works.

With Term's permission, I have a fixed version to post here.

There's two main changes here. The first changes the a_weaponready at the end of the Mastodon change state of each of Shihong's weapons into a simple display-only state, which fixes the VM abort without changing anything else.
The second change simply changes the improperly defined menu stuff into one that's compliant with the proper way of doing things. This is mostly a carryover from a certain period of GZDoom versions, where it would simply refuse to show the new option menus at all if they were defined this way. GZDoom can detect the new menus now without this fix, but it's a harmless change, so I've included it anyway.

A few other mods had this same abort, but I've worked where I can with the authors to fix them for actual releases.

[john190]

This is a bug I was working earlier last month to fix locally on my copies of mods. Effectively, doing anything with a weapon on the same tic that it gets taken away causes a vm abort, but adding an actionless 1-line bit immediately after taking the weapon fixes it, among some other methods. Although I'm sure this isn't the correct way of fixing this, it works.

With Term's permission, I have a fixed version to post here.

There's two main changes here. The first changes the a_weaponready at the end of the Mastodon change state of each of Shihong's weapons into a simple display-only state, which fixes the VM abort without changing anything else.
The second change simply changes the improperly defined menu stuff into one that's compliant with the proper way of doing things. This is mostly a carryover from a certain period of GZDoom versions, where it would simply refuse to show the new option menus at all if they were defined this way. GZDoom can detect the new menus now without this fix, but it's a harmless change, so I've included it anyway.

A few other mods had this same abort, but I've worked where I can with the authors to fix them for actual releases.

Found another. This was on the fixed version and it happened while de-equiping the bfg replacment.
[imgur]https://imgur.com/a/FJGK9rE[/imgur]

[Somagu]

Oops. I see exactly what I left out, I must have forgotten to re-fix that one after getting Term's permission. Sorry, I'll get to it as soon as I can.

[edit]Here's a fixed version. Terribly sorry about that. Please let me know if you spot any other crashes.