I think we are getting closer to a 6.0 release. Which means that we won't be doing a 5.2 release. Maybe it is good to rename that roadmap to 6.1, so that we can move critical bugs to the 6.0 roadmap and keep the 6.1 roadmap for the bugfix release of that.
I think the only main issue that blocks the 6.0 release is still the crash due to that "tri.fanRY <= tri.fanLY" assertion.I have pushed a branch which sets up the light beams directly to the state in which they were when Maikel got the crah. In this branch, the assertion fails directly at application startup:
https://git.openclonk.org/openclonk.git/shortlog/refs/heads/issue1247 [^]
https://git.openclonk.org/openclonk.git/commitdiff/81ba07cc486263e594ac751400ae15d8e0c88428 [^]
I have no idea what the function is even doing. It seems to ascend and descend over a number of beams. But the beam list is not even sorted (at least X coordinates jump back and forth) and some of the beams have zero size.
Peter/Newton, can you use this to understand what is going wrong? If we get this fixed I think we can finish the 6.0 release soon. The remaining stuff seems rather minor to me and most of it I would consider either easy to fix or not release blocking.
MtBrame needs to be fixed as well before but otherwise I agree. Is all the infrastructure available to run a release?
Yeah, MtBrame should be easy to fix. My guess is that the old command structure of doing "Exit fails -> RejectEntrance opens door -> Door action calls SetEntrance(true) -> Exit command succeeds" no longer works or is just not implemented for the hut.Of course we should then also test-play the scenario.
![[de]](/mwf/flags/de.png "Germany")
One thing I am fairly sure should be the case is that the beams are sorted in their X-coordinates. (Which the assertion also asserts)This hints to that the error already happens one step before - at the ray calculation. Sorry, I can't help much there, this is the part of the code I neither touched nor tried to understand so far (because it seemed to work right).
Helpful would be to output the beams in the state in which the assertion happens and draw it.
I might have time on Friday.
> One thing I am fairly sure should be the case is that the beams are sorted in their X-coordinates. (Which the assertion also asserts)
The assertion checks
tri.fanRY <= tri.fanLY. That's checking Y coordinates, isn't it?> Helpful would be to output the beams in the state in which the assertion happens and draw it.
The beam dump is here:
https://git.openclonk.org/openclonk.git/blob/81ba07cc486263e594ac751400ae15d8e0c88428:/light_section_assertion.txt
The LeftX/RightX coordinates are roughly in ascending order, but there's a few jumps.
If these jumps are the problem, it should be relatively simple to put an assert into all functions of C4FoWBeam.cpp and see which function causes the invalid state.
> I might have time on Friday.
That would be great :-)
I made a little debug tool, could this be of help? *gazing at PeterW*Use arrow keys left and right to navigate between the beams.
beams.html
Boy, should really check here more often...
Just to quickly finish this discussion: Rays are sorted by *direction*, which is x/y. In this case, the ray was indeed going backwards (so what Newton said was right), but the mistake was in the Y coordinates. Reason for that was simply a rounding error, where a ray got reduced to about 1/1000 of a pixel, and in the process changed its orientation enough to point into a wrong direction. The fix is simply to eliminate such tiny rays instead of reducing them.
Just to quickly finish this discussion: Rays are sorted by *direction*, which is x/y. In this case, the ray was indeed going backwards (so what Newton said was right), but the mistake was in the Y coordinates. Reason for that was simply a rounding error, where a ray got reduced to about 1/1000 of a pixel, and in the process changed its orientation enough to point into a wrong direction. The fix is simply to eliminate such tiny rays instead of reducing them.
So are there any remaining objections to 6.0 release? And do the release scripts still work?
![[us]](/mwf/flags/us.png "United States")
> And do the release scripts still work?
They should... we can make a dry release to make sure things are packaged correctly.
Can you have a look at this problem?
Edit: ./openclonk: error while loading shared libraries: libvorbisfile.so.3: cannot open shared object file: No such file or directory
when running the 32-bit linux release on ubuntu 14.04 64-bit.
Otherwise the dry release seemed to have worked fine.
Edit: ./openclonk: error while loading shared libraries: libvorbisfile.so.3: cannot open shared object file: No such file or directory
when running the 32-bit linux release on ubuntu 14.04 64-bit.
Otherwise the dry release seemed to have worked fine.
> Otherwise the dry release seemed to have worked fine.
Custom keyboard config not saving is also a pretty nasty bug I think. Multiple people have complained about it already.
Does it work for the repos version? We can postpone that to the 6.1 bugfix release I suppose.
It should really not be hard to fix. Unfortunately, I don't have time at the moment.It probably broke when keyboard configs were changed to scan codes to make them keyboard layout independent. Just needs someone to step through the CompileFuncs and see what is happening.
> Edit: ./openclonk: error while loading shared libraries: libvorbisfile.so.3: cannot open shared object file: No such file or directory
I don't have an ubuntu around at the moment. Do you have "libvorbisfile3" installed? The release candidate works for me on Debian Jessie.
Do you maybe have a different version of libvorbisfile around?
It is quite a lot of work and I don't remember all the steps.
This weekend I have some time, but it would be good if other people are also online/helping.
This weekend I have some time, but it would be good if other people are also online/helping.
I'm very busy finishing my PhD ATM, but I"ll try to be available this weekend.
I'll be there. What time?I have to change the download page after the release because it assumes a 3-digit version number I think.
I am trying to gather some release steps. If anyone knows some places where we wrote down more, please let me know. I know about the release button page.
The procedure could include creation of a release candidate using the dry release function.I think the tag should be in post release because it cannot be undone. If you tag and then decide to still change something last second, you have to give a new version. It happened to me for the 5.0 release, which then had to become the 5.1 release because some important changes to the update system had to be done.
6.0 will also be the first test of the changed update system.
The checklist at the release button should link to or embed the wiki article I think.
I made a preview blogpost, feedback and additions much appreciated.
I have made a dry release, would be good if someone can test the windows installers.
Edit: ./openclonk: error while loading shared libraries: libvorbisfile.so.3: cannot open shared object file: No such file or directory
when running the 32-bit linux release on ubuntu 14.04 64-bit.
Edit: ./openclonk: error while loading shared libraries: libvorbisfile.so.3: cannot open shared object file: No such file or directory
when running the 32-bit linux release on ubuntu 14.04 64-bit.
Just for clarification (for the upcoming update tomorrow):This is now OpenClonk 5.6.0 right? OC had previously been 5.0.0 up to 5.5.1 (aka "OpenClonk 5.1"). I'm just a bit confused since the dry release is labeled as "openclonk-6.0" this time.
Could you please also upload the source tarballs (openclonk-6.0-src.tar.gz)? I'd like to update the AUR entry.
Is work in progress (needs a bit more time, because files need to be removed).
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
