We should probably just disable LZB for the release. It's been broken for a long time and won't magically start working again. The option just confuses people, especially if it appears to work but then desyncs immediately.
Btw: You added a hack to no longer access player infos in OnSynchronized? Wouldn't it be better to postpone that callback until after players are initialized? The current hack seems rather shaky to me.
I think the remaining issue is now with player actions between the host saving the game and the joining player getting activated. I'm going to have a look. I guess we could always just pause the game during runtime join.
It seems that the snapshot engine does not create the parkour arrow helper object, while my self-built engine does. I have no idea what is going on.
So I guess we need to do more testing now and see what doesn't work?
>I'm standing in front of the old problem I had when making crctrl that writing a program that controls another process through pipes isn't exactly without bells and whistles, especially if you want to be fault tolerant. Does anyone know a good environment for this?
What exactly do you mean?
What you want is spawning a subprocess with stdin/stdout attached, reads with timeouts (usually that is realized through nonblocking reads and timeouted polls), being able to close pipes, being able to wait on the process to exit (again with a timeout), being able to kill the process.
But yeah, this is a bit OT…
>You start getting zombie processes
Huh. Doesn't closing clonk's stdin automatically shuts it down?
>you have to be extra careful that nothing writes to buffered pipes/everything flushes correctly; if you use some programming language's API, that one feature you need to do it correctly won't be there, good luck if you expect it to be platform independent; …
Yeah, you've got to be careful. Concerning flushing, in my code, I disabled buffering and let it flush clonk's stdin after every write (dunno if flushing is really necessary here, though).
>reads with timeouts (usually that is realized through nonblocking reads and timeouted polls)
Why exactly with timeouts?
*) also in terms of gameplay
PS: That's why we did early feature freezes the last two times
To make the bugfix release actually happen, we should set up an "8.x" branch. Each time someone fixes a bug, they should immediately push that fix to the 8.x branch as well. Picking out bugfix commits from a huge list of changes just doesn't work, see our 7.1 release that never happened.
Plus, even a bugfix release will have to be tested before release. And then we can as well test and release the latest version.
>plus, even a bugfix release will have to be tested before release. And then we can as well test and release the latest version.
We could also do this in a more standardized manner, so that it is ensured that everything works as intended without everyone testing everything, and maybe even release more often?
On the other hand we could theoretically do a release every month but that really doesn't add anything, does it?
>But it's extra work to do that. I'm not sure if developers will really keep up with it.
Yeah, I guess this would be for a few months only, just so that we can get bugs fixed as quickly as possible.
>And then we can as well test and release the latest version.
We tend to break compatibility with scenarios and save games often which will probably annoy people. But yeah, I'm also for more frequent releases. I just fear that some big feature will happen soon after release (e.g. Larry integration) and then everyone thinks it's not stable enough for months and bugs in 8.0 don't get fixed until two years later.
>Christmas is getting near now
>Many bugs on the Roadmap are either engine stuff
I think that is the problem. We don't have many active engine developers willing to fix bugs, right? That's how the collection of engine bugs got accumulated. So maybe, we should let engine developers decide about the release schedule, and how much of the open stuff they are willing to do. I mean otherwise it is just dreaming.
The rest of the engine stuff, that won't be done for now I guess has to be put aside or postponed. We wait for the willing fixes and then we just release. There is no other way, right?
> So maybe, we should let engine developers decide about the release schedule
Well, then ask Sven2 about his release schedule. He's the only dev with sufficient engine experience still active.
% git shortlog -s v7.0.. | sort -rn
636 Sven Eberhardt ✓ Engine and Tools
424 Maikel de Vries ✓ Scripting and Content
394 Mark ✗ currently Contributors, should be Scripting and Content?
248 Lukas Werling ✗ should be Engine and Tools?
244 Nicolas Hake ✓ Engine and Tools
178 Günther Brammer ✓ Engine and Tools
113 Clonkonaut ✓ Scripting and Content
75 Fulgen301 ✗ should be Contributors
66 David Dormagen ✓ Scripting and Content
46 Julius Michaelis ✓ Engine and Tools
44 Armin Burgmeier ✓ Engine and Tools
14 Tobias Zwick ✓ Administration
12 Martin Strohmeier ✓ Music and Sound
6 Martin Plicht ✓ Engine and Tools
6 Linus Heckemann ✗ should be Contributors
6 Kanibal ✗ should be Contributors
5 Armin Schäfer ✓ Contributors
4 Tushar Maheshwari ✗ should be Contributors
3 jok21 ✗ should be Contributors
2 Philipp Kern ✓ Contributors/package maintainers
2 Matthias Rottländer ✓ Art and Content
1 Matthias Mailänder ✗ should be Contributors
1 kpone33 (duplicate)
1 ckanibal (duplicate)
As noted by Newton the last time he updated the credits for 7.0, we're somewhat running out of space. We can't add all new contributors without removing some others, and we probably also lose a line of contributors for the two new entries in Engine and Tools and Scripting and Content. Making the list scroll is probably too much work for now, but we should try to raise the resolution, if only to make it look less shitty on modern monitors.
Also, how do we sort the entries? Engine and Tools currently appears to be sorted alphabetically except for Sven and Caesar, while Scripting/Art and Content correspond to the absolute commit counts (that list only shows those with github accounts though).
I think sorting by absolute commit counts is fine for all with direct commit access. For the Contributors list, we could add a line for minor contributions of that release only (those with 1-10 commits in the list above). We also have to take in account contributions like art and milestone project stuff that someone else (mostly Zapper/Clonkonaut?) commits to the repository.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill