What happens is that mape first loads the TexMap.txt, however adding all the
texmap entries internally fails, because the materials and textures are not
yet loaded. However, mape must first load the TexMap to see if
OverloadMaterials or OverloadTextures are present in it, to know what
materials/textures to actually load.
For whatever reason, the shader code that was passed to the compiler was
different from the code that got written to the shader log. This is a
huge pain in the ass when trying to debug shader errors because the line
information is completely wrong. I assume this decision was a premature
optimization, so I've removed it and we'll now log the exact same code
as the shader compiler sees.
This should simplify insertion of new textures at arbitrary drawing orders without reassigning palette indices (the latter would invalidate all old maps).
This caused some sounds to not play at all when the object was inaudible at the position the sound was initially launched, but then moved into view (e.g. elevator cases or the planes in The Raid).
Sound() called when the instance is already running used to fail. Now, it always succeeds (also for script sync safety) but updates the sound level and pitch parameters. SoundAt has not been modified since it allows creation of multiple concurrent sound instance of the same effect without object context.
The new behaviour that allows 255 mat-tex combinations (once we increased
C4M_MaxTexCount...) is enabled with MapFg.bmp, and then MapBg.bmp can be
used to draw IFT or other fancy things.
The background landscape is a 8-bit landscape which stores the material
that a particular pixel will be replaced with when it is cleared, e.g.
by digging or blasting.
This is just the groundwork for this and does not offer much advantage
over the IFT flag that was used previously for that purpose. However,
additional features such as keeping the background material/texture
fixed when loam bridges are built, PXS are incorporated into the landscape
or the massmover is moving things around can be added.
See http://bugs.openclonk.org/view.php?id=1338 for more details.
The old implementation was buggy as it would disallow the location if it had too much space (and PathFree2 returns nil). It also doesn't make sense to ask for a location that has space in either direction of a dimension because the location is not automatically adjusted to lie at the center of that space. For example, it would effectively cause fish to spawn directly at walls sometimes.
Maikel de Vries