How to make Dehacked shootable fireballs?

[CaptainManiac]

Uhm,hi.I installed dehacked and tried to make the fireballs of Imps,Barons and Mancubuses to be shootable,since they are visible and big(my idea was inspired my the fireballs of some Serious Sam monster fireballs.I have added the shootable flag and reduced the hit points to make them shootable with bullet,but they still cannot be hit by bullets.Where was my mistake?

[scifista42]

Since I'm not aware of any wads with working shootable projectiles, and since my own elaborate attempts to create them failed, I'm pretty sure that it's not possible to make shootable projectiles in DEHACKED, at least not without game-breaking side effects such as that the projectiles would noclip through things instead of hitting them, or that they would occasionally stay motion-less in the place where they were fired, or something else.

The most promising method seems to be modifying the Lost Soul into a sort of projectile and using Pain Elemental's attack function to fire it, but I wasn't able to get that one working without side effects either. Even if it worked, this would give you only one type of a shootable projectile, and at the cost of sacrificing Lost Soul and PE.

[CaptainManiac]

I did it.The Noblockmap was the reason.And i made them with 3 hit points to be easy.After shooting the firaballs they die with they death animation and the side effects are not commited.Tested them on Vanilla Doom.I am not sure if they will work with mods.

[BigDickBzzrak]

https://www.doomworld.com/vb/doom-editing/90745-help-me-make-a-destroyable-fireball-in-deh/

I made a thread about it like half a week ago.
I could do that with Imp fireballs, but not with Mancubus ones. Dunno about Baron.

[CaptainManiac]

Scifista,you were right about the side effects.On the Mancubus ball there is a funny effect of a self destructing projectile/The Fireballs self-destruct after being shot.Yes,that is for laughter,but i will fix this.I think i know what is the reason

Imp and Baron balls can be made with lowered hitpoints,but i see the Mancubus,s fireball problem.I will try to increase their hit points

[scifista42]

Wow, it works better than I thought it could. The only side effects are that the "dead" fireball still deals damage to whatever it hits, and that fireballs now hit each other mid-flight. I can't get the "stuck in place" bug that I clearly remember from my previous attempts anymore. Looks like I was wrong.

The Mancubus fireballs simply hit each other, because Mancubus fires 2 at once, that's the problem. I don't think increasing their hit points would help it.

[CaptainManiac]

brrzak you need to modify the imp fireball too if you want it to be shootable,not only the imp

[scifista42]

Aaaaah, I've found another very bad side effect, this time with Arachnotrons or any rapid-fire projectile monsters: If a fireball is destroyed close to the monster, the next fireball behind it will hit it and be destroyed, and the one behind it too, and the monster will infinitely keep firing projectiles that immediately get destroyed and stay in place harmlessly.

[CaptainManiac]

Mancubus fireballs are one with middle fire rate and changing radius and hit points will partially fix this.With my BEX patch the Mancubus fireballs will need to be destroyed with rapid fire weapon and most of the fireballs will self destruct

[Fonze]

Would it be possible to give the self-destroying projectiles more health? So they hit each other and then wind up at the intended health. Might help the manc, probably not the arach though.

[scifista42]

It won't help, because when the projectile itself hits something, it will always enter death state instantly, regardless of its current health. Only when the projectile is shot by something else, its health will decrease and the projectile will enter death state only if its health decreased to zero or below.

[CaptainManiac]

I will remove the dehacked mancubus fireball,because it is really screwed up.Fortunately,Revenant's fireball does not give shit

[Fonze]

scifista42 said:

It won't help, because when the projectile itself hits something, it will always enter death state instantly, regardless of its current health. Only when the projectile is shot by something else, its health will decrease and the projectile will enter death state only if its health decreased to zero or below.

Ah, I misunderstood the purpose of changing the health... So in effect, only hitscans (or possibly non-physical projectiles? Assuming such a hack could be done) can decrease its health and "kill" it into its death state. Neat stuff; I'm interested to see how this pans out and what future ideas will come of it.

[scifista42]

Fonze said:

So in effect, only hitscans (or possibly non-physical projectiles? Assuming such a hack could be done) can decrease its health and "kill" it into its death state.

Anything that can deal damage to monsters - hitscans, projectiles (no matter if normal or shootable ones, no matter if of the same or of a different type), barrel/rocket splash damage, and potentially even melee attacks - would hurt the shootable projectile upon hitting it.

[Fonze]

I'm sorry, I might have been splitting hairs a bit, but I was referring solely to decreasing its health, as I try to wrap my head fully around the concept. Wouldn't a player's projectile act the same as, say, that double-manc projectile and cause a collision which would automatically send the monster's projectile straight into its death state regardless of health? If so, then the only real way to decrease the projectiles health would have to be something which doesn't also kill it immediately, though I understand that is the goal which makes this a moot point anyway.

[CaptainManiac]

Scifista,you are right,i used chainsaw againist the shootable fireballs and they exploded without hurting me

[scifista42]

Fonze said:

I was referring solely to decreasing its health,

Hurt = decrease health.

Fonze said:

Wouldn't a player's projectile act the same as, say, that double-manc projectile and cause a collision

Collision with what, and when? The 2 manc projectiles collide with each other because both of them spawn in the same place at the same time.

Fonze said:

which would automatically send the monster's projectile straight into its death state regardless of health?

When 2 projectiles hit each other, there's always one of them which hit the other one first, because the engine processes things sequentially. However, as long as an object is shootable and has a positive health, it can be hit by attacks and possibly die by them, even if the object is already in its death state, because it's a shootable projectile that impacted, but still has positive health.

For example, imagine 2 shootable projectiles (A and B) heading straight against each other. Projectile A impacts onto projectile B. Projectile A doesn't lose any health, but stops moving and enters death state anyway, because that's what projectiles normally do when they impact on something. On the other hand, projectile B loses health (if it loses all its health, it enters death state, if not, then not) and continues moving - and immediately impacts onto projectile A, which still has positive health, even though it's already in its death state. This makes projectile B stop moving and enter death state too, whereas projectile A loses health (if it loses all its health, it enters death state AGAIN, if not, then not), and that's the end of it.

[Fonze]

scifista42 said:

When 2 projectiles hit each other, there's always one of them which hit the other one first, because the engine processes things sequentially. However, as long as an object is shootable and has a positive health, it can be hit by attacks and possibly die by them, even if the object is already in its death state, because it's a shootable projectile that impacted, but still has positive health.

For example, imagine 2 shootable projectiles (A and B) heading straight against each other. Projectile A impacts onto projectile B. Projectile A doesn't lose any health, but stops moving and enters death state anyway, because that's what projectiles normally do when they impact on something. On the other hand, projectile B loses health (if it loses all its health, it enters death state, if not, then not) and continues moving - and immediately impacts onto projectile A, which still has positive health, even though it's already in its death state. This makes projectile B stop moving and enter death state too, whereas projectile A loses health (if it loses all its health, it enters death state AGAIN, if not, then not), and that's the end of it.

Ah okay, this answers what I was wondering about; thank you. Tbh, I had forgotten everything is sequentially figured in Doom's engine (most comp programs, I suppose), so that makes sense that one would "hit" the other first, rather than both "hitting" each other simultaneously. I'm mostly just trying to find out the point of changing the projectile's health, if it matters for projectiles or only hitscans (which I understand now), as well as getting to the eventual questions of "what if both (collision and health)?" and "how would that affect a potential target adjacent to the blast?" So with this, a single projectile could actually experience two deaths (in the right situation).

This is totally off-topic and probably pointless, but to take that a step further, would I be correct to assume that both of those deaths for one projectile would be processed and handled the same, but in tandem? So for example if I fired a rocket and a projectile-based enemy also fired, assuming that both my rocket and this enemy's projectiles are affected by this, could that actually lead to a double-explosion of my rocket, splash damage and all?

[scifista42]

Fonze said:

could that actually lead to a double-explosion of my rocket, splash damage and all?

Yes. Actually, if the rocket impacted while still having positive health (that is, normally, not by being shot/hit by something), its own explosion would always hurt it and (assuming it had low-enough health) it'd die and explode once again.

[Fonze]

scifista42 said:

Yes. Actually, if the rocket impacted while still having positive health (that is, normally, not by being shot/hit by something), its own explosion would always hurt it and (assuming it had low-enough health) it'd die and explode once again.

Wow that's an interesting twist, hehe. I'll have to keep my eye out for progress on this things development; it'll be cool to see how this shapes into a final product. With any luck, some time in the future perhaps somebody will have a great idea and expand upon it.

[scifista42]

There's no development here, it's literally just 2 flags flipped on each projectile thing type, which is all that DEHACKED can do about projectile's shootability, and accepting the resulted behavior with its side effects as they happen to be.

[Fonze]

Ah, I see, I figured there were still a few more . Interesting stuff still; always cool to see vanilla gameplay mods. Will have to check this out later on.

[xttl]

A long time ago I remember playing with this. It was not hard to make rockets shootable (I think it was only a single bit flag that had to be changed), but even though it worked for a while it always caused the game to crash or hang sooner or later.

Here's something from the old DHE Grabbag textfile (included as grabbag.txt in spcial12.zip from archives):

13. Why can't I...
==================

...Shoot rockets in flight?

"But the Fun With DeHackEd file says..." Forget it. It can't be done. Not
properly, anyway. If you turn off bit 4 as required, you'll have a major bug
and the game will crash. Turning off bit 4 is the surest way I know of (now
that code pointers are relatively stable) to crash the game.

Also possibly related:

...Make imps shoot health potions?

Again, this would have been a nice patch, one that I tried to do myself. But
alas, the gettable thing bit is not quite to blame this time: Bit 4
(automatics/can't be hit) is the culprit. It must be turned on for items such
as fireballs- otherwise the game locks up. This bit will prevent you from
picking up a fireball, even if its first normal and death frames are changed to
816 (health potion) and bit 0 (gettable thing) is set. So, you'll just have to
change regular inanimate objects into health potions instead.

The related bug/limitation might not actually affect more advanced engines than vanilla of course.

EDIT: To add something more from antoher old textfile, dhefun12.txt:

[---]   UNDESIRED EFFECTS
[y.5]   It was noted that the exploding rockets trick sometimes caused 
	doom to lock up.  Note that bit#4 must be No.  I set my plasma
	bullets' bit#4=N, and doom hung up on me.  Could this be a coincidence
	or the culprit ??  Perhaps the explosion and puff overlap & lock
	up ??

I also just tested this in vanilla and chocolate-doom: to make any projectile shootable, just clear bit 4 and set bit 2, however the game will lock up at some point. With rockets it can take a little while (but will eventually happen), with plasma you get to see it much quicker (due to rapid fire). It is also a hang, not a crash -- not even in chocolate. Music and sounds will keep playing. I guess the code gets stuck in a loop somewhere for whatever reason. And yeah, explosions and puffs have nothing to do with it.

PrBoom+ -complevel 2 works ok though.