![[de]](/mwf/flags/de.png "Germany")
Yaaaay, we are through, finally a release! And I am happy to see that we get so much feedback on our forum. While we still have this momentum, I would like to plan a bugfix release for our new stable. This release should, hence the name, contain mostly bugfixes and small uncritical enhancements (not the priority though). Here is what I gathered from the forum in the last days and from the OCM leftovers. I think the number of tasks here is enough to fill the time we have till mid of November.errors/bugs
+ graphics card fixes?
+ Savegames of network games don't work
+ The usage of the hammer doesn't work sometimes with one click
+ if you have a shield, climb (or hangle or swim...) and use it the Clonk always turns around which looks very strange when climbing.
+ remove FIXMEs while loading meshes
+ elevator bug(s): http://forum.openclonk.org/topic_show.pl?tid=2562
+ kill them with fire!: search & destroy in the bugtracker
Enhancements
+ make connection between flag and power clearer
+ make it clearer how to pick up stuff (Tutorial 1: remove first chest, instead put objects in wall, ceiling and ground)
+ On first start of the game: automatically activate newly created player
+ particle drawing offsets don't zoom properly under certain conditions. http://forum.openclonk.org/topic_show.pl?tid=2503
+ make the pump a 3d model instead of an animated graphic
other
+ gather with which graphics cards does OC have problems exactly? -> put them into the FAQ. I read enough posts and bugtracker entries about crappy Intel chipsets already.
> OCUs do not work apparently. OpenClonk 3.0 didn't even try to download the ocu but said straight that I will have to redownload
For 5.3.0 we didn't even provide updates, did we? Do you mean the update from 5.3.0 to 5.3.1?
![[ca]](/mwf/flags/ca.png "Canada")
>+ make the pump a 3d model instead of an animated graphic
This could pose quite a problem, because the OGRE exporter does not properly export the animation. The pump uses some fancy rigging which isn't "baked" into the animations.
Oh? why don't you bake it, then? :o
![[at]](/mwf/flags/at.png "Austria")
>+ The usage of the hammer doesn't work sometimes with one click
To be exact the menu interprets the left click also as left click on the menu-item that is created when you use the hammer. (So the left click to open the menu also is interpreted as a click on an entry that is created during said left click. Don't ask me why.)
>+ Boompack attaches to wrong vertex as an heavy item
Generally Carry-Heavy items are just attached to the back-bone. The same other items are attached to when they're worn on the back.
> To be exact the menu interprets the left click also as left click on the menu-item that is created when you use the hammer. (So the left click to open the menu also is interpreted as a click on an entry that is created during said left click. Don't ask me why.)
I have fixed this. The problem Newton is talking about is a different one. It seems like ControlUse() is not even called in the hammer in this case.
Someone on the CM said that it might be when you click behind you, that the first click turns you around and only the second click opens the menu. I don't know how accurate that is, but it might be worth investigating
I have also seen it happening when clicking in the direction your clonk is looking. But yes, if you are not and the bug happens then the clonk turns around.
>+ kill them with fire!: search & destroy in the bugtracker
It would be good to clean up the bugtracker a bit, especially the number of unassigned issues is very high, we should reduce that by closing the old ones, and assigning the relevant ones.
None of those I am really able to do, so I just did some from the bug tracker or forum.
I'll tackle the elevator stuff. I wanted to rewrite it anyway..Ps: and the shield whch should be ~trivial :)
Rewriting stuff sounds exactly like the right thing to do for a stable release. :P
> Flag markers don't fade out when a new flag is added that extends the territory
Fixed in c6bd1ada1272.
> + remove FIXMEs while loading meshes
I have changed the meshes so they do not contain more than one set of texture coordinates.
How did you do that? I already tried that last week with some program that converts the binary mesh info into xml and the other way round. However it casted some errors and after the edit and reconvert to binary clonk couldn't load the mesh at all anymore.
I did exactly what you describe. It didn't show any error, though.
>+ On first start of the game: automatically activate newly created player
I had a quick look in the source code, it seems to be implemented. There might be an update necessary for the startup screen to reflect the change. I haven't got my develepement machine here currently, but I might play around with it myself later today and add a patch here.
http://bugs.openclonk.org/view.php?id=826 <-- highest priority!
Hey guys, just want to leave a note saying that I won't be able to contribute anything more on the update which will be released end of next week. Now that activity died down a bit in general again, I would like to ask if anybody else still got something plans to contribute to the bugfix release. Otherwise, we could bring forward the release and do it during this week.
![[gb]](/mwf/flags/gb.png "United Kingdom")
Thanks for the push, I want to at least fix the "yellow landscape" bug and make material zooming configurable.
Okay, should be done.
Default material zoom is also now 8 (up from 4), as I see way too many screenshots with blurry material textures. I like it better this way - if somebody strongly dislikes this, please speak up!
Default material zoom is also now 8 (up from 4), as I see way too many screenshots with blurry material textures. I like it better this way - if somebody strongly dislikes this, please speak up!
What does it mean? Is the landscape higer resolution, or can't you zoom in that far anymore?
The landscape textures are smaller - 8x8 texture pixels per landscape pixels instead of 4x4.
It's a bit hard to give a fair comparison to something that primarily allows for greater flexibility while zooming and might allow better textures once we get them. After all, it would be easy to get the old effect, simply by scaling the textures up to 1024x1024. But here we go...
Not sure if I like it. The texture repetitions on the "new" screenshot are pretty obvious at the moment.
All the textures are made for to be shown at 4x4 size. Unless you want to redo every texture, please don't push that change.
How exactly where they "made for" that size? We have viewed them for the longest time at the current zoom level, and I think it is holding us back quality-wise.
Should I maybe push the up-scaled textures as well? Or how to be get textures that are "made for" viewing at 8x8 level?
Should I maybe push the up-scaled textures as well? Or how to be get textures that are "made for" viewing at 8x8 level?
They were made for that size in the sense that the details that can be seen are scaled in a size that looks good if the texture is displayed at 4x4: for the graininess of the sand/earth textures and the distinctiveness of the details seen in the textures (see Sven). Most notably this is important for the bricks texture but the others I made were also scaled (from photos etc) keeping these limitations in mind.The only way to scale them up properly is to create them anew completely from the source material keeping those limitations in mind. Given that the quality of the source material is high enough of course.
Please do not underestimate the amount of consideration I put into it while making the material textures.
Well, I haven't seen any change in the textures since I more or less arbitrarily set the zoom factor to 4 - especially on the Tunnel texture, that seems to assume some crumbles of earth to be the same size as a Clonk head. That just looked like a non-brainer to me :)
The question is - how exactly are we going to go about that change? In contrast to our early expectations, people seem to go up to 6x zoom relatively often, so 4x textures simply won't cut it.
The question is - how exactly are we going to go about that change? In contrast to our early expectations, people seem to go up to 6x zoom relatively often, so 4x textures simply won't cut it.
The tunnel texture is not from one of my photos, it's not really good, yes.I don't really see a problem here. I never noticed a blurryness in the game, perhaps partly because there are much more noticeable things that need to be improved graphically.
Okay, I've reset the default material texture zoom to 4. I'll leave it for the lights branch though, as that will require a revision to the textures anyway.
Also - am I the only one that after looking at the textures more closely now sees JPEG artifacts everywhere?
Also - am I the only one that after looking at the textures more closely now sees JPEG artifacts everywhere?
>Also - am I the only one that after looking at the textures more closely now sees JPEG artifacts everywhere?
Yes... where in your screenshot is one? :o
Isn't visible in the thumbnail. But once you open it up you can see a subtle "grid" lying over the texture where the JPEG blocks are. I swear, I can't unsee it anymore :)
![[ua]](/mwf/flags/ua.png "Ukraine")
Dirt looks much like a cave backgroundIf you look at the bottom-left corner (without looking at anythinbg else) you will most likely start to think that brown color is actualy the background
I never really approved of Ringwauls idea to introduce different brightness levels for earth. The idea that scenario designers will surely place them in a way that makes sense is illusive (when not even we ourselves place them right).
>(when not even we ourselves place them right).
I do! :)
Though I see your point now. I guess something more sensible would be to allow materials to change colour based on depth. Would look really cool for deep lakes which get dark at the bottom. Of course this sounds like a lot of work for not a lot of pay-off. And could look really weird. :/
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
