Messages

1

Discussion / Re: Will 2.3.1 fix reaction fire?

« on: October 14, 2010, 08:52:46 am »

I don't know enough about the build system to properly fix it, I just did the obvious thing such that it again worked for me. If make and c::b handle things differently, it must probably be fixed somewhere else.

I didn't know about the patch tracker, I just asked in the thread where to put the patches and was told to attach them. However I just had a look at the tracker and saw that there is another patch (3082295) that also fixes the reaction fire. I'm not sure which one is the better solution, I think this one work better on 2.3 and mine on master, but anyway: Do not apply both or we'll end up with negative TUs, I think.

2

Discussion / Re: Will 2.3.1 fix reaction fire?

« on: October 13, 2010, 09:52:52 pm »

Well, here we go, two commits.
The first one fixes the build (at least the missing files problem, ufo_model still got undefined references).
The second one makes reaction fire ignore reserved TUs.

It's not tested, because starting a skirmish game gets stuck at the end of the load with "Awaiting game start (0)".

3

Discussion / Re: Will 2.3.1 fix reaction fire?

« on: October 13, 2010, 09:01:32 pm »

Btw, how do you like your patches? git-format-patch output (mbox) or git-diff -p output (textfile)?

4

Discussion / Re: Will 2.3.1 fix reaction fire?

« on: October 13, 2010, 08:47:39 pm »

About the crash: That one vanished. I think I've just been too impatient. Looks like the loading screen is broken, but the game loads fine. I see the terminal when I start, then I get the loading screen with the progress bar still empty. Then the window just turns white and nothing seems to happen for a while. And then the main menu pops up.

5

Discussion / Re: Will 2.3.1 fix reaction fire?

« on: October 13, 2010, 07:55:29 pm »

OK, here is what I tried: I pulled the most recent master, did a "Build->Clean workspace" and then tried to build the various projects in the workspace, that's the result:
ufo, ufo_ded and ufo_tests: can't open file 'build/projects/ufo.exe.manifest': No such file or directory
ufo_radiant: can't open icon file 'build/projects/radiant.ico': No such file or directory
ufo_model:
undefined reference to `R_UseActorSkin'
undefined reference to `R_LoadActorSkinsFromModel'

Maybe I'm doing something wrong here, because both files complained about as missing are in the directories where it looks like they should be.

6

Discussion / Re: Will 2.3.1 fix reaction fire?

« on: October 12, 2010, 10:36:15 pm »

What commit shall I base the patch on?
- Current master: Doesn't even build, so no way to test it.
- Older commit (94ad32cb) fixing some other reaction fire action check problem: Builds, but crashes on start.
- 2.3 branch: Builds and works, but won't merge into the current master.

So, pick your poison: Untested or merge conflicts?

7

Discussion / Re: Will 2.3.1 fix reaction fire?

« on: October 03, 2010, 07:16:12 pm »

I spend some hours in the last days digging into the reaction fire, because it doesn't work in 2.3 as is quite well known by now.
I fixed some obvious bugs (about the same fixed in the commit link before) and did some other changes. And, surprise, it still didn't work.
Some debugging later I found the problem:
G_ReactionFireShoot() calls G_ClientShoot() to do the actual shooting, both for mock (probability determination) and the real action.
G_ClientShoot() calls in both cases G_ActionCheckWithoutTeam() to check whether taking a shot is actually a valid action.
G_ActionCheckWithoutTeam() calls G_ActionCheck() to, well, do what it's supposed to do.
G_ActionCheck() checks some stuff and at the end calls G_ActorUsableTUs() to look whether there are enough TUs left.
Thus far all is fine, so let's have a look at G_ActorUsableTUs():

int G_ActorUsableTUs (const edict_t *ent)
{
  ...
  return ent->TU - G_ActorGetReservedTUs(ent);
}

Now have a look at G_ActorGetReservedTUs():

int G_ActorGetReservedTUs (const edict_t *ent)
{
  const chrReservations_t *res = &ent->chr.reservedTus;
  return res->reaction + res->shot + res->crouch;
}

Summary: G_ActorUsableTUs() returns the amount of TUs left and not reserved. If this is greater than the required TUs to fire the weapon, a shot taken. While this makes sense if you simply trigger a shot by clicking an enemy, it's quite bad in reaction fire. Because, obviously, this means that no reaction fire takes place if no unreserved TUs are left.

Executive summary: If you got exactly the amount of TUs left you need for reaction fire, no reaction fire will take place. If you got, by happy chance, after reservation still enough TUs left for that weapon, the actor will fire. As most players will optimize movement to not have any TUs spare, they will never see reaction fire.

What hence needs to be done:
G_ActorUsableTUs() must honor TU reservation only when actions under player control are taking place. During reaction fire, all reservations must be ignored.

If someone tells me who's responsible, I can probably submit a patch to solve that problem.