![[de]](/mwf/flags/de.png "Germany")
PS: also, closing bugs just because we don't expect them to be fixed because of lack of developers feels a bit like giving up to me. But I agree that we shouldn't push them just to the next release.
Hey, great to see someone finally going through the necessary bugfixes, and therefore setting the release plan in motion :). I was surprised when I got like 20 notification emails for the bugtracker.
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.
Yeah, deactivating would be best. Sadly, another nice feature gone.
![[us]](/mwf/flags/us.png "United States")
Didn't work for me on RndMap :(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.
Yeah, [I added an issue for that](http://bugs.openclonk.org/view.php?id=1953). It's not that much of a hack anyways, the HUD code still does pretty much the same.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.
I also want to bring this to attention: http://bugs.openclonk.org/view.php?id=1943It 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.
Christmas is getting near now, I wanted to ask if we have a solid plan for a release now. The last few days I struggled a bit to come up with things to do. Many bugs on the Roadmap are either engine stuff and/or not very serious.So I guess we need to do more testing now and see what doesn't work?
Same problem here, not many bugs left that I can fix on the 8.0 roadmap.
Regarding "more testing": what do we usually test, and could we somehow automate/standardize that?
For 7.0 I remember we played every built-in scenario at least once to ensure it's playable.
I don't think we can automate it. As K-Pone said, this kind of testing involves playing all the scenarios and see if they can still be won, if important things changed or if changes in balancing / object behaviour should result in certain changes in the scenario (e.g. I changed the required construction material for the teleglove, we need to make sure that all scenarios in which the teleglove is important still support it).
We can at least automate checking whether a change doesn't introduce a script error in the initialization scripts. I was working on a little rust thingy to start the dedicated server on every round and check the output for script errors, but rust is just not ready for this yet. 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? (Otherwise, I'm just going to add a --max-frames command line parameter to the engine and roll with that.)
I don't know anything about rust, but I know that I could do it locally in Java (am I that Java guy now? ^^). Good idea by the way!
![[jp]](/mwf/flags/jp.png "Japan")
Detecting script errors is the easiest part of all the testing, however. It is most obvious and even without an automated test doesn't take that long to check (you don't need to do it everytime someone makes a commit, only before a release). Not to discourage you from what you are doing. ;)
Yeah, but having that run at every commit, for all scenarios, doesn't sound so bad, no?
No, it's not bad. As I said, I don't want to discourage anything. ;) Just if you say that other features wait because of this, a reevaluation of its usefulness might be in order!
![[at]](/mwf/flags/at.png "Austria")
>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?
You start getting zombie processes; 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; …
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…
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?
Why do you want to plug into stdin/stdout? You could just read a list of available scenarios or engine start parameters, then for every item in the list launch the engine, wait until the "x warnings, y errors" output is in the log, then kill the process and start the next scenario. The only real benefit is that it runs independent of the log file location and you don't have to deal with log files that were not deleted, correct?
I had some success with pexpect for automatically testing runtime join: https://gist.github.com/lluchs/b1a1f28bf6eba6e0d0d39dced353cf5c
I tried again, the problem was indeed in OC. My code worked mostly as intended. Sample output.
There have been quite a few functional changes lately. I doub't that we can guarantee a stable*) release until christmas?*) also in terms of gameplay
PS: That's why we did early feature freezes the last two times
We can (should?) still decree a feature freeze. Which funtional changes in particular do you have in mind? We could/should focus our testing on those changes.
The switch stuff, the animation and control changes (which I still think are good and we could do even more for the next release!), the fire stuff. And probably more that I forgot now
My changes for the dive jump are still not tested by anyone but me, but I'd like to commit them
You know, there is the option to make use of the second digit in the version number.
I agree - we should go for the Christmas release and aim for a bugfix release a couple months later. Getting everything right is unlikely no matter how long we prepare for release.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.
But it's extra work to do that. I'm not sure if developers will really keep up with it.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?
Everyone always wants to release more often. But we never do it anyway :)
Yes, frequent releases are kind of not necessary, because the active community uses the snapshots anyway, right? Would be interesting who even plays the released version.
On the other hand we could theoretically do a release every month but that really doesn't add anything, does it?
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.
I'm very busy. Are there actual release-blocking bugs? We played a lot recently and things worked fine.
Something broke deathmatch lately. Just fixed it, but I guess there are quite a few still remaining. We really need to test at least two scenarios of every type. I don't have any time next week, but probably some after that.
I had a look at the About dialog (planet/Graphics.ocg/StartupAboutBG.png) and the git log:
% 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.
For contributors: We might want to add hasufell (Julian Ospald, for gentoo) to the list. Might want to, don't have to, if it really won't fit.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
