![[de]](/mwf/flags/de.png "Germany")
Clonk-Karl and I cherrypicked all the bugfixes for 3.3. Here are the binaries for testing:http://londeroth.org/~ck/dry-release/
We already tested a little bit and found these issues that should be analyzed further:
+ somebody needs to compile a mac build and see if it works
+ switching resolution is buggy in windowed mode (seems to be the same on master)
+ using the lorry and the elevator together is buggy
These issues are not release-blocking since they are probably also present in 3.2 but still it would be nice to have them fixed. We are both not at home tomorrow, so the rest of the (networked) playtesting etc. is up to you! Otherwise, have fun playtesting tomorrow! A blog post draft has been prepared.
>+ using the lorry and the elevator together is buggy
How exactly?
Related commits:
Attached objects with SolidMask (slave elevator case...
Move the elevator case behind airships
Fix elevator case to properly carry lorries (#844)
The second one is not in the 5.3 release. Note that moving the elevator behind airships is not purely visual!. The plane (as in "layer") of the elevator case affects its behavior!
PS: not sure if it is only that, though
> PS: not sure if it is only that, though
What else?
> http://git.openclonk.org/openclonk.git/commit/c613c86c379b0477a5512a219a812bcb6586a823
so just this one needs to be picked and then the elevator+lorry is not buggy anmore?
I am not sure, the solid mask stuff is always very mysterious. But it would be my best guess.Can't test it right now since I still have unfinished stuff in my repository and I am still scarred from hg about doing something before having pushed my commits.. :)
PS: I checked the plane of the lorry and it's 300. So the elevator case should work with the lorry without that commit!
![[gb]](/mwf/flags/gb.png "United Kingdom")
Can we cherry-pick 4b63957? That's mostly logging, trying to find the dreaded "could not send direct control packet" bug.
Uh, really? Close connection on packet loss? Doesn't that mean if you have only one connection and many people join, they keep disconnecting?
It's not packet loss - it's when you actually fail to send a packet, for which there should be no reason. And I think kicking people out is better than having them continue with an inconsistent network state.
Practically every large network game in CR is flooded by these messages in the lobby and we almost never get sync losses. We just have to click the team settings a couple of times until everyone has a consistent state.It's not ideal, but it works. If connections are just closed, large games become impossible.
It may sound naive, but could it be that if you send a number (e.g.: 10) of UDP packets at the same time, the network stack just says "no" and the packet isn't sent?
That the packet isn't sent is expected behaviour - say when an UDP connection is used for sending resources, I expect 99% of the packets to initially get discarded, then eventually recovered (which is all very inefficient, hence UDP being really bad at this). So this happens all the time, yet in my tests the packets always got silently dropped.
My best working hypothesis is btw that this happens when the main thread and the network thread are both sending packets at the same time. In the lobby, a lot of resource packets might be going around (= network thread), while the main thread is trying to pass player info updates around (= main thread). That would explain why this happens more often the more players are active. Yet I would really expect sendto to be thread-safe...
[Edit] Which actually shouldn't happen, as the
My best working hypothesis is btw that this happens when the main thread and the network thread are both sending packets at the same time. In the lobby, a lot of resource packets might be going around (= network thread), while the main thread is trying to pass player info updates around (= main thread). That would explain why this happens more often the more players are active. Yet I would really expect sendto to be thread-safe...
[Edit] Which actually shouldn't happen, as the
OutCSec on the Peer in question is being held. So much for that theory.
Hm, actually looking more at the code, if
I really have to clean this up a bit. But no matter how inconsistent this might be right now, it still doesn't explain where the error is coming from.
sendto really was to blame, C4NetIO would actually give an error, but recover the packet in question. Which is still problematic, as the code on the return path assumes the packet is lost, and therefore doesn't execute it. So the direct control effect would actually be visible everywhere but on the client that caused it.I really have to clean this up a bit. But no matter how inconsistent this might be right now, it still doesn't explain where the error is coming from.
I'm describing what the code does that is currently "stable" :)
And it just needs to get into a some version that actually gets played. I don't really want to repeat the whole CR "stable" debacle where nobody played the "dev" version enough to actually make anything more reliable.
And it just needs to get into a some version that actually gets played. I don't really want to repeat the whole CR "stable" debacle where nobody played the "dev" version enough to actually make anything more reliable.
Since all new scenarios are in Experimental, we* actually play dev much more than we play stable.We just never get enough people to experience the packet sending bug.
*We=Me and the people who join when I ask in #openclonk
If you are confident about that, yes please do that. If this is a critical change that can possibly break other things, what needs to be tested to assure that it does not?
Network play. Pretty much every packet the network sends goes through that routine.
More precisely: Try a network game with ten people. To get the message more reliably, disable TCP on the host.
Tested with just one client: [20:54] Sven2: [20:53:42] Network: Fatal: Send failed (socket sendto failed (Resource temporarily unavailable.))
[20:54] Sven2: Looks like we don't need 10 clients
[20:54] Sven2: One is enough...
[20:55] Sven2: I disabled my TCP and now I cannot join
[21:02] Sven2: Anyway. The change should not be picked because it breaks UDP-only connections.
Crash Landing, Berry picking and Rock Bottom all worked in our test.
> switching resolution is buggy in windowed mode (seems to be the same on master)
I've polished this a bit, the result is at http://git.openclonk.org/guenther/experimental.git
Is this eligable for stable? Did you test it on your PC (Linux, Gtk I presume)? Is this change relevant for Windows too (and needs to be tested there)?
Depends on whether the other resolution-setting changes were picked. Yes to the other questions.
Tested it on Windows. Now changing the resolution in windowed mode doesn't do anything anymore and if I switch between Windowed and Fullscreen, it always ignores the resolution but chooses the default desktop screen resolution.Resizing the window in windowed mode does not scale the menus.
> Now changing the resolution in windowed mode doesn't do anything anymore
Which is by design, changing the window size is done via the window borders.
> if I switch between Windowed and Fullscreen, it always ignores the resolution but chooses the default desktop screen resolution.
That doesn't happen with GTK. Hmz.
> Resizing the window in windowed mode does not scale the menus.
I don't have enough motivation to change that, unfortunately.
> + using the lorry and the elevator together is buggy
What exactly do you mean by "buggy"? Is the lorry not transported? Does the elevator control not work? Does it not work with two coupled elevators?
I don't know if it's still relevant, but CreatePartickeAtBone() is pretty cool and didn't break anything in the few games I used it in.
Hm, why wasn't the stable released yesterday? Did nobody feel responsible for that? Did nobody know how to push the changesets and push the release button?What was the problem?
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
