Inverted Synchronization - opening one door closes another door #1

New Issue

2020-12-17T15:44:00+01:00

brunocalado commented

2020-12-17 15:44:00 +01:00

(Migrated from github.com)

Hi. You did a great module.

Is it possible to make a sync door open another at the same time it close another one?

This could allow the creation of amazing puzzles.

Hi. You did a great module. Is it possible to make a sync door open another at the same time it close another one? This could allow the creation of amazing puzzles. ![image](https://user-images.githubusercontent.com/4999783/102502114-fe25ef80-405c-11eb-8488-266d3acee857.png)

manuelVo commented

2020-12-17 23:56:40 +01:00

(Migrated from github.com)

Thanks for the nice words. I'm glad you enjoy the module.

Unfortunately syncing doors in a way that closes one when another one is opened isn't currently possible. I've been thinking about implementing this feature, however I'm not sure about what to do about locked doors.

I see three ways to handle this:

Give synchronized doors the ability to open other doors even though they are locked.
Prevent a door from being opened/closed when another door in the synchronization group is locked
Disallow locking of doors with inverted synchronization

I must say I'm not very fond of either of these possibilities, since all of these lead to a result that might break someones use case.

Any ideas or suggestions for how to solve this problem are greatly appreciated.

Thanks for the nice words. I'm glad you enjoy the module. Unfortunately syncing doors in a way that closes one when another one is opened isn't currently possible. I've been thinking about implementing this feature, however I'm not sure about what to do about locked doors. I see three ways to handle this: - Give synchronized doors the ability to open other doors even though they are locked. - Prevent a door from being opened/closed when another door in the synchronization group is locked - Disallow locking of doors with inverted synchronization I must say I'm not very fond of either of these possibilities, since all of these lead to a result that might break someones use case. Any ideas or suggestions for how to solve this problem are greatly appreciated.

SpartanCPA commented

2020-12-19 05:28:22 +01:00

(Migrated from github.com)

Also interested in this functionality.

brunocalado commented

2020-12-19 17:43:52 +01:00

(Migrated from github.com)

Thanks for the nice words. I'm glad you enjoy the module.

Unfortunately syncing doors in a way that closes one when another one is opened isn't currently possible. I've been thinking about implementing this feature, however I'm not sure about what to do about locked doors.

I see three ways to handle this:

Give synchronized doors the ability to open other doors even though they are locked.

Prevent a door from being opened/closed when another door in the synchronization group is locked

Disallow locking of doors with inverted synchronization

I must say I'm not very fond of either of these possibilities, since all of these lead to a result that might break someones use case.

Any ideas or suggestions for how to solve this problem are greatly appreciated.

I maybe wrong, but I can offer an idea.

Create a second field on the wall config. You can set a second group. This will work like the first one.

Example. All doors closed.
Door A has Group 1
Door B has Group 1, Group 2
Door C has Group 2

Player opens door A.
Door B opens.

Player closes Door B.
Door A closes. Door C opens.

Player opens Door B.
Door A opens. Door C closes.

Player closes Door A.
Door B closes.

> Thanks for the nice words. I'm glad you enjoy the module. > > Unfortunately syncing doors in a way that closes one when another one is opened isn't currently possible. I've been thinking about implementing this feature, however I'm not sure about what to do about locked doors. > > I see three ways to handle this: > > * Give synchronized doors the ability to open other doors even though they are locked. > * Prevent a door from being opened/closed when another door in the synchronization group is locked > * Disallow locking of doors with inverted synchronization > > I must say I'm not very fond of either of these possibilities, since all of these lead to a result that might break someones use case. > > Any ideas or suggestions for how to solve this problem are greatly appreciated. I maybe wrong, but I can offer an idea. Create a second field on the wall config. You can set a second group. This will work like the first one. Example. All doors closed. Door A has Group 1 Door B has Group 1, Group 2 Door C has Group 2 Player opens door A. Door B opens. Player closes Door B. Door A closes. Door C opens. Player opens Door B. Door A opens. Door C closes. Player closes Door A. Door B closes.

rinnocenti commented

2021-01-05 20:52:50 +01:00

(Migrated from github.com)

a better solution be a toggle instead of setting true or false.
setter a opposite of actual state of door.. ( door = !door instead door=true)
then the command always orders the opposite situation.
if it is closed it is open.
if in a group, those that are closed will open and those that are open will close.

a better solution be a toggle instead of setting true or false. setter a opposite of actual state of door.. ( door = !door instead door=true) then the command always orders the opposite situation. if it is closed it is open. if in a group, those that are closed will open and those that are open will close.

arbron commented

2021-01-17 21:09:39 +01:00

(Migrated from github.com)

Another possibility for locked doors in groups is if you toggle the group, all the doors but the locked one will change, and then if that door is ever unlocked it will automatically change to its proper opened/closed state.

For example:
A (open, unlocked), B (closed, unlocked), C (closed, locked)
Toggle A
A (closed, unlocked), B (open, unlocked), C (closed, locked)
Unlock C
A (closed, unlocked), B (open, unlocked), C (open, unlocked)

So doors will always stay synchronized unless they are locked closed in which case they will stay there until unlocked no matter what the rest of the group does.

Another possibility for locked doors in groups is if you toggle the group, all the doors but the locked one will change, and then if that door is ever unlocked it will automatically change to its proper opened/closed state. For example: A (open, unlocked), B (closed, unlocked), C (closed, locked) Toggle A A (closed, unlocked), B (open, unlocked), C (closed, locked) Unlock C A (closed, unlocked), B (open, unlocked), C (open, unlocked) So doors will always stay synchronized unless they are locked closed in which case they will stay there until unlocked no matter what the rest of the group does.

dutchcolonial commented

2021-09-23 17:30:58 +02:00

(Migrated from github.com)

I think a toggle work great (and yes I would be greatly interested in this functionality).
Next to the Group, have a "invert" toggle. All doors that don't have thist toggle set will open an close in synch. Any door that has invert set will do the opposite.
I currently have a map with a corridore with 2 doors (one at each end). One door opens, the other closes. This would be the perfect solution for me.
Of course if you want to go really complex, you could allow doors to be part of multiple groups (maybe a character separated list in the group box). Then, in combination with the invert toggle, these groups or doors can affect each other in complex ways :-)

I think a toggle work great (and yes I would be greatly interested in this functionality). Next to the Group, have a "invert" toggle. All doors that don't have thist toggle set will open an close in synch. Any door that has invert set will do the opposite. I currently have a map with a corridore with 2 doors (one at each end). One door opens, the other closes. This would be the perfect solution for me. Of course if you want to go really complex, you could allow doors to be part of multiple groups (maybe a character separated list in the group box). Then, in combination with the invert toggle, these groups or doors can affect each other in complex ways :-)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: manuel/foundryvtt-smart-doors#1