OS: Windows 10
Version: 0.0.7
Commit/Build: f0b8a51
Steps to reproduce:
You see that the energy, hunger, thirst, nausea and bathroom of the persons in the rides stay the same/freeze as soon as they get stuck or the ride goes on forever because the ride has broken down. The thoughts of the people on these rides are not affected by this bug.
Happiness shows a really strange behavior: whether the person gets stuck on a ride or has to ride it forever (over and over again because the ride doesn't get fixed) the happiness goes down a bit (as it should do), but after a while it goes up again and gets the same happiness-level as before his happiness went down. After that it goes again down, up, down, up etc.
My theory of what happens: happiness goes down because they are stuck on the ride. Then it goes up again, because they think they are normally riding the ride (what normally should increase their happiness of course.)
The following behavior should be observed instead:
-Energy: should go down very slowly.
-Hunger: should go up slowly.
-Thirst: should go up slowly.
-Nausea: should go up slowly when the person keeps riding the ride forever. Should also increase when the person gets stuck on a ride in the air or on a slope.
-Bathroom: Should go up slowly too (your bladder doesn't stop because a ride broke down :) )
-Happiness: happiness should go down rapidly and people should get angry when they get stuck on a ride or have to ride it forever.
On energy, I think that instead of going down very slowly, if the side is a sit down ride, it should go up slowly (because all the peep is doing is sitting). Also, a general question not related to the above issue: on sit down rides like theaters, do peeps gain energy from riding them, because they get to sit down?
It seems that guests in a queue are also affected - their happiness will drop to around 50%, but then it just hovers around that level, while none of their other meters deteriorate.
I just solved the happiness issue (hopefully).
We have a variable called happiness_growth_rate, which is sort-of the target value for happiness. It's specified as an 8-bit unsigned integer, meaning its valid values range from 0 up to 255 (inclusive).
When subtracting from unsigned integers, you want to avoid them going under zero. Doing so means strange behaviour.
There was code to prevent that:
peep->happiness_growth_rate = min(0, peep->happiness_growth_rate - 5);
This means: set happiness_growth_rate to 0 or its current value minus 5, whichever is _lower_. If that sounds wrong, that's because it is. It should have been
peep->happiness_growth_rate = max(0, peep->happiness_growth_rate - 5);
which means set happiness_growth_rate to 0 or its current value minus 5, whichever is _higher_. That ensures it will never go below 0, while the old code almost always ensured it _did_ go below.
@Gymnasiast Sorry, haven't looked at this issue for months, but I can confirm that the happiness part of this issue report is fully fixed: happiness now just goes down for people on broken rides and don't go up again suddently.