There seems to possibly be an internal issue with the slider (and more generally, the
scrollbar implementation form which it inherits) where is min/maximum_positioner_length
equal an even number, sliders with an even number of options will reach max value.
Setting it to what, in this case is 1 below the actual width of the slider image (15)
means both even and odd-numbered sliders will reach max value, however the edge is cut off.
Attempting to set the right_offset to 1 and using the above off value for the positioned
width means only sliders with an odd number of options reach max value.
The magic numbers in this commit seem to give the widget enough space to reach the end of
the slider and max values regardless of the number of options, but the internal widget dimension
calculation should perhaps be investigated in the future.
This fixes a crash that would be caused by memory incorrectly being freed
when removed from a list. Relying on splice stops that from happening.
This also fixes an exit condition when deleting handlers as depth could
sometimes not be decremented.
Finally, checks are made to made sure that an sdl_handler is either
exclusively in the global context or a different context, ensuring
that they cannot be in both.
This caused an error message and recruiting to be abandoned when the
recruit rushers Micro AI was used for two different sides in the same
scenario. It was only presents since the AI refactoring done during
1.13.4+dev and did not affect any release.
The destructor of the context class accidentally incremented the iterator
twice per iteration. If the number of event handlers was odd, the
destructor ended up incrementing the end iterator, which is UB.
I rewrote the whole destructor. It's unnecessary to manually remove event
handlers from the list because the list will do it automatically when it's
destroyed.
This changes the behaviour of victory event so that they are now also fored when there is at least one human that is victorious, for sp and for coop mp scenarios the conditions when victory is fired is the same as before, in non-coop mp games the victory event will now also be fired whenever there is any human side that wins, since such scenarios usually don't use victory events this is not tha much of an issue. For those cases i added the 'local_victory' event (maybe if people want to print congratulation messages in their mp maps or similar)
The reason for this change is that now, since victory events fire on all client the same ,way we can mark them as synced, this specially fixes issues with invalid unit ids of units created suring victory events in sp.
