UFO:Alien Invasion
Archive => Bugs prior to release 2.3 => Topic started by: dast on April 23, 2009, 10:58:29 am
-
made a new build, started campaign - first mission map +farm
-map seemed not to be correctly aligned - visible lines between map blocks
-actor was able to move through the drop ship
in the console.log lots of s.b. but only after a short time in game (actor leaving starting block of map?)
Shutdown server: Server crashed.
********************
ERROR: LET_PathMove: Actor movement is out of sync: 139:115:0 should be 139:121:0 (step 1 of 1)
********************
Shutdown server: Server crashed.
Wrote config.cfg.
Shutdown server: Server quit.
Shutdown gametype 'Campaign mode'
Cvar 'mn_base_id' wasn't found
Shutdown server: Quitting server.
Wrote keys.cfg
-
similar thing here on Ubuntu 9.04
********************
ERROR: LET_PathMove: Actor movement is out of sync: 134:132:0 should be 141:134:0 (step 1 of 1)
********************
Shutdown server: Server crashed.
==== ShutdownGame ====
Server crashed.
./ufo[0x818cce9]
./ufo[0x818cd49]
[0xb7f40400]
./ufo[0x8116e51]
./ufo[0x810758a]
./ufo[0x81075ad]
./ufo[0x81075ad]
./ufo(MN_Draw+0xfd)[0x8107899]
./ufo(SCR_UpdateScreen+0xbe)[0x809886b]
./ufo(CL_Frame+0xd8)[0x8090003]
./ufo[0x813c470]
./ufo(Qcommon_Frame+0x9a)[0x813c739]
./ufo(main+0x66)[0x818ba51]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7774775]
./ufo[0x8069571]
Error: Received signal 11.
did the following before running the game - this is the first time i updated via svn - is that all i need do? type in make maps?
voteslave@quad:~/ufoai/trunk$ svn up
U src/client/menu/node/m_node_text.c
A contrib/dlls/libtheora-0.dll
A contrib/dlls/libtheoradec-1.dll
A contrib/dlls/libtheoraenc-1.dll
Updated to revision 24329.
voteslave@quad:~/ufoai/trunk$ make maps
make: Nothing to be done for `maps'.
-
@voteslave:
On which map did you get the crash ?
-
sorry - can't recall
but i was worried about whether i had recompiled maps
prior to the 'svn up' info i posted below i had done another one which i think updated a maps - but nothing happened then either with 'make maps'
so after any svn up i think all i need do is simply:
voteslave@quad:~/ufoai/trunk$ make maps
or am i missing something - like do i need do ./configure and make as well???
-
just tried again - the map was africa A terror mission)
ERROR: LET_PathMove: Actor movement is out of sync: 119:122:0 should be 123:121:0 (step 3 of 3)
********************
Shutdown server: Server crashed.
==== ShutdownGame ====
./ufo[0x818cce9]
./ufo[0x818cd49]
[0xb80c2400]
./ufo(HUD_ActorUpdateCvars+0x45)[0x807d242]
./ufo(CL_SlowFrame+0x10)[0x8090029]
./ufo[0x813c470]
./ufo(Qcommon_Frame+0x9a)[0x813c739]
./ufo(main+0x66)[0x818ba51]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb78f6775]
./ufo[0x8069571]
Error: Received signal 11.
-
just done it again on 24347
i also noticed that it seems to happen after the game switches from full screen to windowed - it does this itself for no apparent reason
-
Hmm. Too bad. +Africa is a random map.
We're looking for someone who gets this error on a non-random map.
-
Rev 24322. i have this bug repeating all time at any map. It happens when your soldier move then game switching to geomap you can change time speed and if hold esc button game start rapidly swithings between geomap and battlearea. Game runing at Vista (SP1 not activated) CPU q4590 M/B Asus p5q deluxe Video Sappfire radeon 4850
-
Don't know if dam is non random, but I just got the same error message (with somewhat different numbers):
ERROR: LET_PathMove: Actor movement is out of sync: 137:132:1 should be 135:135:1 (step 3 of 3)
The error occurred while trying to move a sniper up the tower. On one round, the sniper made it just to the top of the first flight of stairs. As the game would not let me move the guy further into the second flight, I decided to try and crouch him in case there were some actor height issues. It seemed to work at first, since the grid turned green at the top floor, but the sniper did not move and the grid turned blue again. At this point I decided to try and move him just to the stairs and not beyond when I found a spot there which gave me a green grid. As I clicked to make the guy move, he started his crouched motion towards the stairs, then out the builduing through a wall, and back to the main menu (I started the map in skirmish mode). Checked thre console and the error message was there.
I also recall seeing the same error yesterday with an alien who was coming over the dam towards the tower walked over the railing and into the water just before the game crashed back to the main menu.
I hope this description helps reproduce the issue.
Still, progress has been made with pathfinding. About a week ago I could not move soldiers into the tower building.
Cheers!
-
just done svn up and recompile
i noted this time that it said do "make pk3" which i hadn't done before - not sure if this is something new -do the web page instructions need updating
anyway - it still crashed on the africa map - though slightly different error (negative TU costs)
********************
ERROR: Negative TU costs while walking
********************
Shutdown server: Server crashed.
==== ShutdownGame ====
Server crashed.
./ufo[0x818d061]
./ufo[0x818d0c1]
[0xb7f67400]
./ufo[0x81170a9]
./ufo[0x810760a]
./ufo[0x810762d]
./ufo[0x810762d]
./ufo(MN_Draw+0xfd)[0x8107919]
./ufo(SCR_UpdateScreen+0xbe)[0x80988eb]
./ufo(CL_Frame+0xd8)[0x8090083]
./ufo[0x813c7e8]
./ufo(Qcommon_Frame+0x9a)[0x813cab1]
./ufo(main+0x66)[0x818bdc9]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb779b775]
./ufo[0x80695f1]
Error: Received signal 11.
voteslave@quad:~/ufoai/trunk$
-
@Kaz:
Great :) dam.map is non-random (in the base/maps folder, the *.bsp files are non-random maps while the folders are RMAs). The numbers in the msg are x/y/z coords btw.
Your report should enable me to track it down. Once I can compile again :(
Meanwhile, if you want to help even more, you could toy a bit with that situation and try to find the least complex way to reproduce the crash ie. further narrow it down.
btw that was a *very* good bug report :) Do you happen to be a coder yourself ?
@others:
Thanks so far. No more reports on this issue for now. One reproducible situation is usually enough. But you should take personal notes of places on other non-RMAs if you encounter the crash there. I might ask you for such.
-
negative TUs might be due to the way CL_ActorDoMove and LET_PathMove are implemented.
if the server decides that an actor is going into STATE_CROUCH while walking the following happens:
event for starting the move
end event
event for going into STATE_CROUCH
end event
event for starting the move with the crouched steps
end event when target is reached
it might happen that the CL_ActorDoMove resp. LET_PathMove functions won't note this fact at the right time.
-
@Kaz:
Great :) dam.map is non-random (in the base/maps folder, the *.bsp files are non-random maps while the folders are RMAs). The numbers in the msg are x/y/z coords btw.
Your report should enable me to track it down. Once I can compile again :(
Meanwhile, if you want to help even more, you could toy a bit with that situation and try to find the least complex way to reproduce the crash ie. further narrow it down.
btw that was a *very* good bug report :) Do you happen to be a coder yourself ?
I will try and get some more crashes of this type to send any info. Is there some way to enable more detailed debugging info I could send if/when I get more crashes? You read me right ;) I am a coder, but it has been ages since I've done C/C++ stuff. At the moment part of my full time job description is QA testing systems, which really benefits from detailed bug reports. Another part is fixing bugs, which gives you an appreciation for detailed reports... :P
Cheers!
-
i've also seen (but not thought that much about it as i'm lacking time right now) that the EV_START_MOVE event is send to a maybe outdated vis_mask. See the attached patch. it should (again - untested and unproved) calculate the new vis mask for the new position of the actor and send the EV_START_MOVE event to all players that can see the actor on the new position already.
it would be nice if someone could verify this.
[attachment deleted by admin]
-
Is there some way to enable more detailed debugging info I could send if/when I get more crashes?
...but it has been ages since I've done C/C++ stuff.
UFO has lots of ways to produce debugging info. I prefer to use the debugger. So just find the fastest way to produce the crash. Like in: go from x1/y1/Z1 to x2/y2/z2 => crash.
You may find setting
g_notu 1
debug_map 1,2 or 3
useful though.
I understand I shouldn't try to persuade you to join the dev team (atm), but some qualified testing is what you want to contribute ? Fine with me :) A qualified tester can be worth much more than a 'rusted' coder :P
@Mattn:
*Who* do you think is qualified to verify your patch ? (I hope you're not thinking of ME, coz I haven't even started to look at the event system here...)
Or do you think your patch might fix the above crash ?
-
Hey Duke! Thanks for the debugging tip. I will try it some time later. For the moment, I'm more than happy to keep sending in detailed bug reports and pound on the spanish translation.
Cheers!
-
I can compile again :) So I did some testing. I can confirm a bunch of pathfinding probs with the tower on the dam.map, including being forced to crouch and walking through walls.
Many of them are caused by the map not being 'designed to the grid'.
But I didn't get the crash.
@Kaz:
Just a thought: Do you happen to use a multi-core cpu ? (I'm on an ooold single-core)
-
I've been playing with this bug trying to reproduce it. I have been using the Dam map and getting the error:
********************
ERROR: LET_PathMove: Actor movement is out of sync: 132:138:1 should be 135:137:1 (step 1 of 1) (team 1)
I never saw the out of TUs error (although it seems to be related). I couldn't make it consistent from point a->b, but this is how I was able to reproduce it easily:
If you go to the second floor and crouch and move through the wall so you are standing outside the building. Then run off a bunch of your TUs so that you can click inside the second floor at a place that is to far for you to actually move to, but also a place on the second floor that you can move to standing (i.e. near the stairs from the ground floor to 1st floor). What should happen is your character will stand up, almost all your TUs will be used up, and nothing else will happen.
On your next turn any movement will crash the game.
I hope this helps if it is not clear or you want grid positions I can grab those, but I wanted to type this up real quick before I went on to my other business tonight.
----
edit, oh yea I am using r24374 and I thought it was consistent clicking to a 'standing' spot to far away, but it isn't 100% consistent, trying to figure out why. Fresh compile of everything (first time trying 2.3 and it is amazing, great job so far).
-
Ok couldn't let it go at then, developed an even better algorithm, I have done this a dozen times in almost this exact same way and it has always crashed on me at some point going through it, it seems to depend on where the civilians/aliens are as to when it will crash.
Using r24374, compiled with debug option (not that my attempts at debugging it have gone anywhere), Windows xp 32 bit, AMD Phenom II X3, Radeon 4870 1GB
Here what I do:
Start game, Goto single player, skirmish, switch map to dam, start. Do debug_map 3
1) Grab closest player to tower and run him as clost to the stairs as possible. End turn
2) Send the player to 136, 138, 1 (sometimes it will crash right here, seems to happen if you go through a civilian).
3) Move him outside the building, usually I go to 133, 135, 1 or within 1 space of that area.
4) If there is enough TU crouch and end turn, otherwise just end turn
5) If you haven't crouched yet, crouch, then try to go to 135, 136, 1 (on the stairs).
6) Sometimes it crashes right here, if it doesn't crash it leaves the player standing in the same spot with no TUs, if it didn't crash end turn
7) Try and goto 135, 136, 1 again
8) ... I have never gotten this far without it crashing.
-
I can compile again :) So I did some testing. I can confirm a bunch of pathfinding probs with the tower on the dam.map, including being forced to crouch and walking through walls.
Many of them are caused by the map not being 'designed to the grid'.
But I didn't get the crash.
@Kaz:
Just a thought: Do you happen to use a multi-core cpu ? (I'm on an ooold single-core)
I will try the issue again and check if the crash is consistent. As for your question: yes, I have a Core 2 Duo. If I get consistent results, do you think fiddling with the processor affinity to bind the ufo.exe process to a single core would make it behave exactly as a single core system, or does ufoai change its behavior depending on the number of cores/processors?
Cheers!
-
@ralthor:
Thank you very much for your work:) Following your description, I got the 'crash' too. Aaand I saw a ton of pathfinding bugs there.
@Kaz:
Honestly, I don't know. I only know that multithreading and multi-cores are different 'layers' of multitasking and thus may cause different problems. As I got the crash on a single core, we can investigate that topic later :)
As it's just a 'crash to mainmenu', the debugging is not as easy as it would be for CTD.
Fixing the pathfinding issues might hide the crash. So I'd like to fix the crash *first*.
Could any of you apply Mattn's fix above and see if the crashing persists (before I find the time to do it) ?
-
Ok. Here is my consistent way to obtain the crash, step by step.
1. Goto (137,135,1).
2. Crouch.
3. End turn.
4. Move to (135,138,2): Fails: Square turns yellow if using debug_map.
5. Move to (135,136,1): Crash!
I've tried it several times, and this crashes the game every single time.
@Duke.
I'll look into Mattn's patch and let you know what I find.
Cheers!
-
Tried Mattn's patch. Still crashes at the same spot.
Cheers!