kieranmillar
Level: Smitemaster
Rank Points: 2670
Registered: 07-11-2014
IP: Logged

Not sure if this is a bug we actually want to care about, given that I imagine it would be a total nightmare to programme a workable solution for and is easily avoided by just not doing it.

If you have two separate doors with a connection to the same orb/PP, and combine them together via building more doors, then the resultant door will be connected to the orb/PP twice, and will attempt to execute both connections onto the same door.

If you then split the doors up again by building empty space/water etc. over the door, creating brand new doors, the resultant doors appear to "inherit" the connections, making brand new connections, but if you have a "multi-connection" door being split up, which connection do the new doors inherit? The answer appears to be "only the connection that was set up first in the editor".

Do we actually want to bother coming up with some sort of logical process for choosing what happens to door connections when combining or splitting doors, or do we just want to avoid legitimising this sort of nonsense?

---

[Last edited by kieranmillar at 11-06-2015 10:40 PM]

Dragon Fogel
Level: Smitemaster
Rank Points: 2434
Registered: 06-21-2014
IP: Logged

I think it would be best to have a rule, but one that the player can actually know (so not "whichever was first in the editor").

I suggest "whichever door was initially further north, and if there's a tie that way, whichever door was initially further west." This is consistent with some other tiebreaking behaviors (like which tile of briar matures next).

kieranmillar
Level: Smitemaster
Rank Points: 2670
Registered: 07-11-2014
IP: Logged

Perhaps the most sensible solution, if we care, is to avoid allowing a door to have multiple connections by checking for, and then destroying, one of the connections when two doors are combined, like how the editor does it, probably using the tie-breaker method suggested by Fogel?

There's never any door splitting weirdness if you can never get a multi-connected door.

Also worth mentioning, you can currently build open and closed doors next to each other via build commands, in which case they are both treated as one connected door and the whole thing "fixes" itself into a consistently open or closed single door the next time you trigger the orb/pressure plate, but really this process should happen during build time (i.e. if you build an open door tile adjacent to a closed door, it should build a closed door tile instead).

Nuntar
Level: Smitemaster

Rank Points: 4590
Registered: 02-20-2007
IP: Logged

So we just had a lengthy discussion in chat of the pros and cons of Dragon Fogel's suggestion versus mine, which is that when two doors merge, their connections are combined: any orb/PP that affected one of the doors will affect the combined door in the same way. If an orb/PP affected both in the same way (or all; it's possible for up to four doors to be merged) then it will continue to affect the combined door in the same way. If an orb/PP affected at least two doors in different ways, we have some system for which connection types override which. (I don't feel particularly strongly about which way round this should go, but my suggestion is that toggles override other types, and that merging an open and a close also produces a toggle.)

Splitting a door after merging it would then leave all parts with the same connections as the combined door had.

I feel this is the most "natural" way to handle the issue, and would be the easiest for new players to grasp (the tie-breaking rules less so, but those are unlikely to come up very much; it's just that with this system it's necessary to have some such rules in place). For the record, Dragon Fogel doesn't agree.

Also worth mentioning, you can currently build open and closed doors next to each other via build commands, in which case they are both treated as one connected door and the whole thing "fixes" itself into a consistently open or closed single door the next time you trigger the orb/pressure plate, but really this process should happen during build time (i.e. if you build an open door tile adjacent to a closed door, it should build a closed door tile instead).

I'd prefer building an open door tile adjacent to a closed door to open the door. That's partly influenced by what happens in the editor, but it also seems more natural.

____________________________
50th Skywatcher

skell
Level: Legendary Smitemaster

Rank Points: 3734
Registered: 12-28-2004
IP: Logged

What would be the use case for this functionality? The data structures that orb connections is these three pieces of data per connection:

* Orb position (for now let's disregard plates but they use the same data structure)
* Target tile - it causes a flooding effect from that position
* Action - open/close/toggle

As such there is really no good way to handle edge cases when combining doors. If you have one orb close one door and open another, if you connect the two whatever happens depends on the order in which the connections were defined. We could then arbitrarily decide some rules but I guarantee whatever rules we come up with will be difficult to understand for the players. I think it makes much more sense to handle it case-by-case - that is give DROD Script the ability to affect the connections. But we still need to decide what happens if you do it, and I think one of the two options is the best:

1. Lose all door connections
2. A simple ruleset where one type wins over another type. Maybe Toggle > Open > Close, so anytime a merge happens, Toggle is the most important action to remain.

Other than that:

3. Splitting doors causes them to keep their connection
4. Add commands for adding/removing door connections.

I'd prefer building an open door tile adjacent to a closed door to open the door. That's partly influenced by what happens in the editor, but it also seems more natural.

I think DROD Touch shows that there is a merit to keeping the current behavior, because it can be used in unDROD-like ways. I don't think changing this would affect that hold in any way, I made sure to never have two yellow gates next to each other, but I do like the visual effect created in this situation. No strong feelings either way. One more thing I'd add:

5. A command to open, close or toggle yellow door at a given position.

____________________________
My website | Facebook | Twitter

Dragon Fogel
Level: Smitemaster
Rank Points: 2434
Registered: 06-21-2014
IP: Logged

I honestly think that "make one door's connections completely override the other" is going to be easier to understand than "the door connections combine based on what they actually are". There's just less to think about.

I'm fine with scripting to allow for customizing the connections, but it's probably simplest for the default behavior to be an override.

Xindaris
Level: Smitemaster

Rank Points: 1531
Registered: 06-13-2015
IP: Logged

I am 100% behind getting script commands to alter orb/pp-door connections, and/or to open/close yellow doors. I think I might even have a FR somewhere about that, but my memory on that is fuzzy.

____________________________
109th Skywatcher

Here are some links to Things!

skell
Level: Legendary Smitemaster

Rank Points: 3734
Registered: 12-28-2004
IP: Logged

Dragon Fogel wrote:
I honestly think that "make one door's connections completely override the other" is going to be easier to understand than "the door connections combine based on what they actually are". There's just less to think about.

How would we determine which door overrides which? The one that has the most Northern tile, tie broken by most Western tile? That is, smallest Y coordinate wins, in case of a tie smallest X coordinate in that row wins. Kinda like left-to-right reading, the position of the first letter on the page.

____________________________
My website | Facebook | Twitter

Dragon Fogel
Level: Smitemaster
Rank Points: 2434
Registered: 06-21-2014
IP: Logged

Yeah, I think position-based tiebreaking is best in this case.

Xindaris
Level: Smitemaster

Rank Points: 1531
Registered: 06-13-2015
IP: Logged

I dunno, the grand majority of DROD design seems intended to be kind of position-independent, with exceptions like move order and the way briar works tending to make things less intuitive as a result. But since it's a scripting edge case, I don't have a strong preference as the person scripting whatever widget is in use can probably make things work however they like.

____________________________
109th Skywatcher

Here are some links to Things!

Nuntar
Level: Smitemaster

Rank Points: 4590
Registered: 02-20-2007
IP: Logged

I'll reiterate why I feel differently: with door merging as I suggested, the state can never go from "orb X affects door Y" to "orb X and door Y both still exist, but X does not affect Y".

Nor do I see how "there's less to think about" if you have to remember a system of position-based overriding.

(Of course, I expect that door combining and splitting will almost never come up, and probably is one of those things that just shouldn't be used in puzzles. I would still like it to have a nice, simple, consistent rule for in case it does arise accidentally in a puzzle where it isn't the main focus.)

____________________________
50th Skywatcher

---

[Last edited by Nuntar at 10-15-2020 10:06 PM]

skell
Level: Legendary Smitemaster

Rank Points: 3734
Registered: 12-28-2004
IP: Logged

Nuntar wrote:
Nor do I see how "there's less to think about" if you have to remember a system of position-based overriding.

I was referring to various ideas that were thrown around back when this was discussed in the chat that had some complex rules. My personal favorite is to just remove any connections and let the architect worry, it's going to be an extremely niche functionality anyway. But if I were to chose I'd prefer either your rules (Open+Close -> Toggle, Toggle trumps rest) or mine (Toggle trumps Open trumps Close) since they feel easier to reason about.

I am not a big fan of the solution proposed by Dragon Fogel either, because with weirdly shaped doors it feels like it'd be easy to misread the room.

(side note, briar's tie breaking is flipped, given equal distance from the root it matures westward tiles, tie breaking by ones that are further to the north)

____________________________
My website | Facebook | Twitter

hyperme
Level: Smitemaster

Rank Points: 1062
Registered: 06-23-2006
IP: Logged

Position-based tiebreaking seems like a bad idea to me. Since doors can have arbitary shapes, you need some way of determining what the "position" of a door even is, which is adding complexity for not much gain. Even if you're basing it on something fairly simple like the minimum bounding box, it's still not something I think is easy to reason about.

____________________________
[Insert witty comment here]
Qzvlkx?

Dragon Fogel
Level: Smitemaster
Rank Points: 2434
Registered: 06-21-2014
IP: Logged

Nuntar wrote:
Nor do I see how "there's less to think about" if you have to remember a system of position-based overriding.

There is less to think about because you don't need to put any consideration into how the potentially conflicting orb/door commands will interact. All you need to know is "the new combined door will just be the same as this door which already exists".

Under this concept, "Door Y" does not still exist, it becomes "Door Z", which also still exists. I do not see added value in preventing Orb X from being orphaned.

I'm certainly not suggesting that the priority would be intuitive, but it's basically only one rule. If you combine the controls somehow, you need a rule for every potential conflict - and if three or more doors get combined on the same turn, it's going to be even more confusing.

Under a position-based override, though, if you combine a lot of doors at once, the "dominant" door is going to be the same regardless of what order the building happens in.

mrimer
Level: Legendary Smitemaster

Rank Points: 5056
Registered: 02-04-2003
IP: Logged

Wow, this is confusing. Appreciate all the input and suggestions. I agree the current behavior isn't completely intuitive, but it makes complete sense if you know the code. Terrible basis for a decision, I know. I'd vote for applying the smallest tweak possible to make things feel less arbitrary. This is my knee-jerk reaction:

Kieranmillar wrote: If you have two separate doors with a connection to the same orb/PP, and combine them together via building more doors, then the resultant door will be connected to the orb/PP twice, and will attempt to execute both connections onto the same door.

Not sure this needs to be changed; I don't consider it a bug, probably just not a great game experience. But it seems logical, and it's up to the architect to do this or not, right?

If you then split the doors up again by building empty space/water etc. over the door, creating brand new doors, the resultant doors appear to "inherit" the connections, making brand new connections...

It seems logical to me to keep both door components operating as before.

...but if you have a "multi-connection" door being split up, which connection do the new doors inherit? The answer appears to be "only the connection that was set up first in the editor".

This logic could of course be changed to inherit all current connections. Not sure that's the best choice, because it's not symmetrical with merging doors. This could be kept as-is, and we just say this is how this quirky thing works.

I don't like the idea of modifying the current logic to select based on a positionally-based door's association. So fiddly!

I really don't like the idea of melding connection behaviors together to do something different, like "open + close" --> "toggle". Yikes! This isn't a game feature, just an oddity of how scripted tile building operates. If we *really* want to go in that direction though, we should do it right. For instance:

Though this does seem to be a very niche case at present, there is also the possibility of adding a script command

Activation Link from <x,y> to <x,y> <type>

where type is {open, close, toggle, delete}

There'd be stuff to manage in the back-end (probably analogous to how the room editor controls the logic for managing these associations), but that could be the interface to clearly manage associations if we really want to alter doors, orbs, etc.

I understand this would blow wide open what could be done.

Am I jumping the shark with this suggestion?

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

---

[Last edited by mrimer at 10-15-2020 11:14 PM]

skell
Level: Legendary Smitemaster

Rank Points: 3734
Registered: 12-28-2004
IP: Logged

There was a very interesting conversation. Here are my notes from it:
* When you merge two doors in the editor, when the same orb/PP had connections to both of them, the older connection (as in created earlier) remains
* I finally managed to find again the name of law of triviality
* I take an executive decision to make it so that when two doors are merged their connections are completely removed. There's been a heated debate and that's the only solution that meets the requirements that different people had: depends on a single rule, is easy to remember, is reasonably possible for a new player to understand, has unimportant amount of puzzle potential because no sane person would use it without additional scripting anyway.

...

Well, I guess Mike popped up. The reason the way it works right now is mostly unacceptable is because whatever happens depends on information that's unavailable to the player. I don't think any solution we can implement in game code would be one that an architect wouldn't to override anyway, and thus I think the best option is to start with a clean slate - remove all connections if two doors are merged and let the architect use scripting to set it up the way they want.
I see it as a scripting problem and a scripting solution is, in my opinion, the best way to go. Alternatively - keep the behavior as-is (deterministic but no way to know the result upfront).

____________________________
My website | Facebook | Twitter

Dragon Fogel
Level: Smitemaster
Rank Points: 2434
Registered: 06-21-2014
IP: Logged

I believe the script command has already been suggested. The argument is largely on what the default behavior should be.

Anyhow, we were talking about this in chat and skell is leaning towards just nullifying it entirely. For the record, though, the point of the position-based method I suggested was to have similar behavior to what happens if you connect two doors in the editor: one of them overrides the other.

However, which one overrides in the editor seems to be based on when the door was placed or something similar, which is obviously a terrible idea to use in-game as there's no way for the player to know it. Position is really the only viable alternative for setting a preference in that case - whatever the problems with it, any other option for settling the preference would be clearly worse.

---

[Last edited by Dragon Fogel at 10-15-2020 11:18 PM]

mrimer
Level: Legendary Smitemaster

Rank Points: 5056
Registered: 02-04-2003
IP: Logged

Shows what I get for not reading everything.
My bad.

Edit: When I saw "DROD Script" in your above post, I was thinking "DROD Touch" for some reason. My fault.

skell wrote:
Well, I guess Mike popped up. The reason the way it works right now is mostly unacceptable is because whatever happens depends on information that's unavailable to the player. I don't think any solution we can implement in game code would be one that an architect wouldn't to override anyway, and thus I think the best option is to start with a clean slate - remove all connections if two doors are merged and let the architect use scripting to set it up the way they want.

Sorry, didn't mean to step on your toes. I'm completely fine with your proposal. Definitely the simplest option.

It also has basis in canon. Orbs and door sensors work by attuning them in precise ways according to their positioning and other physical characteristics. Altering the setup would cause orb attunements to cease functioning. Not going to try to fit pressure plates into my narrative.

I see it as a scripting problem and a scripting solution is, in my opinion, the best way to go.

Okay, seems like great minds think alike!

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

---

[Last edited by mrimer at 10-16-2020 12:07 AM]

TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged

mrimer wrote:

Kieranmillar wrote: If you have two separate doors with a connection to the same orb/PP, and combine them together via building more doors, then the resultant door will be connected to the orb/PP twice, and will attempt to execute both connections onto the same door.

Not sure this needs to be changed; I don't consider it a bug, probably just not a great game experience. But it seems logical, and it's up to the architect to do this or not, right?

Example might help.

Imagine a room with three doors. One orb is connected to all three doors, toggling them.

I connect two of the doors with a "Build Yellow Door" command. Hitting the orb now toggles the door twice (for no outward change). I connect this new door to another of the other doors. Hitting the orb now toggles the door three times.

Now let's back up. The orb now opens one of the doors, closes another, and toggles the last. I build doors to connect them all. Now, what happens when I hit the orb? The answer is: it depends. I think it goes in 'door connection order', which is the order that the various connections were made in the editor.

On top of all this, what happens when we click on the door or orb to see what it does? Well, the answer to that is that the colors end up mixing together to make some kind of cyan or purple or whatever, becoming more intense as more connections are layered.

===

Let's go back one final time. Instead of three doors, I create one big door with one orb that toggles it. I then use building commands to break this door into two: now I have an orb that toggles both doors. Then I combine them together... and I get an orb that toggles a single door twice. I can also repeat this as much as I want to get an orb that toggles this door 2^n times, and is colored a solid orange when I click on the orb.

===

Altogether, these are not great outcomes, and aren't very easy for an architect to work around, and aren't very easy for a player to understand.

Personally, I'd prefer a merge that at least preserves connections of the same type, so that if a door is broken and rebuilt, all the orb connections don't have to be linked up again. Whether that's a "connection position priority" or "connection type priority" doesn't really matter -- any complex interactions are for the architect to sort out, but simple interactions being automatically dealt with should give the architect less headaches.

But I'm usually in favor of more scripting tools anyways, and there's one that hasn't quite been mentioned yet, but is very important: we need to be able to break existing connections as well as create them. I'd imagine it'd be something like "Break door connection at (x,y) (flag)", where if (x,y) is an orb/plate it destroys all connections from that orb/plate, and if (x,y) is a door, it destroys all connections pointing to that square of the door, unless (flag) is set in which case it destroys all connections pointing to any square in the door's area.

Xindaris
Level: Smitemaster

Rank Points: 1531
Registered: 06-13-2015
IP: Logged

Actually...

Activation Link from <x,y> to <x,y> <type>

where type is {open, close, toggle, delete}

From mrimer's post, takes care of the need to delete connections, and even has the benefit of only removing one at a time. Though I could see it being convenient to delete all at once sometimes, I'd prefer this over delete all if we only get one of them.

My biggest stake in this is being able to rescript Wheels so they automagically connect themselves up for the architect.

____________________________
109th Skywatcher

Here are some links to Things!

---

[Last edited by Xindaris at 10-16-2020 03:24 AM]

skell
Level: Legendary Smitemaster

Rank Points: 3734
Registered: 12-28-2004
IP: Logged

Note: another reason I prefer clearing up all of the orb connections (or merging them) is because it's less computationally intensive to implement than the solution where NE door takes priority. For the latter I need to check every tile that's not door if that creates a new door connection and take action. For any kind of merging/clearing I can first draw doors and then fix the remaining space.

Also note: For 5.2 I want some kind of generic "Interact with Environment" command that could do stuff like "Toggle door" or "Open door" or "Close door" and it could have an option "Clear all orb/PP connection". Even if we decide not to clear all connections there will be a mechanism to have it.

Another note: no promise I will work on those specific features for 5.2, maybe it'll come in 5.3 or maybe someone else will do the work.

____________________________
My website | Facebook | Twitter

TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged

File: DoorBuild.png (204.2 KB)
Downloaded 247 times.
License: Public Domain

So, I got to spend the last several hours considering this topic, since nothing better to ponder on weekdays (and I don't have access to internet during that time anyways). And I have come up with a nice little thought-experiment that has helped cement my opinions on this.

Now, I'll be covering a few things here that have already been mentioned and agreed on, and/or seem completely obvious. That's perfectly fine: I only want to cover this sort of thing so we're clear on certain foundations -- I'll be building up to stuff. I want to consider how the same setup works in various situations and what strikes me as the intuitive result of these conditions.




So, first off, our scenario. In the attached image, I've got this little 'island' with four open doors and orb in front of them, but I want it to change to the layout depicted to the right instead. But... I'm not going to be using Build commands. Instead, I've corraled a Citizen, and dumped a bunch of Build Markers into the arena. Beethro can watch. (And interfere. It's Beethro.)

Now, this is a contrived case. But it has some notable features here that are important:

* There is no guarantee in the order the building is finished.
* The player can interfere with the order.
* The new doors are built one by one instead of all at once with a single build command.

With these constraints, what we'd like to see is that the outcome, after everything new is built, is no different no matter what order things are done in. That's not necessarily a guarantee, but we'll see how things go.



Case 1

The southern orb is the only one connected to anything, and it only toggles the southern door.

Now, let's get the obvious points out of the way. What happens if an open door is built next to an existing open door with a connection? This should trivially be seen as expanding the original door by one tile, and the new door has no connections of its own. So I don't think there's any argument that this is a simple expansion of an existing door, and the orb will still work, toggling the slightly bigger door.

Okay, so what happens if we build another separate open door first, then connect that to our connected open door with another open door? (So instead of expanding the door by two tiles one at a time, we've built the 2nd tile first and then connected it with the 1st tile.) Again, there aren't any conflicts here, and we don't want the order of building to cause something different. This is an argument against an existing door with no connections being "dominant" over another door (assuming we were considering 'dominant door merging' here).

The citizen will eventually build the rest of the layout, and will connect the southern door to the rest of the unusued yellow doors. My expectation would be that the southern orb would still toggle this new door.

One final note before we move on to the next case: note the Wall built in the middle of the southern door. If that gets built early, then the door will be split into two, causing two connections. Later builds would then reconnect the door, causing double connections unless we do something about that. If it gets built late instead, then the split/double won't occur. This is another argument that something should be done about an orb connecting multiple times to the same door (if that wasn't already clear from my previous post).



Case 2

So, the things I've taken from Case 1 is that it should be trivial to expand a door, the order the door is built shouldn't matter, and doors without connections don't matter.

With Case 2, the southern orb now toggles the north, west, east and south doors on the island. The rest of the orbs continue to do nothing.

This case is considering how connections from the same orb of the same type get merged. And it's similar enough to Case 1 (especially with the Door Split point in the last paragraph) that I think it should be clear and intuitive that, again, the resulting door will be toggled once by the southern orb, so there will be only one connection remaining when everything is build/merged.



Case 3

Now we get to something a little more debatable. All four orbs are now connected to their nearest door, toggling them. What is the expected result?

Well, the orbs still don't conflict with each other: if you painted open door and connected them all in the editor, all four orbs would toggle the resulting mega-door. But it gets us thinking about "dominant door merges" here, where we consider the possibility of only one door's connections remaining.

Here's the kicker though. If "dominant door merge" depends on the position of the door, then order of building suddenly matters. Because if we accept Case 1 (doors can seamlessly merge with unconnected doors without dominance), then whichever door connects to the unconnected NW open door first wins (assuming NW has priority -- obviously if priority was given to another location, then it'd be first to that instead).

As a result, I do not find "dominance" based on door location to be safe.

There is another possibility, of course, and it's something we'll be looking at with 'connection merges' later: instead of "Most NW Door Tile", we could consider "Most NW Orb Connection Tile". The orbs are all connected to a specific tile on the door, and we can use that to break ties, and as skell noted, it's not even that difficult to break ties that way.

But the problem with that is that I, the architect, have arranged for the initial orb connection to be on the exact spot where that wall gets built on each of the four doors. And as soon as that wall is built, the connection must be moved to another tile in the door, and it always chooses the most NW spot. Once again, build order suddenly matters for the consideration of dominance.

So... again, I do not like the idea of one door overruling all others it connects to with its own connections. I am in favor of merging the connections.

With Case 3, the result I expect is that all four orbs will toggle the resulting door. There is no conflict in the orb connections themselves, and they are still clearly affecting the door they were originally connected to... just everything else as well.



Case 4

Case 4 is the same as Case 3 but with a slight twist: only the southern orb toggles its door, while the other three open their door.

There's not much to discuss on this point since the same observations exist as for Case 3, it's just that we end up with a mega-door that is toggled by the southern orb and opened by the other three. I just wanted it clear that different types of connections still seem intuitive if there's no conflict within a single orb.



Case 5

Okay, now we finally get to what this topic was about in the first place. We're ignoring all orbs but the southern one again. Now the southern orb toggles the south door, opens the west door and closes the east door. What outcome should be expected when the resulting mega-door is formed?

If the connections had all been the same type, a seamless merge as in Case 2 would be intuitive. If the connections had been to different orb, a non-conflicting merge as in Case 4 would be intuitive. As per the problems listed in my previous post, we don't want a single orb connecting multiple times to the same door. So we have three connections, and we have to choose how to reduce them down to one.

As I noted in Case 3, "orb connection location" can change, as can "most NW tile in door". As such, build order would cause differences in the result if that was used as a priority system.



So... I agree with Nuntar that the priority should be based on types rather than location, since that would guarantee that no matter how my contrived situation is built, it would result in the same connections.

As for *what* priority system to use... that is going to differ based on personal preference, I'm sure. I do not like Open or Close having different priorities though -- they feel like the same priority to me. I do agree that Toggle is more powerful than both, and should have highest priority.

But I feel that a merge of Open+Close -> Toggle is actually fine if you consider it being both connections having an effect, just on different strikes of the orb. If there were only Open connections, you'd expect the mega-door to only Open; same if it were only Close connections. If it's both, you'd expect the mega-door to open and close... which it does if you hit the orb often enough.

That said, any priority system is going to end up with the same end-result here, so this feels more like a subjective decision than the rest, so I'm not as concerned about that.



So! Perhaps this was about 80% too long, but I wanted to show my entire train of thought and why I feel tile/connection location may be a mistake. And I also definitely wanted to indicate that there are many 'simple merge' cases such that wiping all connections would feel to be far too punishing to architects. If an edge-case happens, sure, give the architect tools to rectify it... but let's give them a reasonable default before then.

Feel free to take any part of the thought-experiment and tear it to pieces ^_^

---

[Last edited by TFMurphy at 10-16-2020 07:35 PM]

mrimer
Level: Legendary Smitemaster

Rank Points: 5056
Registered: 02-04-2003
IP: Logged

TFMurphy, I read through your post carefully and think I followed everything. I can see where you're coming from on all points.

I could see prioritizing by door type. My mind has latched on to deciding how to prioritize open/close/toggle. I'll seek out real-world analogues to help me form an opinion on what to do here. I am familiar with open/close conflicts with my garage door, which toggles. When my garage door wants to both open and close at the same time, it chooses to open for safety reasons. Now, I'd expect the Rooted Empire would want to prioritize security, i.e., defaulting to closing doors when there's ambiguity in order to keep areas secure. I guess that could be considered a toggle in practice. Am I understanding this is the policy being proposed:

* Close + Open -> Toggle
* Close + Toggle -> Toggle
* Open + Toggle -> Toggle
* Open + Close + Toggle -> Toggle

That is, any mix of types results in a toggle. Is this a good experience?

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

---

[Last edited by mrimer at 10-17-2020 03:56 AM]

Dragon Fogel
Level: Smitemaster
Rank Points: 2434
Registered: 06-21-2014
IP: Logged

For my own part: door dominance makes sense to me because it's what happens in the editor. However, in the editor the preference for which door gets dominance is... I think whichever door had a connection made first? Something like that. Obviously not feasible for a player to determine. Position is really the only alternative option that's at all player-readable.

But "clear all connections" is not far off from that, and it has a degree of support in the canon.

In practice, though, I think very few players would bother trying to predict under any ruleset. They'd just wait for the building to finish and then click the door. And a puzzle that involved actually trying to manipulate the connections would probably be widely disliked no matter how it worked if it were based on obscure and unexplained default rules. On the other hand, if we reset the connections and allow scripting to change them, then the architect is clearly responsible for communicating whatever set of rules they want to use.

TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged

mrimer wrote:
I could see prioritizing by door type. My mind has latched on to deciding how to prioritize open/close/toggle. I'll seek out real-world analogues to help me form an opinion on what to do here. I am familiar with open/close conflicts with my garage door, which toggles. When my garage door wants to both open and close at the same time, it chooses to open for safety reasons. Now, I'd expect the Rooted Empire would want to prioritize security, i.e., defaulting to closing doors when there's ambiguity in order to keep areas secure. Not sure where that leaves us here, but how about this policy:

* Close + Open -> Toggle
* Close + Toggle -> Toggle
* Open + Toggle -> Toggle
* Open + Close + Toggle -> Toggle

That is, any mix of types results in a toggle. Is this a good experience?

That's exactly the same as Nuntar's (Open+Close -> Toggle, Toggle trumps rest); and yes, I have thought of that proposed system as "two different types = Toggle" as well. Two different ways that describe the same result.

If you're happy with that, then great. The alternative priority you seem to like is Toggle -> Close (for security) -> Open. I have no qualms with either of these decisions -- I think my overriding concerns was that I did not like the idea of automatically deleting all connections, and that I prefered a 'connection type' priority system over location-based, for the reasons shown in the thought-experiment.

TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged

Dragon Fogel wrote:
For my own part: door dominance makes sense to me because it's what happens in the editor. However, in the editor the preference for which door gets dominance is... I think whichever door had a connection made first? Something like that. Obviously not feasible for a player to determine. Position is really the only alternative option that's at all player-readable.

Well, "door dominance" isn't quite accurate either, because the editor allows Case 3/4 to work fine. So you don't get a "new door that uses the exact same connections as one dominant door", or any orphaned orbs.

And yes, the editor uses connection order, which I agree, should not be used as a priority system (especially since new connections can be made if a door is split). But connection location can change, so it can potentially be a volatile way of breaking ties (albeit in very rare circumstances). And I disagree that position is the only alternative that's player-readable since 'connection type' has been mentioned several times and is always readable to the player (up until we get mixed colors from multiple connections from the same orb, but that's one of the reasons we're in this topic anyways....)

Most merges are going to be simple. We don't need to wipe all connections for that. We just need a nice sensible ruleset that doesn't penalise the architect for daring to build stuff. (And any big edge-cases are going to be on their own heads, so....)

Dragon Fogel
Level: Smitemaster
Rank Points: 2434
Registered: 06-21-2014
IP: Logged

I would like to note that I do not like this option because it is a whole set of priorities to learn for a situation that will almost never come up.

If we are going to merge connections, then my preference would be for conflicting connections to be deleted. There's no prioritization or combination, the Rooted Empire just got bogged down in an argument over them and decided to set them not to do anything until a later meeting could sort the matter out. Which, of course, never happened.

Edit: wait, no, then if conflicts happen and another door is connected which doesn't have a conflict that connection becomes valid. On further reflection, I hate this, too.

I am now entirely on board with just making the doors not work any more and providing scripting so people can make something else happen if they want.

Edit again: okay, I think I have something slightly less drastic. Conflicts result in "no connection", but also "no connection" and "any connection" counts as a conflict.

So a connection will only persist if all doors involved have that connection. This does mean that a door being linked to a door without a connection will end up having no connection, but that isn't necessarily wrong - there are other systems where that sort of thing happens, and there's no inherent reason why doors can't follow such a model.

---

[Last edited by Dragon Fogel at 10-16-2020 08:42 PM]

TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged

Your latest edit would result in connections always being destroyed (since a new open door built would inherently have no connection), or destroyed based on trivial build order (if an immediate new tile was considered as an exception, but two new door tiles were built one way instead of another). (See Case 1.)

You seem to want to have a simple rule, and you also seem okay with "conflict" -> "delete". Is there a problem with that rule being "conflict" -> "toggle" instead? As I noted in my reply to mrimer, it's the same as Nuntar's suggestion just said in a different way, but stated that way is very similar to what you were suggesting before your first edit.

---

[Last edited by TFMurphy at 10-16-2020 08:49 PM : Clarification on Case 1]

skell
Level: Legendary Smitemaster

Rank Points: 3734
Registered: 12-28-2004
IP: Logged

I just love how this issue that will only ever be a thing in one hold in the next 10 years sparked more discussion than... All other bug threads combined in the last 5 years.

____________________________
My website | Facebook | Twitter

Dragon Fogel
Level: Smitemaster
Rank Points: 2434
Registered: 06-21-2014
IP: Logged

Build order would not impact the eventual suggestion other than "splitting" a door into two or more separate pieces before connecting one of those pieces, which is an impact of build order that is unavoidable no matter what the system is.

If multiple doors are connected, the set of connections that remain are the ones that apply to them all, regardless of what order the connections happen in.

But also, the plan is to add scripting to change door connections, so we're only talking about what to do with default behavior in situations where the architect decides not to use that scripting. Consequently, anything that gets decided can be overridden by an architect.

So I think it would be a mistake to add rules that are complicated to deal with on the player end. Specifically, for this to be relevant to a puzzle, the player would have to have some degree of control over which doors get combined - otherwise they can just let the combining play out and check what the final door does afterwards.

This proposed system makes it much more complicated to find a "bad door", because every connection in the system is relevant. To me, this basically sounds like a worse variant of a "hit the orbs in order" puzzle.