It's almost done. Except its sticky bomb (a.k.a grenade). Sticky bomb cannot always stick to the monster it hits. On flight path some other monsters can dodge it.
When the grenade hits something then it spawns another actor - "Stuck Bomb". Stuck Bomb on its spawn executes the script which checks what is the target of the grenade
thrower. If the target is within appropriate range from the grenade then the grenade is set onto that actor. The target actor carries it for approximately 3.5 seconds
(122 tics) and then explodes. But if Sticky bomb does not hit any player or monster then stuck bomb remains where grenade hits. It can be floor, wall, ceilings.
Then stuck bomb waits for any player to be within its explosion range (150 pixels) and then detonates. To see whole sticky bomb performance in ZD watch this:
https://www.youtube.com/watch?v=hpKgw988o-Y
In most cases the greande works as it should and sticks to various targets. But sometimes the grenade fails to reach it and hits something in-between. It can hit any other
monster in its path to target and spawn "Stuck Bomb" which doesn't stick anywhere because the activator of the script is outside the range. This can be seen for example in
2:30-2:50 time interval of the video. The grenade behaves like it would be on the floor.
The problem can be solved by ZD devs by creating new ACS command. Such tagged projectile when entering death state should take the actor it hits and set as an activator of the script.
Every projectile if it hits any actor does damage to it. If the system knows which exactly monster should take the damage then it can also take this actor and do something else -
to be set as activator to a script (without doing damage). Can you devs create such ACS command that could be executed from projectile's death state? The first frame with 0 duration
can call to a script where such command could be called and set projectile's hit actor as activator. Currently ACS has https://zdoom.org/wiki/SetActivatorToTarget . And I'm using it twice
in Script 1053, 3. When called from projectile, the activator is the projectile. The first use of the `SetActivatorToTarget(0)` sets projectile's MASTER as the activator. It's the actor who launched
the projectle. The second use of `SetActivatorToTarget(0)` sets thrower's target as an activator of the script: https://pastebin.com/v3Gk45Dk
The system is quite good for certain targets. It can be tagged and untagged. But it's not good in all ways. In general everything should work without any tags. Since every actor has unique identificator, so the activator
should be possible to be selected without tag. `SetActivatorToTarget(0)` works with 0 as tag. So, new ACS function "SetActivatorFromProjectile(TID)" could be similar. But it should be started
at the first death state frame to set activator to whoever it hits.
Only then the grenade could be set to whoever it hits.
Also currently if there are many same tagged monsters then sticky bomb sticks to any of them but not necessarily to the thrower's target. You can see it in video's time interval 5:11-517.
Female Warrior throws it to its target but sticky bomb sticks not to that target but to some close to it monster. In this situation all monsters had the same tag (=560).
Your best chance of getting something like that implemented is to do a request over at one of that ports that take care of the standardization regarding ACS features.
I see no general benefit in adding such a feature as a ZDaemon-specific one.
From what I understand you want to launch a script from a dying projectile and then pass on the "activator" of that script to an actor (target)?
"SetActivatorFromProjectile(TID)", that name leaves the impression that one can set the activator based on impact inflicted on the current activator of the script.
The way you describe it sounds more like: SetActivatorToTargetFromProjectile() or in a case where the projectile is the activator; SetActivatorUponHit()
Eitherway, I'm not a fan. The big problem is that preferably you'd rather not use any Thing IDs at all, because otherwise there will be conflict with the [LA] wad(s).
Quote:
In general everything should work without any tags. Since every actor has unique identificator, so the activator
should be possible to be selected without tag.
That's where I disagree because the whole idea of Thing IDs is to give the user control over the actors they place, use or whatsoever.
Your best chance of getting something like that implemented is to do a request over at one of that ports that take care of the standardization regarding ACS features.
I see no general benefit in adding such a feature as a ZDaemon-specific one.
From what I understand you want to launch a script from a dying projectile and then pass on the "activator" of that script to an actor (target)?
"SetActivatorFromProjectile(TID)", that name leaves the impression that one can set the activator based on impact inflicted on the current activator of the script.
The way you describe it sounds more like: SetActivatorToTargetFromProjectile() or in a case where the projectile is the activator; SetActivatorUponHit()
Eitherway, I'm not a fan. The big problem is that preferably you'd rather not use any Thing IDs at all, because otherwise there will be conflict with the [LA] wad(s).
Quote:
In general everything should work without any tags. Since every actor has unique identificator, so the activator
should be possible to be selected without tag.
That's where I disagree because the whole idea of Thing IDs is to give the user control over the actors they place, use or whatsoever.
The projectile is tagged. But whatever it hits is not necessarily tagged.
You could make it. GetActivatorFromProjectile(TID);
Do not reject it and do.
To edit 18 Doom monsters by adding 1 more frame is not very good idea just to make them catch a grenade. Also There is a risk that they won't work as before. Something can be broken.
One call from tagged projectile to ACS is more practical.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum