[still present in r3568] Incorrect pain conditions

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: [still present in r3568] Incorrect pain conditions

Re: [still present in r3568] Incorrect pain conditions

by Enjay » Sun Apr 29, 2012 8:52 am

My apologies. I was thinking about action specials.

Re: [still present in r3568] Incorrect pain conditions

by Gez » Sun Apr 29, 2012 8:41 am

Since when can ACS features be called in DECORATE? If you are referring to [wiki]action specials[/wiki], then they aren't an ACS thing. They are "global" functions that can be called from the map itself (thing or line specials), from ACS, from DECORATE, from the [wiki]console[/wiki], and even from [wiki]FraggleScript[/wiki].

In all other cases, when a function exists in both ACS and DECORATE, it's explicitly said so. Cf. [wiki]ACS_NamedExecute[/wiki].

For another example, you can use [wiki]Radius_Quake[/wiki] in DECORATE because it is a special, but not [wiki]Radius_Quake2[/wiki] because it's an ACS function; instead you have the DECORATE function [wiki]A_Quake[/wiki].

Re: [still present in r3568] Incorrect pain conditions

by Enjay » Sun Apr 29, 2012 7:55 am

Gez wrote:Well, [wiki]SetActorState[/wiki] is an ACS function.
Can it not be used in decorate like some other ACS features can?

Re: [still present in r3568] Incorrect pain conditions

by Gez » Sun Apr 29, 2012 7:39 am

Well, [wiki]SetActorState[/wiki] is an ACS function. But you could have some [wiki]named script[/wiki] and have the item run [wiki]CallACS[/wiki]. That would probably work.

Re: [still present in r3568] Incorrect pain conditions

by Enjay » Sun Apr 29, 2012 7:22 am

Gez wrote:However, you can't use an A_Jump or Goto in the custom inventory Use code since it will not actually change the actor's state.
Thinking aloud here, would it be possible to create an inventory item that had [wiki]SetActorState[/wiki] in its decorate definition to send an actor into its pain state and, if so, would setting the tid argument to 0 mean that the inventory item would affect itself or the actor that had the item in its inventory?

Re: [still present in r3568] Incorrect pain conditions

by Enjay » Sun Apr 29, 2012 7:13 am

Gez wrote:Don't give it a pain state?
Which would mean that it wouldn't be able to ever to go into a pain state - from any damage source. The kind of situation that I am thinking about where +foilforcepain would be useful is a missile that always puts lesser enemies into the pain state (and thereby buys the player a bit of time) but it doesn't have the same effect on a boss/much tougher enemy. However, that enemy should still have the possibility of occasionally going in to a pain state from most attack so removing its pain state would not be appropriate.
Gez wrote:Force pain should force pain. Finer-tuned controls should be done with damage-specific pain chances.
Agreed, but, for my sonic effect, that takes us back to having to edit every monster in the game to be very susceptible to the sonic pain and one actor to not be. Having to change the code for every single actor just to make one of them behave differently seems inefficient to me.

I had considered the "give them an inventory item and use A_Jump" method but, as you said, that would involve updating a ton of actors.

And thanks for that code snippet. All those conditions and sub conditions do illustrate the complexity of the relevant code.

Re: [still present in r3568] Incorrect pain conditions

by Gez » Sun Apr 29, 2012 6:57 am

Enjay wrote:I take your arms race point but all I'm saying is that there is now no way for any actor to be excluded from the effects of a forcepain missile and it feels to me like there should be.
Don't give it a pain state? Force pain should force pain. Finer-tuned controls should be done with damage-specific pain chances.
Enjay wrote:Presumably the A_RadiusGive idea would be to define an inventory item that puts any actor that has it into their pain state (how would such an item look? - can monsters have inventory items activate in their own inventory?) and then have another actor (in my case the sonic grenade) repeatedly give out the inventory item to any actor within the specified range, using the RGF_MONSTERS flag?
In the broad lines, yeah. You can give CustomInventory items to monsters and they will perform the actions there. However, you can't use an A_Jump or Goto in the custom inventory Use code since it will not actually change the actor's state. If I were coding the sonic grenade effect from scratch, I'd probably use some sort of timed powerup, like maybe PowerIronFeet which won't affect the monster otherwise. Then have in the monster's states A_JumpIfInventory checks for the presence of that token powerup.

Though I understand not wanting to update a ton of already-existing actors with rewritten sonic grenade code. It's just that I don't see a 100% satisfying way to solve your problem. Piling up new complexity to the already nigh-incomprehensible pain code doesn't appeal to me.
Spoiler:
Argh! Can you follow that code?

Re: [still present in r3568] Incorrect pain conditions

by Enjay » Sun Apr 29, 2012 6:35 am

I take your arms race point but all I'm saying is that there is now no way for any actor to be excluded from the effects of a forcepain missile and it feels to me like there should be.

Presumably the A_RadiusGive idea would be to define an inventory item that puts any actor that has it into their pain state (how would such an item look? - can monsters have inventory items activate in their own inventory?) and then have another actor (in my case the sonic grenade) repeatedly give out the inventory item to any actor within the specified range, using the RGF_MONSTERS flag?

Re: [still present in r3568] Incorrect pain conditions

by Gez » Sun Apr 29, 2012 6:19 am

The problem here is that we get an arms' race.

+NOPAIN -> +FORCEPAIN -> +FOILFORCEPAIN -> +FORCEPAINDESPITEFOILFORCEPAIN -> +NOIREALLYMEANNOPAINATALLNOTEVENWITHFORCEPAINDESPITEFOILFORCEPAIN -> +SUDOFORCEPAINSLASHYESTOALL -> +NANANANOTLISTENINGANDNOTPAINED -> ...

All that for unreliable and glitchy pain hacks. Pretty much what motivated [wiki]A_RadiusGive[/wiki] to come into being.

Re: [still present in r3568] Incorrect pain conditions

by Enjay » Sun Apr 29, 2012 6:12 am

Graf Zahl wrote:Anyway, the proper fix in your case should be to give the player a custom painchance of 0 for the specific damage type and not rely on hacks that he doesn't get subjected to anything uncontrollable.
I haven't actually tried that because when read the Wiki, it said:
The Wiki painchance entry wrote:Sources of damage that have the FORCEPAIN flag ignore this property.
So I figured it wouldn't work. In fact, I had a few ideas that I was going to try but every idea that I had, according to the Wiki, would not work because +forcepain would override the setting that I was planning on using. That's why I suggested a way to ignore +forcepain because, as far as I can tell, there is no longer any method by which an actor can be made immune to a +forcepain attack. I would imagine that boss actors and other enemies that are supposed to be tough for whatever reason could really do with such an ability.

For my particular situation, I suppose that I could create a silent custom pain state for the player but that's not ideal (and I'm guessing wouldn't suit all mods) so I do feel that there should be a better way of making an actor able to ignore a +forcepain attack somehow.

Re: [still present in r3568] Incorrect pain conditions

by Graf Zahl » Sun Apr 29, 2012 5:31 am

... and here we have the proof why I think that the entire pain/damage system should not be tinkered with - just because some person thinks it doesn't work like they want to.

Tell me what you want, but I think it's stupid to make the damaged actor feel pain if all the damage gets protected away. IMO this particular change should be reverted and 0-damage to cause pain only be allowed when it comes from ripping projectiles - because those have been handling it incorrectly forever.

Anyway, the proper fix in your case should be to give the player a custom painchance of 0 for the specific damage type and not rely on hacks that he doesn't get subjected to anything uncontrollable.

Re: [still present in r3568] Incorrect pain conditions

by Enjay » Sun Apr 29, 2012 4:10 am

Aaaand, I have found something in one of my projects that gets a (minor) break from this. In my Burghead mod there are sonic grenades that spew out invisible zero damage +forcepain projectiles in all directions for about 30 seconds. Any actor coming within the range of these projectiles is put in to their pain state so frequently that they are effectively immobilised. However, I didn't want the player to be constantly yelling in pain when he was near his own sonic grenades so I gave the projectiles a custom damage type and set the player to be immune to this kind of damage. It worked and the player didn't yell in pain when he was near the sonic grenade effect. Now he does. OK, it's only a minor aesthetic point and I'm not that bothered by it, but it's there.

I know that I could fix it by removing +forcepain from the projectiles and then giving every monster a very high susceptibility to sonic damage and the player very low susceptibility. However, editing every enemy just to make one actor (the player) behave differently does seem to be the wrong way around.

What I would suggest then is something like the +foilinvul flag but for +forcepain (+foilforcepain ?). I don't know if flags can work this way but being able to set this flag for different damage types would be even better. That way an actor could be immune to one type of forcepain missile but not any others that may exist.

Anyway, such a flag would be a much better solution to my (minor) problem. Instead of editing the projectile and every enemy in the game, I could just give the player the +foilforcepain flag and be done with it. Any chance?

Re: [still present in r3568] Incorrect pain conditions

by NeuralStunner » Sun Apr 15, 2012 5:07 pm

I would agree, though the occasional older mod might get stuck with non-functional features because of it. Might be wise to include some sort of compat flag...

Re: [still present in r3568] Incorrect pain conditions

by Enjay » Sun Apr 15, 2012 4:51 pm

I've done a bit of digging around and I think I may have been remembering the discussion incorrectly. Both The Ultimate Doomer and myself had used 0 damage projectiles: TUD to force specific pain states and I used ripping projectiles (which caused pain states with 0 damage even though other projectiles did not) to force any actor into its pain state regardless of damage type. There may be other instances of it too. In fact, I'm sure that there was. However, the threads I found seem to indicate that the discussions did not turn out as I remembered them and the upshot of them was that such situations should have the +FORCEPAIN flag used.

This last post by Randy in one of the following threads is interesting however:
randy wrote:
Enjay wrote:From memory, being struck by a 0 damage projectile did not cause pain states.
Referencing the original id Source, it should. I probably introduced this bug myself when I made negative missile damage do healing.
http://forum.zdoom.org/viewtopic.php?f=7&t=23981

http://forum.zdoom.org/viewtopic.php?f=2&t=23982

I'm sure it was discussed elsewhere but that's all I'm coming up with ATM.

However, for all instances that I have just tried without FORCEPAIN, pain states were not caused by 0 damage attacks.

At one point, the "MonsterRail" BEX pointer could be given to enemies, set for 0 damage and still cause pain states. I'm absolutely certain of that. [edit] I just checked - it did way back in ZDoom 1.23 but doesn't any more.

Code: Select all

#BEX

[CODEPTR]

FRAME 185 = MonsterRail
[/edit]

I don't know if other 0 damage hitscan attacks could cause pain states in the past (I'm pretty sure they could) but I just tried a 0 damage custom hitscan attack fired by ZombieMen and they did not cause pain in each other or me, even though they are hitting each other many times with the attack that I defined.

So, to revise my earlier statement, I think that FDARI's desired "cleanest" behaviour of 0 damage attacks not causing pain unless they have the FORCEPAIN flag is how things seem to be working ATM and it is probably how it is meant to be working too.

Top