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

Pages: 1 ... 84 85 86 87 [88] 89 90
2176
Yes, for that error to occur means the client got nothing on their network connection for > 10 seconds. ANY client that has a connection that awful would have no chance to play Glest in its current state. I noticed no problems on the server, which confirms that this client's connection must have been the likely cause. I think our latest changes with Silnarm's packet fix should make things a lot more stable than ever. We need people to continue testing and posting any logs if issues arise.

Thanks

2177
Will do, I am still learning glest, thanks for the pointers.

2178
Ok the new resource type works like this:

Resource = fish (this is setup to use the new static_no_recoup_cost)
Unit = Fishing Hole
Unit = Penguin
Unit = Fish (hidden unit with height and width of 0)

A penguin costs: 75 gold and 1 fish

#1 A penguin builds a Fishing Hole which costs: 100 gold and 100 wood
#2 The Fishing Hole can produce Fish Units which costs: 100 gold and -7 fish (which adds fish resources to the fish resource count once production of the hidden fish unit is done)

With normal static resources, once the unit (penguin) dies than the resources used to produce it (if the resource is static) are placed back into your resource count. In our case we don't want the resources back but there is no way to stop that otherwise so I created a new type of static resource that will not give back the static resources used to build a Unit when the Unit dies.

Does that make sense?

2179
Yes please I'd like to have access.

P.S. I made a new resource type (which will be included in the next update) called:

static_no_recoup_cost

It is EXACTLY like static except when a Unit dies that requires a static_no_recoup_cost resource as its cost, it WILL NOT recoup the cost of the resource as it does with static.

This allows my son to create fish and coin resources for his tech's and when the unit dies associated with the resource then it doesn't add the resource back.

Let me know if the new network changes work well now?

Thanks

2180
Updates at:

mega glest - http://soft-haus.com/glest/code/megaglest-source-3.2.4-4-beta1.7z
regular glest patch - http://soft-haus.com/glest/code/glest_patch_2010_jan_30.diff

This update (hopefully) fixes the disconnect issue found by Titi and also adds Silnarms contribution to cut down on network cholesterol :)

Thanks

P.S. Its time we got mega-glest in svn somewhere to make this a little easier.

2181
Ok, the logs helped and I see what the problem is, I'll look into the solution shortly.

2182
Tom: I don't see the ESC problem you are talking about in my version of Glest (does anyone else see it?)

Titi: Is the network code working well? I suppose we'll need some testing for at least a couple days?

Silnarm / Titi: Thanks for the info about the slowdown and speed up, I did not know what they were there for.

P.S. I'm making good progress in building a CodeBlocks project to cross compile mega glest in ubuntu to produce a Win32 binary.

2183
Tom, where did you get glest.bin from, the auto-installer built into Ubuntu? If so you need to build your own version to get the fixes we have been implementing until someone is able to produce a binary for Ubuntu 8.10

Thanks

2184
Hello silnarm:

In reply to your post about network congestion. In general if a client cannot AT LEAST keep up to the # packets generated each "group" of FPS then they cannot play. I think we could use something like Titi mentioned, an algorithm that the server could calculate to determine if the client will be able to play or not.

The threading would help in many cases since it would allow for clients to "catch up" without creating choppiness (at least I believe there is a way). This would only work in the case where clients have a good enough pipe on their network connection. You need:

1) good enough FPS (video card has something to do with that)
2) good enough network connection / traffic should be reasonably low

and... we should make sure the network packet sizes used in glest are absolute minimum so as to not require to much chattiness over the network.

Anyways more discussion once we get the current situation reasonably under control. We may hit a threshold that we cannot do better with the current framework, but as of yet that is not the case.

Thanks

2185
Updates at:

mega glest - http://soft-haus.com/glest/code/megaglest-source-3.2.4-3-beta1.7z
regular glest patch - http://soft-haus.com/glest/code/glest_patch_2010_jan_28.diff

Thanks

(the only change was one line of code to socket.cpp for posix and windows)

2186
My mistake on the crash, one line of code used the wrong variable, a fix will be ready shortly.

2187
Regardless of the solution it will be very important to separate network communication into threads (both on server and client). Otherwise we have major problems related to FPS on each computer playing a network game, which will slow down the network transmit rates AND the network connection will also add additional problems if the connection is slower.

By creating threads we can manage the congestion in a separate manner from the UI. Things still need to be synchronized, but how we do it can be less visible to each system as we handle it in the threads.

This needs to be carefully planned and designed well to take glest to the next level for multi-player features.

Recap:

The current network code slows down the FPS AND the FPS will slow down the network communication. This connection needs to be addressed.

Thanks

2188
What you say is totally true. However I disagree with the solution. My phase #1 approach at changing the code is just an attempt to properly understand the network code. I have already posted about the frame issue as a problem in previous posts. The goal for now was to try to get the existing code to work "better" so that multiplayer has greater potential in the short term.

With that said I believe a better approach for the long term (which many other games use) is to run the whole network engine in background threads on both client and server (and thus avoid choppy GUI) and from those threads we would be able to better synch network packets in the GUI. Each packet ALREADY carries the frame # which is essential, and we could have the threads queue up the data and pass it to the GUI at the right time in both server and clients. This is what I had previously called phase #2 which would ultimately remove the synch problem for good and open the door for perhaps > 4 player in the future.

I have already experimented with enet (a common network engine used in games written by one of the authors I know who works on Sauerbraten) but it is of no use for phase #1 do to its design.

Thanks

2189
Actually it "should" be possible to build using linux and mingw. I am able to use codeblocks to compile a tool I wrote for my router that compiles to my routers linux (busybox - Tomato firmware), ubuntu and windows.

2190
I'll try to get a Windows binary compiled using my VirtualBox XP Image once we verify that the network code is working (all changes are also in the windows code so it should be easy to produce a working binary).

P.S. sorry Titi we cannot help with testing today as I am working (PST is our timezone)

2191
Updates at:

mega glest - http://soft-haus.com/glest/code/megaglest-source-3.2.4-2-beta1.7z
regular glest patch - http://soft-haus.com/glest/code/glest_patch_2010_jan_27-1.diff

Thanks

P.S. many of these bugs are from original glest network code but are showing up since the network code runs faster.

2193
Strange, I am not able to reproduce the following:

- connect to a non exsiting server ( any ip where no glest is running ) :
Game freezes for some seconds and comes back. If you now press the "return" button glest client crashes

- server opens with more than 1 open slot
client connects/disconnects several times -> server crash

- clients still connect to any open slot, not the first one ( top down order )

I will try (and get the boys to try)

Are you saying each change I make you want me to give the build a new name? If so would I call it 3.2.4 beta2, then beta 3 etc?

( Please give the clients new version numbers today we already get mixed up with the different glest3.2.4_beta1 versions .... )

Thanks

2194
All reported problems reproduced and patched:

Updates at:

mega glest - http://soft-haus.com/glest/code/megaglest-source-3.2.4-beta1.7z
regular glest patch - http://soft-haus.com/glest/code/glest_patch_2010_jan_25.diff

I won't be looking at any new features until we get the networking stuff solid first, so everyone let me know how this version works out.

2195
Ok I "think" I found the start crash issue (random crash just when client games are about to start.

Updates at:

mega glest - http://soft-haus.com/glest/code/megaglest-source-3.2.4-beta1.7z
regular glest patch - http://soft-haus.com/glest/code/glest_patch_2010_jan_24.diff

2196
Ok whoever is able to test, the updated glest patch and the mega-glest 3.2.4-beta1 are available at:

http://www.soft-haus.com/glest/code/

Glest patch is called:        glest_patch_2010_jan_23-2.diff
Mega Glest update called: megaglest-source-3.2.4-beta1.7z

This update:

- improves network play stability and performance
- allows chatting once connected in the lobby when preparing to start a new game (once you are connected)
- sends a text message to all players if a player purposefully quits a game in the middle of play.
- Tells both server and clients whether or not the selected Map, Tile, Tech and FogOFWar settings all match

That is it. Please test and give feedback so that we can get a rock solid release of multiplayer.

I have stubbed in code for auto-download of mis-matched content, but that is currently disabled until some quality time can be spent getting feedback and coding it to be solid.

Thanks

2197
Ok found a few glitches related to when you manually disconnect the server in the lobby, and choppiness when changing settings on the server in lobby mode, all have been fixed but I won't publish updates until we have done more thorough testing. In general game play seems fine though with multi-player.

2198
Multiplayer / Re: tom123s network problems
« on: 23 January 2010, 15:17:26 »
Tom I think you need to relax, Glest is just a game, and we offer out time for free (and no I wouldn't take your money anways). I don't want to discourage you from playing glest but when you encounter a problem, don't expect 24 x 7 paid style support.

Thanks

2199
Ok, tightened up the network code, and also have added the ability to chat while waiting in the lobby (both server and clients).

As usual the patch for regular glest 3.2.X and the whole archive for megaglest are waiting at my website:

http://soft-haus.com/glest/code/

The patch for regular glest is called: glest_patch_2010_jan_23.diff.txt
The archive for mega glest is called:   megaglest-source-3.2.3-beta4-2.7z

Let me know how this goes.

P.S. if you want loads of debug info in the console (which is helpful is we encounter issues) compile with:

bool Socket::enableDebugText = true;

in socket.cpp

Remember there is one socket.cpp for posix (linux) and another for windows.

2200
By the way when I said "existing oversight" I meant that the code in glest all along did not properly handle return codes from socket send and receive operations and thus that might explain some random weird behaviour within glest over the years (especially related to one or more slow clients or network congestion).

So hopefully we'll get things moving along shortly, and yes I'll patch both regular glest and mega glest.

Thanks

Pages: 1 ... 84 85 86 87 [88] 89 90