Messages

1

Coding / Re: the AI discussion

« on: August 31, 2010, 01:30:38 am »

kobold: if you're willing to test this extensively with 2.3 and the campaign, I can most definitely produce a patch for 2.3 so you can try it out.
Most of the changes are in the ai file itself.

On the subject, what's wrong with the bloodspiders (I haven't really played since I came back)?

2

Coding / Re: the AI discussion

« on: August 28, 2010, 09:54:22 pm »

back, I just couldn't stay on that island for just 12 days...

3

Coding / Re: the AI discussion

« on: August 01, 2010, 04:38:07 pm »

Here's the svn diff of my current status

Not much has changed since the last diff.
I've switched the damage estimation to the mixed model (mock for gravity/splash, math for the rest). This leads to normal execution times (as long as there aren't many such weapons being held on the field).
Ofc since I did squat of a progress on the math estimations, some of it's "features" are still there (e.g I just had aliens try to shoot through walls. In my defence my squaddie was getting non-0 hitchances too).
Enable the commented-out "#define MOCK_ESTIMATION_ONLY" if you want to see the difference of mixed estimation vs mock-only.
You do get interesting things happening with mock-only in the rivertown map (see bug report).

It's possible that you will get an unreferenced function error at compile time, include the appropriate .c file. Somehow my linker has no issues with it (probably because I used to have it included sometime in the past?).

You may/may not decide to commit this to the trunk. The problem is I won't be around till the 18th to fix any broken bits that come up.

4

Coding / Re: the AI discussion

« on: July 31, 2010, 04:26:35 pm »

gonna go afk for another 2 weeks because of vacations

5

Bugs prior to release 2.3 / Re: Can't start a game with 2.3 : game crashes

« on: July 23, 2010, 05:35:18 am »

there's a series of threads concerning ATI graphcards, try looking into them.

6

Bugs in older version (2.3.1) / Re: Alien AI

« on: July 23, 2010, 05:26:25 am »

Hello, I'm currently working in the AI from several aspects.
Feel free to drop in the discussion (it's in the 'Coding' section of the forum). I make a fugly introduction to how the AI seems to work and then try to explain why many (including wall-shooting) bugs exists/how to fix em.

Atm I'm working on some fixes for the AI that should improve the difficulty factor and stop aliens from shooting into walls. Specifically on wall-shooting, I actually let them take 10 imaginary shots using the real shooting mechanics so they pretty much know exactly what's going to happen. It makes sense that they would stop shooting through walls, right?

Wrong, kinda. The classic maps where silly wallshooting happened a lot (africa map) has ceased, but now aliens keep shooting through walls in rivertown. Did you notice I skipped the "try to"? Yes, the little critters actually found a bug in the code and are actively exploiting (damn cheaters!). I'd challenge you to cross the river in that map without loosing half your squad...
So the issue may not exactly be an AI one. Also, that shot sampling cannot be used in the real AI since it's too slow.
I'm still looking for someone into the math of simple geometry and the error function (CDF), to fix some math that make that UI hit-predictor behave improperly (so we can use it in the AI).

I know that the alien god-o-vision (call it wallhack if you may), is kinda cheesy. The problem at this point is that if we drop that, the aliens will become even dumber and the workload will be immense just to bring it in line with th current piece-of-cake difficulty. The plan is to buff it as much as we can, then once we can provide a very strong challenge, try to drop things like this (maybe based on difficulty?). All game AI more often than not knows where you are, it's how it uses that information that makes you aware of it. If it wasn't for this wallbug, you probably wouldn't have noticed it.

You can take a look at the new AI yourselves, but it needs trunk ver and/or some minor coding. See the discussion.

7

Coding / Re: the AI discussion

« on: July 22, 2010, 02:56:08 pm »

You are correct on the AI_FindHidingLocation point.
Wanna play around with it? I'm tied with the shooting & bugs atm.

Bear in mind that LUA uses that function aswell, we can adjust for any changes (e.g parameters) you'd want in the C AI, but I have no idea what lies in LUA-land.

Also, this function only checks visibility and not shootability, which may lead to silly things like 'hide behind someones back' (common for mellee units). Now, I wouldn't suggest putting the AI_HideNeeded there aswell. It's heavy as it is atm.
Gah, I'm torn again on the G_Vis AND/OR HideNeeded combination. The OR is clearly slower (atm, because of mockshots), but the AND doesn't let the aliens shoot from positions that are visible yet can't take that much fire back (e.g. corners).

8

Linux / Re: UFO:AI 2.3 mission crash: ufo ai Assertion `firemode >= 0' failed

« on: July 22, 2010, 09:58:58 am »

wrong forum, and this has been fixed for a couple of days now. Try updating from svn.

9

Tactics / Re: IR-goggles

« on: July 22, 2010, 09:56:19 am »

The code for shooting makes no mention of goggles when it's actually making the shot itself.
So I'm 99% certain that it has absolutely no effect on accuracy

10

Bugs prior to release 2.4 / Re: Reaction Fire - End Turn

« on: July 21, 2010, 10:49:27 pm »

starting line 357 of g_reaction.c:
So yeah, this can explain everything,

Code: [Select]

/* Change active team for this shot only. */
team = level.activeTeam;
level.activeTeam = ent->team;

/* take the shot */
tookShot = G_ReactionFireShoot(G_PLAYER_FROM_ENT(ent), ent, ent->reactionTarget->pos, ST_RIGHT_REACTION, ent->chr.RFmode.fmIdx);

/* Revert active team. */
level.activeTeam = team;

Now, every 10 serverFrames, the AI code checks to find an actor to move like this:

Code: [Select]


if (level.framenum % 10)
return;

/* set players to ai players and cycle over all of them */
for (i = 0, player = game.players + game.sv_maxplayersperteam; i < game.sv_maxplayersperteam; i++, player++)
if (player->inuse && G_IsAIPlayer(player) && level.activeTeam == player->pers.team) {

if the AI thread interrupts the thread running the RF while it's taking a RF shot (assuming they are on different threads), then the activeTeam check is true, and I'm assuming the same goes for player->inuse. That will get the AI going. Now, IF all the aliens have next to 0 tu's, and given that the 2.3/current-trunk AI is quite fast, it will call for 'end of turn' once the for loop completes. It depends on the thread interleaving and that's why it's so hard to reproduce.

This is especially visible in my modified AI where it's execution time is currently very lengthy. RF[interrupted]->AI-start[interrupted]->RF[completes]->AI resumes thinking it's his turn. At this point it will try to make the alien shoot and the 'it's not your turn' will start swamping the log.

If this is really the problem, locking access to level or level.activeTeam while RF shooting should be enough (I have no idea how to do that). If there's a way for the AI to make sure RF is not going on at any given point, tell what to check for and I can fix this from the AI side.

UPDATE: Confirming that some kind of end of turn can be caused because of the RF & access to the level.activeTeam. I killed the AI by making it call end of turn as soon as it's about to start thinking for one of the aliens. Loaded up an open-space map and tried to move my squaddies. Result:

Code: [Select]

Team 1 ended round
Team 0's round started!
Team 0 ended round
Team 1's round started!

x12 !!!
And that's from a simple 20-TU walk in front of an alien. Notice that there's NO team 7 mentioned anywhere in there. Strange.
After moving around a little bit more and getting shot enough, the following strange occasion happened:
My squaddie "died" to RF getting the death animation, then promptly got up again, followed by crash with:
"ufo: src/client/battlescape/cl_actor.c:1779: CL_AddTargetingBox: Assertion `chr' failed."

This is different from all the other RF-related crashes I got, it's a different one every time. This is quite an important bug and we should get to it asap.
Unfortunately I have no idea how to mutex things.

11

Coding / Re: the AI discussion

« on: July 21, 2010, 08:28:51 pm »

/* evaluate moving to every possible location in the search area,
    * including combat considerations */
   for (to[2] = 0; to[2] < PATHFINDING_HEIGHT; to[2]++)
      for (to[1] = yl; to[1] < yh; to[1]++)
         for (to[0] = xl; to[0] < xh; to[0]++) {
            const pos_t move = gi.MoveLength(gi.pathingMap, to, crouchingState, qtrue);
                                if (move != ROUTING_NOT_REACHABLE && move <= ent->TU) {

Glancing at that snippet, it strikes me that if you're willing to (1) store movement costs and/or paths, (2) ignore movements that aren't from one adjacent tile to another (which would presumably exclude aliens leaping from a ledge to a multi-step drop), and (3) stipulate that aliens use a single consistent heuristic during movement (either maximizing safety, or maximizing speed) -- that you might be able to save some computation by caching.

I'm not sure I'm following your train of thought, then again I only just woke up and my coffee is not even half empty.
Even though I never tried to play with this set of loops (shaunc did), what I get from it is that it sequentially tries to evaluate movement cost to any tile within a box surrounding the alien. It doesn't calculate each step separately. So, if you're standing at the top of the stairs, the bottom of the stairs might be 4 TU's away (2 tiles),  but reaching the tile at the bottom of the drop next to the stair is only 2 TU's (one step into the air, then drop). This is all ofc done from the pathing algorithm which does consider drops. I've seen both soldiers and aliens casually drop from ledges instead of going for the stairs (actually getting them to use the full length of the stairs is kinda tough). As for (3), we don't use any heuristics, we calculate the full set of possible moves but we never even know the series of steps we'll take to reach the destination. The pathing might be using some kind of heuristic, and it definitely seems to be producing the fastest path to a destination (as I've seen the code laced with comments/ideas about checking the visibility/RF-exposure while we walk).

Under those assumptions, the 'best' movement from one tile to another will likely be the 'best' movement from the source tile to an adjacent tile, plus another movement.  This is false if you aren't willing to assume (3) -- e.g. it might be 'worth it' to walk standing to one location IF that leaves TUs to reach a safer location, while if that intermediate destination were actually the endpoint you'd crouch.    But if you can cache, you might save some computation by more quickly excluding impossibilities (because they're not adjacent to any possible shorter-path tile), and depending on whether the moveLength caches.  If THAT caches, then the above stuff I wrote can mostly be ignored -- I'm basing this just on the loop structure and that it's pathfinding, not on a deep examination of the code base.

Crouch is so not considered in the AI, it makes me sad. The only chance for the alien to crouch is if it ends it's about to end it's turn and it has enough TU's. On the next round it will always stand up before moving . At least shooting from a crouched position is one of the 'todo' things on my list. Moving while crouched can only come into play after that, as moving somewhere crouched, only to stand up and shoot, is always (not considering safety) counter-productive.
The current structure of the aiAction_t, is pretty simplistic atm. It can only store:  [mov],[shoot],[mov]. Each one is optional, and moves only define coords, not crouch status. As you can see, there's very little that can happen with this struct, and upgrading it to a linked list of generic actions is a must for any serious additions. There's a light exception to this struct, but it's not worth mentioning since it's almost the same behaviour.
If you check a few lines above the quoted code snippet, you'll see a G_MoveCalc call. I'm not 100% sure, but I believe that it precalculates the 'pathingMap' for usage from our team. So in essence every call to gi.MoveLength should be locating the appropriate cached value rather than re-calculating pathing.

update: I looked into the move algo's because of a crashbug, and I saw: "/** @todo add heuristic for A* algorithm */", so it sounds we got no heuristic for that either. Anyone wanna go for it? Pathing doesn't seem to be the issue atm, but aliens hugging the hulls of ships needs pathing calculations for a greater area (we need to use pathDistance instead of vectorDistance). A complete search would smack us face if we expand the 'searchbox' to a needed size, so finding out the proper heuristic would be a very nice addition.

12

Coding / Re: the AI discussion

« on: July 20, 2010, 02:15:09 am »

I'm close to producing something semi-usable (pending the fixes ont he hitprobabilities), and I spent my last day debugging my working copy.

Here's one thing that really puzzled me:
some aliens end up having "ent->chr.reservedTus.reaction>0" while the other members of the reservedTu struct seem uninitialized (like weapon).

AI_FighterCalcBestAction considers using "tu = ent->TU - move", which is fine as long as noone has enabled RF. This ends up in aliens trying to use more TU's than they have while shooting (G_ActionCheck returning qfalse), and even worse, when moving (so they end up a few spots before their cover destination in plain LOS/LOF).
I replaced the usages of "ent->TU" with "G_ActorUsableTUs(ent)", as an immediate patch to this behaviour, but this needs to be looked into more detail as it gimps some aliens (less tu's) without a reason.

For some reason RF keeps giving my alien who's interrupting a chance to play as if it was his turn. Somehow it only works for the alien that is reacting, and I like this one. The problem is that the G_ActionCheck always returns false because "level.activeTeam != player->pers.team". activeTeam is set for the player.
So currently, this RF doesn't work with the AI I'm building unless some changes in trunk in the past 2 weeks adressed this issue. If someone is up-to-date in trunk, try and see if G_ActionCheck's first if statement is ever entered while you're causing a RF.

Also: please consider rolling the 2.3 AI back to it's release version, at least for changes produced in this thread. Lemme play around with the AI in the trunk, and if we deem them to be proper AND STABLE, then we can copy them to 2.3. You could keep the dodon patch if you think it's ok, but I believe it's behaviour is only fitting along with the fixes in the damage estimation.
The mess I created by that 'innocent' code refactorization that got posted in 2.3 introduced a series of crash-bugs. Thank god for geever pointing that out to me the hordes of angry players.

UPDATE
Ok, since the playtime is now below 2-3mins for small maps, haven't crashed in 3 hrs and I merged with latest trunk, I guess you can have a look at my current work copy and see how it feels:
the diff vs trunk 31041. I have no idea how easy it is to apply those, I spent like 40 mins trying to get mine to work when I was moving to latest trunk.
The entire g_ai.c file if you don't like the patch You should also add "#define GUETE_DAMAGE_AVOID_FACTOR   0.4" in g_ai.h.
PLEASE DON'T COMMIT THE PATCH. There are quite a few things I need to do before we can consider that one, namely the performance.
Kildor on IRC mentioned that he gets an undefined reference for TR_TestLine on line 165, you can just delete lines 33 up to 203 and get away with it (as long as you don't try to enable math estimation as mentioned later on). Also delete the entire AI_CalculateDamageMath in this case.

Now some general notes on the code: Currently only the sampling damage estimation via G_ShootSingle is in, after applying some sensible optimizations. You can find some blocks of "#if 0/#endif" that drop the main dmg estimation function of 31041 and most importantly the code that enables selection between sampling and math-based damage estimation.
The reason why the math-based (see: CL_GetHitProbability) is out is because:
a) it has some inherent problems with occlusion (as mentioned in previous posts) which are still not fixed
b) I think I did something wrong. The result comparison between those the two estimation methods vary so much, as to imply it.
Uncomment the block before line 500 to see the difference with the math enabled (while commenting out line 500). You may wish to also comment-out 494-497 and all lines referencing testTotalDamage, these are used to compare results from both damage estimations.

You will find many //-style comments, these are things that need to be removed/ironed-out before considering to applying this patch to trunk.

I'd mention the new wonderful things I saw my critters do, but I'm biased and want to hear your own comments. The bad things I've spotted so far that I need to fix are:
* Need to preclude from the G_Vis calculation (next to the HideNeeded) any units we expect to kill. Example: a machinegunner chose to run away and hide from a lone knife yielder that had the misfortune to end his turn 2 blocks away from him. The knifer was also the only one in the building.
* Get rid of the RF TU's that are auto-magically held for some (apparently random) aliens. Waaaait a moment, I do remember that shaken actors 'refuse to let his guard down', maybe this is the perpetrator?

Also, in reference to the dodon patch, I switched the "!HideNeeded || !G_Vis..." to "!G_Vis && !HideNeeded". The reason is that you want to be BOTH non-visible AND non-shootable, and in that order, is because:
a) If you're visible, you're most likely shootable, so don't use the horrendously expensive HideNeeded (I kinda beefed it up a bit)
b) You can be non-visible and still shootable: EXACTLY Behind someone's back (so CLOSE_IN maximizes too). Which was what the critters (melee units mostly) would prefer to do in closerange. It can be 'oh WOW!' if you didn't pay attention on the enemy's turn, but unless we can find a way to only allow this via non-visible flanking moves, it's too silly.

A very precious performance trick that I just thought:
Since the G_Shoot*'s are the performance hitters, and AI_HideNeeded really hammers those mulitple times for each alien, why not create a 'Threat Map' that is common for all the aliens? The only thing mobile in our turn is us, so all the damage an enemy can apply to a certain square is almost (unless we cut a LOF with the body of an alien) fixed (sans the armor protection). Assuming that aliens really consider 200 spots to move (as per shaun's post), they will also check damage received from 8 enemies, with an avg of 3 different firetypes. So 200x8x3=4800 calls to damage estimations (ha! times 10 for the sampling)
Then we should (we actually don't) do the same in the case we shoot-and-move (FindHidingLocation), times the amount of aliens we move == the reason this is still slow.
If we share a 'threat map' common for all aliens, we should be dropping the performance cost of hiding anywhere from X-fold to 2X-fold (where X is the number of aliens we have).

13

Bugs prior to release 2.4 / Re: Reaction Fire - End Turn

« on: July 19, 2010, 10:53:58 am »

A few mins ago I saw something that fits a 'reaction fire triggers end of turn'.

I had debugger on with breakpoints on the AI functions and as I was moving my actors to some random positions my breakpoints started kicking in and the AI was fully running in the stacktrace.
For a moment I thought that RF kicks in the AI (and that I had missed some trunk RF changes), but this explanation seems more plausible.

update: it happened again and I think it's under the same circumstances:
I got one of my soldiers die from alien RF and in the same turn I moved another of my soldiers to a place where he could get rf'd.
The debugger kicked in on the G_ActionCheck if (TU > G_ActorUsableTUs(ent)){return qfalse;} (the lines which I guard with breakpoints) for about 5 times in a row while the stacktrace was still indicating RF-related function names.
But straight after that I landed in my pure AI breakpoints.
Log is squeaky clean.

Now that I also looked into it more closely, all the AI attempts to move/shoot get thrown out from G_ActionCheck because "level.activeTeam != player->pers.team". activeteam is still 1.
As far as I know, we should never have activeteam 1 AND call the AI to compute it's turn.

Maybe my experiences are something wrong I've done in my copy or maybe it's indicative of the problem. Just thought I'd share

Update:
Yes, this happens quite frequently. RF checks turn into AI's turn to move while console starts spamming 'Can't perform action - this isn't your round!' (I don't think I let the console flush before killing the process in the previously mentioned example). But this happens only on random intervals. I re-checked the AI and it only kicks in for "G_IsAIPlayer(player) && level.activeTeam == player->pers.team". Notice the disparity between starting the AI and G_ActionCheck returning false? The same expression evaluating differently without the AI ever touching the level.activeTeam or player->pers.team values.
I wouldn't know much about these, but it sounds like a thread issue.
Also I got a 'ufo: src/server/sv_world.c:423: SV_HullForEntity: Assertion `ent->solid != SOLID_TRIGGER' failed.' on the last happening. I remember someone complaining about this elsewhere, maybe they have a common root?

14

Bugs prior to release 2.4 / Re: [30961] BUG - can't kill aliens over a stunned one

« on: July 19, 2010, 10:51:18 am »

I did notice this one in 2.3 release aswell

15

Bugs prior to release 2.3 / Re: 2.3 rev 31015 Win32bit Unable to play in Battlescape

« on: July 19, 2010, 01:07:28 am »

31039 for trunk and 31041 for 2.3