Confusing: Marked area of landmarks can overlap
stefandollase opened this issue ยท 11 comments
The Syntax
I will use the following syntax to describe a configuration of landmarks:
Lower Layer
1 2
3 -
Upper Layer
4 -
- -
These layers are stacked directly above each other, so when I right-click landmark 1
, I get a cuboid which consists of all four landmarks.
The Issue
Now, lets assume a user fails to understand how landmarks work and places more landmarks than necessary, like so:
Lower Layer
1 2
3 -
Upper Layer
4 5
- -
Next, the user right-clicks landmark 4
, which results in a rectangle, consisting of the landmarks 1
, 2
, 4
and 5
. This is certainly not what was intended by the user. He wanted the cuboid. Thus, he right-clicks other landmarks. Eventually, the cuboid is displayed and the user is happy. He places the Filler and he expects it to use the cuboid. However, this is not always the case, because there actually exist several marked areas, because he right-clicked multiple landmarks. The Filler might use the cuboid, but it might also use any of the other marked areas, e.g. the rectangle consisting only of the landmarks 1
, 2
, 4
and 5
. This means the Filler will only handle one wall of the intended area.
How to fix it
Here are several suggestions that should help to prevent the issue in the future:
- Allow each landmark to only be part of one marked area. This prevents overlapping marked areas.
- If an area is marked that is not a cuboid, then for each corner of the marked area check whether there exists a perpendicular landmark which can extend the marked area. A line becomes a rectangle, a rectangle becomes a cuboid. Of course, this check should only be done when the user right-clicks a landmark.
- Allow the user to extend an already marked area. In the example above, one issue was that the cuboid and the rectangle exist both at the same time. This can be solved by replacing the rectangle with the cuboid.
i think the better solution here is better documentation and getting the guide/wiki running
the markers can't be part of multiple marked area's but you need to place the filler on the one that made the area, the one who has LOS to the other corner makers defining said area. If you setup like in your first configuration and place the filler on another marker then the one you clicked on it won't work (unless that changed again)
In my 1.10 port I have already rewritten the way that landmarks work, and the first of your suggestions has been implemented.
The second suggestion might help, however it might be confusing as the current behaviour is only to check the landmark that was clicked.
The third suggestion sounds like what's meant to already happen, but doesn't sometimes as it might bug out or some markers might not be correctly joined up - although the new system should stop that from happening.
The new behaviour (if a player placed down 5 markers in the second configuration) is that markers 1, 4 and 5 would be connected together into a rectangle (note that 2 is not connected, although it looks visibly like it is), and then right clicking on either 1 or 3 would connect 3 to the rectangle and produce a cuboid made of 1, 3, 4 and 5. 2 would not be connected to any of them.
@stefandollase most users indeed won't read it in advance but once they bump into something like that and get confused that documentation can help them figure out what they where doing wrong
@AEnterprise
You might be right, however I prefer working and user friendly software instead of software with well documented bugs :-P
@stefandollase https://github.com/stefandollase you started the issue
stating that is the user who "fails to understand how landmarks work".
Then, it's not a bug of the game per se, it's an error cause by not
understanding how a mechanic is suppoused to work.
2016-07-30 5:45 GMT-03:00 Stefan Dollase [email protected]:
@AEnterprise https://github.com/AEnterprise
You might be right, however I prefer working and user friendly software
instead of software with well documented bugs :-Pโ
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3403 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH-ja4Ica3ia4EqDvE4BTljvnSoYOod8ks5qaw8sgaJpZM4JYOZn
.
@zenieldanaku
The point of this issue is to describe how the current behaviour is unintuitive for the user and to discuss how this can be changed.
- A user does not associate a marked area with the landmark that was right-clicked. The user associates a marked area with all landmarks that he placed to mark that area. This includes the right-clicked landmark as well as all other landmarks on the corners of the marked area (up to 8 landmarks in total).
- Especially, the user does not distinguish between landmarks that are part of the marked area and landmarks that only look like they are part of the marked area, because they happen to be placed on one of the corners.
- Also, the user does not understand that there might be multiple marked areas even tough he only sees one of them (e.g. there is a rectangle and a cuboid, but he only sees the cuboid).
I think that this should be considered a bug for the following reason: Even tough the program works as intended by the programmer, the intended behaviour is hard to understand for the user. Here, the bug is not that the implementation is different from what the programmer wanted to implement, but the intended behaviour is different from how the user expects it to work. The solution to such a bug is not to explain the user that his expectations are wrong, but the solution is to change the implementation to match the users expectation.
I think it should not matter where the Filler is placed. Any of the corners of the marked area should be fine. Also, placing the Filler should not only pop of the landmarks that are part of the marked area, but it should pop of every landmark that is placed at any of the corners of the marked area.
I reopen this, because there still seems to be interest in the topic.
let me just say this: there is NO bug present here, the real issue is that it isn't very obvious on how to use them, that's a big difference
@AEnterprise
I think I made my point very clear. Let's clarify your point of view without further discussing the minor point whether this is a bug or not, because this really only depends on our (maybe different) interpretations of the word:
- Do you think the current behaviour is intuitive?
- Do you think the current behaviour should be changed to be more intuitive? Why (not)?
@AEnterprise
I agree that good documentation is a great thing, however I don't think this issue can be solved by it. Most of the users won't read it.
@AlexIIL
It is great to hear that someone already thought about this and fixed it. I am not familiar with the modding tools, so I cannot test your implementation to provide feedback. However, I will be happy to try it whenever it is available in a mod-pack :-P
It's been quite a while, but hopefully this is fully fixed in ef1dcc2 for 7.99.19-pre6