project-navigation
Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - dodon

Pages: 1 2 [3] 4
31
Bugs in older version (2.3.1) / Re: Alien AI
« on: July 09, 2010, 08:17:55 am »
after i moved with my first soldier from room to room in the house, the alien start RF shooting on my soldier outside, but there was a big wall between the alien and my soldier. this damn alien shouldnt seen him moving but he did, the AI use a wallhack ><

...

 i dont understand why a AI use a different RF as my troops!?

The RF code works for both sides the same way. And there is a test to hit in it.
So you more likely hit this bug: Reaction Fire - End Turn

32
Tactics / Re: Reaction Fire
« on: July 09, 2010, 08:06:37 am »
good breakdown :)

I think you missed the following (I work with trunk so there might be differences):

Mind or speed skills are meaningless for RF.
Soldierstats influence the chance to hit.


There are no random parts, RF is fully predictable (and thus avoidable by AI).
And the player can do the same :)


2. chance to hit is smaller than 30%
3. friendly fire possibility greater than 5% (depending on mental state higher)
I thinkthats the chance to hit with atlast one bullet, so burst mode improve the chances.


2. chance to hit is smaller than 30%
that seems to be the most important part for the RF not happening. Good soldiers and precise wappons  improve that chance

This means, the alien can move freely and even attacking multiple times, without triggering RF, as long the AI takes it out of line of sight in the end.
The code works for both sides the same way ;)


I'm not sure, if this TU recalculation on attack should happen at all
I think thats a bug


you missed the part where the react "reaction TU" are not reset after a shot so the next shot takes place on the "next step"
There is no test for reaction fire after crouche and turne.

33
Coding / Re: Assertions in dbuffer.c
« on: July 08, 2010, 09:04:16 pm »
the round end bug must be thread related, too (rounds get ended without user hitting e)
Weren't the buffers unsed to transmit data between client and server?
I compiled the the debug version with free buffer treshold = 0 and got the poblem, that one thread grabed a buffer that an other thread released.
With a higher threshold value it is more likely, that two threads grabed the same buffer and corrupted their message.


feedback is welcome than welcome
I'll test it on monday, no time till then.



34
Coding / Re: the AI discussion
« on: July 08, 2010, 08:30:43 am »
Mattn/other people that work on g_combat.c: What's the real use of the mock shots? Can we ninja-in the mock structure (and the shooting code) values that would stop us from having to sample shots?
It's not so much as the base dmg (we could easily estimate that) nor the % to hit (we could use the UI estimation function). It's the LOF issue which we cannot substitute with LOS. And remember, we don't deal with only one LOF, we deal with a 'window' to the target, since we don't always hit spot on and that's where the partial cover really comes into play (I guess we could skip the window calculations in favor of speed without sacrificing a lot).

I encountered the mock shots in reaction fire. 100 of them are used to calculate the chances to hit and the chances of friendly fire. I think there is also a formula to calculate partial visibility.

35
Coding / Assertions in dbuffer.c
« on: July 07, 2010, 10:18:56 pm »
In the recent trunk versions I encountered several assertions in dbuffer.c while in battlescape. Most of the time in my second turn.

The location of the assertions change but the circumstances are similat to this code (I changed the code to highlight the problem):

Code: [Select]
static struct dbuffer_element * allocate_element (void)
{
struct dbuffer_element *e;

if (free_elements == 0) {
struct dbuffer_element *newBuf = Mem_PoolAlloc(sizeof(struct dbuffer_element), com_genericPool, 0);
newBuf->next = free_element_list;
free_element_list = newBuf;
free_elements++;
allocated_elements++;
} else {
assert(free_element_list);
}

...
}


The important detail is: when the assertions happens, the value of free_elements is 0 although it should not be 0.


The only way i came up to get such a result is a second thread which accesses an other function in dbuffer.c and channges free_elements. I did some other tests that confirm my assumption.


What's the general strategy to handle multiple thread access of resources in Ufo AI ?
What's the best way to secure the global data in dbuffer.c ?

36
Coding / Re: the AI discussion
« on: July 07, 2010, 03:20:23 pm »
I was getting a lot of assertion errors in dbuffer.c
I investigated this. Have no time now, will post later.


When I get home I'll update from svn and see if that issue has been resolved.
not likely

EDIT:
Assertions in dbuffer.c

37
Coding / Re: the AI discussion
« on: July 02, 2010, 09:31:15 pm »
If this 'error'/'new behavior'  was introduced into a patch, how come nobody went 'omg aliens are cowards now'?
The "hiding is good" part was always there. And the second part was added to make the aliens more visible.


Getting stabbed is now quite popular, aliens will not cower in a bungalow close to you never to come out again.
As the new behaviour needs high morale the aliens will hide again, when the casualties rise.


attached the above change as a diff
Ugh, missed that step yesterday  :(

38
Coding / Re: the AI discussion
« on: July 02, 2010, 12:13:26 am »
if (AI_HideNeeded(ent) || !(G_TestVis(hidingTeam, ent, VT_PERISH | VT_NOFRUSTUM) & VIS_YES)) {
         /* is a hiding spot */
         //bestActionPoints += GUETE_HIDE + (aia->target ? GUETE_CLOSE_IN : 0);
         bestActionPoints += guete_hide->integer + (aia->target ? guete_close_in->integer : 0); //AI TESTING MODIFICATION FROM NONICKCH
      }

I dug through the archive and i figured out whats wrong.


first occurence is ok
Code: [Select]
/* hide */
if (!(G_TestVis(-ent->team, ent, VT_PERISH | VT_NOFRUSTOM) & VIS_YES)) {
/* is a hiding spot */
guete += GUETE_HIDE + (aia->target ? GUETE_CLOSE_IN : 0);
} else if (aia->target && tu >= 2) {


then a todo was added:
Code: [Select]
/* hide */
/** @todo Only hide if the visible actors have long range weapons in their hands
* otherwise make it depended on the mood (or some skill) of the alien whether
* it tries to attack by trying to get as close as possible or to try to hide */
if (!(G_TestVis(-ent->team, ent, VT_PERISH | VT_NOFRUSTUM) & VIS_YES)) {
/* is a hiding spot */
bestActionPoints += GUETE_HIDE + (aia->target ? GUETE_CLOSE_IN : 0);
/** @todo What is this 2? */
} else if (aia->target && tu >= 2) {


the next step is an implementon of the todo:
Code: [Select]
/* hide */
/** @todo Only hide if the visible actors have long range weapons in their hands
* otherwise make it depended on the mood (or some skill) of the alien whether
* it tries to attack by trying to get as close as possible or to try to hide */
if (!(G_TestVis(-ent->team, ent, VT_PERISH | VT_NOFRUSTUM) & VIS_YES) || AI_NoHideNeeded(ent)) {
/* is a hiding spot */
bestActionPoints += GUETE_HIDE + (aia->target ? GUETE_CLOSE_IN : 0);
} else if (aia->target && tu >= TU_MOVE_STRAIGHT) {
this code is ok,


but if you look at the AI_NoHideNeeded
Code: [Select]
/**
 * @param ent The alien edict that checks whether it should hide
 * @return true if hide is needed or false if the alien thinks that it is not needed
 */
static qboolean AI_NoHideNeeded (edict_t *ent)
you realize that the description of the @return and the function name don't match. So AI_NoHideNeeded changed to
Code: [Select]
/**
 * @brief Checks whether the given alien should try to hide because there are enemies close
 * enough to shoot the alien.
 * @param ent The alien edict that should (maybe) hide
 * @return @c true if hide is needed or @c false if the alien thinks that it is not needed
 */
static qboolean AI_HideNeeded (edict_t *ent)
and our hiding code now is:
Code: [Select]
/* hide */
if (AI_HideNeeded(ent) || !(G_TestVis(-ent->team, ent, VT_PERISH | VT_NOFRUSTUM) & VIS_YES)) {
/* is a hiding spot */
bestActionPoints += GUETE_HIDE + (aia->target ? GUETE_CLOSE_IN : 0);
} else if (aia->target && tu >= TU_MOVE_STRAIGHT) {
and that is error, the name of the function in this context was right. So now there is a "!" missing. The code realy should look like:
Code: [Select]
/* hide */
if (!AI_HideNeeded(ent) || !(G_TestVis(-ent->team, ent, VT_PERISH | VT_NOFRUSTUM) & VIS_YES)) {
/* is a hiding spot */
bestActionPoints += GUETE_HIDE + (aia->target ? GUETE_CLOSE_IN : 0);
} else if (aia->target && tu >= TU_MOVE_STRAIGHT) {


the last change has no problems so the code should be
Code: [Select]
/* hide */
if (!AI_HideNeeded(ent) || !(G_TestVis(hidingTeam, ent, VT_PERISH | VT_NOFRUSTUM) & VIS_YES)) {
/* is a hiding spot */
bestActionPoints += GUETE_HIDE + (aia->target ? GUETE_CLOSE_IN : 0);
} else if (aia->target && tu >= TU_MOVE_STRAIGHT) {

---------------------------------------------------------------------------------------------------------------------------


Now let's take a closer look at AI_HideNeeded
Code: [Select]
/**
 * @brief Checks whether the given alien should try to hide because there are enemies close
 * enough to shoot the alien.
 * @param ent The alien edict that should (maybe) hide
 * @return @c true if hide is needed or @c false if the alien thinks that it is not needed
 */
static qboolean AI_HideNeeded (edict_t *ent)
{
/* only brave aliens are trying to stay on the field if no dangerous actor is visible */
if (ent->morale > mor_brave->integer) {
edict_t *from = NULL;
/* test if check is visible */
while ((from = G_EdictsGetNextLivingActor(from))) {
if (from->team == ent->team)
continue;

if (G_IsCivilian(from))
continue;

if (G_IsVisibleForTeam(from, ent->team)) {
const invList_t *invlist = RIGHT(from);
const fireDef_t *fd = NULL;
if (invlist && invlist->item.t) {
fd = FIRESH_FiredefForWeapon(&invlist->item);
} else {
invlist = LEFT(from);
if (invlist && invlist->item.t)
fd = FIRESH_FiredefForWeapon(&invlist->item);
}
/* search the (visible) inventory (by just checking the weapon in the hands of the enemy */
if (fd != NULL && fd->range * fd->range >= VectorDistSqr(ent->origin, from->origin)) {
const int damage = max(0, fd->damage[0] + (fd->damage[1] * crand()));
if (damage >= ent->HP / 3) {
const int hidingTeam = AI_GetHidingTeam(ent);
/* now check whether this enemy is visible for this alien */
if (G_Vis(hidingTeam, ent, from, VT_NOFRUSTUM))
return qtrue;
}
}
}
}
}
return qfalse;
}


If I am right only brave aliens (when they are threatened by enemy fire) ever feel the urge to hide.
It looks like the code is stuck somewhere between the implementation of AI_HideNeeded and AI_NoHideNeeded.


This code should work fine.
Code: [Select]
/**
 * @brief Checks whether the given alien should try to hide because there are enemies close
 * enough to shoot the alien.
 * @param ent The alien edict that should (maybe) hide
 * @return @c true if hide is needed or @c false if the alien thinks that it is not needed
 */
static qboolean AI_HideNeeded (edict_t *ent)
{
/* only brave aliens are trying to stay on the field if no dangerous actor is visible */
if (ent->morale > mor_brave->integer) {
edict_t *from = NULL;
/* test if check is visible */
while ((from = G_EdictsGetNextLivingActor(from))) {
if (from->team == ent->team)
continue;

if (G_IsCivilian(from))
continue;

if (G_IsVisibleForTeam(from, ent->team)) {
const invList_t *invlist = RIGHT(from);
const fireDef_t *fd = NULL;
if (invlist && invlist->item.t) {
fd = FIRESH_FiredefForWeapon(&invlist->item);
} else {
invlist = LEFT(from);
if (invlist && invlist->item.t)
fd = FIRESH_FiredefForWeapon(&invlist->item);
}
/* search the (visible) inventory (by just checking the weapon in the hands of the enemy */
if (fd != NULL && fd->range * fd->range >= VectorDistSqr(ent->origin, from->origin)) {
const int damage = max(0, fd->damage[0] + (fd->damage[1] * crand()));
if (damage >= ent->HP / 3) {
const int hidingTeam = AI_GetHidingTeam(ent);
/* now check whether this enemy is visible for this alien */
if (G_Vis(hidingTeam, ent, from, VT_NOFRUSTUM))
return qtrue;
}
}
}
}
return qfalse;
}
return qtrue;
}

What do you think?
It's quite late and I hope there are not too many errors in this post.

39
Tactics / Re: Reaction Fire
« on: June 28, 2010, 10:45:28 pm »
...RF is NOT bugged. ...
as it roughly behaves like this description, does not damage other parts of the game (with aborts, memorycorruption, segfauilts...) and is quite predictable for something with several random parts.


... Seriously, I saw reaction fire was bugged ...
as it has contradicting code, miscalculations, some parts of this description are not implemented.

Disclaimer:
My tactic does not rely on RF, but it works quite well, when I need it.
I play with the trunk-version and spent some time looking at the RF code (so I'm quite shure about the bugs)

40
Coding / Re: the AI discussion
« on: June 28, 2010, 10:30:05 pm »
The AI is quite weak and we should improve it.
So here are some random thoughts


I have not noticed MedPacs in your description. Are they missing?


a) Aliens stupidly home in towards the closest phalanx member. They will promptly get stuck in a corner only 2-3 steps away from plasmablade-stabbing my squaddie in the face. This gets worse when there are aliens in their spaceship where they will clump on the other side of the hull where a squaddie is taking cover.
After I noticed this, my successrate went up :)


That's limiting the tactical abilities quite a bit. I think this is quite obvious in the landing standoffs where you and the aliens are facing each other. Instead of thinning out your numbers before trying to get cover, each of the aliens shits it's pants individually and runs for cover.
I think the aliens go for the civilians (easy to hit/kill (no armor) + good place to hide(won't fight back if not killed))
So this might need some rebalancing


Also note the huge values of the bonuses like hide. 60!
I would judge the hidingplace by these questions:
  • can a Human kill me in the next turn?
  • can a Human hurt me in the next turn?
  • am I able to attack a Human in the next turn?


Do you remember my gripe about the aliens sticking to the other side of the hull of the ship when my squaddie is right next to it? I believe we can trace this behaviour down to the closing distance scoring. Notice that I do mention in the diagram that the distance used is the Vector, not the pathing distance. Combine this with the fact that the AI cannot possibly plan for more than one turn (we only ever check where we can go only this turn) and the scoring ends maximizing behind the wall because it is close by absolute distance and no other reachable spots produce anything with a better score (we're already hidden and can't reach to shoot someone). Obvious solution to this is to factor in the path distance aswell. Replacing vector with just path *might* be counter-productive since it usually also means firing distance when no walls are involced. This is probably worth checking in the immediate future.
I would describe this action as go near a place where I can use my wappons in the next turn. And different wappons call for different actions:
  • meelwappon: shortest path to a square adjacent to a human (never tried it, but I thought about stabbing through a window)
  • direct fire: shortest path to a square with line of sight to a human
  • indirect fire: ?


If I had do improve the AI I'd
  • fix the fire through wall bug
  • improve the "pathfinding"
  • refacture the bad code (reload, equipt wappon, ...)
and then check the new behaviour.

41
Bugs in older version (2.3.1) / Re: wrong TU visual in HUD
« on: June 26, 2010, 02:26:43 am »
Autostand/Autocrouch was not on.
I doubt that.
The autostand feature is by dafault on (you can change it under options, gameplay) and the movement you describe here is exactly what autostand does.
... he uncrouches, walks over, crouches and still has 3 TUs left. ...

The problem with the displayed TUs is, that it ignores the autostand option and calculates the TUs always as crouched movement.

Example for the movement (all soldiers started with 30 TU, crouched at the border of the map and move in a straight line):

1. top soldier:
  • manualy uncrouch 3 TU
  • walk 12 squares 24 TU
  • manualy crouch 3 TU
2. soldier in the middle(autostand: no)
  • 10 squares crouched movement TU 30
3. bottom soldier(autostand: yes)
max movement for 30 TU: :
  • auto uncrouche 3 TU
  • walk 10 sqares 20 TU
  • auto crouche 3 TU
manualy spend the remaining 4 TU for an other square crouched movement (and still 1 TU left)

42
Discussion / Re: reaction fire fix?
« on: June 24, 2010, 02:41:38 pm »
could someone post full reaction fire spec for the old vs new system, I mean i would like to know how the old one worked, and how the new one works, thank you
use the search in the Contribute section, there are several pages that discuss what was changed and why it was changed.


I had 8 guys standing at the entrance of a UFO, 6 had plasma rifles, 2 had plasma blasters. An ortnok popped out, killed one of my guys and popped back in and no one fired.
6 guys pointing at the door of a UFO. 2 had double pistols, rest had rifles ... 3 aliens pop out and shoot at me. Of the 6 guys pointing at the door, only one of the ones that had a pistol fired back. So maybe it's just rifles?
the TUs of the fire mode affect when a soldier fires, so selecting an apropriate wappon/firemode might help


additional notes (if I remember the sourcecode correct)
  • the soldiers don't waste ammunition, so if the chances to hit are to low, they don't shoot (so experienced soldiers and an apropriate wappon/firemode might help)
  • the soldiers don't harm friendly units or civilians, if the probabillity to hit one of them is to high they don't shoot


.... But: reaction fire is broken ...
No it is not, but in 2.2 it was broken - it was way to powerful ;)

43
Should be fixed

from the patchtracker:

Quote
Apply in r30082 and r30084 to trunk and 2.3 branch



44
it is of by 1  (kill actor "2" and actor "1" gets disabled)

I had a look at the code but the obvious fix has some other issues.

I have to think about a good solution.




45
@Edi
     the new behaviour was introduced in r29675. It does not hang, it is very slow. (the missing *.mdx-files are calculated)

     As a workaround turn GLSL shaders off.


@Duke
     add
     -lmingw32 -lSDLmain -lSDL -mwindows
     to Other Linker options

     Then it does compile.
     But there is something else  wrong - on my mashine ufomodel can't find texturefiles

Pages: 1 2 [3] 4