When switching dialogs in editor mode, the (paint) tools dialog wouldn't
be properly cleared, instead only destroying the dialog window. Thus,
the next time it would be used, it'd try painting onto a device context
which did no longer correspond to any existing window, which made OpenGL
sad.
It would be set by state and then immediately reset in Default(). This had the effect that if you used the color picker on sky before ever selecting a background material, the wrong background would be used.
A texture array is conceptionally what should be used in this case. One
advantage of this is that we don't have to generate mipmaps ourselves but can
let the graphics driver take care of it. Same for selection of the mipmap
level. This would even allow to choose different mipmap levels for different
textures.
This is a somewhat experimental change since it makes OpenGL 3.0 a hard
requirement for OpenClonk. I expect that this is fine, but if this causes
failures during landscape creation on common hardware/drivers we should
revisit.
RejectCollect is not called on CreateContents or other forced entry methods but should still cause the lantern to attach. So move any side-effects to Collection2 instead of direct RejectCollect.
The lantern dummy had Timer=1 and wasn't doing anything. Use a simple overlay instead.
Note that interaction menus still show the lantern always with off-material. But that's a bug in the interaction menu.
The clonk opening the menu should always have higher priority so the clonk is predictably selected on the left side even if standing behind e.g. a crate.
Other clonks should be behind because interaction with them is rare but having your fellow players stand in front of a building is very common. Allies also tend to run in front just when you opened that menu.
I am still not 100% sure in which situation this occurs (see also old comment in line 168). I suspect it happens when an object is removed from the menu and the object check timer ticks just before the inventory timer.
It is possible that this should rather be resolved by removing the inventory check effects when the right conditions are met (aka the menu is removed). IF that is even the cause. Right now I don't think the current situation is too bad, because the check is very lightweight and superflous content check effects will be removed when a new menu is opened on either side anyway.
It was always either used in conjunction or forgotten. If someone wants invincibility while still allowing fire (e.g. an unkillable fire golem), there's now a parameter to allow it.
Clonkonaut