Sell multiple packages based on the same room

[Epicea_old]

Can you tell me what the settings are that cause the problem?
I will test and correct them at the system level so everyone does not need to check every room.

Yes the "Availability Requires" field was populated even though the room was built without any dependancy. You'll probably struggle to distinguish that from where it's supposed to have a value but, you might try the case where one "Availability Requires" is populated, the gate is AND and the second "Availability Requires" isn't populated, that also describes what I saw but on a couple of rooms it's hard to generalise.

[amberbb]

Can you tell me what the settings are that cause the problem?
I will test and correct them at the system level so everyone does not need to check every room.

We had some rooms that "acquired" some dependencies that we had not set.

However, your help text of
"An error has occured: room dependancies cannot be calculated. This can occur if two or more rooms are dependent on another in a circular manner. Please check the room advanced settings."
was very explanatory and after we had found and corrected a few introduced anomalies, everything was quickly back to normal.

PS: New Zealand English spelling would be
An error has occurred: room dependencies cannot be calculated. This can occur if two or more rooms are dependent on another in a circular manner. Please check the room advanced settings."

[markkinchin]

I have checked both the amberbb and Epicea setups before and after the change and both had various forms of circular room dependencies before the change.
For example room A is only available if room B is available and Room B is only available if Room A is available.

The recent logic changes included making the dependency logic recursive so dependent rooms of dependent rooms affect dependent rooms etc.
Previously this was not the case and only the first dependent room itself was checked for availability and could have been flagged as available even if it was not because it had a dependency on another room that was not available.
I believe this is the change that has caused the changed logic calculation in both cases.

Previously the logic was not working properly in these recursive cases and now that it is working in a more rigorous (and in my opinion better) manner it has upset your settings that were working as you wanted.
I can see the fix in both cases has been to remove the circular room dependencies.

p.s. circular dependencies can still be used and if so the logic should block all of them if any of them are unavailable.

[Epicea_old]

I have checked both the amberbb and Epicea setups before and after the change and both had various forms of circular room dependencies before the change.
For example room A is only available if room B is available and Room B is only available if Room A is available.

sorry Mark but that just can't be. We have only ever had one room that's dependent on another. And that was working just fine, this week and last week.

[markkinchin]

The recent logic changes included making the dependency logic recursive so dependent rooms of dependent rooms affect dependent rooms etc.
Previously this was not the case and only the first dependent room itself was checked for availability and could have been flagged as available even if it was not because it had a dependency on another room that was not available.
I believe this is the change that has caused the changed logic calculation in both cases.

I really do believe what happened the other day is that when I updated the logic certain settings that previously caused no harm and did nothing started having an effect.
The settings may have been there since the initial setup or introduced at some stage and never noticed or cared about because the logic still worked as wanted - until I updated the algorithm the other day.
Anyway the main thing is that it is now working properly and I am sorry for the inconvenience.