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.


Topics - titi

Pages: 1 ... 3 4 5 6 [7] 8 9 10 11 ... 18
151
While My internet connection was broken I found the following problem:

without internet enter  the lobby. then leave the game or go to options .... it will all result in a crash.

here is one when leaving the game:
Code: [Select]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./megaglest'.
Program terminated with signal 6, Aborted.
#0  0x00007fe7ddd85425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#0  0x00007fe7ddd85425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fe7ddd88b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007fe7ddd7e0ee in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007fe7ddd7e192 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00000000006c8041 in Glest::Game::Program::loopWorker (this=0x2bdf920) at /home/tscharn/glest/megaglest/source/glest_game/main/program.cpp:399
#5  0x00000000006ad657 in Glest::Game::ExceptionHandler::handleRuntimeError (msg=<optimized out>, getStackTraceString=true) at /home/tscharn/glest/megaglest/source/glest_game/main/main.cpp:652
#6  0x00000000006ad77f in Glest::Game::handleSIGSEGV (sig=<optimized out>) at /home/tscharn/glest/megaglest/source/glest_game/main/main.cpp:5196
#7  <signal handler called>
#8  0x0000000000a29ac2 in cleanup (this=0x41ba0e0) at /home/tscharn/glest/megaglest/source/shared_lib/sources/platform/common/simple_threads.cpp:383
#9  Shared::PlatformCommon::SimpleTaskThread::~SimpleTaskThread (this=0x41ba0e0, __in_chrg=<optimized out>) at /home/tscharn/glest/megaglest/source/shared_lib/sources/platform/common/simple_threads.cpp:366
#10 0x0000000000a29c29 in Shared::PlatformCommon::SimpleTaskThread::~SimpleTaskThread (this=0x41ba0e0, __in_chrg=<optimized out>) at /home/tscharn/glest/megaglest/source/shared_lib/sources/platform/common/simple_threads.cpp:375
#11 0x0000000000a2be8a in Shared::PlatformCommon::SimpleTaskThread::execute (this=0x41ba0e0) at /home/tscharn/glest/megaglest/source/shared_lib/sources/platform/common/simple_threads.cpp:496
#12 0x0000000000a6febf in Shared::Platform::Thread::beginExecution (data=<optimized out>) at /home/tscharn/glest/megaglest/source/shared_lib/sources/platform/sdl/thread.cpp:85
#13 0x00007fe7e1907fd5 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#14 0x00007fe7e194b999 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#15 0x00007fe7e16dfe9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#16 0x00007fe7dde42cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#17 0x0000000000000000 in ?? ()

152
UPDATE: alpha2 with animated trees is available:
http://mods.megaglest.org/tilesets/birch_forest_a2.7z



its so much fun to make new tilesets with the new possibilites :D

Here in action with reduced polys:
(click to show/hide)
(click to show/hide)
(click to show/hide)

THE birch ( here as a highres model ):
(click to show/hide)

153
I am not entirely sure this is related to the pause. Here is the full info from the client which crashed: http://pastebin.com/dnV1Hunt

stacktrace is here:
Code: [Select]
Core was generated by `./megaglest --connect=178.3.49.20:61367'.
Program terminated with signal 6, Aborted.
#0  0x00007f8e52761425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#0  0x00007f8e52761425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f8e52764b8b in __GI_abort () at abort.c:91
#2  0x00007f8e5279f39e in __libc_message (do_abort=2, fmt=0x7f8e528a9028 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:201
#3  0x00007f8e527a9b96 in malloc_printerr (action=3, str=0x7f8e528a9218 "double free or corruption (fasttop)", ptr=<optimized out>) at malloc.c:5018
#4  0x00007f8e530b9916 in std::string::assign(std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00000000009e74e3 in operator= (__str=..., this=0x19f2d88) at /usr/include/c++/4.7/bits/basic_string.h:544
#6  Shared::Platform::Mutex::v (this=0x19f2d60) at /home/user1/SCM/megaglest-trunk/source/shared_lib/sources/platform/sdl/thread.cpp:220
#7  0x000000000053789e in ReleaseLock (this=<optimized out>, keepMutex=<optimized out>, deleteMutexOnRelease=<optimized out>) at /home/user1/SCM/megaglest-trunk/source/glest_game/../shared_lib/include/platform/sdl/thread.h:173
#8  Shared::Platform::MutexSafeWrapper::~MutexSafeWrapper (this=0x7f8e1aff7fe0, __in_chrg=<optimized out>) at /home/user1/SCM/megaglest-trunk/source/glest_game/../shared_lib/include/platform/sdl/thread.h:124
#9  0x00000000007e9ae8 in Glest::Game::ClientInterface::updateFrame (this=0x19f2960, checkFrame=checkFrame@entry=0x0) at /home/user1/SCM/megaglest-trunk/source/glest_game/network/client_interface.cpp:1175
#10 0x00000000007ed1a8 in updateNetworkFrame (this=<optimized out>) at /home/user1/SCM/megaglest-trunk/source/glest_game/network/client_interface.cpp:886
#11 Glest::Game::ClientInterfaceThread::execute (this=0x11f69c90) at /home/user1/SCM/megaglest-trunk/source/glest_game/network/client_interface.cpp:110
#12 0x00000000009e699f in Shared::Platform::Thread::beginExecution (data=<optimized out>) at /home/user1/SCM/megaglest-trunk/source/shared_lib/sources/platform/sdl/thread.cpp:85
#13 0x00007f8e564ec196 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#14 0x00007f8e5652ce49 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#15 0x00007f8e562c3e9a in start_thread (arg=0x7f8e1affd700) at pthread_create.c:308
#16 0x00007f8e5281eccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#17 0x0000000000000000 in ?? ()

154
Here is a nearly finished tileset which will only work with current svn version:

update, here it is: http://www.titusgames.de/tilesets/desert4_a.7z  ( Only works with MegaGlest versions >3.7.1 !  Currently svn only )

Image1:
(click to show/hide)
Image2:
(click to show/hide)

155
We played  2 games  with 4 players. Both were very slow for the clients. The more units we had in game the more worse it was ( not a big number of  units maybe 300-400 ) . But for the server all was smooth!.
I for myself saw only 25 fps, but it was nearly unplayable because the movement of the units was too choppy.  It was like always freeze and trying to catch up followed by each other.

It looked like the computer was waiting for something ( thread/mutex problems ).  I don't think he was waiting for messages in this moment because I did not had many lines on the console about "waiting for message" .

In the last game I saw this on my console, but I think it doesnt matter:
(click to show/hide)

After these two games we tried the same with 3.7.1
I nearly never fall below 200 fps there and the commmanding of units was more responsive too .


156
Since rev.4173 there are no more crashes in th game for clients. But now we often see very high CPU load for clients in multiplayer games..
Usually its reproducable and happens within the first 5 minutes of a game ( 3 player game in our case ).

to get an idea how much it is:
when CPU load on server is something like 60% on clients we see 155% CPU-load.

157
I got this when tomreyn ( the server)  quits the game.
Code: [Select]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./megaglest'.
Program terminated with signal 6, Aborted.
#0  0x00007f21357c2425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#0  0x00007f21357c2425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f21357c5b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f213580039e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007f2135896807 in __fortify_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007f2135895700 in __chk_fail () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x00007f21358967be in __fdelt_warn () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x0000000000aa6fe8 in Shared::Platform::Socket::hasDataToRead (socket=901007224) at /home/tscharn/glest/megaglest/source/shared_lib/sources/platform/posix/socket.cpp:1056
#7  0x0000000000865cb8 in Glest::Game::NetworkInterface::getNextMessageType (this=0x2b77f80) at /home/tscharn/glest/megaglest/source/glest_game/network/network_interface.cpp:84
#8  0x000000000087c12d in Glest::Game::ClientInterface::waitForMessage (this=0x2b77f80) at /home/tscharn/glest/megaglest/source/glest_game/network/client_interface.cpp:1664
#9  0x0000000000883cee in Glest::Game::ClientInterface::updateFrame (this=0x2b77f80, checkFrame=0x0) at /home/tscharn/glest/megaglest/source/glest_game/network/client_interface.cpp:866
#10 0x0000000000887340 in updateNetworkFrame (this=<optimized out>) at /home/tscharn/glest/megaglest/source/glest_game/network/client_interface.cpp:847
#11 Glest::Game::ClientInterfaceThread::execute (this=0x39bbd80) at /home/tscharn/glest/megaglest/source/glest_game/network/client_interface.cpp:115
#12 0x0000000000a6eb4f in Shared::Platform::Thread::beginExecution (data=<optimized out>) at /home/tscharn/glest/megaglest/source/shared_lib/sources/platform/sdl/thread.cpp:85
#13 0x00007f2139344fd5 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#14 0x00007f2139388999 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#15 0x00007f213911ce9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#16 0x00007f213587fcbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#17 0x0000000000000000 in ?? ()

158
Closed bug reports / [fixed] crash when leaving menu (rev 4168)
« on: 8 March 2013, 00:49:08 »
I don't know exactly which menu it was but maybe the stack tells something. It happened when I wanted to leave MG :
Code: [Select]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./megaglest'.
Program terminated with signal 6, Aborted.
#0  0x00007f02c5294425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#0  0x00007f02c5294425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f02c5297b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f02c528d0ee in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007f02c528d192 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00000000006c44e6 in Glest::Game::Program::loopWorker (this=0x17b68d0) at /home/tscharn/glest/megaglest/source/glest_game/main/program.cpp:399
#5  0x00000000006a9227 in Glest::Game::ExceptionHandler::handleRuntimeError (msg=<optimized out>, getStackTraceString=true) at /home/tscharn/glest/megaglest/source/glest_game/main/main.cpp:652
#6  0x00000000006a934f in Glest::Game::handleSIGSEGV (sig=<optimized out>) at /home/tscharn/glest/megaglest/source/glest_game/main/main.cpp:5196
#7  <signal handler called>
#8  0x0000000000a21402 in cleanup (this=0x2d89050) at /home/tscharn/glest/megaglest/source/shared_lib/sources/platform/common/simple_threads.cpp:383
#9  Shared::PlatformCommon::SimpleTaskThread::~SimpleTaskThread (this=0x2d89050, __in_chrg=<optimized out>) at /home/tscharn/glest/megaglest/source/shared_lib/sources/platform/common/simple_threads.cpp:366
#10 0x0000000000a21569 in Shared::PlatformCommon::SimpleTaskThread::~SimpleTaskThread (this=0x2d89050, __in_chrg=<optimized out>) at /home/tscharn/glest/megaglest/source/shared_lib/sources/platform/common/simple_threads.cpp:375
#11 0x0000000000a237ca in Shared::PlatformCommon::SimpleTaskThread::execute (this=0x2d89050) at /home/tscharn/glest/megaglest/source/shared_lib/sources/platform/common/simple_threads.cpp:496
#12 0x0000000000a6797f in Shared::Platform::Thread::beginExecution (data=<optimized out>) at /home/tscharn/glest/megaglest/source/shared_lib/sources/platform/sdl/thread.cpp:85
#13 0x00007f02c8e16fd5 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#14 0x00007f02c8e5a999 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#15 0x00007f02c8beee9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#16 0x00007f02c5351cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#17 0x0000000000000000 in ?? ()

159
Every 50% I get a crash when I leave a multiplayer game: http://pastebin.com/raw.php?i=9WVgSj9W

We just start the game and after playing some seconds I try to leave the game ( as client ) 0> crash

160
MegaGlest / (thoughts about how to) reduce lag
« on: 28 February 2013, 18:14:28 »
In some svn versions we saw some lag after joining that made me think about lag in general.

What kind of lag do I talk about here is a lag related to multiplayer. Its the command delay lag. So if you give a unit a command it may take a  moment until it reacts.

How does it work in general:
Commands of all clients are send to the server. This collects all commands of one key frame and distributes them to all clients. for execution.
Now the client ( servers a client too in this logic ) receives the command list and executes all commands in the moment they were meant for.
If there are no commands for the next keyframe, the client stops and waits for them.
If the command list was already received it does not stop and just executes the command.

The following scenarios make trouble now: ( Client KeyFrame is c here and server KeyFrame is s )

A client sends his commands to the server. As this takes a while. It can cause one type of commad lag which is:
Delay d=Client to server send time+ time to next command distribution of server+ time to send commands from server to client.
If this delay is bigger than the duratoin of 1 keyframe the command is executed one keyfFame later which is the some lag you already feel.

so   
Code: [Select]
Delay d / keyFrameDuration is the number of keyframes the command is delayed.
This Lag is "natural" and nothing we can change! Its caused by the network speed and is the raw time needed to send packages to the server and back.

But I think there is another problem which makes this problem worse:
Its caused by the start of of the game and the fact that each clients has its own timing.

In the moment the server wants to start he sends a "Start" command to all clients. Once the clients receive this message they start their game and timer.
As the time such a single "start" message can vary a lot it can cause the folowing effect:
a) if a client reaches the next keyframe he might be there too early, because sending the command list takes a bit longer than the initial start message. By this the client has to pause and wait until ist received. This is bad and will result in visible stop and go. To solve this we delay the start of the client a bit to ensure the command list form the server is alreay received.

But what happens if the client starts too late ( for whatever reasonslike long time of sending first message or whatever) ?
This is is very bad and  because it will cause teh following:
As already said the client starts his game and timer after receiving his start comand. If this is delayed for something like 5 seconds we will never be able to catch up this delay at the moment, because the game is timed locally to the clock/timer we started when we received the start message.
5 seconds back means: send a command to the server. the server will queue this command for next command round, but as teh server is already 5 seconds further this command will be in a command list meant for the next server keyframe.  Sadly this command cycle will happen 5 seconds later on the client. For the player on this client this looks like a 5 second delay commanding his unit, also the connection might be fast enough.

I think/hope this can be fixed with the following idea:
On the client once we receive a command list from the server, we save the time ( or better the local game frame )when it was received. Now if we want to start executing this command we compare the current frame to the one we saved after receiving the game.  If this time difference gets too big its the time we need to catch up. This should not be done too exact as sending messages over network can differ a lot. We need to watch it for a longer time period like 10 key frames for example to be sure. Average/Min/And MAx should give us a good idea of what value we can use  to correct the lag.
On the other hand we must correct if clients need to wait for server commands like described before.



161
we wanted to play svn with 3 people. directly after the game started it freezed and all people where disconnected form me ( server ) . Then the server continued.
we tried this 2 times with same result.

The next try ended up with me ( server still loading  ) and 2 clients beeing disconnected.

so something must be wrong.

162
We have this problem s for some revisions now ( since work on joining in game started ):

got to internet game and open a server there. This should be conflict by default with one open slot. Noone can join your game, but its shown on the masterserver .
If I open a second network slot it works and people can join.

163
MegaGlest / New Terrain Rendering possibility
« on: 20 February 2013, 00:33:04 »
A new kind of terrain rendering which is fully compatible with old one and gets us one step closer to use shaders one day.


(click to show/hide)
(click to show/hide)
(click to show/hide)


164
Feature requests / Attack while moving
« on: 16 February 2013, 12:59:27 »
Something I really miss is in Megaglest is a real "move attack" skill. For example a tank which shoots while it passes the enemy.

Some problems I see when doing this:
- The AI will not use it in the right way
- The automated attacking of your own units will also not know how to use this feature in the right way

If soemone has an idea how the units should be have, please tell us.

And something what you will soon want to have with this are something like turrets  for tanks. So two models representing one unit. One turns to the enemy ( the turret ), and the other model rotates according to the movement. of the object.

165
Maps, tilesets and scenarios / map ragor
« on: 25 January 2013, 21:42:39 »
I made a new multiplayer map where you are forced to expand very early. What dó you think?

Download here:
http://www.titusgames.de/maps/ragor_a1.mgm


166
MegaGlest / alternative way to setup MG in eclipse
« on: 19 January 2013, 14:23:08 »
As I wasn't very happy with setting up an eclipse project using cmake, here is an alternative description (for linux):

step1:
Checkout MG.
run build-mg.sh and make everything work so you can compile MegaGlest

step2:
Import MG in eclipse ( via right click ):

Choose the source directory in your svn checkout.


step3:
Setup compile options in eclipse:
-  change make call to "make -j4" where 4 is the number of CPU-Cores you have.
-  set build directory to "build" in your checked out directory.


step4
Setup run configuration so you can launch MG directly form eclipse:


update:
We had some trouble to setup this for my son. All external things( from libs ) were marked as error.

To fix it we disbabled "build automatically" and made a "Project->clean" after this.


167
Bug reports / repair/remove settings
« on: 30 December 2012, 23:04:34 »
I wasn't sure if this is more a bug or a feature request, but here we go:

The last days I often changed the monitor because I was on a LAN Party I have new hardware and so on ... All those monitors had different screen resolutions and I ended up on a small monitor with a huge resolution which I was not able to change from MG because the "ok" button was unreachable.

Another problem we had with last release was a broken language file and so on.

All those problems are very easy to fix for me by editing the ini files manually, but for computer noobs this might be hard to do. Even just removing the glestuser.ini is hard for them and makes MG unplayable for them. Maybe its a good idea to add a "program" that just removes all settings or just sets the default which is installed with MG and reachable via start menues.

168
Hi, today we had an out of sync while playing which made me think a lot.
What happened:
I played magic and I was forced to morph nearly all my initiates to Battlemages, because I was attacked and did not had enough fighters. But my opponent was attacked too by a third player and so he gave up on attacking me. When I saw this I though that I better interrupt all those morphing units because otherwise I would not had anymore initiates to get gold.  SO I send all the morphing units back to gold.
The result was an "out of sync" because excatly in the moment where my command was executed some of the initiates were already morphed to battlemages. But "mining" is not a command a battlemage can do .... ( unknown command for unit xxx game out of sync )

Thinking about this, I came to the conclusion that something similar is the reason for "out of syncs" with slow computers falling back  too, becasue a morphing initiate for example gets an command, but when the command is executed its no longer an initiate , its a battlemage then!

How to solve this ?
We must detect if this unit maybe was a unit of this unit type before and in this case we simply skip the command if there is no such command class.

But how to differ this from a real out of sync ?

169
My last checkin (rev 1924 ) already mentioned it: If you press "shift+e" a screenshot is taken. but you need this combination to use the new listbox navigation using shift+letter+button. ( By the way the list box hotkey feature is in menu state connected now too )

170
Looking at the advanced tutorial I get a strange line wrapping behaviour now:


171
Closed bug reports / [fixed] no preview screen for linked factions
« on: 16 October 2012, 18:00:18 »
In custom game menu are no preview screens for linked factions.
A possible but not so nice way to fix it is to place a screen in the directory with the links too.

172
Closed bug reports / [fixed] ultra pack?
« on: 14 October 2012, 09:19:18 »
In svn I now see a new techtree called "ultrapack" but this does not work as expected. I think its only partly checked in.
Beside of this, didn't we wanted to put this in the mod-center instead of placing it in the core data?

173
If you are connected to a headless server and you are the first/controller switch one slot to a cpu mega.
Then wait 10 seconds and then switch control to network. What you see is screenshot1 for some seconds and then screenshot2 .

What is this "AI1" and "-deaktiviert-" ( english "deaktivated") good for and why is it shown ?
I bet this has something to do with the trumpet playing much too often since some revisions.

screenshot1:
(click to show/hide)

screenshot2:
(click to show/hide)

174
I think this is something I broke  8) ... Its just a marker here so I don't forget it.

The problem:
Hitting "reload last game settings" on a headless server  doesn't restore all. The slots above 4 are not restored. This is something that needs to be fixed.


175
MegaGlest / perf tool
« on: 23 September 2012, 22:29:21 »
hi, tomreyn showed me a tool today that I did not know: perf
In ubuntu install "linux-tools-common"

then run megaglest like this:

perf record ./megaglest
after this just do:
perf report

Here is my result of a long ( singleplayer )game with many units ( 4vs4 ) (using svn rev 3576 ):
http://pastebin.com/raw.php?i=mbXasFV1

I think this is quite useful!

Pages: 1 ... 3 4 5 6 [7] 8 9 10 11 ... 18