[http://sourceforge.net/p/ufoai/bugs/2085 Item 2085] imported from sourceforge.net tracker on 2013-01-28 19:18:54

Hi,

This is the specs of my mobile lappy which i carry ard with the SVN
R23824.

System - WIN XP SP3, Internal 256MB Geforce, 768MB Ram, 1GHz Processor, HP
Laptop.

Self Compiled the SVN R23824 couple of days ago and continues to Beta test.
Encountered this issue:

At one of the maps - Crashed UFO, civilians appear out of map.....
===== Comments Ported from Sourceforge =====

====== odiewoof (2009-04-03 09:26:39) ======

Out of Map 1
====== odiewoof (2009-04-03 09:27:14) ======

Out of Map 2
====== tlh2000 (2009-04-04 06:23:15) ======

that's a pathfinding issue
====== aduke1 (2009-06-05 20:19:59) ======

Odie,
did this happen just *once* ?
was it at gamestart or after a couple of turns ? (ie. did they walk there ?)

====== odiewoof (2009-06-06 05:34:54) ======

Okie, this happens every now and then. But after much review, and forum chat, i believe it boils down to that BIG BUG - Pathfinding. Maybe we can keep this artifact as shelved first, and continue working on the pathfinding issue.

:D
Thanks. And oh for the record, its usually after a couple of turns. Never did i see any at the start of game (though i am not in skirmish mode, and my LOS dont cover so much area....). AFAIK, its always after a few turns, and this can ultimately crash the game (return to console..... with the very common crash game log.....)
====== aduke1 (2009-06-08 21:13:12) ======

I fear it's not just 'one big bug'. Pathfinding still has several bugs :( So working on this one is as good as any other pf bug...

I *assume* that there are no civ starting points in the void, so the civs must have *walked* there (and then got stuck ?). So keep an eye on the civs. It would be nice if you could actually watch them walking there during their turn.

3Q:
1. The pics show the civs at the 'upper right' border (ie. positive X) of the map. Do the pics show the startup orientation of the map or did you *turn* the map since startup ?
2. Does it always happen on a specific side of the map ?
3. can you confirm that the civs are *stuck* there, ie. did you ever see them walk out of that pos again ?
====== odiewoof (2009-06-09 02:15:04) ======

Hi Duke,

Regarding earlier note, here's what i can remember:

I *assume* that there are no civ starting points in the void, so the civs
must have *walked* there (and then got stuck ?). So keep an eye on the
civs. It would be nice if you could actually watch them walking there
during their turn.

(Regarding this, I cannot be 100% ascertain for that revision. But so far, i have not seen any civi in LOS @ start [turn 1] and got there. It usually happens when 1 or 2 end of turn has passed). Actually, i tried to zoom maxed out so i can 'try' to catch any movements..... Is there actually a way in DEBUG mode (i compile all in debug) where i can see all 'aliens + civis' so that i can track??


On your 3Q:
1. The pics show the civs at the 'upper right' border (ie. positive X) of
the map. Do the pics show the startup orientation of the map or did you
*turn* the map since startup ?
(I am almost very sure that i have somehow rotated the map..... i have a bad habit of always rotating my maps. I will take note of this for subsequents submissions).

(For the record of that map, its rotated for sure. Just that i do not rmbr the angle turned.)

2. Does it always happen on a specific side of the map ?
(For those revisions, yes, usually ends up on my 'right' side..... i have even seen aliens stuck there. Then again, i have rotated my maps.....)

3. can you confirm that the civs are *stuck* there, ie. did you ever see
them walk out of that pos again ?
(No. I never got to see them walking out. Reason? It usually crashed to console / geoscape after 2 more turns.....)
====== wilminator (2009-06-09 02:37:31) ======

Odiewoof,
Have you compiled with the latest SVN (24629)? I have noticed that Duke and I have both made a couple changes that may affect the civies and the aliens in the walls.

As far as the game crashing on you, I've had that happen too. I'm trying to figure out what causes it; I'm usually moving around the map when it happens.
====== wilminator (2009-06-09 02:44:45) ======

I'm merging ticket 2793166 into this one:


See http://ufoai.ninex.info/forum/index.php?topic=3584.msg26174#msg26174 :

I've seen that too but they can "hide" on a "no moveable tile"
I tried to capture an alien and searched for it and i found it on his own
ship.
But this tile is normaly not moveable
====== aduke1 (2009-06-09 21:58:53) ======

Odie,
I'm pretty sure I've seen some cvar that allows you to see every actor on the map. Unfortunately, I don't remember where...
It would also be helpful if you could
- determine the xy-positions of the civs (using 'debug_map 3')
- dump the routing to CSV (using....uhm...wilminator ???)

wilminator,
I have a suspect. In RT_UpdateConnection(), around line 1280, the second reset conn&stepup uses the wrong dir. It lacks the 'dir ^ 1'.
I know it's wrong, but I could not yet map it to any bug reported. I guess that bug is more likey to cause blocking of walkable places rather than opening non-walkable places (civs bug). Not sure though.

For *half* of the dirs, the wrong results caused by the bug will be auto-corrected by subsequent calls to RT_UpdateConnectionColumn() due to the method we work our way through the map.
(That's why the orientation of the map is so important, Odie)

Also keep in mind that we might be tracing from *outside* the map *into* the map because mins/maxs are a little off (remember that 'CSV-files differ in size'-thingy ;)

====== wilminator (2009-06-10 04:09:40) ======

Odiewoof,
- dump the routing to CSV (using....uhm...wilminator ???)
Use debug_sroute and debug_croute. This will create ufoaiserver.1.walls.csv and ufoaiclient.1.walls.csv in the same directory as your ufoconsole.log file; mine is in C:\Documents and Settings\<username>\Application Data\UFOAI\2.3-dev\base.

Aduke1,
Good eye- please commit that change. My source is a mess from trying to work on doors being located incorrectly in game.
====== odiewoof (2009-06-10 04:40:38) ======

Hi,

I have just compiled 24629. Yet to test it. Curious, do i need to clean compile the maps (aka "compile_maps.bat /clean" parameter?) I have done it w/o the clean..... assuming that ufo2map did not change. Or that it will auto pickup the changed maps.

In addition, I will take note of the debug_sroute and debug_croute. Where do i type it btw? On the console when i am in battle (during battle, start of battle, when hung or when crashed out back to console? Or the moment i see this happening now? :D)


=============
Oh and hope u found that actors causing crashing to desktop issues. :D

On that, i noticed it usually crash out when i try to move / aliens moving. Could it be that it moved onto a &#039;bomb&#039; tile (impassible or invalid tile) tat caused this? Maybe we have some of that issue..... juz a wild guess since i saw a couple of related issue with tiles not supposed to be passable but causing issues. :D
====== tlh2000 (2009-06-10 05:32:53) ======

maybe this is fixed in 24658? move move length return values weren&#039;t checked so an edict could maybe walk to an unreachable location.
====== aduke1 (2009-06-10 22:46:09) ======

wilminator,
I committed the fix. Any idea what it actually fixes ??

odie,
you can issue debug_*route any time between start of battle and crash to geo.
And yes, after a significant change to ufo2map (like rev 24662) you&#039;ll need to use /clean to apply the change to all maps.
====== wilminator (2009-06-11 00:22:35) ======

aduke1:
It fixes the backtrace for skipped cells. ufo2map defaults to all 0 values, so this *should* not have an effect there- it is meant more for ufo.exe, where the values need to be fixed because of a breakable moving or disappearing. But I wouldn&#039;t put it past the code that this will help fix some of the zig-zag through walls that were out there, if my last commit didn&#039;t get them.
====== tlh2000 (2009-06-29 19:06:53) ======

this might also only be client side issue that is maybe already fixed with the event timing fixes i did a few days ago.
====== sf-robot (2009-07-15 02:20:33) ======

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).