if the pirate catcher becomes active just after I have queued up pirates all pirates in the queue should get the perk applied instantly and the time shorten instantly. I should not have to cancel all my pirates (at 50% refund) then requeue them just to get the perk. This goes the same with the observatory. When the observatory perk is active any active journey should instantly get applied the perk and the journey should be shortened, I should not have to cancel my journey and restart it just to get the perk applied. This goes both ways of course if the perk should expire all queued pirates or partial trips should lose their perk benefit until the perk become active again... it just makes more sense this way.
Might make more sense - but far easier to program (and less processing required) single check for perk availability at start of recruitment/voyage than having to keep checking availability.
Programmng just needs to be as soon as the perk is active/inactive it triggers an event to reevaluate pirate queue times/exploration times based on the perk state. if written properly one function can be written for the same event trigger and really is not all that complicated.
its kind of complicated if you're say 10 seconds into recruiting a 20 second troop, and then pc kicks in and halves the time - do you shave 10 seconds off the new max time, or convert it to a ratio and reevaluate progress against percentage complete? There's a middle ground where it could re-evaluate time at the start of each pirate trained, so that if it applies halfway thru training a gunner, when that sole gunner finishes, the rest of the troops get the pc applied to them. With Observatory, it could do the same thing and recalculate trip time on all tiles except the current tile. I do feel like this should be done, but I can see a lot of potential bugs arising because of it. Say you go to gem to speed up your army right as pc expires. You could run into a condition where you clicked the button right as it finished and you spend an extra 50% gems you weren't planning to.
One thing computers are good at is math and following instructions. Pick an option and I guarantee it will do the same thing each time. Your making it a lot more complicated than it needs to be. Perks trigger function to instantly reevaluate times upon activation/deactivation applied to all scenarios whether there is 10s left or 1h. In the case of gemming protection probably is already in place to lock in the gem amount regardless of new changes on the confirmation screen. The user won't know the difference and regardless agreed to pay the gem amount so there is no harm done.
