Unit test 3 still fails, because the functions are not runtime overloadable. Test 12 fails, because liquid transfer does not work correctly yet. This fill be fixed in the next checkin.
Added debug logging, this has to be removed again later.
Unfortunately, now the object is not actually transferred, but removed, and a new one is created or an existing one is filled in the liquid container. The logic could use a rework actually, because everything was more clear when the container stored things in variables.
The liquid container now stores liquid objects, instead of volume and liquid type. Liquid objects can have be of a specific type, such as Liquid_Water, Liquid_Oil, etc..., but they can also just stay Library_Liquid for other liquids.
The liquid container logic has become more complex now, but still works as before. Transferring liquids to other objects may still need some improvements:
- at the moment, transferring liquids between liquid containers is possible
- maybe liquids objects, such as oil, can enter a liquid container while another liquid is in that container already - will need a unit test for that
- transferring liquid from a liquid container to a structure or crew member should be possible (but is not yet), if the target is not a liquid container but contains liquid containers
The steam engine can burn oil as fuel now. Added test to power system unit test. Still needs support for actually getting oil into the engine.
Fixed a bug in LiquidContainer that would return no liquid if the entire contents are removed. Added unit test for said bug.
Fixed overspilling of connected liquid containers. Pump no longer counts as a liquid container/tank, so that it still spills liquid if no drain is connected.
The steam engine does not remove the barrels, it just empties them. Made power system unit test 19 end if both pumps are pumping, this seems to be the intention of the unit test. Added power system unit test 20: Steam engine fueled by oil barrels.
Now it is possible to connect lines from a pump to the steam engine. This is achieved by the steam engine being a liquid tank. It did not seem good to allow connection from pumps to all liquid containers (i.e. barrels). A liquid tank is also a liquid container, they share the same interface, but it is also a structure.
It is not yet possible to fill the steam engine with any liquid though, because it is not defined what kind of liquid it accepts. This will be oil in the future. Furthermore, the behaviour when the pump adds incompatible liquid is not defined yet.
This messes up so many things as one could have expected. Instead we do the sensible thing and enable it only in the test scenario. For future reference all sequences involving an elevator and NPC clonks are broken with this feature.
Scenario that tests SetGraphics() in various ways: Setting graphics of meshes/sprites to other objects, overlaying objects onto other objects.
The scenario is not in the Issues.ocf folder, because it addresses multiple issues #1458 and #1538 and the status of the issues has not been acknowledged yet.
The default squid is still friendly (with a new texture now). Setting friendly=false during Place()ment creates red, angry squids.
Being in an ink blot drains a Clonk's breath faster now (because of the panic and increased heart-rate of course).
The friendly squid texture was created by Matthi as well.
The desync was caused by PropList->GetProperties returning the properties in an arbitrary order. They are now sorted first.
The debug logs are left in place, because I assume that I will need them again and they prove to be helpful.
The color of object lights can now be changed. This includes the following changes:
- added light test scenario, based on DarkCastle, with some lights,
- new functions SetLightColor() and GetLightColor() with C4Script documentation,
- third drawing pass for rendering the light color, the drawing passes are now referenced by enum,
- the blending of light from multiple colored light sources works correctly with alpha blending,
- light color value affects the intensity of the light,
- alpha blending of the light depends on color value and lightness. This means that brighter (= more value) and lighter (= more whiteish) light will be preferred in blending over other lights,
- the object light color is rendered to the lower half of the fow light texture now,
- the shader accesses the brightness/direction information and color information correctly,
The patch was created from the following commits:
dab898a SetLightColor()
f57286e Color texture experiment
d0702f5 Dynamic color
fa14cdf Light test scenario
f99203d Alternate lights
474bade Bugfixes
3113698 Brightness handled better
516fb21 GetLightColor
1d91ec9 Improvements
3cfbf6c Documentation
95ec185 Improvements: Light Shader
a63bffc Scope of alpha
20c7ca0 Improvement: C4FoWLight
17d9123 Undo code style
d79411b Cleaner code
(cherry picked from commit 36dec610e36860b88417e91ce727250673bc2ec2)
Conflicts:
src/landscape/fow/C4FoWRegion.cpp, merged
This makes it easier for internal calculations and that value of 10 now represents a single light bulb. It is advisable to only use multiples of 10 for production and consumption values.
Renamed CreateObject() to CreateObjectAbove() and replaced all occurrences in script files.
Added CreateObject(), the function may need a rewrite though, see comment in code.
Updated documentation
Appending and including skeletons works now. Documentation updated.
Skins such as appendto.Clonk.Farmer.skeleton are handled as if the skin name were not included: appendto.Clonk.skeleton
This also changes a bit the structure of how meshes are reloaded in general,
in particular mesh materials are only reloaded once and not once per
C4DefGraphics instance. (Fix crash on reload with included skeletons, cherry picked from commit 2f69aa4850ab7a4b621e5f30cbc537d40f32c0df)
Fix linking of C4Script standalone tool (cherry picked from commit b03a332b73463b378c94e4e92b66d45b923b3b9c)
All calls that reference an existing Gui window now start with "GuiUpdate" (exception: GuiClose). All other functions are always to be called DURING menu creation and layouting.
The "Margin" property replaces Gui_AddMargin.
find . -type f -name "*.c" -print0 | xargs -0 sed -i 's/CustomGuiOpen/GuiOpen/g'
find . -type f -name "*.c" -print0 | xargs -0 sed -i 's/CustomGuiClose/GuiClose/g'
find . -type f -name "*.c" -print0 | xargs -0 sed -i 's/CustomGuiSetTag/GuiUpdateTag/g'
find . -type f -name "*.c" -print0 | xargs -0 sed -i 's/CustomGuiUpdate/GuiUpdate/g'
find . -type f -name "*.c" -print0 | xargs -0 sed -i 's/Gui_AddCloseButton/GuiAddCloseButton/g'
find . -type f -name "*.c" -print0 | xargs -0 sed -i 's/Gui_UpdateText/GuiUpdateText/g'
find . -type f -name "*.c" -print0 | xargs -0 sed -i 's/Gui_AddSubwindow/GuiAddSubwindow/g'
The property can be used to give GUI windows a margin. Either the same margin in all directions (Margin = "1em") or different margins (Margin = ["1em", "2em", "10$", "0.5em"] - [left, top, right, bottom]).
Before you'd define the X coordinate of the top-left corner of a window with X = [500, -40], now you do Left = "50%-4em". The em values currently do not scale with font-size yet, but it is important to do the formal change as early as possible to not have to do all work twice. Scaling of font and thus menus can be implemented later.
This should reduce the confusion about why the function behaves so differently from Gui_Open: the style objects only provide an interface for those easy GUIs, they are not really part of the GUI system.
The honorable goal of the particle system should be that this scenario always runs fluently. Even though optimizing the drawing will not be possible after a certain point, the particle system should scale down the drawing automatically to allow for a fluent game.
Mark