Ok, I know this is not the good place for bug reports, but launchpad seems to refuse me to send bugs there, so before the information is lost... Those behaviors happened in commit 77829145eeeeb4e58016d081c2f870b15caab2b0 from the github mirror.

bugs

Crash: boost::bad_format_string

Here is the trace of the executable (I tend to run stuff I compiled from a terminal, for that kind of things):

TI(100540): destination appears to have become split from current location -> fail
Cmd_EnemyFlagAction::execute player(3): flag->owner(4) number=10
Forcing flag at (31, 39) 
Cmd_EnemyFlagAction::execute player(3): flag->owner(1) number=9
Fatal exception: boost::bad_format_string: format-string is ill-formed
Game: Writing Preload Data ... zsh: segmentation fault  /usr/local/widelands

I tried a debug version, but the log is really heavy and I have no idea from where to select for useful informations.

It happen if the AI attack, when I have (at least) 1 castle selected and hiden in a screen corner (botom-right, in my case). I still have a savegame allowing to reproduce it, it happens around 4h09m.

freeze with no window on fullscreen

Usually, I am using widelands in windowed mode. By accident, I asked my window manager to place it under it's fullscreen mode. This caused the game to freeze without having a window on a graphic report. Really close to a crash imho, but the process still being there... so let's call it a freeze :) The same problem obviously happen when using widelands' interface to go fullscreen. Here is the trace:

This is Widelands Version unofficial-git-7782914 (Release)
Set home directory: /home/USER/.widelands
Widelands executable directory: /usr/local/
Adding directory: /usr/local/data
selected language: (system language)
using locale fr_FR.UTF-8
Graphics: Try to set Videomode 1280x800
Graphics: OpenGL: Version "3.3.0 NVIDIA 340.96"
Graphics: SDL_GL_RED_SIZE is 8
Graphics: SDL_GL_GREEN_SIZE is 8
Graphics: SDL_GL_BLUE_SIZE is 8
Graphics: SDL_GL_ALPHA_SIZE is 0
Graphics: SDL_GL_BUFFER_SIZE is 24
Graphics: SDL_GL_DOUBLEBUFFER is 1
Graphics: SDL_GL_DEPTH_SIZE is 24
Graphics: SDL_GL_STENCIL_SIZE is 0
Graphics: SDL_GL_ACCUM_RED_SIZE is 16
Graphics: SDL_GL_ACCUM_GREEN_SIZE is 16
Graphics: SDL_GL_ACCUM_BLUE_SIZE is 16
Graphics: SDL_GL_ACCUM_ALPHA_SIZE is 16
Graphics: SDL_GL_STEREO is 0
Graphics: SDL_GL_MULTISAMPLEBUFFERS is 0
Graphics: SDL_GL_MULTISAMPLESAMPLES is 0
Graphics: SDL_GL_ACCELERATED_VISUAL is 1
Graphics: SDL_GL_CONTEXT_MAJOR_VERSION is 2
Graphics: SDL_GL_CONTEXT_MINOR_VERSION is 1
Graphics: SDL_GL_CONTEXT_FLAGS is 0
Graphics: SDL_GL_CONTEXT_PROFILE_MASK is 2
Graphics: SDL_GL_SHARE_WITH_CURRENT_CONTEXT is 0
Graphics: SDL_GL_FRAMEBUFFER_SRGB_CAPABLE is 0
Graphics: OpenGL: Double buffering enabled
Graphics: OpenGL: Max texture size: 8192
Graphics: OpenGL: ShadingLanguage: "3.30 NVIDIA via Cg compiler"
**** GRAPHICS REPORT ****
 VIDEO DRIVER x11
 pixel fmt 370546692
 size 2720 1024
**** END GRAPHICS REPORT ****

Remarks

Those are really remarks, not important stuff.

annoying window position

I am using i3 as a window manager. It is a tiling one. When I start widelands, it appears as a floating window split with every half of the window on each screen.

make install moves things directly in /usr/local

I know it's a wanted behavior, but only because I read the CMakeLists.txt. There were no documentation about that. This could be fixed by adding a simple readme making it explicit. Also, I'm curious about why you forced the paths, I think cmake does it's job decently usually (even if it would not place the stuff into /usr/local/games, but I don't think that distinction is really useful honestly). I guess you have a good reason, but I fail to see which one.

the wiki about dependencies will be outdated

The wiki says that widelands depends on SDL1.2 stuff, but for build 19, it will depend on SDL2 stuff. This is just to remind you to update it

PS: again, sorry about not using the bug tracker, it just refuses to work, and after trying to do a bug report twice, it becomes annoying (and tbh, I really dislike it's interface, but it's a matter of taste, and if it worked I would have done with it).

PPS: the markdown help lacks the instruction to quote and place "code".

Top

Quote

SirVer wrote:

freem wrote: Crash: boost::bad_format_string Here is the trace of the executable (I tend to run stuff I compiled from a terminal, for that kind of things):

I guess this is a localization error of a string in the game - a boost formatting string got wrongly translated. Bugs like these are the reason why we do feature freezes and do not allow translations at some point. Which locale are you playing on? Can you reproduce this? Can you provide a savegame before the crash?

GunChleoc asked me to send him the savegame by mail, I did it. I am playing with the french locale, and can reproduce that bug easily, sounds like it's caused by having a window partially outside screen while that attack. Not sure any other event could trigger the crash.

freeze with no window on fullscreen

Dunno what that is - the output looks fine.

I am using i3 as a window manager. It is a tiling one. When I start widelands, it appears as a floating window split with every half of the window on each screen.

outside of Widelands control. SDL chooses where to place the window. For what it's worth, awesome (the window manager) does place the game floating in the middle of the first screen.

I guess the placement on virtual screen's center is a change from SDL2, since widelands was centered on the screen from which it was started before. And about being floating, I think that wesnoth might have found a way, but now that you mention it, it's true that I don't know a lot of games with SDL not having floating windows by default... I wonder how they did it. I'll try to find out (seems like it is possible to receive non-portable events from window managers, but it seems like a lot of work and I doubt they used that to fix this).

make install moves things directly in /usr/local

there are cmake options for defining the install directory which we adhere too. if you run a ./configure && make install, most software will install into /usr/local. What would you expect otherwise?

Sorry I was not explicit enough. The binary to go in /usr/local/bin, data in /usr/local/share, etc. Or, at least, the stuff going into a single folder in /usr/local/widelands. For now, it gives this:

% ls /usr/local 
bin  ChangeLog  COPYING  CREDITS  data  doc  etc  games  include  lib  man  mpd  sbin  share  src  VERSION  widelands  wl_map_info  wl_render_richtext

Again, not a big problem, can easily be fixed by the user.

The wiki says that widelands depends on SDL1.2 stuff, but for build 19, it will depend on SDL2 stuff. This is just to remind you to update it

Thanks

PS: again, sorry about not using the bug tracker, it just refuses to work, and after trying to do a bug report twice, it becomes annoying (and tbh, I really dislike it's interface, but it's a matter of taste, and if it worked I would have done with it).

not to worry, I think the first bug is easy to track down, the second one non-fixable without your system and a repro case.

I simply really don't like using forums for bug reports, it makes bugs and improvements harder to track. Useless work.

Top

Quote

your reply make me realize that it is more complex than what I thought, since, on Debian, binaries not from packages are installed in /usr/local/bin, and this would include widelands. I can't think of any way to put it into any games section under /usr/local that would be portable. Now, about why I noticed the thing was installed into /usr/local and not /usr/local/bin, the reason is simple: I am a programmer myself, so I gave myself the rights to install stuff in /usr/local, to avoid using root idendity everytime I need to try something in roughly real conditions. I thought cmake defaults were a pretty decent configuration, but it seems my sight was too short.

Top

Quote

I can't reproduce the crash from the savegame on current trunk - it might indeed be a translation error. Which language did you play in?

ETA: I just ran i18nspector, and it didn't flag up any placeholder issues except for 2 strings in the en_GB Tribal Encyclopedia).

Busy indexing nil values

Top

Quote

freem wrote:

SirVer wrote:

You mean send her the savegame.

Huh... sure I'll try to remember. No garantee at all though.

No worries, you couldn't have known and I won't be offended it you forget. Just treat me like a human being

GunChleoc wrote:

I can't reproduce the crash from the savegame on current trunk - it might indeed be a translation error. Which language did you play in?

I'm playing with the french locale.

ETA: I just ran i18nspector, and it didn't flag up any placeholder issues except for 2 strings in the en_GB Tribal Encyclopedia).

Maybe it's because of some other aspect of my system. I am using a Debian which is a lot customized, for example I am not using dbus, systemd or pulseaudio, at all. But I can't see how this could be related...

boost::format errors usually occur when there is a problem with substituting place holders in strings, or if a string contains a weird character that can't be handled (e.g. if something is accidentally escaped).

I tested this again and I still can't reproduce the crash. I loaded the savegame, selected a castle, moved the castle outside of the screen to the bottom right, then moved the Widelands window outside of the screen on the bottom right.

Busy indexing nil values

Top

Quote