UFO:Alien Invasion
Archive => Bugs prior to release 2.3 => Topic started by: scamp on April 20, 2009, 06:07:14 pm
-
I had a farm map today and during the night had a lot of trouble to path. It seemed like my soldiers were not pathing into some dark places once they went into "light" places ( during the night, some buildings have lights... once my soldiers were in they couldn't move out of it again ). Luckily I had 1 patrol sniper in the back which hadn't been anywhere and I could send her step by step close enough to the enemy ship, but otherwise I would have had to cancel the mission : My soldiers simply didn't move where I wanted them to move.
I'm not 100% sure it has to do with light , but I could physically 'see' where my soldiers would probably still go due to it being lighter, and they did. They just didn't want to move into the darker pieces of the map ( there weren't walls or anything, nothing barring them to go there, just their own 'fear of the dark' I guess :) Like I said before, 1 of my soldiers managed to move where my other soldiers could not, so it's not like they could not move there ( another soldier could ? )
-
It is a known problem. Devs are already fighting with it. This has stopped the whole project for a while now [2-3 weeks]
We all hope it will be fixed soon.
-
Ah, didn't know, haven't read the whole dev thingie yet. Maybe there's a problem in the 'lighting-check' somewhere then ?
Anyway, if more people report their pathing issues, that should help developers in the right direction I suppose ?
-
Ok , today took some screenshots. The pathing bug is definately related to the mapping. The way the map pieces are 'bound together' creates the pathing error in some way. It's visible on the screenshots as a little line between the map 'zones'. I can upload these screenhots if needed. But it's definately a mapping issue, not a pathing issue.
-
Ok , today took some screenshots. The pathing bug is definately related to the mapping. The way the map pieces are 'bound together' creates the pathing error in some way. It's visible on the screenshots as a little line between the map 'zones'. I can upload these screenhots if needed. But it's definately a mapping issue, not a pathing issue.
How do you know that? Did you debug the pathfinding code? Did you check the maps in uforadiant? Screenshots cannot say this, I'm sure. Maybe the map tiles are not matched correctly when the sys assembles the PATHFINDING-MAP. Maps didn't change much for quite a long time and If Richlv says they're okay, I believe it. ;)
-geever
-
Sure, geever, but anyway I see the same strange little line scamp mentioned, outlining exactly (!) the impassable area(s). I never noticed those before pathfinding broke.
Maybe the map tiles are not matched correctly when the sys assembles the PATHFINDING-MAP
At least it is an interesting side-effect, that the map reflects problematic zones.
Do you have a hint, if/how we can make further investigations? I'd bet there's something hidden in this context!
Something within the map makes the pathfinding believe, there's an obstacle - an unlinked chain, a height difference? Strange enough, that these areas are quite large and connected to an outline which is "straight-ahead", not curvy. May be at last it's similar to the good ole Pentium thingy (4 : 2 = 1,99999873)?! ;D
-
Pathfinding is a black magic, only Wilminator and Duke nows that, and sometimes they loose the way either. ;)
-geever
-
I'm sure that it's not a map issue.
The RMA is composed of maptiles. The 'routing' part of the pathfinding code has then to recalculate the connections along the borders of the tiles. And that's exactly the code we're still having some issues with...
-
I'm sure that it's not a map issue.
The RMA is composed of maptiles. The 'routing' part of the pathfinding code has then to recalculate the connections along the borders of the tiles. And that's exactly the code we're still having some issues with...
Ah ok , admittedly I know nothing of the code , it's just strange that the pathing issue is visible on the map as a small dotted line for some reason. Maybe it would help to know why this line is formed during the initial map build ( because it seems static after the initial map has generated ) and that might solve the pathing issue. Let's all hope that Duke and his team finds the bug , this mapping issue makes testing 2.3 very hard. I had an alien who didn't even try to shoot me or lob a grenade and he was 2 tiles away , I guess his AI said "knife him" but there was no path from that alien to my squad.
-
...Duke and his team...
LOL. I'm still a noob here. The pathfinding code is the *only* part of the code that I understand to some extent. However, the fact that was able to assist wilminator a few times seems to have earned me quite some respect from those devs who have already contributed much more to this project. Thx guys :) *bows*
@scamp:
The dotted line may or may not be a map issue. If you post a good screnshot of it, richlv probably can tell you.
-
good enough?
(http://pic.leech.it/t/c3259/74bb9505ufo00.jpg) (http://pic.leech.it/pic.php?id=74bb9505ufo00.jpg)
I can't get into this upper square, I've marked some ends of the lines also!
-
Yup ! Good enough.
Those lines shouldn't be visible imho.
richlv ?
-
Ye borsti posted a pic where the lines are pretty obvious. That's the lines I was talking about :)
-
for the record, i don't read forum much, so if somebody wants my input, ping me on irc (like borsti did ;) )
as for the issue, i have tested farm map several times. i managed to see lines like that a few times, but they are barely visible for me, and only at some angles, as if tiles are misaligned for a pixel or two. i suspect this to be a renderer issue, and not connected to the pathfinding problems (unless tiles are misaligned enough to cause pathfinding issues, which i don't view as a likely cause)
as for the cause of inpassable tiles, i think duke is correct - this gotta be pathfinding, maps indeed haven't changed in a notable way since pathfinding merge. and given that even non-rma maps have pathfinding issues, i'm pushing the blame here ;)
-
@richlv:
Good to know that you don't read the forums too much. Unfortunately I don't use IRC.
We are a great community, so it'll work out somehow. Thx, Borsti :)
I already took the blame. It's pathfinding imho.
However, those lines shouldn't be visible. I remember that I did NOT see such lines when I toyed with the RMA village map some weeks ago, so it's probably not a general fault in RMA.
Just a thought: could it be some screen resolution thing ?
-
i think the intensity of the lines can depend on resolution, yes.
looking at them, it seems to be slight misalignment of individual tiles, but that's just a guess :)
-
This would explain, why the area behind this lines is unreachable. But on the other hand, the map wasn't touched for a long time, so why should there a misalignment NOW? Have there been changes in the way maps are "interpreted"?
There's only a few things I can think of:
- Due to some kind of standardization some edges haven't the same coordinates as before (rounding issue)
- The "geographical" and the "routing" map component sometimes (but why and where?) get an offset (e.g. one starts counting with 0, the other wit 1) so they don't match in the result
- different rounding algorithms in components above
-
I just tested with +farm and rev 24154.
1. I couldn't find a place where I couldn't walk (exept some stairs)
2. I saw those lines sometimes, especially when zooming out. When I zoomed in at them, they disappeared.
I could even make them disappear by scrolling. So the maptiles are properly aligned. What we see is a visual effect of two irregular textures side by side. Similar to the effect you get if your tapestry is not properly aligned.
Conclusion: plz retest with latest trunk and see if you any blocking.
-
24182
Pahtfinding +farm is working well
but most other maps just crash the game
> What we see is a visual effect of two irregular textures side by side
But then we shouldnt see a black line
I think the texture is set up to high
If ground is pixel 0 the texture seams to be set on pixel 3
'Couse if you change the angle of view the black line disappear.
[attachment deleted by admin]
-
In my tests yesterday I can confim all of the above:
- lines still visible, but not blocking
- unable to change the level / stairs don't work
- maps often crashed without any message
Updated to latest trunk a few minutes ago (24205), now compiling all maps agin (to be sure)...
-
I think the texture is set up to high
If ground is pixel 0 the texture seams to be set on pixel 3
from the mapping point of view, that's not possible - textures are applied to brush faces, so texture _is_ brush face (or ground in this case).
if there is no alignment error for the tiles themselves, then this is some rendering glitch or so.
-
again an update: Stairs work, but not those in the UFO?!
-
- maps often crashed without any message
Do those crashes still happen after you recompiled all the maps ?
Do they happen with both RMA and non-RMA maps ?
If so, please give me 2-3 names of non-RMA maps that crash.
-
please also define "crashing". ufo is shut down completely? you just return to the menu (if so - what is the console output)
-
Duke,
there was another crash, but I'm not sure what it was exactly (not reproducible). I'll have to do some more tests.
The latest one happened, when I tried to fire a grenade to an alien which was out of range. Strangely I've got no message about that, on screen simply nothing happened, so i left-clicked again - and found myself on the Windows-desktop... After that I checked the console-log: THERE was logged that I tried shooting. But that was the last message on console, nothing else (Mattn, this answers your question?).
uhm... I'm not very well versed in abbreviations, what's an RMA map?
-
1. mattn recently fixed some segfault with shooting at empty space or something - maybe you can try latest trunk (and always run trunk in gdb... see wiki for details)
also, that's not connected to pathfinding ;)
2. rma = random map assembly. essentially, maps that are compiled from multiple tiles. they appear in your console log as +name (having '+' in front of the mapname)
-
1. mattn recently fixed some segfault with shooting at empty space or something - maybe you can try latest trunk (and always run trunk in gdb... see wiki for details)
also, that's not connected to pathfinding ;)
Some segfault on shooting was still alive after that fix, that one is on the tracker and yesterday's IRC log.
-geever
-
always run trunk in gdb... see wiki for details)
Which wiki? ufo:ai-wiki gives no result when searching for "gdb". :P
At least I can start a debugging session from c::b, but this is quite inconvenient. I'd rather have a link in my start menu...
2. rma = random map assembly.
ah, thanks. Haven't seen any others yet, at least I wasn't aware of if. ;D
Well, updated to 24247, waited for the first mission (+farm) and it crashed right after starting the battle view.
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 5.2.1
Program received signal SIGSEGV, Segmentation fault.
At C:/Programme/Spiele/ufoai-2.3_dev/src/client/renderer/r_model_brush.c:894
Stack:
#0 004CD9EB R_LoadBspLights(mod=0x4bf06cc) (C:/Programme/Spiele/ufoai-2.3_dev/src/client/renderer/r_model_brush.c:894)
#1 004CF0C5 R_ModAddMapTile(name=0x22f480 "farm/f_silo", day=qfalse, sX=-40, sY=24, sZ=0) (C:/Programme/Spiele/ufoai-2.3_dev/src/client/renderer/r_model_brush.c:1098)
#2 004CFCEA R_ModBeginLoading(tiles=0x2eebdef "", day=qfalse, pos=0x2eed6b4 "", mapName=0x2eead24 "+farm") (C:/Programme/Spiele/ufoai-2.3_dev/src/client/renderer/r_model_brush.c:1190)
#3 00491A75 V_LoadMedia() (C:/Programme/Spiele/ufoai-2.3_dev/src/client/cl_view.c:215)
#4 004822A5 CL_RequestNextDownload() (C:/Programme/Spiele/ufoai-2.3_dev/src/client/cl_main.c:516)
#5 004DB07F Cbuf_Execute() (C:/Programme/Spiele/ufoai-2.3_dev/src/common/cmd.c:228)
#6 00482E0B CL_SendCommand() (C:/Programme/Spiele/ufoai-2.3_dev/src/client/cl_main.c:898)
#7 00483433 CL_Frame(now=97006, data=0x0) (C:/Programme/Spiele/ufoai-2.3_dev/src/client/cl_main.c:1048)
#8 004E49F8 tick_timer(now=97006, data=0x1117ae84) (C:/Programme/Spiele/ufoai-2.3_dev/src/common/common.c:1039)
#9 004E4BA5 Qcommon_Frame() (C:/Programme/Spiele/ufoai-2.3_dev/src/common/common.c:1120)
#10 0050F217 WinMain(hInstance=0x400000, hPrevInstance=0x0, lpCmdLine=0x251f1f "", nCmdShow=10) (C:/Programme/Spiele/ufoai-2.3_dev/src/ports/windows/win_main.c:368)
#11 00000000 0x0051c70a in main() (??:??)
Do I need to give more info in such a case, or is that all what's important?
Best way would be to load it to pastebin and ask via IRC while the debugger is still active, right? ;)
-
http://ufoai.ninex.info/wiki/index.php/Debugging
stack trace might be enough as it stands, but i don't code, so you might be required to provide 'bt full' output from within gdb :)
-
Thanks richlv, in the meantime I managed to create a link by myself (found some docs about gdb-paramaters within the mingw-directory).
Anyway, the page you cited contains the word "gdb" literally, but searching the wiki doesn't bring it up. Strange.
Seemingly this is not my day. :P
The first flight to Sydney brought the above crash. The 2nd did work, but I couldn't find the 4th alien (probably in the upper level of the UFO where I can't go), so I needed to abort it. The 3rd one hung after "waiting for players", had to kill it via Task Manager. *sigh*
I'd better go to bed and try it another day... :(
-
Thx for the callstack :)
Looks like the crash is more related to lighting than to pathfinding. But then again, the data for both is in the same (bsp-)file.
When did you compile the maps the last time (rev?) ?
-
too bad the SVN-rev isn't displayed somewhere in the logs... Sorry, I don't remember exactly. The timestamp of the .bsp's is beginning at yesterday about 12:30 GMT +2 (and I made an update before). Regarding CIA logs it must have been 24207 (I translated in wiki while maps compiled). 8)
-
Good news 1: That's new enough. btw you may want to take notes about the revs that you updated to. That might save us a considerable amount of work when analyzing things sometimes.
Good news 2: We can now safely assume that the crash is not related to pathfinding :)
Bad news: I have no clue about the lighting stuff.
Passing on to Mattn ....
-
found the problem - will think about a clean fix... but might take some time (more a design bug)
-
was easier than i thought - should be fixed in r24261
-
Mattn, should we recompile maps after fix, or this is not problem of ufo2map?
-
was easier than i thought - should be fixed in r24261
hi Mattn,
I just recompiled the maps and codes (compile_maps with /clean para) at 24255 for current installer binary uploading.
Do i need to recompile to accomodate for 24261??
Or a simple compile_maps (without the /clean) is enough?
I noticed that by deleting a certain map, and recompiling it (from 24261 and 24255), the sizes for the bsp files and checksums are not same..... I guess need to recompile? (just wanna a confirmation before starting the 2 hrs task again. Lol.)
:)
-
There was an important fix in rev 24256 that may or may not fix the 'blocking along the lines of maptiles in RMA'-issue.
The devs are eager to know if anybody can still reproduce that problem with a newer rev.
-
There was an important fix in rev 24256 that may or may not fix the 'blocking along the lines of maptiles in RMA'-issue.
The devs are eager to know if anybody can still reproduce that problem with a newer rev.
Okie! Nods.
I have recompiled a new version update for this.
However, it is only 14% uploaded to nakido's server.... takes another abt 2-3 hrs (here is +8GMT, 10.49am). I have the link already, just that it will be be valid until fully uploaded.
For those interested and lazy / unable to do SVN update, can check out this later (abt 2-3 hrs later) download (http://www.nakido.com/38CCE5D990D3CB15286C766440203DAF6400C2D4).
-
> I noticed that by deleting a certain map, and recompiling it (from 24261 and 24255), the sizes for the bsp files and checksums are not same..
Thats quite normal if you use more than 1 thread
-
There was an important fix in rev 24256 that may or may not fix the 'blocking along the lines of maptiles in RMA'-issue.
The devs are eager to know if anybody can still reproduce that problem with a newer rev.
Hi Duke,
U saw my reply in other entry?? Wanna update that i tried to enter battle, and some battle maps (in fact quite a few when i tried on skirmish) was not able to start. It simply crashed back to desktop, closing both application and console together. :(
*edit 1*
Oh forget to mention my revision - R24273.
*edit 2*
Yikes, bad me. Forget to mention OS and system! Win XP SP 3 (Home). 378MB ram on lappy and i thnk 1GB processor.
-
Thx, odie.
I usually use the 'Show new replies to your posts.'-feature of the forums, so there is no need to cross-link the threads.
-
Thx, odie.
I usually use the 'Show new replies to your posts.'-feature of the forums, so there is no need to cross-link the threads.
Yes sir! Understood! :D