UFO:Alien Invasion
General => Discussion => Topic started by: Ildamos on September 16, 2010, 09:14:44 am
-
^Subject.
I've stopped playing the game hoping 2.3.1 will fix this.
-
2.3.1 ??? Searched around a bit ... couldn't find any announcement that there will be such a thing. *shrug
-
Cause it *will* be released
-
I've been playing 2.4 for over a month, and RF hasn't been an issue. What build have you been playing, because I stopped seeing RF issues in 2.3 about halfway through August, when playing the Muton builds.
-
I've been playing 2.4 for over a month, and RF hasn't been an issue. What build have you been playing, because I stopped seeing RF issues in 2.3 about halfway through August, when playing the Muton builds.
The 2.3 RF works just well with most guns bigger (slower) than pistols. Maybe that is why, you just advanced your game to point where aliens rarely use those.
-
Could anybody plz say (or provide a link to) what the prob with RF really is you are talking about ?
-
I'm pretty sure it's this (http://ufoai.ninex.info/forum/index.php?topic=5000.0).
-
I think there are several problems:
- the reaction fire code is bugy (there was a patch for 2.4 that fixed the more important ones.)
- A lot of people complain, that the RF worked in 2.2 and it is broken in 2.3. But they might just remember the performance of their elite troops at the end of 2.2 and expect the same behaviour of the rookies in the beginning of 2.3 (and the players with more experienced troops usualy report, that RF works in 2.3)
- It is difficult to judge when RF "should work". (while an alien moves the player has to evaluate the wappon range, the TU the alien spent in view (of a soldier), the chances to hit a friend and the cances to hit a foe). So there might be some false bugreports.
To get better data i added a line to log the results of the mockshot. And I must say the mockshot is executed a lot but most of the time the hits on a enemy are below the necessary 30.
you can improve the "visibility" of RF to the player if you remove the test with the mockshot. But then you will get the following bug reports ;):
- RF is broken, the soldiers shoot but they never hit a target
- RF is broken, it wasts a lot of amo
- RF is broken, the aliens cheat with RF and always hit (well once in a while an alien will hit a soldier)
- ...
-
So we're not talking about the handling of reserved TUs or that they don't react at all. It's just that they don't shoot/hit as often as the player *expects*.
I found this in the topic Hertzila linked to:
I gave 2.3 a good long play and have to say...RF is NOT bugged. The problem is that starting soldiers are just lame. From what I can tell, there are two things the matter in RF, Mind stat of soldier and TU cost of RF shot...once you get better soldiers, RF becomes quite reliable and deadly.
-
Then there's also the reply 20:
After examining the source of 2.3 some time, I've come to conclusions, that:
RF can only be used by right hand.
Mind or speed skills are meaningless for RF.
There are no random parts, RF is fully predictable (and thus avoidable by AI).
It's buggy. Badly.
After which the same guy explains why it's bugged and how and a patch to fix it. And a patch tracker for those changes.
-
His patch has been applied to trunk on August 11th.
So are we talking about former problems with RF in 2.3 *release* ?
-
If it has been applied, then yes, it seems so.
So will there be a 2.3.1 release that fixes this RF issue for 2.3 versions or is it straight to 2.4?
-
If it has been applied, then yes, it seems so.
So will there be a 2.3.1 release that fixes this RF issue for 2.3 versions or is it straight to 2.4?
This is what i called "a patch for 2.4" and it is only in 2.4 but it should be easy to backport this
-
just for reference:
http://ufoai.git.sourceforge.net/git/gitweb.cgi?p=ufoai/ufoai;a=commitdiff;h=df5831042e3e6df044bd2b15f5c557dde7ff0097
-
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.
-
feel free to just attach a patch here.
-
Or reset the reservation TU when we end the round, which make sens, cause reservation is only need when we are playing.
-
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?
-
* why isn't the build working? what is the problem?
* backtrace available about the crash (or already fixed?)
if you have a patch for 2.3 available, just attach it - if it can't get merged into master we should fix you build problems and you should base it upon master
-
- Current master: Doesn't even build, so no way to test it.
Did you make clean before building? That solved the problem for me.
-
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.
-
c::b is looking for the printed path relative to build/projects - so creating a directory build/projects/build/projects with the two files in it should be a work-around.
about R_UseActorSkin, maybe a missing file.
-
off topic, request if there will be a 2.3.1 can there be a deferential patch, DL another 0.5GB on this crappy WIFI here its a nightmare.
dont mind me i am just browsing the forum.
-
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.
-
Btw, how do you like your patches? git-format-patch output (mbox) or git-diff -p output (textfile)?
-
I think Mattn preferes format-patch
-
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)".
-
thanks a lot - it would be better to post patches on the patch tracker - this time i've seen them - but they might get lost on the forum.
-
i can't accept your first patch - at it break compilation via normal make
-
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.