Messages

1

Mapping / Re: Problem getting uforadiant set up

« on: July 16, 2010, 08:45:12 pm »

I was just playing around with this for the first time yesterday and left the compiler binary blank.  It seemed to work ok.  I got pretty far into the tutorial before I had to do yardwork.  Textures all seemed ok, with the exception of the one not being there anymore.

2

Coding / Re: Assertions in dbuffer.c

« on: July 14, 2010, 03:50:00 pm »

I haven't seen any errors in this since the fix (in trunk).  I do get a lot of other errors though so maybe they just happen first.  It's very rare that a skirmish finishes.

3

Coding / Re: the AI discussion

« on: July 13, 2010, 09:53:01 pm »

The main loop in AI_PrepBestAction is also a bit buggy

Code: [Select]

/* set borders */
dist = (ent->TU + 1) / 2;
xl = max((int) ent->pos[0] - dist, 0);
yl = max((int) ent->pos[1] - dist, 0);
xh = min((int) ent->pos[0] + dist, PATHFINDING_WIDTH);
yh = min((int) ent->pos[1] + dist, PATHFINDING_WIDTH);

...
/* 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) {

I think I have found a couple problems that might need someone to verify.

The first problem is the border consideration.  It's perfect if the actor is in the dead center of the battlefield.  It is wrong if the actor is by an edge.  For example:

Let's say an actor is standing on the right edge of the map, but still vertically centered.  Instead of having a box with a horizontal side of (tu+1)/2 + (tu+1)/2 (or just tu), we have (tu+1)/2 + 0.  If I'm right, then that is just a simple if/else fix.

The 2nd problem is the last if statement.  I was curious as to how inefficient the loop was so I added an else to it that just counted the number of unreachable moves.  Depending on the position of the alien it was between 200 and 11,000.  I'm unable to figure out why it spikes that high.  My next step was to see how many possible moves there are to see if 11,000 is just noise or a lot and something is wrong.  I might try that tonight.


Update:
Ok, so it is pretty significant.  The aliens are averaging about 8700 impossible moves out of 9248.  One thing I noticed is that the math above assumes 1 TU per move which is optimistic.  Another thing is that it tries all 4 floors, but this map only really has 1 (africa small).

Maybe a better calc would be:

Code: [Select]

dist = ((ent->TU + 1) / 2) / TU_MOVE_STRAIGHT;

This results in 2048 total moves with about 200 being possible (again, just 1 floor out of 4 being possible, and I always assume a straight walk but the real path is probably curved).  This seems to be a significant performance gain.

Update 2:
Debugging this has made me realize that the original /2 was for TU_MOVE_STRAIGHT but never labeled that.  The square needs to be 2TU/TU_MOVE_STRAIGHT to check the farthest the alien can possibly walk in all directions.  That explains the performance boost I saw but it certainly crippled the aliens. 

I still don't like the loops.  Mainly the issue I have now is that PATHFINDING_HEIGHT is always 8, even if a map is only 4 levels tall.  The other thing is that the PATHFINDING_WIDTH is always set to 256 but I think the Africa small map is a lot smaller than that so a lot of movements aren't going to be reachable.  A better implementation would be a sphere around the actor that has a radius of TU/TU_MOVE_STRAIGHT.   

4

Coding / Re: the AI discussion

« on: July 12, 2010, 05:40:40 pm »

Finally back online and I had a thought.  

We are using g_trace to make a bunch of lines to simulate %s.  Can we instead make 1 trace but make the end point larger and larger (based on the ACC) as it traces away from the gun almost like a cone?  Then calculate the % based on the surface area of the trace circle when it hits the target.

So if the area of the circle at point X is 400 and the overlap is 200, it would be 50%.  

Then if something is in front of the target, we can figure out which percentage of the circle is blocked.

For example, two objects in front of the target.  The area of the target circle at the first object is 100, and 30% of it is covered.  The area of the target circle at the 2nd object is 200 and it's 15% covered.  The area of the target circle at the target is again 400, with 50% coverage.  Since we still don't know how much of the 30% and 15% are overlapped (but we probably could figure it out somehow) we'd probably say the shot has (((.5 * 400)-(.3 * 400)-(.15 * 400))/400 = (200 - 120 - 60 ) / 400 = 5%

And I just realized that all those 400's cancel out so it's really just: .5-.3-.15 = .05.

Not sure how this would work with grenades though.



Yeah...pretty much ignore this.  I spent a lot of time looking at the trace functions and I'm not seeing a way to do it.  It also is probably oversimplifying stuff.

5

Coding / Re: the AI discussion

« on: July 08, 2010, 02:47:26 am »

So are you looking for a cheap version of G_ClientShoot that does the following(going down the lines in G_ClientShoot):

*ignores the if statements in the beginning that make sure you aren't shooting yourself and you have ammo(ammo check is done in ActorThink)
*probably keep the range check
*ignore the ammo check for multiple fire shots?  Or keep that?
*still calculates the visibility
*call G_GetShotOrigin (part A)
*fires the shots
*does the else part of the last if

Is there anything in shootGrenade or shootSingle that you'd also want to remove?  I think those methods will do B, C and D for you.

We could probably call those shoot methods a couple times to get a window of LOFs if that is more what you are looking for.  Not sure how expensive that is though.

6

Coding / Re: the AI discussion

« on: July 07, 2010, 07:07:55 pm »

AI_GetDamagePotential
...

The penalty we take on performance is quite significant. The fan-out may be only 10 (ontop of the previous one, for a total 160x number of leaves compared to 2.3 AI), but the tracing calculations needed here are a heavy factor.
Performance optimizations needed: An obvious proper bridge to the G_ClientShoot (no reason to try 10x, instead it can give us a base dmg+deviation), OR a complete copy of the damage calculations inside the AI code (bad, code replication&heavy maintenance). Best solution is a mathematical equation that can give us comparable results with minimal CPU.
For people wanting to try and extract the math equations, have a look at g_combat.c. Entry point is G_ClientShoot. HELP APPRECIATED, I SUCK AT MATH

Been looking at this at work today.  I have a couple ideas:

1.  Instead of 10x, what if we set up a delta value.  We run it once to get a base value and if the 2nd run is within the deltaof the first value we just return the average of the two.  If it isn't, we keep running up to 10x until the average is within the delta. 

For example:
delta = 10
run 1: damage = 100
run 2: damage = 94 (avg 97)
returns 97

or
run 1: damage = 100
run 2: damage = 25 (avg 62.5)
run 3: damage = 44 (avg 56.3)
return 56.3

2.  Personally, I like the project management time estimation formula ( (worst case + best case + 4x most likely) /6 ) So we'd run it at least three times.  Take the best, worst, and average.  Then put it through the formula.  The 2nd example above would return 58.3.

AI_HideNeeded
...
Now, this function is what cause the MAJOR fan-out disaster of doom. If you exclude the changes in this function, the AI is fast enough to play, but here we fan-out again, ontop of our 160x worst case scenario. For every of those leaves we check the damage possible for every enemy. Yes, that's another set of the same fan-outs we had up to this point (we just have num_enemies, not num_enemies+civilians). So that's a worst-case scenario of 8, bringing our fanout up to 8x10=80. Since this is in sequence with the damage calculations, this is multiplicative bringing the total amount of leaves to 160x80=12.800 for a worst case scenario. Yes, this is the point where the CPU just shrieks and tries to liftoff. And don't forget, the shooting calculations are a whole lot heavier than any other calculation we ever do.
Obviously, this would need to be another place were we need to improve quite a bit if we still intend to perform full-tree non-heuristic searches. Only checking only vs enemies that have a direct line of sight would be a first step (but that would make us oblivious to indirect-fire nades/launchers). Other than that, I can't see many ways to keep this functionality and still preserve a full-tree searching. The performance of this function is mainly influenced from the AI_GetDamagePotential function, so any performance gain (in fan-outs) there affects this function in a sqrt kinda of way (8x8 vs (8-Y)x(8-Y)).

And a couple for this as well:

1.  Still go through every actor, but only do the calculation if the actor is visible or has a grenade/launcher weapon.

2.  Maybe if one of the 10 calls to G_ClientShoot returned a value higher than the  HP * GUETE_DAMAGE_AVOID_FACTOR, that would be enough for them to hide.  So stop looping if that happens and just make them hide. 

7

Coding / Re: the AI discussion

« on: July 07, 2010, 02:50:59 pm »

I did notice that the AI_Run is called on ServerFrame events, and only 1/10 of them is utilized. ActorThink is called way more than 8 times in the aliens turn, so that's the first place to start.
What are serverframes, when is AI_Run really called and why do we have to call ActorThink more than once for any alien is the issues I will solve...

Just to save you a few minutes, I threw in some breakpoints and this is what I found:

ServerFrame is called every second no matter if it is the alien, civilian, or players turn.  90% of the time, it just returns (as you already noted).    The other 10%, it figures out if it's an AI players turn to move and then moves 1 player and then returns.  So one AI player every 10 seconds.

From what I could tell, ActorThink is called for every alien and every civilian.  That may be why you are getting more than 8 calls per turn.  The good news is that with the new super smart aliens, the civilians die in the first turn so there are less of them to calculate.

I was getting a lot of assertion errors in dbuffer.c so I could never finish an alien turn completely so this might not be 100% accurate.  When I get home I'll update from svn and see if that issue has been resolved.

8

Windows / Re: make_UfoAI_win32 (all in one win32 build script)

« on: July 06, 2010, 10:39:06 pm »

Don't know why, but if you go into src/client/renderer/r_main.c and comment out these lines, it'll load:

Code: [Select]

Com_Printf("using GL_ARB_framebuffer_object\n");
Com_Printf("max draw buffers: %i\n", r_config.maxDrawBuffers);
Com_Printf("max render buffer size: %i\n", r_config.maxRenderbufferSize);
Com_Printf("max color attachments: %i\n", r_config.maxColorAttachments);

At least, it loaded for me.  My ufoconsole.log file ended with "max render b" and that let me to the printout error.  I hope it helps you too.  Technically, I should probably find out why but codeblocks debugger isn't stopping at that break point.  Gonna try eclipse now.


Update:  Ok, now I'm confused.  I tried figuring out why the lines were causing it to hang and put the lines back in and everything is still working.  I'll let you know if it happens again.

9

Windows / Re: make_UfoAI_win32 (all in one win32 build script)

« on: July 06, 2010, 09:17:26 pm »

Just tried building from trunk yesterday for the first time and couldn't get it to load.  I figured it was something I was doing incorrectly (still could be) since 2.3 did build and run correctly.  My ufoconsole.log is identical to the one above.  The progress bar on the main loading screen never progressed.

Windows XP

10

Coding / Re: the AI discussion

« on: July 06, 2010, 04:42:06 pm »

Just as a preface, I'm not that great at C, but it looks like if G_ClientShoot returns false, you don't have to call it 9 more times.  The only time it returns false is when no shot is generated.  If it wasn't a mock shot then it could return false if the reaction fire kills you, but since this is mock, that isn't going to execute.  I doubt that saves much CPU though since all the hard math comes after those checks. 

You might want to experiment with breaking out of the if(shots) if it returns false since 0 shots should land.  That might not be valid though since the AI actor could run out of ammo.

I hope that helps a little.  I tried building trunk last night and it hung on the loading screen.  Going to try again tonight.

11

Coding / Re: the AI discussion

« on: July 02, 2010, 04:01:23 pm »

I'm not any type of authority   I just saw that while browsing through some of the files and figured I'd try and help.

12

Coding / Re: the AI discussion

« on: July 02, 2010, 03:37:16 pm »

Hey, can I somehow remove the fog of war?

I'm at work right now so I can't play to test it, but I think this:

#define G_IsVisibleForTeam(ent, team) ((ent)->visflags & G_TeamToVisMask(team))

line in g_local.h (line 187) can be changed to true.

13

Coding / Re: the AI discussion

« on: July 01, 2010, 04:32:52 pm »

Thanks for the cool graphs and wiki page with the summary of the stuff above. 

Looking at them and the g_ai.c file, it looks like the current AI works the same no matter what difficulty level you are playing at.  That will be good to know when I play some harder campaigns later.

14

Coding / Re: the AI discussion

« on: June 30, 2010, 09:23:24 pm »

I would love to help you test this out.  It sounds like a lot of fun actually.  Is there a certain build I need to get to start messing around?  Also, is there a way to either save a video or another build that stores the movements of all the players and enemies?  That seems like it would help a lot with testing this.

One question I have about the GUETE_ metrics.  Would it be possible for the aliens to modify them as the game progresses?  I have absolutely no AI programming knowledge but here is what I'm thinking: 

Let's say that the very first mission all the aliens start at the default setting and the game keeps track of all the damage they do to players and civs.  They keep it like that for a few missions to get a good average damage.  Then maybe the game bumps up GUETE_KILL (or another stat) for a few missions and see if the average damage increases.  If so then they change the default to that and start modifying another attribute.  If it decreases then they drop it back down but remembers that the particular combination of values didn't work so it knows not to try again. 

15

Discussion / Re: Thank you!

« on: June 28, 2010, 06:39:51 pm »

Yes, the game is amazing.  Thank you!

I just checked out the alternate HUD.  Very cool.