It's not supposed to be on the player. It's a property on the scenario only.
There is no way to decide to start a scenario based on data that doesn't yet exist. By the time it's attempting to roll a bound scenario, it's too late to change those properties on the scenario.
See how all the other content unloads or changes based on a player.
There might be one that set it to false that a writer messed up on in some testing content. Yeah, it doesn't do anything as those are all properties used in binding to a tile once and nothing else unless they're rebound.
Yeah that's what I thought, and I have yet to find any examples to the contrary. I think I just got confused by the default scenario as it has one function setting explorable to false next to another unrelated function (for random number generation only) that's affecting the player, and saw a connection where there wasn't one and shouldn't have been one.
TLDR: all fixed and understood now. As said I have changed the wilderness_bubbles scenario so that when it loads for the player (objectInstancedToPlayer) it checks for genitals (hasPenis || hasVagina) and, if no genitals found, immediately ends the scenario, as you previously described.
I am just going through final proof reading now. Before I could say with confidence that this was a finished, release-ready scenario, I would need to do a thorough runtime debugging of it, in order to make sure all the logic, in-text if-statements and in-text randomization all works and flows as expected (it would be hubris to assume that I hadn't made a single type or mistake that running the scenario wouldn't immediately reveal). But, to my knowledge it is not possible for me to do this - as far as I can tell I do not have access to run a specific tryout scenario in engine. So instead proofreading repeatedly, and when I've gotten it as stable as I can make it without runtime testing, I'll declare it a finished submission, probably later today.
Have proof read it until I can't stand the sight of it (the universal measure of when something is finished), and am ready to call it a finished submission. The scenario is saved as wilderness-bubbles and is 3 sets 33 scenes long, though how much of this will actually be experienced in a single playthrough depends largely on the player. It's really meant to be two scenario's in one, with the kind of sex scene experienced dependent on the player's dialogue options at the start, and the length of the scene based on the player's choices and... stubbornness. :P
TLDR: wilderness-bubbles submission is now finished and ready for your perusal. Enjoy. :P
Comments
There is no way to decide to start a scenario based on data that doesn't yet exist. By the time it's attempting to roll a bound scenario, it's too late to change those properties on the scenario.
See how all the other content unloads or changes based on a player.
There might be one that set it to false that a writer messed up on in some testing content. Yeah, it doesn't do anything as those are all properties used in binding to a tile once and nothing else unless they're rebound.
I am just going through final proof reading now. Before I could say with confidence that this was a finished, release-ready scenario, I would need to do a thorough runtime debugging of it, in order to make sure all the logic, in-text if-statements and in-text randomization all works and flows as expected (it would be hubris to assume that I hadn't made a single type or mistake that running the scenario wouldn't immediately reveal). But, to my knowledge it is not possible for me to do this - as far as I can tell I do not have access to run a specific tryout scenario in engine. So instead proofreading repeatedly, and when I've gotten it as stable as I can make it without runtime testing, I'll declare it a finished submission, probably later today.
TLDR: wilderness-bubbles submission is now finished and ready for your perusal. Enjoy. :P