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 - frr

Pages: [1]
1
Today when I started a game by loading a savegame taken very early in the game (first ufo recovery), with "setdeveloper DEBUG_EVENTSYS" I managed to finish that recovery session. But the very next recovery session failed again, and it was NOT the "actor still moving" message. I'm attaching a log of ufoai's stdout+stderr, and the events.log.

My system configuration:
Fedora 10 64bit on a cheap all-Intel notebook
i965GM, integrated Intel graphics, C2D CPU, 2 GB RAM.

Speaking of my system configuration: about two months ago, I had a problem that seemd to stem from the Intel graphics driver. With "realtime lighting" and "GLSL shaders" both on, Battlescape initialization used to fail reliably with the three bargraphs overflowed left, and the system would freeze solid (i.e. a complete hang of the kernel). A normal user-space memory leak wouldn't have a chance to cause this effect :-) See also the JPG image attached. As I said, this does NOT seem to happen anymore. Now I have both "realtime lighting" and "GLSL shaders" turned on and I've been through two battlescape sessions without this problem. I'm not wasting time with this bug, because I know that the current Fedora release is r11 (while I have r10 installed), and the Intel graphics driver has just undergone a bit of revolution (between r10 and r11), the dust hasn't quite settled yet...

Actually I've tried loading a savegame once more, and with those graphics features turned on, I got stuck in the "Battlescape empty screen" once again (with the three bargraphs just empty). So maybe I'll just turn them off again, when I feel like zapping some more aliens...

I'm aware that this message probably doesn't help much in the way of precise debugging information :-)
I intend to provide this as just a bit of informal feedback, from my odd setup...
Overall I have to say that the 2.3-DEV series seems to be gradually improving - every time I compile a new version, some of the bugs are gone, the look and feel is better, there are new models, even new music... it's great :-)

2
Bugs prior to release 2.3 / Re: ERROR: Actor is still moving
« on: August 10, 2009, 11:59:34 pm »
Okay, I've tried version 25602 (fresh from SVN) and guess what: first crashed UFO, made a savegame from Geoscape just before entering Battlescape, shuffled my team about a bit, clicked "next turn" and here it was:
  ERROR: Actor on team 7 is still moving (3 steps left)
A full listing of the ufoai stdout and stderr for the session is attached.

My system configuration:
Fedora 10 64bit on a cheap all-Intel notebook
i965GM, integrated Intel graphics, C2D CPU, 2 GB RAM.

Unfortunately, it doesn't seem very reproducible.
I went on to re-load the savegame just before entering the Battlescape, typed "setdeveloper DEBUG_EVENTSYS" into the console, and voila: the bug didn't re-surface. This was perhaps my first ufo crash recovery mission that I managed to finish (without a ufoai crash).

3
Heheh yes I've noticed the recent thread on "actor still moving" in the bugreport forum. I'm going to add a short note.

4
> make clean-maps
>
good, that's what I was missing :-) Anyway it seems to have the same effect as my low-level command: all the .bsp files are gone... yes, it's actually the same command, finally I found it in build/maps.mk.

The most important point though: in SVN revision 25602, the position of the Earth in the geoscape view is exactly what I wanted :-) Thanks a lot, now it's perfect :-) I recalled this "issue" from two months ago, and got misguided by a screenshot on the homepage yesterday to believe that the issue is still there :-)

Hmm... and the battlescape still crashes, but again with a different message. (I shall report someplace else, I know)

5
Thanks for your response in the first place :-) I guess I've noticed some past bugs in geoscape "panning" meaning "orbiting" (globe rotation), or its GUI controls. So just to make sure, note that I'm talking about a different thing: efficient use of display screen space.
That said, my .svn/entries contains the following information:

dir
24765
https://ufoai.svn.sourceforge.net/svnroot/ufoai/ufoai/trunk
https://ufoai.svn.sourceforge.net/svnroot/ufoai

2009-06-19T19:14:42.731945Z
24765
bayo-fr
has-props

I guess this *is* 2.3-dev, except almost 2 months ago... so indeed I may be missing something :-) I'm going to do a "svn up" right away and compile the latest version, including all the maps... and see if something has changed in the meantime.

BTW, I couldn't find an appropriate "make target" to remove all the stale .bsp files. I understand that it is appropriate to recompile all the maps for a new version of the ufoai code, although the source XML file of the map hasn't changed. So I ended up doing just
 rm -f `find . -name "*.bsp" -print`
... and "make maps". I hope this is allright...

6
Discussion / Geoscape panning? (Why is earth centered on the screen?)
« on: August 08, 2009, 11:22:54 pm »
I have a question regarding Geoscape "ergonomy". Apologies if this is an FAQ, I'm a noob, I haven't studied possible config tweaks, and a quick search in the UFO AI forum hasn't revealed any discussion on the topic...

Note that in the Geoscape view, the Earth seems to be strictly centered on the screen (main window). At the same time, you have the Geoscape menu on the right. Regardless of whether your screen is 4:3 or widescreen, at optimum zoom the globe is partly hidden/overlapped by the menu. At the same time, you have a stripe of unused space (cosmic void, literally) on the left of your screen. Is there some way to pan the Earth to the left in the Geoscape view, so that you can have optimum zoom on the globe *and* the globe completely unobscured by the menu?
Either rotate the camera/viewport in the 3D space to the right, or make the 3D viewport start on the edge of the menu, so that you can still have the Earth centered in the 3D viewport, if there are technical reasons for that... (so that zooming in on the Earth surface doesn't happen "sideways" for instance).

Otherwise, thanks a lot for re-implementing the classic UFO game :-) The spirit of the game is clearly there, just keep fixing the bugs :-) I've compiled from SVN twice in the last three months or so on Fedora 10 64bit on an all-Intel notebook machine, and I discovered some bugs/features on both occasions, with some battlescape bugs ultimately preventing completion of even the first ufo crash site session - but I never had the time to report back soon enough after the download... (Family getting in the way - I have a kid that I prefer to pay attention to :-) I'll find the time to download again, get to the first crash site and report any remaining bugs, I promise :-)

Pages: [1]