UFO: Alien Invasion Issue Tracker
UFO: Alien Invasion
Go to the previous open issue
Go to the previous issue (open or closed)
star_faded.png
Please log in to bookmark issues
icon_project.png UFO: Alien Invasion / Closed Bug report #259 Aliens die too early
Go to the next issue (open or closed)
Go to the next open issue
This issue has been closed with status "Closed" and resolution "Not determined".
Issue basics
  • Type of issue
    Bug report
  • Category
    Battlescape
  • Targetted for
    Not determined
  • Status
    Closed
  • Priority
    4. Useful
User pain
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
Affected by this issue (0)
There are no items
People involved
Times and dates
  • Posted at
  • Last updated
  • Estimated time
    Not estimated
Issue details
  • Resolution
    Not determined
  • Reproducability
    Not determined
  • Severity
    Not determined
  • Complexity
    Not determined
  • Platform
    Not determined
  • Architecture
    Not determined
Attachments (0)
There is nothing attached to this issue
Duplicate issues (0)
This issue does not have any duplicates
Description
[http://sourceforge.net/p/ufoai/bugs/259 Item 259] imported from sourceforge.net tracker on 2013-01-28 18:15:21

Screenshot:
Aliens are about to be hit by the rocket,
but have already dropped their weapons.

See also issue 1539172.

===== Comments Ported from Sourceforge =====

====== hajo4 (2006-08-18 16:36:57) ======

Aliens about to be hit by rocket have already dropped their weapons
====== hoehrer (2006-08-21 21:57:06) ======

Logged In: YES
user_id=1434318

Various comments from duplicate #1539172:

===========================
"On explosions, the aliens often die before the impact
of the rocket or grenade.

E.g. the message "G_ActorDie: kill actor on team 7"
is shown when the grenade is still flying, and
during the explosion the model of the alien
has already disappeared." -- Nobody/Anonymous

===========================

"And if it is the last alien of a mission,
the mission ends before the hit&die-animation
is finished." -- hajo4

===========================

Werner
====== hoehrer (2006-08-22 13:21:02) ======

Logged In: YES
user_id=1434318

The problem seems to be located in G_ShootSingle (g_client.c).
I suspect that the function doesn't wait until the
projectile has hit the target but it calculates the impact
vector straight away and deals the damage.

Werner
====== hoehrer (2006-08-23 19:20:56) ======

Logged In: YES
user_id=1434318

Mattn told me this may have been introduced since td1 (kinda
big time-frame though :-/)

I just check Revision 2900 and it already had this bug.
====== hoehrer (2006-08-23 19:40:40) ======

Logged In: YES
user_id=1434318

In Revision 2500 when soldiers 'die' (i.e the HPs are 0)
they drop their guns onto the ground (still too early) but
they do not fall onto the ground themself and still have
their guns in hands -> duplicate gun models.
====== hoehrer (2006-08-23 20:54:06) ======

Logged In: YES
user_id=1434318

Rev 2200 has the problem as well
====== bandobraz (2006-08-24 21:45:40) ======

Logged In: YES
user_id=1557623

<hoehrer> @Bandobras ... is there a way to check for a
rocket when it impacts/explodes?
<hoehrer> The current way is firing the rocket and at the
same time calculating damage+death+DropOfWeapons

I&#039;m neither sure what is the question nor, regardless, what
is the answer. :) In G_ShootSingle by (tr.fraction < 1.0) we
check if the projectile is within the target object and by
(tr.ent) if the object is a local entity (or a wall, etc.).
Now, tr is changed in gi.trace, once for each bounce of the
projectile. And how gi.trace works is yet another matter...
====== bandobraz (2006-08-24 21:46:22) ======

Logged In: YES
user_id=1557623

<hoehrer> @Bandobras ... is there a way to check for a
rocket when it impacts/explodes?
<hoehrer> The current way is firing the rocket and at the
same time calculating damage+death+DropOfWeapons

I&#039;m neither sure what is the question nor, regardless, what
is the answer. :) In G_ShootSingle by (tr.fraction < 1.0) we
check if the projectile is within the target object and by
(tr.ent) if the object is a local entity (or a wall, etc.).
Now, tr is changed in gi.trace, once for each bounce of the
projectile. And how gi.trace works is yet another matter...
====== hoehrer (2006-08-25 07:01:20) ======

Logged In: YES
user_id=1434318

The lack of comments in that function aside [1], I admit
that I don&#039;t really understand the code here ...
trigonnometry and vector-calcualtion iI can deal with, but
the way this function works just isn&#039;t clear to me ...

e.g. What exatly is meant by &#039;bounce&#039; ... a rocket or normal
projectile doesn&#039;t bounce, it flies straight until it hits.
So at least the name is a bit irritating here. And if the
impact is checked with the location of the target (&#039;what&#039;
exactly _is_ tr.fraction anyway?) why is damage dealt before
the rocket is really there?

Same is true for &#039;muzzle&#039; ... I think it is _modified_
throughout the function ("VectorCopy(impact, muzzle);") and
then does not reflect its name [2] anymore ... instead
&#039;from&#039; is used for the non-changing var.

Mind you I&#039;m not trying to complain here, but it just
confuses the hell outa me :-/ and I really want to fix this bug.

Werner

[1] This lines alone are kinda confusing because I have to
guess what it &#039;should&#039; do ... and why is one line executed
twice?

range -= tr.fraction * range;
VectorCopy(impact, muzzle);
VectorScale(tr.plane.normal, -DotProduct(tr.plane.normal,
dir), temp);
VectorAdd(temp, dir, dir);
VectorAdd(temp, dir, dir);
flags = SF_BOUNCED;

[2] http://en.wikipedia.org/wiki/Muzzle_%28firearm%29
====== bandobraz (2006-08-25 07:37:39) ======

Logged In: YES
user_id=1557623

<esben> I&#039;m taking a wack at that timing issue with the die
animation. I think
the problem is that G_ShotSingle() isn&#039;t waiting for the
animation to
finish before doing the damage thing. Not sure if I can
just insert
the wait or if the function needs to be split up [00:21]
<Bandobras> good luck! :) [00:23]
<Bandobras> the problem is probably the server-client separation
<Bandobras> I&#039;m not sure there is an easy way to tell
<Bandobras> if the animation is finished on the client
side... [00:24]
<Bandobras> but there is surely a way to tell client to display
<Bandobras> various animations one after another, in a queue...
<Bandobras> (I&#039;m assuming G_ShotSingle() is on the servers
side; [00:25]
<Bandobras> otherwise it would probably be named
CL__ShotSingle() or
something...)
<Bandobras> esben, the timing problem may have something to
do with the flag
INSTANTLY [01:38]
<Bandobras> and the and the variable cl.eventTime, as seen
in cl_parse.c
<Bandobras> but queuing the events may even a better idea
[01:39]
<Bandobras> than computing their times and waiting
<Bandobras> I have no clue how all this works...
====== bandobraz (2006-08-25 07:49:41) ======

Logged In: YES
user_id=1557623

> e.g. What exatly is meant by &#039;bounce&#039; ... a rocket or normal
> projectile doesn&#039;t bounce, it flies straight until it hits.

Yes, but potentially you could fire rubber projectiles that
will bounce after they fly straight and hit a wall. I&#039;ve
tried it with some hacked scripts and it works. :)

> why is damage dealt before the rocket is really there?

What do you mean? Of course everything is dealt before the
animation plays, but the order/timing of individual
animations should be corrected...

> Same is true for &#039;muzzle&#039;

I would be glad if you made the code more readable. After
you understand it, that is. :)

> VectorAdd(temp, dir, dir);
> VectorAdd(temp, dir, dir);

Is it equivalent to "dir = 2 * temp + dir"? Perhaps it is right?


====== hoehrer (2006-08-25 09:46:34) ======

Logged In: YES
user_id=1434318

Just for information:

This will drop the equipment before the projectile animation:
G_ShootSingle -> G_SplashDamage -> G_Damage -> G_ActorDie()
====== hoehrer (2006-08-28 06:47:21) ======

Logged In: YES
user_id=1434318

Ok, one more thing I forgot in the previous comment: AFAIK
the dropping of the inventory is not dealt with as an
&#039;animation&#039; per-se but it is an instant action (executed in
G_ActorDie):

G_InventoryToFloor(ent);

Werner


Werner
====== hoehrer (2006-08-28 07:47:41) ======

Logged In: YES
user_id=1434318

I&#039;ve tried to move the dropping of the inventory into the
client (&#039;cause the CL_ActorDie function is located there).
See the attached diff.

The problem here will probably be that the server might not
be synchron with the client.

Werner
====== bandobraz (2006-08-28 09:55:27) ======

Logged In: YES
user_id=1557623

AFAIK dropping has to be done _both_ in the client and in
the server. In this particular case, the equipment may not
be collected after the battle...
====== hoehrer (2006-08-28 09:58:39) ======

Logged In: YES
user_id=1434318

That&#039;s why I still need to test (SP & MP) if my solution
works ... I&#039;m kinda confused by the implemention of the
server/client code :-/

CL_ActorDie is called after an event (EV_ACTOR_DIE) was
sent, but i don&#039;t know if _both_ (sv & cl) will execute this
function then.

Werner
====== hoehrer (2006-08-28 10:09:40) ======

Logged In: YES
user_id=1434318

Ok, i just realized that my diff doesn&#039;t work at all (no
header definition of G_InventoryToFloor), so nevermind that :-/

Werner
====== bandobraz (2006-08-28 10:38:53) ======

Logged In: YES
user_id=1557623

> CL_ActorDie is called after an event (EV_ACTOR_DIE) was
sent, but i don&#039;t know if _both_ (sv & cl) will execute this
function then.

No, only client, server probably does this separately for
it&#039;s data structures, before/after sending EV_ACTOR_DIE...
====== hoehrer (2006-08-28 11:35:30) ======

Logged In: YES
user_id=1434318

Ok, then I&#039;m out of ideas how to solve that problem at all ...

Werner
====== hoehrer (2006-08-28 11:40:48) ======

Logged In: YES
user_id=1434318

Here&#039;s my last idea anyway. Maybe it works.

Replacing...
=======================
/* send death */
gi.AddEvent(G_VisToPM(ent->visflags), EV_ACTOR_DIE);
=======================
... with ...
=======================
/* send death */
gi.AddEvent(G_VisToPM(ent->visflags), V_ACTOR_DIE &
~INSTANTLY);
=======================
... in G_ActorDie (g_client.c) might just do the trick.
But i have no way to test it yet.

Werner
====== bandobraz (2006-08-28 11:41:09) ======

Logged In: YES
user_id=1557623

See the IRC logs. (But it&#039;s hard, nevertheless, I think.)
====== hajo4 (2006-09-04 14:21:00) ======

Logged In: YES
user_id=1561716

Also happens in RC4, and with Flamer:
Alien hit by flamer will die,
has weapon still in hand + dropped copy of weapon on floor
====== nobody (2006-11-05 23:18:57) ======

Logged In: NO

Same with human soldiers killed by grenade, rc5
====== cassiterite (2006-11-20 18:06:38) ======

Logged In: YES
user_id=1171370
Originator: NO

trunk revision 4824 is my attempt at fixing this.

I have to admit I didn&#039;t read through any of the comments here, I figure that the sever has nothing to do with this.. it is just sending events to the client and it is the client&#039;s job to animate/time them correctly.

So I simply adjusted the time of the inventory drop and subsequent appearance of the largest weapon/item of the dropped actor on the battlescape to happen slightly after the impact (well that is the theory anyway).
====== cassiterite (2006-11-21 13:21:38) ======

Logged In: YES
user_id=1171370
Originator: NO

Trunk revision 4833 tweaks the timing somewhat (the delay between the death and the item drop) and fixes an issue in my previous fix where the appearance of thrown items on the battlescape&#039;s floor was being unintentionally delayed (now this _is_ intentionally delayed, but by only by 75ms vs 400ms for items dropped by a dead actor).

The fix is not complex but I I think I could come up with an even simpler approach. The really simple approach however may have unintentional side-effects (well I can&#039;t be sure without being 100% familiar with the possible combination of animation sequences). The approach I have taken keeps the event timing manipulation as narrow/focussed as practical. Rudimentary testing reveals it doesn&#039;t have any strange side-effects, so I&#039;m marking this bug as fixed.
====== hoehrer (2007-01-11 10:34:44) ======

Logged In: YES
user_id=1434318
Originator: NO

Is this bug really fixed? The bug #1604603 [1] was recently closed, but there are hints this _this_ one still causes some problems.

I&#039;ll reopen this bug as "Reminder" (dunno if hter is a better status for this) just in case.

Werner

[1] https://sourceforge.net/tracker/?func=detail&atid=805242&aid=1604603&group_id=157793
====== tlh2000 (2007-08-15 16:37:03) ======

Logged In: YES
user_id=116930
Originator: NO

fixed in r10846
Steps to reproduce this issue
Nothing entered.
Todos (0 / 0)
Issue created
footer_logo.png The Bug Genie 4.3.1 | Support | Feedback spinning_16.gif