Add a maximum padding setting to the DynamicRowContainer
This adds the concept of maximum padding in-between child elements to the DynamicRowContainer. By default the container tries to calculate a dynamic (x axis) padding so that the elements use all the available space. Under some circumstances, that can look more than a little awkward though:
This can be remedied with the new maximum padding, if set it will use the value as maximum distance in-between elements, everything below that threshold will still get calculated dynamically. In order to see the difference check out the same situation with the new setting:
– fix logic in pagination row calculation – fix pagination button logic – improve state hash calculation function on the status bar – replace the RowContainer instance used as the context container with the DynamicRowContainer
This finishes up the DynamicRowContainer for now. Some tweaks had to be made when determining the limits of how far the user gets to paginate/scroll and what state the scroll buttons need to be in accordingly. If the number of child element now exceeds what can fit in a row, the buttons are shown properly now:
Finally the container type was made to replace the existing “context container”, which is the internal name for the big area on the right in the UI next to the main UI elements on the left hand side which are always shown. In order to make this fully work some smaller changes also had to be made in the way that the container sets the sizes of its child elements and thus might implicitly change their dirty state. In other words: the elements might not update properly under some circumstances. See it in action in the shop mode:
– improve child positioning (still WiP for the reduced padding version) – add pagination buttons if necessary – preliminary pagination mechanics (not quite working) – add some default textures on the texture manager so that widgets can show certain basic textures without a need to have a texture manager instance
This adds the bulk of the mechanics for the pagination, this still requires some tweaks though. That means it will already show the pagination buttons if need be, otherwise it will use the full width to show the actual content. The other change made is that the TextureManager now always pre-loads some basic UI textures, amongst those the scroll up/down textures and also exposes these texture IDs publicly, so that they can be used from anywhere without having an instance of the TextureManager ready.
Add the skeleton and first bits of implementation for a semi-dynamic container widget
This introduces the beginning an partial implementation of the DynamicRowContainer. Unlike the regular RowContainer class this will support a dynamic (hence the name) number of elements and pagination. However, unlike the RowContainer (or ColumnContainer) it will only allow the child elements to have a specific size and ratio. The size is calculated based on the desired number of rows and the number of elements per row as well as an aspect ratio.
– Make more code generic in the job scripts – Implement the hygiene logic on the Python end – Add a new job: wash_hands – Handle object categories better in some cases – Handle containers with only one children more gracefully (improve padding calculation)
The theme here is the full implementation of the hygiene mechanics. The idea here is to slowly decrease the hygiene value (slower than hunger) and also let it negatively affect (once again, to a lesser degree) the overall health. In order to let the health recover both hunger and hygiene need to be above 0. That might be subject to change, let’s see what the future brings. 🙂 As often in these cases that means that some features are suddenly used in a way that has not happened before. This means that this commit also brought changes in the UI code (poor handling of padding calculation in containers with only one child element) as well as in the object selection code, which did not handle object types that have more than one category very well. As already mentioned, the mechanic is complete for now, but is still missing a slightly improved model for the sink as well as a hand washing animation, so the next commit which will bring these asset updates will get a nice flashy screenshot or video. 🙂
Hi! Just a small heads-up: everything that was written up to this point was written after the commits were made. The process of working through the backlog started around the beginning of September 2019, which means that as further back in time we go, the more the commentary might be off. Some messages might seem a bit rushed, the grammar might be off or I might have mentioned a feature that was only implemented later, sometimes much later. Please bear with me here. 🙂 The good news is that this should improve from here on, as the plan is to write this commentary around the same time the actual commits are happening. Thank you!
Simplify the human object script code and fix the hunger/health mechanics (hygiene WiP)
This removes quite a bit of redundant (Python) code and makes it more re-usable, something that will be required as soon as more game play stats need to be manipulated. It simplifies the code in a few places that did essentially the same thing, ever so slightly differently: