Topics

76

Closed bug reports / [Fixed] r4375 with --starthost freezes

« on: 4 June 2013, 03:12:58 »

r4375 (full rebuild) with --starthost makes MG freeze for me with a black screen (need to kill -9). Navigating to the host menu also makes it freeze. It doesn't get listed on masterserver either.

When attaching gdb it finally segfaults: http://megaglest.nopaste.dk/p45850

Stacktrace from attached gdb before segfault (during freeze): http://megaglest.nopaste.dk/p45851

77

Bug reports / 3.7.1, r4372: Megapack: Norsemen worker amination: small bag

« on: 3 June 2013, 22:32:47 »

There's a single wrong image in the animation of the norse worker when he grabs his bag of gold and gets ready to return to the castle.

Normally a norseman worker who is on his way back to the castle looks like this:

http://postimg.org/image/rm7n7wn4b/

However, there is exactly one image where his bag suddenly shrinks to half the size:

http://postimg.org/image/spwcxlx57/

As discussed with Titi, that's due to a bug in the worker animation (and is not related to the engine).

_{Edit by Omega: image links need to be direct links to work with the img tag (consider using imgur?)}

78

Closed bug reports / [fixed] r4362: Host reports: Value not found on list box: [***missing***]

« on: 3 June 2013, 03:04:57 »

When you host a game, and a client who is missing the currently configured mod joins (I assume that's the cause, it could also be the faction setting of "*Random*"), the server will spill out this error message repeatedly:

Code: [Select]

[2013-06-03 03:30:00] *ERROR* In [components.cpp::setSelectedItem Line: 439]
instanceName [listBoxFactions1] idx = 0 items[idx] = [Natulka]
[2013-06-03 03:30:00] *ERROR* In [components.cpp::setSelectedItem Line: 439]
instanceName [listBoxFactions1] idx = 1 items[idx] = [*Random*]
[2013-06-03 03:30:01] *ERROR* In [menu_state_custom_game.cpp::switchSetupForSlots Line: 2203] Error [[listBoxFactions1] Value not found on list box: [***missing***]
Stack Trace:
./megaglest:Shared::Platform::megaglest_runtime_error::megaglest_runtime_error(std::string const&, bool)address [0xa1b012] line: 237
./megaglest:Glest::Game::GraphicListBox::setSelectedItem(std::string, bool)address [0x555ea9] line: 441
./megaglest:Glest::Game::MenuStateCustomGame::switchSetupForSlots(Glest::Game::SwitchSetupRequest**, Glest::Game::ServerInterface*&, int, int, bool)address [0x7531df] line: 2183
./megaglest:Glest::Game::MenuStateCustomGame::update()address [0x76fd6f] line: 2350
./megaglest:Glest::Game::Program::loopWorker()address [0x6ac9c0] line: 459
./megaglest:Glest::Game::glestMain(int, char**)address [0x690790] line: 5121
./megaglest:Glest::Game::glestMainSEHWrapper(int, char**)address [0x694276] line: 5368
./megaglest:Glest::Game::glestMainWrapper(int, char**)address [0x69440e] line: 5440
/lib/x86_64-linux-gnu/libc.so.6:__libc_start_main()address [0x7f5272616ea5] line: 0
./megaglest() [0x514bb9]address [0x514bb9]
]

I think this exception should be caught and handled, no need for an error message and stacktrace there, since it makes people think that an unhandled error occurred, when there is really not a problem.

79

Closed bug reports / [fixed] r4357: Japanese: castle keeps playing "new worker units created" sound

« on: 2 June 2013, 02:44:20 »

I noticed today that on r4357, when you play Japanese and create a worker, the castle will repeatedly play back the sound which indicates that a new worker was created while it is producing a new worker. The sound plays back roughly every three seconds while new a worker is being produced. This differs from the behaviour in 3.7.1, earlier versions and actually also somewhat recent revisions where this sound was only played back once when the entire production cycle of a new worker ended.

80

Closed bug reports / [fixed] r4357: Host SegF when client disconnects during pause

« on: 2 June 2013, 01:25:26 »

When I was testing rejoining games with Atze (who was hosting) tonight on r4357, I joined his running game, remained connected for roughly a minute while we were chatting. I don't think I gave any orders at that time. Then I disconnected again. Doing so apparently triggered some bug on Atze's end, and he ran into a segmentation fault. Sadly all that's available is an error.log file, so I'm posting this in case it can be of use:

Code: [Select]

[2013-06-02 02:58:03] Runtime Error information:
======================================================
In [/home/atze/Programme/Spiele/repos/megaglest/source/glest_game/main/main.cpp::handleSIGSEGV Line: 5270] Error detected: signal 11:

Stack Trace:
mk/linux/megaglest:Glest::Game::ExceptionHandler::handleRuntimeError(char const*, bool)address [0x68e3a9] line: 653
mk/linux/megaglest() [0x68e5d9]address [0x68e5d9]
/lib64/libpthread.so.0:()address [0x7fcb212c5140] line: 0
/usr/lib64/libstdc++.so.6:std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&)address [0x7fcb1e1e8dcb] line: 0
mk/linux/megaglest:Glest::Game::Game::ReplaceDisconnectedNetworkPlayersWithAI(bool, Glest::Game::NetworkRole)address [0x5c4179] line: 2967
mk/linux/megaglest:Glest::Game::Game::update()address [0x5c5942] line: 1913
mk/linux/megaglest:Glest::Game::Program::loopWorker()address [0x6ac5a1] line: 459
mk/linux/megaglest:Glest::Game::glestMain(int, char**)address [0x69b427] line: 5121
mk/linux/megaglest:Glest::Game::glestMainSEHWrapper(int, char**)address [0x69ebc9] line: 5368
/lib64/libc.so.6:__libc_start_main()address [0x7fcb1d897455] line: 0
mk/linux/megaglest() [0x50f6c9]address [0x50f6c9]

81

Bug reports / r4355: Rejoin: OOS after rejoin

« on: 2 June 2013, 00:16:59 »

Note:
OOS on rejoin was previously discussed in another thread: https://forum.megaglest.org/index.php?topic=9045


I was hosting, Titi joined, we started together, then he left and rejoined. We later went OOS and here is how...

At the very moment Titi rejoined i ordered my single hunter and single spearman to the top left corner, and they started walking there. When they had roughly made one third of the way to their destination i decided to split them up: I let the spear man continue his way to top left, but reordered the hunter to bottom left.

The next thing Titi saw is that my hunter took a short route between the lakes to head to bottom left, where he got involved in a fight.



The next thing I saw was my hunter going straight down on our safe (right) side of the rightmost lake, then heading towards the enemy (to the left).
But on my screen my hunter never reached the enemy (or surpassed the center of the map) before we ended the game.



So clearly the game went out of synch there already, but we did not actually wait until one of us would run into an OOS error message, since we could tell from chatting that we were seeing different things on screen already. We both recorded DebugWorldSynch logs:

Titi's logs

My logs (ignore the screenshot included there, it is from a different game)

82

Closed bug reports / [fixed] r4353: Server locale used in messgae to client

« on: 1 June 2013, 20:53:13 »

When I was connected to Filux' game lobby (he was hosting and had his game set to polish locale) while his game was already running (rejoin enabled), I (client, english locale) received this message:



Such messages should be displayed in the clients' locale.

83

Closed bug reports / [fixed] r4353: Rejoin: "Waiting for server to start game", readiness indicator

« on: 1 June 2013, 20:48:55 »

When you connect to the lobby of a running game (rejoin enabled), it says this:



... even though the game is already in process. Instead it should cleary indicate that you are connected to a game which is already running.

At the same time, the readiness indicator has no use on this screen and should be removed.

84

Bug reports / r4353: CPU replacement inherits players' UUID

« on: 1 June 2013, 20:40:09 »

Filux was hosting, I was a client, both Linux-64. He set the game up with rejoin, and I joined his running game later.

I then disconnected and was replaced by a CPU. And reconnected.

Then Filux' network player list looked like this:



And mine looked like this:



So the CPU which replaced me in the slot I was previously playing in had inherited my UUID, which I don't think it should.

Additionally, for me, the CPU was not listed as *AI* but as ???. I guess *AI* is already not so great (AI6 would probably have been correct) but ??? is definitely wrong.

85

MegaGlest / New MegaGlest tutorial video

« on: 1 June 2013, 03:39:42 »

Here's a new MegaGlest tutorial video by Zyx:



Nice voice, good English (native speaker I guess), it just get's a bit loud with the other gals + guys in the background later on. Still a nice video.

86

Bug reports / r4343: Rejoin: Headless server lacks rejoin support

« on: 31 May 2013, 20:22:24 »

I know this is for later, just putting this here as a tracking bug so we don't forget about it. It's also only relevant if we actually end up having this feature in the next release.

87

Bug reports / r4341: Rejoin: When multiple players join simultaniously, game may never resume

« on: 31 May 2013, 20:18:43 »

There are some oddities with rejoin and pausing. When you have a game where players will disconnect and reconnect repeatedly then you will run into this situation where one of them rejoins, and there is no player currently in process of joining, but the game does not resume - it remains paused. I'm not exactly sure what triggers it, maybe there are situations where clients get stuck in the join in sequence, maybe due to the game state download progress messages. When you setup a game with multiple network clients and they rejoin, and some rejoin at the same time (I'm not sure this is actually necessary to reproduce) this issue is guaranteed to occur.

Edit (tomreyn, 2013-06-01): better subject title

88

Closed bug reports / [fixed] r4341: Prax zombies remain standing when dead, death animation not working

« on: 31 May 2013, 20:13:22 »

This was introduced very recently: When you play the Prax mod, v0.5.3.3, the zombie units remain standing (but do not move) when they die. They will vanish at some point, but their death animation is never played back, so they just stand there, are no longer selectable, then vanish entirely. This didn't happen when we were testing yesterday, so I assume this can be related to the r4340 change.

89

Bug reports / 3.7.1: Delayed screen updates

« on: 31 May 2013, 04:01:06 »

Sometimes when I explore, it will happen that while I can see the surface of a the area I'm newly exploring, the surrounding objects there are not actually shown until I move another unit there to explore further.

Here's an example, this screenshot was taken on 3.7.1 on atibox while playing Japanese on the Conflict map. I'm settling to the bottom  left gold spot, which is actually way larger than shown here, and is next to the mountains, which are missing here.

This could be an issue which is specific to my graphics card and its properties (and shortness of resources), but I think I've heard reports from other people about this issue, too. It's surely a minor issue, though, walking to this spot with a worker (or any other unit) can fix it. I think this still occurs on head of trunk.

90

Feature requests / Outline text on loading screen

« on: 31 May 2013, 03:41:51 »

On the loading screen, all text should be outlined. This can be necessary since the loading screen (faction) images are often too light, so that the text is not readable. This is especially bad for loading screen hints. An example which demonstrates this issue is the Egyptian faction loading screen.

Another option is to only outline the loading screen hint, which is not repainted.

Yet another option would be to design new loading screens for Megapack (or to try to modify the existing ones).

91

Feature requests / Announce on lobby when players join/leave

« on: 31 May 2013, 03:29:38 »

While the trumpet already provides an indication that a new player has connected to a server, it doesn't say when this happened nor who has joined, nor is it announced when someone disconnects.
Ideally I'd like to have time coded (translated to each clients' time zone) messages about joins and parts, and a switch in options to disable them.

Here's an example of how those could look:

Code: [Select]

tomreyn: moo!
[21:35] titi_linux has joined.
titi_linux: quak
[21:36] softcoder has joined.
softcoder: I fly bleifrei and fight fire with lighters.
[21:36] softcoder has left.
[21:37] titi_linux has left.
tomreyn: meow.

Another option would be to only display joins/parts in the backlog ('m' key) view.

92

Bug reports / 3.7.1: "Techtree is different between client and server Megapack"

« on: 31 May 2013, 02:50:12 »

When a client has different data in his or her copy of the Megapack techtree, the following warning message may show:

tomreyn: Techtree is different between client and server Megapack

This error message should be rewritten so that it makes more sense:

System: Warning: Techtree "Megapack" is different between client "tomreyn" and server.

In case this is not technically feasible, please use this format instead:

tomreyn: Warning: The following techtree is different between client and server: Megapack

I think this message is still used on head of trunk, too.

93

Closed bug reports / [fixed] r4338: If client denies download prompt, ask him again

« on: 31 May 2013, 02:38:06 »

Currently, when a user connects to a hosted server and lacks a mod setup there, he gets a download prompt. If he decides not to download it then he remains connected, and all other players receive a repeated warning saying that this player is missing this mod.

This is not very useful the way it is now: If the user decides not to download the mod then he won't be able to play on this server. So you could argue that clients who deny mod downloads should be disconnected. However, the server admin may decide to take this into account and instead set to a mod this user actually has, so that no download will be necessary.

So I suggest to solve this as follows: the client should check in regular intervals (maybe every 5-10 seconds) whether all the mods needed are available. And, taking into account changes the server admin made, whenever any mods are unavailable on the client, the download prompt should be displayed there (again). So denying a download will then only result in the prompt vanishing until the next mod check unless the server admin has already changes to a mod which the client does have available.

94

Closed bug reports / [fixed] r4338: Lobby mod downloads should default to accept, not deny.

« on: 31 May 2013, 02:28:19 »

When you connect to a hosted server and are missing a mod, you get a download prompt. If you press enter there (which can easily happen if you were just about to chat), the mod download will be rejected. This is non-intuitive and requires you to reconnect to get a new prompt. In the meantime all other players keep receiving a repeated hint that you are missing this mod.

I think when you hit enter there, either the download prompt should be accepted, or, probably maybe better, this should have no effect on this prompt. Hitting escape, however, should allow to bail out from the prompt, denying the download prompt.

95

Closed bug reports / [fixed] r4338: Headless server admin lacks UI to ready up, is "not ready"

« on: 31 May 2013, 02:12:59 »

Filux and I (both Linux-64) were playing on a Windows 7-64 headless today (running on my VM, with really bad performance for reasons I was unable to determine). I connected there first and thus was the headless admin. Everything looked fine, however, I was set to (and shown as) "not ready" and there was no way I could ready up. Apparently this UI element is missing there.

96

Closed bug reports / [fixed] r4338: Boost may work on larger area than indicated?

« on: 31 May 2013, 02:04:01 »

I've noticed that there seem to be situations where boost works outside of the range it should.

In Prax, sorcerers get a boost when they stand within reach of a stone circle (and only then). This is indicated by a small red face icon over their heads.

On this image, you can see a sorcerer who is currently being boosted by the only stone circle I had built in this game:



However, if you look at the range of this stone circle, then it shows that this sorcerer should not be boosted at all, since he is clearly standing outside of the stone circle's range.



NB: I've edited these images to be lighter, they didn't look this bad originally.

Update:

Here's another image which shows this or a related issue. This time there is a boost affecting only a single worker in a group of workers. In fact, since there is no building nearby to boost any worker (check mini map), not a single worker should be boosted there. Note that this screenshot is a few weeks old, I'm not sure whether this is already fixed (the above screenshots are current, though):

97

Closed bug reports / [Fixed] r4338: Rejoin: Duplicate savegame download?

« on: 30 May 2013, 21:02:09 »

When Filux and I were testing r4338 tonight with rejoin enabled, I was reconnecting to his server a couple times. Every time I reconnected / rejoined his game, two file downloads were shown, both of which seemed to be savegame files, one with a .XML and one with a .ZIP file extension. Is it possible that the .XML file should have been removed when .ZIP was introduced but this was forgotten? Or are these just different files?

98

Closed bug reports / [Fixed] r4338: Worker end-of-harvesting animation may be played twice

« on: 30 May 2013, 19:51:12 »

When a worker has finished harvesting (the type of resource does not matter), it may stand up / stop chucking wood twice. I.e. the animation can be played twice. This doesn't seem to always happen, but it does happen in enough cases to be notable. So far I only spotted this in multi-player games (I have not played much single player lately) but it happened both when hosting and as a client, so I assume it also affects single player.

This bug has been introduced somewhat recently, most likely within the past 20 revisions, more likely within the past 10.

I'm happy to provide a video in case this problem description is insufficient to identify the issue.

99

Closed bug reports / [fixed] r4337: Rejoin: Linux-64 client segfault on rejoin

« on: 29 May 2013, 21:41:17 »

Tonight, Atze, Filux and I were testing the rejoin feature. We played an entire game without using the feature, and won against 3 CPUs. Then (I hosting on atibox) asked Atze and Filux to quit and reconnect. They did, and at the same time. Filux said he got a timeout, however the game announced he had rejoined. Atze got back in, too, taking the slot of a CPU which had already been dead (all units and structures removed). He told me on in-game chat that he had a black screen (apparently the chat was not), so I unpaused the game (it did not unpause automatically). The game continued, and Atze could see the game, but a second or two later the game paused itself again. I unpaused again, and it paused itself again.

Atze then ran into a segfault:

Code: [Select]

~/Programme/Spiele/repos/megaglest> gdb -q -n -ex "bt" -batch mk/linux/megaglest core
[some stuff removed here by tomreyn]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `mk/linux/megaglest --ini-path=mk/linux/ --data-path=mk/linux/'.
Program terminated with signal 6, Aborted.
#0  0x00007ff66f8bdd25 in raise () from /lib64/libc.so.6
#0  0x00007ff66f8bdd25 in raise () from /lib64/libc.so.6
#1  0x00007ff66f8bf1a8 in abort () from /lib64/libc.so.6
#2  0x00007ff66f8b6c22 in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007ff66f8b6cd2 in __assert_fail () from /lib64/libc.so.6
#4  0x0000000000820abe in Glest::Game::NetworkManager::getServerInterface (this=<optimized out>, throwErrorOnNull=<optimized out>) at /home/aufgehts/Programme/Spiele/repos/megaglest/source/glest_game/network/network_manager.cpp:111
#5  0x00000000005ba7fe in Glest::Game::Game::setPaused (this=0x227d04e0, value=false, forceAllowPauseStateChange=true, clearCaches=false, joinNetworkGame=false) at /home/aufgehts/Programme/Spiele/repos/megaglest/source/glest_game/game/game.cpp:5661
#6  0x0000000000596e27 in Glest::Game::Commander::giveNetworkCommand (this=this@entry=0x227d1928, networkCommand=0x1e7f3e10) at /home/aufgehts/Programme/Spiele/repos/megaglest/source/glest_game/game/commander.cpp:889
#7  0x000000000059973b in Glest::Game::Commander::updateNetwork (this=0x227d1928, game=<optimized out>) at /home/aufgehts/Programme/Spiele/repos/megaglest/source/glest_game/game/commander.cpp:642
#8  0x00000000005c9013 in Glest::Game::Game::update (this=0x227d04e0) at /home/aufgehts/Programme/Spiele/repos/megaglest/source/glest_game/game/game.cpp:2180
#9  0x00000000006ab221 in Glest::Game::Program::loopWorker (this=0x2d9ee00) at /home/aufgehts/Programme/Spiele/repos/megaglest/source/glest_game/main/program.cpp:458
#10 0x0000000000699590 in Glest::Game::glestMain (argc=argc@entry=3, argv=argv@entry=0x7fffd9aab608) at /home/aufgehts/Programme/Spiele/repos/megaglest/source/glest_game/main/main.cpp:5110
#11 0x000000000069d689 in Glest::Game::glestMainSEHWrapper (argc=3, argv=0x7fffd9aab608) at /home/aufgehts/Programme/Spiele/repos/megaglest/source/glest_game/main/main.cpp:5355
#12 0x00007ff66f8aa455 in __libc_start_main () from /lib64/libc.so.6
#13 0x0000000000510309 in _start () at ../sysdeps/x86_64/elf/start.S:113
I assume this can be hard to reproduce, so I hope the stack trace is useful.

100

Bug reports / r4335: Button click sounds

« on: 29 May 2013, 02:09:42 »

So... here's a list (sorry guys):

Main menu -> New Game -> Return: This should be the high (back) click sound, but is the standard low (forward) click sound.

Main menu -> New Game -> Tutorial -> Play now: Should be a low (forward) click sound, but is none.

Main menu -> New Game -> Scenario -> Play now: Should be a low (forward) click sound, but is none.

Main menu -> Options -> Audio | Video | Misc | Newtork | Keyboard Setup: Should be a low (forward) click sound, but have the high (back) one.

Main menu -> Exit: Should be a high (forward) click sound, but is none.

In-game menu: All button click sounds are missing

In the very most of places, multi-option selection boxes (the ones with the arrows to the left and right) do not have any click sounds. They currently do have some (only)...

• on the Internet lobby screen for the refresh interval selection box
• on the custom game menu when you are connected as a host but only on the readiness-indicator and
• on the custom game menu when you are connected as a client (everywhere then).

I think the multi-option selection boxes  should have the low click sound everywhere.

Generally those click sounds are not a big deal, but they are currently incoherent, which doesn't make a great impression.