Project

General

Profile

Bug #2789

Potential risk of misunderstanding using the colored "owned" crosshair feature

Added by Lars Söderberg over 2 years ago. Updated 3 months ago.

Status:
Closed
Priority:
Normal
Category:
GUI
Target version:
Start date:
07/20/2015
% Done:

100%

Reproducibility:
Always
Operating system:
Other
Severity:
Normal

Description

In order for this not to be buried and forgotten in the depths of Github, I'll write this here as well.

http://i.imgur.com/yYMlYXv.jpg

In the above image I'm looking at the counter. There's nothing there to steal, but it is still marked as red. While it isn't that big a problem, to the left in the image is a "doorway" that you can open. It is also marked as red, and the player might be afraid to open it since it shows as red despite being a thing that you are allowed to interact with.

A suggested fix (which I don't know how easy it is to implement, nor if it's the best way to fix it) is to check and see if the thing you look at is also movable or a container.

Associated revisions

Revision 7c80ddc9 (diff)
Added by Andrei Kortunov 3 months ago

Owned crosshair improvements (bug #2789)

History

#1 Updated by Jiří Kuneš over 2 years ago

I will just add that doors should also have this check, because if they are owned and you try to unlock them it will be crime...

#2 Updated by Marc Zinnschlag over 2 years ago

  • Category set to GUI
  • Target version set to openmw-0.37

#3 Updated by Marc Zinnschlag about 2 years ago

  • Target version changed from openmw-0.37 to openmw-0.38

#4 Updated by axujen . almost 2 years ago

Jiří Kuneš wrote:

I will just add that doors should also have this check, because if they are owned and you try to unlock them it will be crime...

What if only owned locked doors were red?

#5 Updated by Marc Zinnschlag almost 2 years ago

  • Target version changed from openmw-0.38 to openmw-0.39

#6 Updated by Chris Robinson almost 2 years ago

Perhaps it should be tinted red if interacting with the object would be considered a crime if someone were to witness it, rather than simply being owned. IIRC, with vanilla Morrowind things can be owned by NPCs or factions, and it's legal to use/take things that are owned by a faction you belong to.

#7 Updated by Marc Zinnschlag over 1 year ago

  • Target version changed from openmw-0.39 to openmw-0.40

#8 Updated by Marc Zinnschlag over 1 year ago

  • Target version changed from openmw-0.40 to openmw-0.41

#9 Updated by Marc Zinnschlag 12 months ago

  • Target version changed from openmw-0.41 to openmw-0.42

#10 Updated by Marc Zinnschlag 7 months ago

  • Target version changed from openmw-0.42 to openmw-0.43

#11 Updated by Andrei Kortunov 7 months ago

What if only owned locked doors were red?

Good suggestion.

Also note that this bar is not the owned door, it is an owned activator.

Interaction with activators should not be marked as a red.
Only exception are beds. The bed is an activator which launch "ShowRestMenu" command on activation via attached script. I think this command itself takes care about sleeping crime.
How may we notice the difference between owned bed and owned bar BEFORE activation?

#12 Updated by Andrei Kortunov 3 months ago

A hackish fix for this bug:

const MWWorld::CellRef& cellref = item.getCellRef();
// there is no harm to use unlocked doors
if (item.getClass().isDoor() && cellref.getLockLevel() <= 0)
    return true;

// TODO: implement a better check to check if item is owned bed ()
if (item.getClass().isActivator() && item.getClass().getScript(item) != "Bed_Standard") //or use "Bed*" 
    return true;

In first check I show owned crosshair only for locked doors.
In second check I'm trying to determine if item is a bed.
Using the owned activator is not a crime itself, but if a script, attached to activator, contains something like:

if ( OnActivate == 1 )
    ShowRestMenu
endif

there will be a Trespassing crime.
Any ideas?

#13 Updated by Andrei Kortunov 3 months ago

A testing branch, if someone is interested: https://github.com/akortunov/openmw/tree/ownedcrosshair

#14 Updated by Alexei Dobrohotov 3 months ago

  • Status changed from New to In Progress
  • Assignee set to Andrei Kortunov
  • % Done changed from 0 to 50

#15 Updated by Alexei Dobrohotov 3 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100

Also available in: Atom PDF